Failed payments cause up to half your churn: fix the stack
Involuntary churn - subscribers lost to failed payments, not decisions - accounts for 20-40% of total churn across subscription businesses, per Recurly's research. WooCommerce Subscriptions ships a failed-payment retry system that can recover a large share of it, and it is off by default. The full recovery stack has four layers: automatic retries, gateway card updaters, dunning email, and measurement. This post is the configuration guide for all four.
Every save flow, offer test, and winback sequence on this blog addresses voluntary churn: a customer decided to leave. Involuntary churn is different in kind. Nobody decided anything. A card expired, a balance ran short, a bank got suspicious, and a paying subscriber silently became a former subscriber. You do not win these customers back with persuasion, because they were never persuaded to leave. You win them back with infrastructure.
How big the problem actually is
Between a fifth and half of your churn, depending on price point and category. Recurly puts involuntary churn at an estimated 20-40% of total churn across subscription businesses. Churnkey's State of Retention 2025, built on 6 million failed payments, says involuntary churn averaged around 1% monthly across their dataset and can comprise "40% of your churn, if not more" depending on the business.
Recurly's churn rate benchmarks put average involuntary churn at 1.25% against 3.60% total churn across industries - roughly a third of all churn. Price point matters a lot: in the same benchmarks, subscriptions above $250 per customer see just 0.18% involuntary churn while the $10-25 tier sees 1.30%. Cheap subscriptions ride on cheap cards. Most WooCommerce subscription stores live in exactly that low-ARPC band, which means the involuntary share of churn skews high here.
For where that sits inside your overall churn picture, the WooCommerce churn benchmarks post covers the voluntary side: 4-7% monthly voluntary churn is the middle band, with another 1-3% involuntary on top. This post is about that second number.
Layer 1: the WooCommerce Subscriptions retry system
WooCommerce Subscriptions has a built-in Failed Recurring Payment Retry System, documented here, and it is disabled out of the box. Enable it under WooCommerce -> Settings -> Subscriptions -> Miscellaneous -> "Enable Automatic Retry". If you run automatic recurring payments and have never touched this checkbox, this is the highest-leverage minute you will spend on churn this quarter.
Once enabled, a failed renewal payment triggers five retry rules over seven days instead of failing immediately:
| Retry | Time after failure | Customer email | Store owner email |
|---|---|---|---|
| 1 | 12 hours | none | Payment Retry notice |
| 2 | 24 hours | Customer Payment Retry | Payment Retry notice |
| 3 | 48 hours | none | Payment Retry notice |
| 4 | 96 hours (4 days) | Customer Payment Retry | Payment Retry notice |
| 5 | 168 hours (7 days) | Customer Payment Retry | Payment Retry notice |
During the retry window the renewal order sits in pending and the subscription in on-hold. Only after the fifth retry fails does the order get marked failed and the standard renewal invoice email go out. Two limitations from the official docs worth knowing: the system only applies to automatic recurring payments (manual renewals are excluded by definition), and it does not trigger for SEPA payments.
The default schedule is sensible. The first retry at 12 hours catches the largest class of soft declines - insufficient funds and temporary holds - without bothering the customer at all. The customer emails at 24 hours, 4 days, and 7 days form a built-in dunning skeleton, which the dunning email sequence post covers in template-level detail.
Customizing the retry rules
You rarely need to, but the whole system is filterable. The developer guide exposes three filters:
wcs_default_retry_rules- replace or reshape the store-wide rule setwcs_get_retry_rule_raw- modify an individual rule as an arraywcs_get_retry_rule- modify an individual rule object
Each rule is an array with five properties: retry_after_interval (seconds until this retry, cumulative across rules), email_template_customer and email_template_admin (email class names, empty string for no email), and status_to_apply_to_order / status_to_apply_to_subscription. So a store that wants a gentler schedule - say three retries over ten days with a customer email on each - writes a small wcs_default_retry_rules filter and is done.
One warning, straight from the developer docs: do not stack excessive retry attempts. Repeatedly slamming a dead card can get your account flagged by the payment gateway. More retries is not more recovery; past a point it is just noise the card networks penalize. Related: some declines should never be retried at all. Stripe's documentation lists hard decline codes - incorrect_number, lost_card, stolen_card, authentication_required and friends - where the issuer has said no permanently and only a new payment method fixes it. Retries against those are wasted attempts; the fix is the customer updating their card, which is what the emails are for.
Layer 2: the gateway's own retry logic
Your gateway may also have opinions about retries, and it pays to know whose system is actually running.
Stripe Smart Retries uses a model trained on Stripe network data to pick retry times, with a recommended default of 8 retries within 2 weeks. But Smart Retries is a Stripe Billing feature - it applies to Stripe-managed subscription invoices. A standard WooCommerce Subscriptions store using the Stripe gateway creates its own charges on its own schedule, so the WooCommerce retry system above is your retry engine and Smart Retries never enters the picture. The exception is WooPayments' Stripe Billing mode, where subscription billing happens on Stripe's side and Stripe's retry machinery applies. Know which world you are in before you debug a retry that did not happen.
The reason network-level retry timing matters: Recurly's payment recovery research found that retry strategies informed by network-level payment data improve recovery rates by 10-20 percentage points over single-merchant retry logic - in one enterprise case they document, recovery went from roughly 53% to 71%. A fixed five-step schedule is good; it is not the ceiling. But for most stores the gap between "retries off" and "retries on" dwarfs the gap between "fixed schedule" and "optimized schedule". Take the free win first.
Timing beats volume, too. The same Recurly research found 90% of recovered transactions occur within the first 10 days of a failed payment. Both the WooCommerce seven-day schedule and Stripe's two-week default live inside that window for a reason: a card that has not worked in ten days is almost never going to start working on its own. After that point, the customer has to act, which is layer 4's job.
Layer 3: card updaters, the fix for expired cards
A meaningful class of failed payments involves a card that no longer exists: expired, reissued after fraud, replaced by the bank. No retry schedule recovers these, because the card number itself is stale. Card updaters do.
Stripe's card account updater checks saved cards against the Visa, Mastercard, American Express, and Discover updater networks and automatically rewrites the stored payment method when the issuer reports a new number or expiry. Coverage is strongest for US-issued cards and requires no action from you or the customer; Stripe emits a payment_method.automatically_updated event when it happens. If you are on Stripe, you are already getting this. Renewals that should have failed simply succeed, which is why your involuntary churn on Stripe is probably better than you deserve.
PayPal has an equivalent for vaulted card payments: Real-Time Account Updater, which checks for updated card credentials at transaction time and updates the vaulted card on file. For subscribers paying with a PayPal wallet rather than a vaulted card, the funding-source problem largely moves inside PayPal: the customer's wallet, not your store, holds the card relationship. Either way, the practical takeaway is the same - card-expiry churn is mostly a solved problem on the major gateways, and if you are on a smaller gateway without updater support, expect structurally higher involuntary churn and lean harder on layers 1 and 4.
Layer 4: dunning email
Retries and updaters are silent. When they fail, a human has to act, and email is how you reach them. The numbers say it is worth doing properly: in Churnkey's 2025 dataset, dunning email and SMS campaigns alone recovered an average of 42% of failed payments, and the full stack - retries plus messaging - recovered 70% of detected involuntary churn. Combined with the 10-day recovery window above, the shape of a good dunning program is obvious: few emails, early, every one of them pointing at the update-payment page. Recovery is a sprint, not a drip.
The WooCommerce retry system's built-in customer emails are a functional floor. The dunning email sequence post covers the upgrade: what to say, when to send relative to the retry schedule, and why a discount in a dunning email is always a mistake.
What recovery rate to expect
Honest answer: the public benchmarks are SaaS-heavy and gateway-level; nobody publishes WooCommerce-specific recovery numbers, including us (the early ChurnStop install cohort is a save-flow dataset, not a payments one - a save flow only touches voluntary churn, which is exactly why this stack has to exist alongside it). Directionally, from the sources above: retries alone recover the large soft-decline class, messaging alone averages around 42%, and a full stack reaches 70% at the top end. If half your failed payments become recovered payments, and failed payments were a third of your churn, you just cut total churn by a sixth without changing your product, your pricing, or your cancel flow.
The checklist
Fifteen minutes, in order:
- Turn on automatic retry. WooCommerce -> Settings -> Subscriptions -> Miscellaneous -> Enable Automatic Retry. Verify with the testing guide if you want proof before trusting it.
- Confirm your renewals are automatic. Manual-renewal subscriptions never retry, by definition. WooCommerce -> Settings -> Subscriptions: if "Accept Manual Renewals" or "Turn off Automatic Payments" is on, the retry system is idle for those subscriptions.
- Check your gateway's updater coverage. Stripe and PayPal vaulted cards: covered. Anything else: read the gateway's docs for "account updater" and set expectations accordingly.
- Review the customer retry emails. They exist and they send at 24 hours, 4 days, and 7 days. Read them as a customer would. Then upgrade them.
- Measure. The built-in Failed Payment Retry Report shows revenue recovered and average attempts per recovery. Watch it monthly, and split involuntary from voluntary churn in your own reporting so the churn rate math stops blending two different diseases.