Using Drupal Commerce for node subscription - part I: the requirements and existing modules
Drupal Commerce is the de-facto eCommerce solution for Drupal 7. Being so, it already has many different contributed modules that enhance its capabilities and make it much stronger, fit to answer any possible scenario.
Well, unless you want something a bit different...
I will describe the requirements I had:
-
Each user can create/update a node without any payment.
The node can be published or not, but there can be other fields that describes different situations accordingly this node would be part of a view results or not.Specifically, there is a "mobile expiration date", which defines till when this node would be part of the view that is being sent to mobile devices via Services.
- Each user can pay for the node to be part of the mobile content, so by buying a product that refer to this node, the "mobile expiration date" would be updated.
- Payment should be a subscription, not a one-time payment, and in this case it was defined that using the Paypal subscription mechanism is an appropriate payment solution.
- As being a subscription-based mechanism, the site should handle re-payments, payment failures and cancelations.
Each of those requirements do have some kind of a solution is existing modules, which I will describe, with their mismatches to the requirements:
-
Pay for a node - the module Node checkout seems to do exactly that:
"Admin can associate a node type with a product.
When users create nodes of that type the product gets added to their cart and they are redirected to checkout.
When they complete checkout their node is published"
Trying to work with this module, we found out couple of mismatches:
- Multiple products - while not in the original requirements, it was clear that several different subscription options should be possible to a node. For example - "per month" vs "per week" subscription. When using "node checkout" you can define multiple products to be added, but all of them would be added together, and there is no way to differ between those products.
- Publishing - the module fits when all you need to do is either publish an unpublished node, using the standard "publish" option. When you want to do another task, maybe a more complicated one - it is impossible.
-
Recurring payments - handling recurring payments in any eCommerce system is problematic, since you suppose to keep the payment credentials on the site somehow. This is why 3rd party services works to handle these tasks for you, and making your development much easier.
Looking at this post on drupalcommerce.org, it is clear that while it is a needed requirement, there is no big success in it. We decided to use Paypal as the recurring payment service, especially since lots of its API is known, stable and work with Drupal (>6K Drupal Commerce sites already work with Paypal, according to statistics), and because its service is known for many users.
Looking into existing modules to handle recurring payments, we found out several modules:
- Commerce Recurring Framework seems to have all the right building blocks, and since we already know more of Lee's work (and specifically, he is also the developer of the Node checkout module...), it seems promising. Unfortunately, the module is what it is - a framework, which still has only small amount of sites using it, and seems to need more work in order to make it work as we needed. In addition, once we decided to work only with Paypal, lots of the things this framework can give us seems not needed.
- Subscriptions - it seems that while the recurring payments is not a strong feature, the subscription mechanism is something that seems strong with all of the different modules - Subscriptions / Subs / Commerce subscription / Commerce subscription products / (and especially) Commerce subscription products PayPal. Unfortunately, for our use case all of those modules does not help, since they focus on subscribing a user to a node/product/role/content type, and not subscribing the node itself. None of those modules has their building blocks generic enough to be re-used in different use cases.
While we failed to find a solution out-of-the-box, we learn a lot from those modules, their approaches, and their code, and used this in order to build our solution, which will be described in next posts.
Part II: creating the orderPart III: Paypal subscription and recurring payments
Ralates to: Drupal Planet