Involuntary churn: what it is and what recovery is worth
Involuntary churn: customers lost to failed payments, not decisions. Why retries miss some, the EU authentication catch, and what recovering 6 is worth.

Involuntary churn is the customers who leave without deciding to: a renewal payment fails, nobody fixes it, and the subscription ends. Recurly's definition fits in one line: "Involuntary churn is when a subscriber loses access because a payment fails."
It belongs to nobody. It is not a product problem and not a campaign, so it ends up in a billing setting that nobody reviews. That is also why it is often the cheapest churn to recover: the customer never chose to leave.
On a product with 1,100 customers at €60 a month, 11 renewals a month end in a failed payment that nobody fixes. Recovering 6 of them keeps €360 of MRR: €4,320 of ARR every month, and €2,400 of acquisition that does not have to replace them.
Involuntary churn is customers lost to failed payments, not decisions: an expired card, no funds, a bank asking for authentication. On a product with 1,100 customers at €60 a month, recovering 6 of 11 failed renewals keeps €360 of MRR, €4,320 of ARR every month.
Key takeaways
- Involuntary churn is customers lost to failed payments, not decisions, and it usually belongs to a billing setting nobody reviews.
- Retries cannot fix hard declines such as a lost card or authentication_required: those need the customer to act.
- In the EU, a renewal the bank refuses to exempt goes back to the customer for strong customer authentication.
- On 1,100 customers at €60, recovering 6 of 11 failed renewals keeps €4,320 of ARR every month and €2,400 of acquisition.
- Split last month's cancellations into canceled and failed, count the failed ones and price them with ARPU × 12.
Involuntary churn vs voluntary churn: two different fixes
Both end in the same line of the churn report. They have almost nothing else in common.
| Voluntary churn | Involuntary churn | |
|---|---|---|
| What happens | The customer cancels | A payment fails and the subscription lapses |
| Did the customer decide? | Yes | No |
| Usual causes | Product, price, fit | An expired or replaced card, no funds, the bank asks for authentication |
| Who owns it | Product and marketing | Billing, which usually means nobody |
| The fix | A better product or a better message | A retry, a new card, an authentication step |
| How long the fix takes | Months | Days |
The SaaS churn rate counts both in one number. Splitting it is the first step: the two halves need different people and different weeks.
Why involuntary churn belongs to nobody
The product team reads usage. Marketing reads campaigns. A failed card shows up in neither.
What exists instead is a setting in the billing tool. Stripe's page on automatic payment retries shows how it works. The retries run on a schedule: "The recommended default setting is 8 tries within 2 weeks." When they run out, the subscription moves to whatever state was configured, canceled included, and "After the final payment attempt, Stripe makes no further payment attempts."
Retries cannot fix every failure. For a list of hard decline codes, among them lost_card, stolen_card and authentication_required, the same page says: "For these failures, the scheduled retries continue but the payment only executes if you obtain a new payment method."
So part of involuntary churn can only be recovered by the customer: a new card, or a check with their bank. If nobody asks them, the schedule ends and the account is gone.

