Drupal is a great platform for commerce. For simple tasks it’s very easy to get started with the Commerce Kickstart distribution, but there’s no consensus on what to use for more complex features. This means you might need to perform a long research to be able to choose a solution for more complex e-commerce tasks.

In a recent project we needed a solution for recurring payments, so I thought I’d share the results of our research.

Recurring payments

When your customers pay for your service or product periodically, you need recurring payments. Subscriptions are a good example.

For recurring payments you need to handle the following:

  • Credit card data
  • Subscription management (subscribing, cancelling, upgrading, downgrading)
  • Refunds
  • Dunning
  • Discounts and coupons
  • Account management
  • Invoice emails
  • Billing

Solutions for Drupal 7

We considered three different approaches when researching recurrent payment solutions. The first 2 only use Drupal modules, and the third one uses a recurring payment service like Recurly or Chargify.

Commerce Recurring Framework

The Commerce Recurring Framework (only dev! 2.x branch is mostly the work of pcambra creates a Recurring entity that stores information on the order, the recurring period, the recurring price, the end date and optionally the trial period and price. Each time a recurring payment is made, a new order is created in the background. Your usual product pricing rules nicely apply to this order.

Using additional commerce modules like Commerce Dunning, Commerce Discount, Commerce Coupon, Commerce Card on File, Commerce Billy and Commerce Return Merchandise Authorization you can get a basic grip on almost all the points from the wishlist above.

Commerce License

Commerce License (mostly written by bojanz from Commerce Guys) is shipped with a License entity. The License entity itself has nothing to do with recurring payments. “The License entity is usually created during order checkout, that holds information about accessing the purchased resource, and it has a status and an optional expiration date”.

It is the Commerce License Billing module that makes recurring billing possible for licenses.

The Commerce License framework is very flexible and it is the recommended way now to do recurring payments with Drupal Commerce. The downside is that you will probably need to code your own License plugin. Currently I could find 2 license plugins on drupal.org: one for user roles (included in Commerce License) and Commerce License OG (now dev). EDIT: dwkitchen drew my attention to one more plugin: Commerce License Node.

There is a difference between the approach of Commerce Recurring Framework and Commerce License:

  • Commerce Recurring Framework handles recurring payments, nothing more.
  • Commerce License takes a step back and asks the question: what are recurring payments usually used for? To gain expirable access to a resource. So it strives to create a general framework for managing data related to expiring access.

Chargify and Recurly

Third party services let you outsource the commerce component of your site, so that you don't have to do the theming and maintenance for it. It is a way to deliver commerce functionality at a much lower upfront investment cost, especially if you don't do a deep commerce integration. It does however come with a price: as monthly subscription cost and in terms of ownership. If anything happens with the 3rd party service (in case it would go out of business or change strategy so that it is no longer a good business fit), you might lose data or have to do a complex import scenario. So I think it makes most sense to use a 3rd party service when you are investigating new products where you need to get up and running fast, and need to learn from expedited customer interaction.

From a Drupal perspective the issue with Chargify and Recurly is that they do not have a Drupal Commerce integration.

  • The Recurly module integrates nicely into Drupal (not Drupal Commerce!) including push notifications from Recurly.com. It also includes built-in pages for users to view invoices, subscriptions, and to upgrade/downgrade their subscription level. It supports Recurly.js which allows you to get rid of the PCI-compliance headache.
  • The Chargify API does much less: it’s just a wrapper for the Chargify php library.

The two services work similarly. You can set up a “Buy” button really fast by just embedding some code on your page. This button redirects you to the service’s so-called “Hosted page” where customers can buy the product. Credit card data, subscription management, dunning, notification emails, refunds, discounts can be easily handled on the merchant’s Chargify/Recurly account. This way however you will miss:

  • Drupal Commerce goodies like:
    • Cart: Customers will only be able to buy stuff one by one.
    • Order, product, discount management: Neither customers nor admins can view orders on the Drupal site. You’ll have to sync your products and discounts on your Drupal site (for display) with those on the service site (for actually paying for them).
  • Proper user account management: Each time you use the Chargify Hosted pages a new Chargify user account gets created which is not the desired behavior for returning customers. Creating two user accounts with the same email is also possible in Recurly. To get around this you will need to use the API.
  • Advanced subscription management: With Chargify customers do not have one page to handle all their subscriptions. Instead, they get a separate link in email for each subscription.
  • Flexibility in general: For example, you cannot fully customize the dunning process in Recurly.

Both services have an excellent API. Using the API can get you most of the above features (like Drupal Commerce goodies). Webhooks enable Drupal to react on events on the service side. But you will lose the benefit of not needing to maintain your code.

3rd party payments services usually have a monthly fee. The simplest package in Chargify costs $65/month, in Recurly $99/month. In addition there is a per transaction and revenue cost.

Conclusion

Opt for the Commerce Recurring Framework, if you

  • only want to handle recurring payments, nothing more
  • want to do that fast
  • need the flexibility of Drupal Commerce
  • don’t want to code
  • have a developer team that can handle the risks of a dev module

We went with this in our project that sparked the research.

Choose Commerce License, if you

  • are more picky about module stability
  • still want to do it your own way with Drupal Commerce
  • are willing to do some coding

It seems there is a preference in the community to use Commerce License for recurring payments.

You should definitely use Recurly or Chargify if you

  • want reliability and maintenance of recurring payment functionality to be somebody else's headache
  • are not scared by the monthly fee
  • need something working fast without Drupal Commerce or you can invest in custom development for its integration

Additional resources

About the author

András Czövek

Senior Developer, Drupal Architect

András is a Drupal Architect at Pronovix.