With the Commerce Recurring module, any Drupal Commerce website can create recurring orders that users can manage directly in Drupal. This is useful for donations, subscriptions, and memberships, especially for selling access to content. We created the module well before payment gateways like Stripe had robust recurring solutions in place with full webhook support.

However, the market has now evolved, partly because of the SaaS explosion. If you’re looking for a solution to recurring payments, you have many options to implement them reliably beyond Commerce Recurring.

While before we would always lean toward using a native Drupal solution for recurring billing, now the answer is more nuanced. How should you implement recurring payments in Drupal Commerce?

Start by ruling out what you don't need

Before diving into frameworks and modules, it's worth asking whether you actually need Drupal Commerce at all for your subscription use case.

If your requirements are straightforward, like selling access to a user role that unlocks gated content, you could implement that with nothing more than Stripe Checkout and a webhook listener. A customer hits Stripe's hosted checkout page, subscribes, and your Drupal site receives a webhook notification. You grant the role. When Stripe tells you the subscription was canceled or a payment failed, you revoke it. No shopping cart, no checkout flow, no Commerce module required.

Some use cases genuinely are that simple, and adding unnecessary complexity doesn't serve anyone.

Why you still may want Drupal Commerce in the picture

Drupal Commerce gives you a full cart model, a checkout flow that can be enriched with other integrations — your tax library, your address book, whatever else your application requires, and a complete order history. Once you need any of those things, running everything through a payment gateway's API and reacting to webhooks starts to get complicated fast.

Here are some of the scenarios where Commerce earns its place:

• Multiple subscriptions or mixed carts. We built a donation platform for a major research university where alumni could create a donation cart, picking multiple funds on either a one-time or recurring basis, and then manage that as a shopping cart with full order history. That level of integration into the application will significantly increase your API requests if you try to build it on top of a payment gateway alone.
• Abandoned cart visibility. If you're only recognizing completed subscriptions through webhooks, you lose insight into everyone who started the process but didn't convert. With Commerce, you have abandoned cart data and can easily remarket to those noncommittal shoppers.
• Enriched subscription data. The Commerce Recurring framework is centered around subscription entities, which are fieldable entities just like anything else in the Drupal data model. Customize them with additional fields and data points tailored to your business. Compare that to a subscription object tucked away in a payment gateway's dashboard, where your only option for custom data might be anonymous metadata fields.
• Non-standard billing workflows. Not every subscription fits the mold of "charge a card on the first of every month, and if it fails, cancel." We have a utility client using Commerce Recurring where subscriptions are not cancelled immediately. After all the dunning emails have gone out, the account goes into a customer service queue rather than getting shut off. In another case, an enterprise client sells high-dollar subscriptions but invoices customers by check. No automated billing at all.

What the Commerce Recurring framework actually does

With Commerce Recurring, you create a billing schedule and choose whether it's prepaid or postpaid, whether it renews on a rolling interval from the subscription date or on a fixed date each month, and whether initial charges are prorated. Then you enable recurring billing on a product variation type, and any purchase of that product creates a subscription entity tied to the customer.

The framework uses Advanced Queue to process renewals, which means if your server goes down or cron gets delayed, charges don't get lost. If you’re worried about managing billing within your own application, afraid a payment might be lost because of a server hiccup, it won’t be. It’s as reliable as your Drupal website.

Where Commerce Recurring falls short today

While Commerce Recurring has been in use on production sites for years, it hasn't yet had a full, stable release, and there are real gaps we plan on addressing.

• User interfaces. The customer-facing experience is rudimentary. Right now, we don't show customers their next payment date, how much it will be, or which card will be charged by default. We usually end up building a custom representation on our client sites.
• Plan changes aren't turnkey. Commerce Recurring has an API for scheduling changes to a subscription (switching rate plans, for instance), but out of the box, that system is only used for scheduling cancellations at the end of a billing period. There's no user interface for a customer to upgrade or downgrade their plan. If prorated plan changes are critical to your business, a gateway like Stripe offers that out of the box.
• Dunning is basic. The module has an API for scheduling and delivering dunning emails when payments fail, but it's still rudimentary. You don't get open-rate analytics or browser-based email template management. Platforms like Stripe or Recurly offer more robust implementations.
• Language and labeling need polish. Some of the terminology in the UI is developer-centric rather than merchant-friendly. For example, a customer probably isn't going to think of their subscription as a "recurring order." These are the kinds of things that need attention before a stable release.

What's on the roadmap

We have a long list of UX and feature improvements planned for the module before a full stable release, but the high-level goals are:

• A proper subscription tab on the user account page showing active subscriptions, next payment date, payment amount, current payment method, and a prompt to update the method if it's expiring before the next charge
• Better integration with the Commerce Email module for browser-based dunning email templates
• An activity stream on the subscription page similar to the order page
• Improved admin forms that are more defensive against accidental misconfiguration
• Cleaner language and labeling throughout

The timeline is still being determined, but the direction is clear: if you're using Commerce Recurring, we want it to be fully integrated into everything the Drupal Commerce ecosystem provides, not a module that requires heavy customization just to meet baseline expectations.

A hybrid approach

You don't have to choose entirely between the Commerce Recurring framework and a gateway-managed solution. We've paired Commerce Recurring's subscription entities with Stripe-managed subscriptions on client projects. The subscription entity in Drupal is the system of record, but the actual payment processing is decoupled from Drupal's cron. Stripe handles the billing cycle and sends a webhook. Drupal responds to that webhook to update the subscription status.

For the right use case, this implementation gives you the best of both worlds. Rich, fieldable subscription data model within Drupal, combined with the reliability and tooling of Stripe's billing infrastructure.

Remember, it’s a framework that helps you build your solution.

So how do you decide?

It comes down to one core question: how much do you need to customize the lifecycle of a subscription?

Lean toward a gateway-managed approach if:

• Your subscription model is straightforward. Subscribe, bill, cancel.
• You value the existing UI that gateways offer for plan management and payment method updates.
• Prorated upgrades and downgrades are important to your business.
• You want sophisticated dunning workflows and analytics out of the box.
• You don't need to deeply integrate subscription data with other entities in your Drupal site.

Lean toward Commerce Recurring if:

• You need to own the subscription data model and enrich it with custom fields.
• Your billing workflows are non-standard. Manual invoicing, delayed cancellation, complex dunning rules.
• You want subscription management integrated into a full shopping cart and checkout experience.
• You need to combine subscriptions with one-time purchases in a single cart.
• Your subscription workflow needs to interact with other Drupal entities, like licenses that grant and revoke user roles.
• You want abandoned cart visibility for incomplete subscription signups.

And if you're somewhere in between, the hybrid approach is legitimate and well-tested, especially if you have the development skills and/or staff.

Don’t underestimate an open source community

This article came about partly because of a question posed to the Drupal community in Slack. Within hours, multiple people who run Commerce Recurring in production weighed in with specific, actionable guidance — from memory management tips for high-volume renewal processing to honest assessments of where custom code is still necessary.

Drupal Commerce has a community of over 2,000 developers who are ready to share their experience at the drop of a hat. When you're evaluating a platform for something as critical as recurring billing, having access to that kind of peer expertise is valuable. You’re not relegated to a labyrinth of vendor documentation. You can get real-world battle stories and genuine experience.

And if you're weighing your options for recurring payments and want to talk through what makes sense for your specific situation, reach out to us.