In the EU, recovery needs the customer
European cards add a step: strong customer authentication, or SCA, from the EU's payment rules.
Stripe's guide to strong customer authentication says it applies to "customer-initiated" online payments in the UK and Europe, for "transactions where both the business and the cardholder's bank are located in the" European Economic Area.
Renewals are initiated by the business, not the customer. The guide says: "These payments technically fall outside the scope of SCA." But "SCA is required for the customer's first payment – subsequent charges, however, may be exempted from SCA." And it is "ultimately the cardholder's bank that decides whether or not to accept an exemption." When the bank refuses, "These payments then have to be resubmitted to the customer with a request for Strong Customer Authentication."
That is the authentication_required decline on the list above. No retry recovers it. The recovery email has to bring the customer to a page where their bank's check works, on a phone, in one step.
Direct debit has its own catch. Stripe's retry page says: "By default, Stripe doesn't automatically retry failed payments made with local payment methods." SEPA Direct Debit is one of them. A European product that takes SEPA should check that switch before it counts its churn.
What recovering involuntary churn is worth
Take the product this blog's SaaS posts use: 1,100 paying customers at €60 a month, €66,000 of MRR. Every month 4 of every 100 cancel, 44 customers, and each one costs €400 to replace, the example acquisition cost reduce churn uses.
Say 11 of those 44 never decided to leave: their renewal failed and nobody fixed it. That is 1 of every 100 subscriptions a month, a quarter of the churn. A follow-up, a message at the first failure with a link to update the card and pass the bank's check, recovers 6 of the 11. Both numbers are declared for the example, not a client's.
Failed renewals nobody fixed 11 a month (1 of every 100 subscriptions)
Recovered by a follow-up 6 of 11
MRR kept 6 × €60 = €360
ARR kept €360 × 12 = €4,320, every month
Acquisition avoided 6 × €400 = €2,400 a month
Churn after recovery (44 − 6) ÷ 1,100 = 3.5 of every 100
The ceiling is the 11. A follow-up can only recover renewals that failed; it does nothing for the 33 customers who chose to go.
That is why it comes first. It needs no experiment, no new feature and no campaign: a setting, a message and a page.
If you don't know how many of your cancellations were never a decision, the Activation Audit maps where customers leave and marks the fixes to make before any experiment.
Who should own involuntary churn
Give it an owner and one number: failed renewals nobody fixed, each month, read next to the churn rate.
The owner checks three things:
- The retry schedule. How many tries, over how long, and whether local payment methods such as SEPA are retried at all.
- The message at the first failure. Sent the day the payment fails, with a link to update the card and pass the bank's check on a phone.
- The end state. What happens after the last retry is a decision: cancel, mark unpaid, or pause.
Every recovered customer shows up in the customer retention rate, and keeps their customer lifetime value running, since churn is one of its inputs. The owner can say how many of them were never going to leave.
The involuntary churn number for your product
Involuntary churn = failed renewals nobody fixed ÷ customers at the start of the month
Value of recovery = failed renewals nobody fixed × recovery rate × ARPU × 12
Acquisition avoided = recovered customers × acquisition cost per customer
What to do by Monday: export last month's cancellations from the billing tool and split them by reason: the customer canceled, or the payment failed. Count the failed ones. Check which decline codes they carry, and how many are authentication_required or a lost or expired card. Multiply the count by a recovery rate below one in two, by ARPU and by 12. Put that number next to one month of acquisition spend.
Work through this with your own numbers
You are a SaaS operator measuring involuntary churn. Inputs: [paying customers at the start of the month], [ARPU per month], [cancellations last month], [cancellations where the renewal payment failed and was never fixed], [how many of those carry hard decline codes such as authentication_required or lost_card] and [acquisition cost per customer]. Calculate involuntary churn as failed renewals nobody fixed ÷ customers at the start of the month, and its share of total churn. For recovery rates of 1 in 4 and 1 in 2 of the failed renewals, calculate customers recovered, MRR kept, ARR kept (MRR × 12), acquisition avoided and the churn rate after recovery. Flag any recovery above the number of failed renewals as impossible, and say which failures need the customer to act rather than a retry.
FAQ
What is involuntary churn?
Customers who leave because a payment failed, not because they decided to: an expired or replaced card, insufficient funds, or a bank that asks for authentication. If nobody fixes the payment, the subscription lapses and counts as churn.
What is the difference between voluntary and involuntary churn?
Voluntary churn is a customer who cancels; product and marketing own it, and the fix takes months. Involuntary churn is a failed payment nobody fixed; billing owns it, and a retry, a new card or an authentication step fixes it in days.
How do you reduce involuntary churn?
Review the retry schedule, send a message at the first failure with a link to update the card and pass the bank's check, and choose the state after the last retry on purpose. Some declines, such as authentication_required, only clear with the customer.
Does SCA affect subscription renewals in Europe?
Renewals are initiated by the business and technically fall outside SCA, but the first payment needs it and the cardholder's bank decides on exemptions. When it refuses, the payment has to go back to the customer with an authentication request.
How much is recovering failed payments worth?
Failed renewals nobody fixed × recovery rate × ARPU × 12. On a product with 1,100 customers at €60 a month, recovering 6 of 11 keeps €360 of MRR, €4,320 of ARR every month, and €2,400 of acquisition at €400 a customer.
Before you spend on bringing customers back, count the ones who never chose to leave. The Activation Audit maps where customers leave in five business days, for $500, and the map stays with you whether or not you hire anyone.
Your store, five days.
$500. Zero commitment. Yours either way.
What’s holding your store’s sales back, in minutes.
Free, no card. Shopify stores for now.