In short
- Core WooCommerce cannot do recurring billing. It is a one-time checkout engine. Subscriptions require a plugin that owns a schedule, plus a gateway that can charge a saved card without the customer present.
- Most churn is involuntary. Expired cards, insufficient funds and failed authentication kill renewals that the customer never intended to cancel. Recovery depends entirely on retry logic and dunning email.
- The gateway decides what is possible. If it cannot store a network token and charge off session, no plugin can rescue the renewal. Check gateway capability before you pick the subscription plugin.
- Action Scheduler is the silent failure point. Renewals fire from WordPress cron. On a poorly hosted store the queue backs up, renewals run late or not at all, and nobody notices for weeks.
- Reporting is the gap nobody budgets for. Woo gives you order totals, not monthly recurring revenue, cohort retention or a churn rate you can act on. Expect to build or buy that layer separately.
Recurring revenue is the most attractive business model in e-commerce and the most operationally unforgiving. A one-time store fails loudly: checkout breaks, orders stop, you find out within the hour. A subscription store fails quietly. Renewals decline in the background, the retry queue gives up, and three months later the MRR line has a slope nobody can explain.
WooCommerce makes this harder than hosted platforms do, because the stack is assembled rather than bought. That assembly is also the reason merchants choose it: you own the data, the schedule and the dunning copy. This piece walks through how recurring billing actually works on Woo, which pieces are doing which job, and where the failures cluster.
How recurring billing works on WooCommerce
Out of the box, WooCommerce is a transaction engine. A customer adds a product, checks out once, and a gateway captures one payment. There is no concept of a billing period, a renewal, or a saved payment instrument that can be charged later. Everything described in this article is added by extensions sitting on top of that core.
Recurring billing on Woo is three separate systems pretending to be one feature. Understanding which system owns which job is the difference between debugging a renewal in ten minutes and guessing for a week. If you are still choosing your stack, the trade-offs in our guide to how to choose the right e-commerce platform for your store apply with extra force once subscriptions enter the picture, because platform switching costs rise sharply when you are carrying live billing agreements.
The three moving parts
The subscription plugin owns the contract. It records that customer 4,812 pays $29 every month starting 14 March, tracks the next payment date, and decides what status the subscription is in (active, on hold, cancelled, expired, pending cancellation).
The scheduler owns time. When the next payment date arrives, something has to wake up and say “charge this now”. On Woo that something is Action Scheduler, a background job queue that piggybacks on WordPress cron.
The gateway owns money and the stored credential. It holds the tokenized card, performs the charge when asked, and returns either a success, a soft decline (retry might work) or a hard decline (retry will never work). The plugin cannot create a payment method it was never given permission to reuse.
What happens on a renewal, step by step
A renewal is not a customer action. It is a server-side event that produces a brand new order. The plugin creates a renewal order linked to the parent subscription, then asks the gateway to charge the stored token for that order total.
On success, the renewal order is marked complete or processing, the subscription’s next payment date advances by one billing period, and the customer gets an order confirmation. On failure, the renewal order goes to failed, the subscription usually goes on hold, and the retry sequence begins if one is configured.
That distinction matters for reporting. Every renewal is a separate order in the database, which is why subscription stores accumulate order rows far faster than their customer count suggests, and why database performance becomes a live concern earlier than on a one-time store.
Why Action Scheduler deserves your attention
WordPress cron is not real cron. It fires when someone loads a page, which means a low-traffic store can go hours without triggering the queue. Action Scheduler mitigates this by batching jobs, but it still depends on something poking the site.
When the queue backs up, renewals process late. Late renewals mean the billing date drifts, customers get charged on inconsistent days, and the failed-renewal retry schedule compresses or stretches unpredictably. The standard fix is to disable WordPress pseudo-cron and run a real system cron job hitting wp-cron.php at a fixed interval, which is a hosting decision rather than a plugin setting. We cover the server side of this in detail in hosting WooCommerce properly, and subscription stores are precisely the case where cheap shared hosting stops being a false economy and becomes a revenue leak.
| Layer | What it owns | Typical failure | Where you debug it |
|---|---|---|---|
| Subscription plugin | Billing contract, status, next payment date, proration rules | Wrong status transition, orphaned subscription after a refund | Subscription edit screen, order notes |
| Action Scheduler | Firing the renewal at the right time | Queue backlog, actions stuck in pending for days | Tools then Scheduled Actions |
| Payment gateway | Stored token, the actual charge, decline codes | Token not saved, off-session charge rejected, authentication required | Gateway dashboard plus Woo logs |
| Email layer | Renewal receipts, failure notices, dunning sequence | Mail silently not delivered, so recovery never happens | Transactional mail provider logs |
Plugin options and what they actually handle
There is no neutral way to say this: the official WooCommerce Subscriptions extension is the default for a reason, and the alternatives are mostly chosen on price or on a specific feature the official plugin handles awkwardly. What varies between them is less the happy path and more the edge cases.
Every plugin in this space can create a product that bills monthly. The differences show up in variable subscriptions, mixed carts containing both one-time and recurring items, synchronized renewal dates, free trials with a deferred first charge, and how cleanly the plugin hands control to the gateway.
Questions that separate the options
Ask whether the plugin supports variable subscriptions, meaning one product with monthly and annual options at different prices. Many stores discover this requirement after launch, and retrofitting it means rebuilding the catalog.
Ask how it handles a mixed cart. If a customer buys a subscription box and a one-time gift card in the same order, some plugins split the order, some refuse, and some create a recurring charge that incorrectly includes the gift card.
Ask whether it supports date synchronization, so that everyone bills on the 1st rather than on their individual signup anniversary. This is standard for membership and media businesses and it materially simplifies dunning, because your failed-payment volume arrives in a predictable wave rather than smeared across the month.
Ask what happens on manual renewal. If the gateway cannot charge automatically, does the plugin email an invoice with a pay link, or does the subscription simply expire? For merchants on gateways without token support, manual renewal is the whole product.
| Option | Licensing model | Strongest at | Watch out for |
|---|---|---|---|
| WooCommerce Subscriptions (official) | Annual commercial license | Broadest gateway support, variable subscriptions, proration, synchronized dates | Cost at small scale; reporting is thin |
| WooPayments built-in subscriptions | Included with the gateway | Zero extra license cost for simple monthly or annual plans | Tied to one gateway; fewer advanced billing rules |
| YITH WooCommerce Subscription | Annual commercial license, lower price point | Budget-conscious simple recurring products | Narrower gateway compatibility; fewer proration controls |
| SUMO Subscriptions | One-time marketplace purchase | Flexible billing schedules, pause and resume flows | Support cadence and compatibility testing are on you |
| Memberships layered on subscriptions | Separate add-on | Gating content or pricing by plan tier | Two plugins means two sources of truth for access |
Compatibility is the real selection criterion, not the feature list. Your subscription plugin has to coexist with your gateway, your tax plugin, your checkout customizations and increasingly with High Performance Order Storage. We looked at that migration separately, and the short version is that subscription stores carry the most risk in it because they have the highest order volume per customer. Woo remains a credible choice for this workload, as we argued in WooCommerce in 2026 is still a serious option for SMB stores, but the plugin surface area is the cost you pay for that flexibility. Merchants weighing the alternative should read WooCommerce versus Shopify for stores under one million revenue, where recurring billing is one of the clearest dividing lines between the two.
Gateway support for tokens and off session charges
This is the section that should drive your stack decision, and it is usually the last one merchants read. A renewal is a payment made without the cardholder present. In card-network language that is a merchant-initiated transaction against a stored credential, and not every gateway integration on Woo supports it.
Two capabilities matter. The gateway must be able to store the credential in a reusable form, ideally as a network token rather than a raw card reference. It must then be able to charge off session, flagging the transaction correctly so issuers understand it is a recurring charge the customer previously agreed to.
Why network tokens change the economics
A network token is a card number substitute issued by the card network rather than by your gateway. When a customer’s physical card expires or is reissued after fraud, the token can be updated automatically behind the scenes, so the renewal still works.
That single mechanism removes a large share of involuntary churn, because expired cards are one of the most common renewal failure causes in any subscription book. The feature is sold under different names by different providers, usually as account updater or card lifecycle management, and it is worth asking your gateway directly whether it is already enabled on your account rather than assuming it is.
Reading the decline, not just the failure
Gateways return structured decline reasons, and treating them all as “payment failed” is the most expensive mistake in subscription operations. Soft declines (insufficient funds, issuer unavailable, velocity limit) frequently succeed on a later attempt. Hard declines (card reported stolen, account closed, do not honor with a hard flag) will not succeed no matter how many times you retry.
Retrying a hard decline does nothing except accumulate gateway fees and raise your decline ratio, which some acquirers monitor. Retrying a soft decline at the right interval is where recovered revenue comes from. A dunning configuration that does not branch on decline type is leaving money on the table in both directions.
| Gateway | Stores reusable token | Off-session renewals | Handles SCA step-up on renewal | Practical note |
|---|---|---|---|---|
| Stripe / WooPayments | Yes, network tokens supported | Yes | Yes, with authentication request emails | The reference integration for Woo subscriptions |
| PayPal (reference transactions or subscriptions API) | Yes, as a billing agreement | Yes | Handled by PayPal’s own flow | Reference transactions may need to be enabled on the account |
| Braintree | Yes | Yes | Yes, via 3-D Secure 2 | Strong vaulting; configuration is heavier |
| Authorize.Net | Yes, via Customer Information Manager | Yes | Limited outside the US | Common in North America, weaker for EU rules |
| Square | Yes, card on file | Yes, in supported regions | Region dependent | Good fit when the store also runs physical POS |
| Bank transfer, cheque, cash on delivery | No | No | Not applicable | Manual renewal invoices only |
Capabilities and regional availability for every provider above change on their own release schedules, so treat the table as a starting map and confirm current support in the gateway’s own documentation before you commit. For a wider view of the options available to US merchants specifically, see our rundown of the best WooCommerce payment gateways for US merchants.
Failed renewals, retries and dunning emails
Here is the number that reframes the whole category: a meaningful share of subscription cancellations are not cancellations at all. The customer still wants the product. The card simply did not go through, and the merchant never recovered the payment.
Industry estimates for the involuntary share of total churn vary widely by sector, average order value and card mix, so treat any single published figure with caution and measure your own. What does not vary is the direction: a store that does nothing about failed renewals loses customers it had already won.
Designing a retry schedule
The default retry rules in most plugins are reasonable but generic. A better schedule reflects when money arrives in your customers’ accounts. Retrying an insufficient-funds decline on day 1 and day 2 is largely wasted; retrying around a typical payday, or simply spacing attempts across 3–5 days, converts better.
Four to five attempts spread over roughly two weeks is a common shape. Beyond that, additional attempts rarely recover anything and start to look like pressure. Set a definite end state: after the last attempt, either cancel or move the subscription to a pending-cancellation status that preserves the record for a win-back campaign.
Dunning email is a copywriting problem
The retry sequence recovers payments the issuer was always going to approve. Dunning email recovers the rest, and it only works if the customer reads it and acts. That makes it a conversion surface, not a system notification.
Three things reliably improve recovery. Say what will happen and when (“we will try again on Tuesday, and your access continues until then”), rather than only reporting the failure. Put a one-click update-payment-method link in the email, going straight to a pre-authenticated page rather than to a login screen. Send from a monitored address so replies reach a human, because a portion of recipients will reply instead of clicking.
Verify that the mail is actually arriving
Transactional email from WordPress is unreliable by default, since PHP mail from a shared host lands in spam or is dropped outright. A subscription store that sends dunning email through wp_mail without an authenticated SMTP or API provider is running its recovery process blind.
Check deliverability as a billing metric, not an IT detail. Open rates on failed-payment emails should be high, because the subject line is genuinely urgent. If they are not, the problem is delivery rather than copy.
| Decline reason | Class | Retry worth it? | Best next action |
|---|---|---|---|
| Insufficient funds | Soft | Yes, space attempts over several days | Retry plus a short email offering a date change |
| Expired card | Soft but permanent without new data | Only if account updater is active | Ask for a new card; enable network tokens |
| Authentication required | Soft, customer action needed | No, retrying alone will fail | Send the authentication link immediately |
| Do not honor | Ambiguous | One or two attempts maximum | Email the customer to contact their bank |
| Stolen or lost card, account closed | Hard | No | Stop retrying, request a new payment method |
| Gateway or issuer timeout | Soft, technical | Yes, retry quickly | Short-interval retry within hours |
Strong customer authentication and renewal declines
Merchants selling into the European Economic Area and the United Kingdom operate under strong customer authentication requirements that originate in the revised Payment Services Directive. According to the European Commission, which maintains the directive and its regulatory technical standards, electronic payments generally require multi-factor authentication of the payer, with defined exemptions.
Recurring payments are one of the areas those exemptions were designed for. The first charge in a subscription normally carries full authentication, because the customer is present and can complete a challenge. Subsequent fixed-amount renewals are typically treated as merchant-initiated and do not re-challenge the customer, provided the mandate was established correctly at signup.
Where this breaks in practice
The pattern fails when the first transaction did not properly establish the mandate. If the gateway integration took a one-off payment and only later tried to reuse the credential, the issuer may demand authentication on the renewal, which cannot be completed because nobody is at the checkout.
It also fails when the amount varies. Variable-amount recurring charges (usage-based billing, or a subscription whose total changes because a tax rate or shipping cost moved) fall outside the simplest exemption and can trigger a step-up. Plugins handle this by emailing the customer an authentication link, which recovers some but never all of the affected renewals.
Issuer behavior is the other variable. Two banks in the same market, given the same correctly flagged merchant-initiated transaction, can respond differently. That is why EEA and UK subscription books usually show a higher involuntary decline floor than comparable US books, and why testing with real cards from several issuers before launch is worth the effort. A general background on the mechanism is available on Wikipedia’s overview of strong customer authentication, and the authoritative text sits with the European Commission and the relevant national regulator.
What to check before launching in a regulated market
Confirm that your gateway flags renewals as merchant-initiated with the correct stored-credential indicator. Confirm that the signup flow records a mandate rather than a one-off payment. Confirm that your plugin sends an authentication-required email automatically when an issuer does step up, and that the link in it works on mobile.
Finally, keep the exemption boundaries in view when designing pricing. A plan with a fixed monthly amount is easier to bill reliably than one that fluctuates, and that reliability has a measurable value in retained revenue. Rules, thresholds and exemption criteria in this area are revised periodically, so the current position should always be confirmed with the European Commission, the UK’s Financial Conduct Authority or your national regulator rather than taken from any secondary source, including this one.
Upgrades, downgrades and proration
A subscription business that cannot move customers between plans has no expansion revenue. Upgrades are the cheapest growth available, because the customer already trusts you and the only friction is a billing change. Woo handles this through a switching feature, and the configuration is where most of the thinking goes.
Switching introduces a question with no universally right answer: what happens to the money already paid for the current period? The three standard answers are charge the difference immediately and keep the existing renewal date, start a fresh billing period from the switch date, or apply a credit toward the next renewal.
Choosing a proration policy
Charging the prorated difference and keeping the original renewal date is the cleanest for reporting, because billing dates stay stable and MRR moves on the day of the switch. It is slightly harder for customers to understand, since they see an unexpected partial charge.
Resetting the billing period on upgrade is easier to explain and produces a cleaner customer experience, but it scatters renewal dates and complicates cohort analysis. If you have synchronized everyone to the 1st of the month, resetting on switch defeats that work.
For downgrades, the usual and safest policy is to defer: let the customer finish the period they paid for and apply the lower price at the next renewal. Issuing cash refunds on downgrade invites abuse and creates reconciliation work that scales badly.
Operational details that bite later
Decide what happens to a switch mid-dunning. A customer whose payment has failed should generally not be able to upgrade until the balance is settled, otherwise you create a subscription that is simultaneously overdue and more expensive.
Decide how switches interact with coupons. A percentage discount applied to a $19 plan behaves very differently when the customer moves to a $99 plan, and merchants routinely discover that a legacy promo code is now discounting their most expensive tier. Scope recurring coupons deliberately, and prefer limiting a discount to a fixed number of billing cycles over leaving it open-ended.
Reporting: MRR, churn and cohort views
WooCommerce reports on orders. Subscription businesses are not run on orders, they are run on recurring revenue, retention and the rate at which the base erodes. The gap between those two facts is the single most common complaint from Woo merchants with a mature subscription book.
The official extension ships basic subscription reporting, including active counts and renewal revenue. That is enough to see whether the business is growing. It is not enough to see why, which is what you need when the growth rate changes.
The four numbers worth instrumenting
Monthly recurring revenue, normalized across billing intervals so an annual plan contributes one twelfth per month. Without normalization, annual plan sales create revenue spikes that hide the underlying trend.
Net revenue retention by cohort, which combines churn, downgrades and expansion into one figure. A book losing 3% of customers monthly while upgrading the rest can still grow, and only a net view shows that.
Involuntary versus voluntary churn, tracked separately. These have completely different fixes: one is a payments problem, the other is a product problem. Reporting them as a single churn number guarantees you will work on the wrong one.
Renewal success rate by attempt number, which tells you whether your retry schedule is earning its keep. If attempt three never recovers anything, the schedule is miscalibrated.
Getting those numbers out of Woo
Three approaches are common. Query the database directly and build the metrics in a BI tool, which is the most flexible and the most work. Push subscription events into a dedicated subscription analytics service, which is fast to set up but adds a vendor. Or export on a schedule into a spreadsheet model, which is unglamorous and perfectly adequate below a few thousand active subscriptions.
Whichever route you take, define the metrics once and write the definitions down. Churn calculated on customer count and churn calculated on revenue give different answers, and a team that silently switches between them will argue about a trend that does not exist.
The cohort view is the one that repays the effort fastest, because it separates a genuine retention improvement from a change in acquisition mix. Group customers by signup month, track the share still active after one, three and six billing cycles, and a flat month becomes legible as either a weak cohort or a billing failure. Platform choice feeds into this too, since the reporting you get for free differs sharply across stacks, a theme we return to throughout our e-commerce platform selection guide.
Compliance, disclosure and where to get advice
Subscription commerce is an active regulatory area in several markets, and the rules concern how plans are disclosed, how consent is captured and how easily customers can cancel. In the United States, the Federal Trade Commission has pursued enforcement around negative-option and automatic-renewal marketing, and several states maintain their own automatic renewal statutes with their own notice requirements. In the European Union and the United Kingdom, consumer-rights and payment-services rules govern both disclosure and authentication.
The practical implication for a Woo store is that the cancellation path and the renewal reminder are compliance surfaces, not just UX choices. Stores that bury cancellation behind a support ticket, or that fail to state the renewal price and interval clearly at signup, carry risk that no plugin setting removes. Reporting by regulators and complainants about specific companies in this space should be read as allegations where matters remain unresolved, rather than as findings.
This article is general information for merchants and is not legal, tax or compliance advice. Requirements differ by jurisdiction, change regularly, and depend on specifics this piece cannot know, including where your customers are, what you sell and how you market it. Before launching or redesigning a subscription offer, consult a qualified attorney or compliance adviser for your markets, and verify current rules directly with the relevant authority, such as the US Federal Trade Commission, the European Commission or your national consumer regulator.
FAQ on WooCommerce subscriptions
Can WooCommerce handle subscriptions without a paid plugin?
Not with core alone. You need an extension that owns the billing schedule. The lowest-cost route is usually a gateway that bundles simple recurring billing, such as WooPayments subscriptions, which avoids a separate license but limits you to straightforward monthly or annual plans on that one gateway.
Why did my renewal not charge at all?
If there is no failed renewal order, the problem is almost always the scheduler rather than the gateway. Check Tools then Scheduled Actions for pending or failed actions piling up, and confirm that a real server cron job is hitting wp-cron.php. A renewal that never fired leaves no gateway record, which is the clearest diagnostic signal.
How many times should I retry a failed renewal?
Four or five attempts spread across roughly two weeks is a common configuration, with intervals widening rather than clustering in the first 48 hours. Branch on the decline reason: hard declines should not be retried at all, while insufficient-funds declines benefit from spacing attempts across several days.
Do subscription renewals require 3-D Secure authentication every time?
Generally no for fixed-amount renewals in the EEA and UK, provided the mandate was established with full authentication at signup and the gateway flags later charges as merchant-initiated. Variable amounts and incorrectly established mandates can trigger a step-up, in which case the plugin should email the customer an authentication link. Confirm current exemption criteria with the European Commission or your national regulator.
What is the difference between automatic and manual renewal?
Automatic renewal charges a stored payment credential with no customer involvement. Manual renewal emails an invoice with a payment link that the customer has to act on. Manual renewal is the fallback for gateways that cannot store tokens, and its recovery rate is far lower, so it suits low-volume or high-value plans rather than mass-market subscriptions.
Will subscriptions slow my store down?
Indirectly, yes. Every renewal creates an order, so a subscription store accumulates order rows much faster than a one-time store with the same customer count, and the background job queue adds load. The usual answers are proper hosting with object caching, a database that is actually tuned, and moving to High Performance Order Storage.
How do I reduce involuntary churn fastest?
Two changes deliver most of the available recovery: enable network tokens or an account updater service on your gateway so reissued cards keep working, and make sure dunning email is actually being delivered through an authenticated provider. Both are configuration rather than development work, and together they address the two largest involuntary failure causes.
Can customers pause a subscription instead of cancelling?
Yes, if your plugin supports it. Pause is worth enabling, because a customer who pauses for two months usually returns, while a customer who cancels mostly does not. Cap the pause duration and the number of pauses per year so the feature does not quietly become a free plan.
Should I offer annual plans alongside monthly?
Annual plans improve cash flow and remove eleven renewal failure opportunities per customer per year, which is a real churn reduction rather than an accounting trick. The trade-off is a larger upfront commitment that converts worse, plus revenue recognition that complicates your MRR reporting unless you normalize it.