Subscriptions and Recurring Payments in WooCommerce

Three things have to line up, and a gap in any one of them stops the whole thing.

• A subscriptions plugin, which manages the products, the schedule, the subscription records and the renewal orders.
• A payment gateway that supports recurring charges — specifically, one whose WooCommerce integration supports tokenised repeat billing rather than only one-off payments.
• A reliable scheduler, because renewals are triggered by scheduled tasks. On a site where wp-cron only fires when someone visits, a low-traffic day means renewals don't process.
• That last point catches people. Move scheduled tasks to a real server cron before launching subscriptions, not after the first missed billing run.

Recurring card payments in India operate under RBI rules that are stricter than in many markets, and they change periodically. The practical requirements have been:

• A mandate (an e-mandate or standing instruction) registered by the customer, with a maximum amount, rather than an open-ended authorisation.
• Pre-debit notification to the customer before each charge, a set period in advance.
• Additional factor authentication for the initial mandate, and for charges above a threshold.
• This is implemented by your gateway, not by you — which makes gateway choice the single most important decision for an Indian subscription business. Confirm the gateway's WooCommerce integration handles mandates end to end before committing.
• UPI Autopay is worth asking about specifically, since many Indian customers prefer it to card mandates.

A renewal creates a new order and attempts payment against the stored token. Plenty can interrupt that.

• The card expired, was replaced, or was reported lost.
• Insufficient funds, which is temporary and worth retrying.
• The mandate was cancelled by the customer at their bank, which you may not learn about directly.
• The gateway had an outage at exactly the moment your scheduler fired.
• The product no longer exists, or its price changed in a way the subscription doesn't handle.
• Each of those needs a different response, and the difference between a temporary and a permanent failure is the distinction that matters.

Dunning is the process of recovering a failed payment, and it's where subscription revenue is actually lost or saved. Plan it before launch.

• Retry temporary failures on a schedule — a few attempts over a week or two, spaced out rather than hammering.
• Don't retry permanent failures. A cancelled mandate will fail identically forever.
• Email the customer at each stage, with a direct link to update their payment method. Most recoveries come from this, not from the retry itself.
• Decide what happens to access during the retry window: suspended immediately, or a grace period? A grace period recovers more customers and costs you the service in the meantime.
• Set a clear end point, after which the subscription is cancelled and the customer is told.
• Track the recovery rate. If it's low, the emails are usually the problem rather than the retry schedule.

Customers upgrade, downgrade, pause and change payment methods, and each needs a decision made in advance rather than improvised when the first request arrives.

Upgrades usually want proration — charge the difference now and move the renewal date, or charge the full new amount at the next renewal. Both are defensible; pick one and put it in your terms.

Pausing is popular with customers and complicated in practice: does the renewal date shift, does access stop, is there a maximum pause length? Decide, or you'll answer differently each time.

Price changes on existing subscriptions are the sensitive one. Existing subscribers on an old price is normal and usually the right call; migrating them needs notice and, depending on the mandate terms, may need re-authorisation.

• Someone has to watch failed renewals and act on the ones that need a human.
• Refunds on subscription orders are more involved than one-off refunds — partial periods, and whether access is revoked.
• Customers will email asking to cancel rather than using the account page. Make self-service cancellation genuinely easy; hiding it produces chargebacks, which are worse.
• Reporting: churn, lifetime value and recovery rate are the numbers that matter, and WooCommerce's default reports don't show them.
• Reconciliation between gateway settlements and WooCommerce orders, which diverge more often than you'd like.

• A complete signup with mandate registration, on a real phone.
• A renewal, by manually triggering the scheduled task rather than waiting a month.
• A failed renewal, and the full dunning sequence including the emails.
• A customer updating their payment method mid-subscription.
• A cancellation, and confirmation that access ends when it should.
• A refund, and what happens to the subscription afterwards.
• The whole flow again after every plugin and gateway update — subscriptions break in ways that only show up a month later.

If subscriptions are the whole business rather than one product line, a dedicated subscription billing platform handles dunning, proration, tax and reporting far better than a WooCommerce plugin will, and integrates with WooCommerce for the storefront.

For a simple case — a membership renewed annually, or a small number of subscribers — the WooCommerce route is entirely reasonable and much cheaper.

The deciding question is whether billing complexity is core to your business. If it is, don't build it on a plugin. If it's incidental, a plugin is fine.