Glossary

What is involuntary churn?

Involuntary churn is subscription cancellation that the customer did not intend. It happens when a recurring payment fails — usually because the card expired, the account was over its limit, or the bank temporarily declined the charge — and no successful retry or dunning sequence recovers the payment before the subscription cancels. The customer wanted to keep the service but lost it anyway.

Voluntary vs. involuntary churn

Voluntary churn is the customer actively deciding to cancel — they no longer want the product, found a competitor, or hit a budget cut. Involuntary churn is the customer who wanted to stay losing the subscription anyway because a payment failed and was not recovered. The two are completely different problems with completely different solutions.

Voluntary churn is solved by improving the product, the pricing, the onboarding, or the retention narrative — the kind of work the marketing and product teams own. Involuntary churn is solved by improving payment recovery: smarter retries on the right schedule for each failure reason, and a branded dunning email sequence that asks the customer to update their card. Treating them as the same problem leads to wasted effort on both sides.

How much SaaS churn is involuntary

Industry research consistently puts involuntary churn at roughly 20-40% of all SaaS churn. ProfitWell has published data in that range; Recurly’s research on subscription billing finds that merchants who do not actively recoup failed payments typically lose around 6% of MRR per month to involuntary churn, while merchants with smart retries plus dunning reduce that to around 1%. The recoverable portion is large, and the recovery mechanics are well-understood.

The arithmetic is unforgiving for a SaaS that doesn’t address it. At $10K MRR, a 6%/month involuntary churn rate is $600/month walking out the door — $7,200 a year. At $50K MRR it’s $36K a year. Most of that revenue is recoverable; the customers didn’t mean to leave.

Why involuntary churn happens

Almost every involuntary-churn event traces back to a specific Stripe failure code. The top drivers for subscription billing are:

• expired_card — The card on file expired and the customer hasn’t updated it. The single largest involuntary-churn category for long-tenure subscriptions.
• insufficient_funds — The account didn’t have the balance at the moment of billing. Almost always resolves on the next payroll deposit.
• card_declined — A temporary bank hold or generic issuer decline. Usually clears within hours.
• authentication_required — The card needs 3D Secure verification (common under European PSD2 rules).

See the complete Stripe failure codes reference for every code and the optimal recovery strategy per code.

How to reduce involuntary churn

Two mechanics do most of the work. The first is smart retries scheduled by failure reason: an insufficient_funds retry waits for the next payroll deposit (48h / 5d / 10d), an expired_card retry is skipped entirely (no retry can succeed against an expired card), and a processing_error retry fires fast (the underlying issue is usually transient). See the full retry schedule per failure reason.

The second is a branded 3-step dunning email sequence from your custom domain that asks the customer to update their card — especially for failure codes that no retry can fix (expired cards, authentication-required, lost or stolen cards). Together, smart retries and dunning typically reduce involuntary churn from ~6% to ~1% of MRR per month, an ~83% reduction in lost revenue.

Frequently asked questions about involuntary churn