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
The churn rate is a perfect example of how a blended metric hides the decision boundaries you actually need to see. When two completely different problems (voluntary vs involuntary) get summed into one number, you lose the signal for what to fix.
The teams that win are the ones who split the metric and make the boundary visible. Once you see the split, the action becomes obvious - one needs product work, the other needs payment communication. But as long as it's blended, both stay under-resourced.
It's the same pattern as measurement systems that hide what different departments are optimizing for - visibility of the split is what creates alignment.
That’s a really clean way of putting it.
The blended churn number isn’t just incomplete — it actively hides the decision boundary. As long as product and billing are looking at the same combined figure, both teams stay slightly under-resourced and slightly pointed at the wrong problem.
Once the split is visible, the next action is usually obvious. One bucket needs product and positioning work. The other needs better communication and a lower-friction card-update path.
The measurement itself is what creates the alignment.
One split that matters in Europe and is missing from most dunning setups: not every failed renewal is a declined card. A share of them are SCA challenges, where the bank wants the cardholder to authenticate an off-session charge. In Stripe those surface as authentication_required rather than a hard decline.
It matters for the recovery flow because the email that works for a dead card is the wrong one here. Nothing is wrong with the card. The customer needs to complete a challenge, and if your email points them at a card form, they re-enter the same card and fail again.
Cheap check before you write any copy: pull last quarter's failed invoices and group them by decline code. If authentication_required is a meaningful slice, it needs its own message and its own link.
This is an important one, especially in Europe.
authentication_required is not a dead card. Treating it like expired_card or insufficient_funds is one of the fastest ways to send the customer down the wrong path.
The practical split is:
Card problem → update payment method
SCA / authentication challenge → complete the bank check, usually on the same card
If the email sends them to a generic “update your card” form, a lot of people just re-enter the same card and fail again.
Agree on the cheap check: group last quarter’s failed invoices by decline code first. If authentication_required is a meaningful slice, it needs its own message and its own action, not the same dunning copy as a hard decline.
We already treat decline codes as different recovery paths rather than one generic “payment failed” sequence. SCA is one of the cases where that distinction matters most.
Then the cut worth adding is measuring recovery by decline code rather than in aggregate. Authentication challenges recover on a different curve to expired cards, and an average hides which message is doing the work.
One detail worth planning for: the SCA path usually needs the customer to authenticate inside a session, so a link that drops them into a generic billing form can lose them even when the copy is right.
Agreed — recovery rate by decline code is the cut that actually tells you what’s working.
An aggregate number hides two different curves:
authentication_required often recovers if you get them into an in-session challenge quickly
expired_card / stolen_card only recovers if they update the method
Same “recovery rate,” completely different action.
On the SCA path specifically: the link has to start the authentication session, not dump them on a generic billing form. If they land on “update your card,” a lot of people re-enter the same card and fail the challenge again. The copy can be right and the destination still wrong.
That’s why we treat the destination as part of the recovery path, not just the email text
The distinction between voluntary and involuntary churn is really useful. I think it’s easy to treat all churn as a product problem, when failed payments can be a completely different issue.
The point about retries only solving “when to charge again,” but not the communication or card-update friction, was especially interesting. Tracking the active → past_due/unpaid → canceled path seems like a simple but useful first check.
Thanks — that’s exactly the distinction I think most teams miss.
Once you start treating failed payments as a separate problem from “customers didn’t like the product,” the next checks become much simpler. The active → past_due/unpaid → canceled path is a good first cut, and then the real work is usually in the communication and how easy it is to update the card.
Appreciate you reading it closely.
This is spot on. In my day job managing contact center operations for payment plans, I see this at scale every single day—cards expire, decline, or get reissued due to fraud constantly.
But honestly, even in my own personal life as a consumer, when my card gets replaced, I completely forget half the services and places that actually have it on file. It's almost never a conscious decision to cancel; it’s just the friction of remembering and updating everywhere.
If you treat a failed card as voluntary churn, you end up trying to fix the product when you really just need a frictionless, clear communication flow. Great breakdown.
This is a really useful perspective — both the contact-center side and the personal one.
The “I forgot half the places that had my card” problem is exactly why treating it as voluntary churn leads people the wrong way. Most of those customers didn’t decide to leave. They just never got a clear, low-friction prompt to update the new card.
That’s why the communication and update path usually matter more than another retry attempt. Appreciate you adding the real-world view.
We learned this the hard way — our involuntary churn was nearly 30 percent of total churn and we had no idea until we segmented the data. The biggest win was not better retry logic but a simple email flow: the moment a payment fails, send a plain-text email that says exactly what happened and gives a one-click update link. Our recovery rate jumped from 35 percent to 65 percent just from that change. The lesson: treat failed payments as a communication problem, not a technical one.
That’s a really clean result — and a useful one for other people reading this.
A jump from 35% to 65% recovery from better communication rather than more retry logic is exactly the pattern I keep seeing. The technical retry already happens. The missing piece is usually a plain, specific message plus a one-click way to fix it.
Appreciate you sharing the actual numbers. Did you keep access open during that email window, or restrict it fairly quickly? Do you monitor the decline codes and respond accordingly?
This is a really useful distinction. Founders often treat all churn as a product problem, but failed payments are a completely different type of loss and potentially easier to recover.
I also like the idea of separating voluntary and involuntary churn before deciding what action to take. Better retry logic, clearer communication, and a frictionless way to update payment details can probably have a direct impact without changing the product itself.
I’m curious how often early-stage SaaS founders actually track this as a separate metric from overall churn.
Thanks — that’s the core point.
In my experience, most early-stage SaaS founders don’t track this separately. They look at one blended churn number and assume it’s mostly a product or pricing issue. The involuntary piece only becomes visible when someone specifically pulls the past_due / failed-invoice path.
That’s why it’s worth doing even a rough split. You don’t need a fancy dashboard at first — just enough visibility to know whether the next action is product work or a better recovery flow.
Wondering whether you’ve tried separating it in your own numbers yet?
The interesting measurement issue here is that churn rate usually lumps together two very different events with completely different fixes: someone actively deciding to leave, and a payment simply failing. A single number can’t really tell you what to fix. Splitting those two metrics is probably more valuable than just trying to improve the combined churn rate.
Since you’re already pretty deep into this, where would you classify a customer whose card fails, exhausts all retries, and then gets updated three weeks later? Is that a resurrection or do you treat it as never having churned?
Whichever way you draw that line will move both rates, so the split is only really useful if the boundary is explicitly defined right next to the metric.
Good question — the boundary matters.
I treat it as churned, then recovered if the subscription actually ended (or access was cancelled) and later came back. If the card was updated while the subscription was still past_due and never fully cancelled, I treat that as recovered before churn.
In other words:
Failed → recovered inside the grace / retry window → not churn
Failed → cancelled / ended → paid again later → churn + resurrection
That second group should not quietly disappear from the involuntary-churn number, or the metric gets too flattering. The split only stays useful if those two cases are defined next to the number.
We use the same rule when looking at recovery rate: recoveries inside the window count against the original failed payment. Comebacks weeks later are a separate win.
That's the complete answer, both cases defined next to the number, and late comebacks counted as a separate win keeps the metric honest. The only free parameter left is the grace-window length itself; worth stating that next to the number too, since moving it moves the churn rate.
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.
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
Great point — the "blended metric" trap is real. I see founders optimizing for the average while the real leak stays invisible.
Speaking of launches — I'm putting ThumbRank on Product Hunt today at 10 AM Kyiv / midnight PT. If you're around, would love your feedback: https://www.producthunt.com/products/thumbrank
Happy to return the favor when you launch. Let's keep building! 🔥
Good luck with ThumbRank today.
I’ll take a look if I get a chance. The “looks good until you test the edge case” point is a useful one — that’s exactly why the blended churn number is so misleading.
Thanks Retryfix. Appreciate it — and you're right, the edge case test is where most assumptions die. Same with thumbnails: looks perfect on a 27-inch monitor, then you open it on a phone next to 10 competitors and realize it's invisible. That's the edge case that burns views before the algorithm even gets a chance to evaluate the video.
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.
That distinction is useful. Would be open to continuing the conversation beyond the thread — what’s the best email to reach you on?
Sure — happy to continue.
You can reach me at support@retryfix.com (that comes through to me).
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
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.
That makes sense. The interesting part is that “failed payment” and “lost customer” aren't really the same event — there’s a recovery window between them.
I wonder if the more useful metric is therefore revenue at risk → revenue recovered → revenue permanently lost, segmented by failure reason and customer action.
That would make the funnel much more actionable: a decline isn't necessarily a churn event, but a decline with no successful retry, no card update, or no customer response becomes a measurable leakage point.
It also seems like this could expose a different optimization priority for each merchant: one might need better retry logic, while another might already have good retries but lose money because customers never complete the recovery flow.
Yes — that’s the more useful model.
A decline is not churn. It’s revenue at risk. The actual loss only happens if nothing in the recovery window works.
The sequence I think about is:
Failed payment
Revenue at risk
Recovered (retry succeeded, or customer updated the card)
Permanently lost (no successful retry, no card update, no response)
Segmenting that by decline reason and customer action is what makes it actionable. One merchant can be leaking at retries. Another can have decent retries and still lose most of the money because customers never complete the update flow.
That’s why a single recovery-rate number is only a start. The more useful question is: where in the window is this merchant actually losing the money?
That’s also why communication + card-update friction often beat more retry tuning. If the customer never acts, another retry against the same broken card doesn’t change the outcome.
Makes sense on the revenue-at-risk vs permanently-lost cut.
If you ever want to see that split on a real Stripe account, there’s a read-only demo here:
https://retryfix.com/demo/start
No pitch — only if it’s useful.