Most founders know their churn rate. Almost none know how much of it is just failed cards
Most SaaS founders can tell you their MRR, their churn rate, and their CAC payback period. Ask them how much revenue they lost last month to failed card payments and you usually get a shrug.
“Stripe retries them automatically, right?”
It does — a bit. But for a lot of subscription businesses, failed payments are one of the largest and least-monitored revenue leaks in the company. Industry benchmarks put involuntary churn (customers who didn’t choose to leave — their card just failed) at 20–40% of total churn.
That distinction matters. Voluntary churn is a product or positioning problem. Involuntary churn is mostly a payments and communication problem. They need completely different fixes.
A simple way to measure it:
You don’t need a new tool. You can get a usable number from Stripe in about 20 minutes:
-
Pull subscriptions that ended in the last quarter
-
Check whether they went active → canceled (voluntary) or active → past_due/unpaid → canceled (involuntary)
-
Cross-check with invoice.payment_failed events
Sum the MRR that never recovered
When founders run this for the first time, the involuntary share is almost always higher than they expected.
Why Smart Retries alone usually aren’t enough
Stripe’s Smart Retries are a good foundation — they pick better timing than a fixed schedule. But they only answer one question: “When should we try charging this card again?”
They don’t:
- Distinguish soft declines from hard declines in a way you can act on
- Tell the customer what actually went wrong
- Make it easy for the customer to update their card
That’s why recovery rates often stall in the 30–40% range even with Smart Retries turned on. The remaining recovery usually comes from clearer communication and a low-friction card-update path.
I wrote a longer breakdown with the full calculation method and examples here if useful:
https://retryfix.com/blog/failed-payment-revenue-impact
Curious what percentage of your churn you’ve been able to attribute to failed payments versus actual cancellations?
#churn #saas #stripe #failed-payments
When setting up that recovery flow, how long of a grace period do you usually recommend before restricting account access or officially cancelling the subscription?
Good question — this is one of the parts most teams get slightly wrong.
I usually recommend a 7–14 day grace period before restricting access, with the exact length depending on your price point and customer type:
Lower-priced / self-serve ($20–80/mo): 7–10 days is usually enough.
Higher-priced or B2B ($100+/mo): 10–14 days is safer. You don’t want a good customer locked out over a temporary card issue.
A few practical principles that work well:
Cutting access too early creates support tickets and bad feeling. Waiting too long just extends free usage on a failed payment. The 7–14 day window is the sweet spot for most SaaS.
The voluntary vs involuntary split is the right cut, but I'd push on the involuntary bucket itself, because active -> past_due -> canceled is not one thing, it's two very different customers wearing the same status, and the recovery math breaks if you treat them as one. Some are true involuntary: they wanted to stay, the card genuinely broke (expired, rotated, a bank fraud-flag), and better dunning plus a frictionless update path recovers them. But a real chunk of past_due -> canceled is disguised voluntary churn: people who had already decided to leave and just let the charge fail instead of clicking cancel, because failing quietly is easier than confronting a cancel flow. That second group looks identical to the first in Stripe's status transitions, so summing all past_due -> canceled MRR as "recoverable involuntary" quietly overstates the opportunity, and dunning them harder just irritates people who already left (and can spike chargebacks and spam complaints). The two are separable with a signal you already have and Stripe doesn't: pre-failure engagement. Someone who was actively using the product the week the card failed is almost certainly true involuntary, worth aggressive recovery. Someone who went dark 30 to 40 days before the charge failed used the card as their exit, and no retry sequence saves them. So the recovery ceiling isn't one number, it's true-involuntary MRR (high recoverability) versus passive quitters (near zero), and averaging them makes both your leak and your recovery rate look wrong. Genuine question: when you pull that past_due -> canceled bucket, do you segment it by whether the customer was still active in the weeks before the charge failed, or does everyone in past_due get the same dunning sequence? Because I'd bet your real recoverable number is smaller, and your true recovery rate on the still-engaged slice is a lot higher than the blended 30 to 40% suggests.
You’re right — this is an important refinement.
The active → past_due → canceled path does mix two different groups:
True involuntary – still engaged, card genuinely failed
Quiet quitters – already checked out and just let the charge fail instead of cancelling
Treating them as one bucket does inflate the “recoverable” number and can lead to over-dunning people who have already left.
On the practical question: we do not currently give everyone in past_due the exact same sequence. The main signals we use are:
Decline code (soft vs hard)
How far through the retry window they are
Plan value / MRR of the account
We don’t yet automatically segment on pre-failure product engagement (last active date, feature usage, etc.), though I agree that signal is one of the cleanest ways to separate the two groups. That’s something I’d like to add more explicitly.
In practice we already see what you’re describing: recovery rates are meaningfully higher on accounts that were still active shortly before the failure, and much lower on accounts that had already gone dark. The blended 30–40% number hides that variance.
Appreciate you pushing on this — it’s a sharper way to think about it.
This is the kind of metric that looks clean in a dashboard and kills you in reality. I had a similar blind spot with my AI scoring — the number looked great (75/100) until I tested it on a black square. "Dead" metrics are worse than no metrics because they give you false confidence. Always segment by edge case.
Exactly. A clean-looking number that hides the important split is often more dangerous than having no number at all — it gives you false confidence.
The voluntary vs involuntary cut (and then the further split inside involuntary) is one of those cases where the blended metric actively misleads you about where to spend effort.
Appreciate the insight
The distinction between voluntary and involuntary churn is the strongest part. Treating failed payments as a separate revenue problem gives founders something much more actionable than looking at churn as one number.
Thanks — that’s exactly the point I was trying to make.
Once you separate the two, the next action becomes much clearer. One is mostly a product/positioning problem, the other is mostly a payments and recovery process problem. Mixing them just leaves both under-addressed.
The distinction between voluntary and involuntary churn is really useful. I think failed payments often get treated as a pure payment-processing problem when a big part of recovery is actually about what happens after the decline.
The interesting part for me is that the recovery funnel probably has several different failure points: the retry itself, identifying why it failed, communicating the right action to the customer, and finally making the card update frictionless.
I’d be curious to see how you break down recovered vs permanently lost revenue across those stages. That seems like it could reveal where the biggest leakage actually happens.
You’re right — treating it as pure payment processing understates the problem.
The recovery path does break into several distinct stages, and leakage happens at each of them:
Retry logic – whether you even attempt the right declines again
Diagnosis – understanding why it failed (soft vs hard)
Communication – telling the customer what happened in a way that gets action
Friction to fix – how easy it is for them to update the card
In practice we see the biggest permanent loss at stages 3 and 4. The retry itself is rarely the main bottleneck once Smart Retries (or equivalent) are on. Most of the revenue that stays lost is from customers who never got a clear message or who hit friction when they tried to update the payment method.
We don’t yet have a perfect public breakdown of recovered vs permanently lost at each stage across all merchants, but the pattern is consistent: improving the communication + card-update steps usually moves the overall recovery rate more than further tuning the retry schedule.
Good framing — the multi-stage view is the more useful way to look at it.