What is involuntary churn?
Involuntary churn is a subscription ending because a payment failed, not because the customer decided to leave. A card expires, a bank declines a renewal charge, or a payment method gets blocked, and the subscription lapses without anyone choosing that outcome. The customer often does not know it happened until the product stops arriving or access disappears.
That distinction matters more than it sounds. A retention team reading “churn” as one number treats every lost subscriber as a product or pricing problem, and goes looking for a discount, a win-back email, or a feature the customer supposedly wanted. None of that touches a card that stopped working. It fixes nothing, and the customer the retention team is trying to win back was never trying to leave.
What does involuntary churn actually change for the business?
It moves the fix from marketing to billing. A subscriber lost to a declined card doesn’t need a better offer; they need a retry that lands on a day their bank will approve, or a message telling them their card is about to expire. Treat that customer with a save-offer campaign and you’re marketing to someone who has no idea their subscription lapsed, while the actual mechanism — a dead card number sitting in your payment gateway — goes untouched.
Involuntary churn also changes what counts as “acceptable” churn. A brand reading one blended churn rate has no way to tell whether most of it is deliberate cancellation or payment failure; illustratively, a store could be looking at roughly two-thirds voluntary and one-third involuntary, or the reverse, and a single combined number would look identical either way. Paddle and ProfitWell put the involuntary share at 20–40% of all subscription churn across the businesses they’ve measured (vendor-reported), which means a meaningful chunk of what looks like a retention problem is, for a lot of stores, actually a retry-and-recovery gap.
The table that follows sets out where the two commonly cited figures come from and what each one actually measures, since they answer different questions.
| Metric | Figure | Source | What it measures |
|---|---|---|---|
| Revenue lost to failed payments | ~9% of MRR | Baremetrics (vendor-reported) | Recurring revenue at risk each month from declined or failed renewal charges, across the subscription businesses it tracks |
| Share of churn that is involuntary | 20–40% | Paddle / ProfitWell (vendor-reported) | Proportion of all cancelled subscriptions that were payment failures rather than deliberate cancellations |
Take from this table that involuntary churn is not a rounding error next to voluntary churn; on the low end of the ProfitWell range it’s still a fifth of every subscriber you lose, and none of that fifth chose to go. If your own churn report doesn’t split the two, you’re guessing at which lever to pull.
Where operators go wrong with involuntary churn
The most common mistake is retrying a failed card once, immediately, and giving up. A single instant retry catches almost nothing beyond the cases where the first attempt was a transient network blip. A card declined for insufficient funds often clears within a few days as the customer’s own paycheck or account balance resets; retrying on day one and again on day four succeeds far more often than retrying twice on the same afternoon. The specific retry schedule that works for your customer base — how many attempts, spaced how far apart, over how many days — is a setting to configure and test in your payment gateway or subscription app, not a number to copy from another store’s blog post.
A second mistake is silence. A dunning sequence that only retries the card, with no email or SMS to the customer, misses every failure caused by an expired card, because no retry schedule fixes a card number that no longer exists. The customer needs to hear about it, ideally before the renewal date, not after three failed attempts have already happened.
A third mistake is measuring recovery as a single win/loss number instead of by failure reason. A “card expired” failure and a “bank declined for suspected fraud” failure need different responses — the first needs a card-updater or a direct request for new details, the second sometimes needs the customer to call their own bank before your retry will ever succeed. A recovery rate reported as one blended percentage hides which of those two problems is actually costing you more, and which one your current retry sequence is failing to touch.
A fourth mistake, and the one that costs the most at scale, is routing every failed renewal through the same generic “update your payment method” email regardless of failure reason. A customer whose card is about to expire, a customer whose bank flagged a transaction, and a customer who genuinely doesn’t have the funds this month all get the identical message, and all three convert at whatever rate the least-relevant version of that email produces.
What is involuntary churn confused with?
Voluntary churn. This is a customer actively cancelling, whether through a billing portal, a support ticket, or letting a free trial expire on purpose. The intent is the whole difference: voluntary churn tells you something about the product or the price; involuntary churn tells you something about the payment method. Blending the two into one “churn rate” answers neither question well.
A chargeback. A chargeback happens after a charge succeeds, when the customer or their bank disputes it later, usually citing fraud or an undelivered service. Involuntary churn is the opposite point in the flow: the charge never went through in the first place. A chargeback needs dispute evidence submitted to the processor; a failed renewal needs a retry and a card-updater. Confusing the two sends the wrong ticket to the wrong queue.
A refund. A refund is money going back to a customer who already paid. Involuntary churn is money that was never collected. They can look similar on a revenue chart — both are a dip — but a refund needs a policy decision and a refund workflow, while involuntary churn needs a retry schedule and a messaging plan.
Passive churn is sometimes used as a synonym for involuntary churn, and in most usage it is one. Some vendors use “passive churn” more narrowly for the subset caused specifically by a card expiring, as distinct from a decline for other reasons. Check how your own subscription platform defines the term before you build a report around it, because the label affects which segment of failures a given dashboard filter actually includes.
For a brand doing $3M-$30M in revenue on Shopify Plus or a comparable paid subscription platform, this is not an academic distinction. At that scale, a card-mix problem across a few thousand subscribers is a recurring five- or six-figure monthly gap, not a handful of individual accounts to chase down by hand. Below that floor, the fix is usually to turn on your payment gateway’s built-in retry logic and move on; the volume doesn’t yet justify a dedicated recovery workflow. This isn’t for a store running under a hundred active subscriptions on a free or unmanaged payment stack — there isn’t yet enough volume for a retry schedule and failure-reason segmentation to outperform the platform default.
Involuntary churn is a payment recovery problem, not a retention campaign, because the customer never asked to leave — the fix is a retry schedule that matches how banks actually re-approve declined cards, a card-updater feed, and messaging that names the specific failure reason instead of a generic “update your card” nudge. Payment recovery is the discipline that builds and tunes that retry-and-messaging system, and it’s worth estimating your own exposure with the failed payment calculator before deciding how much of it to build. For the fuller picture of where these figures come from across the industry, see the failed payment and involuntary churn benchmark.
Sources
- Baremetrics, failed payments and involuntary churn benchmarks across subscription businesses it tracks — vendor-reported.
- Paddle / ProfitWell, share of subscription churn attributable to failed payments rather than deliberate cancellation — vendor-reported.