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
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.
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.
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.
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.
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.
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.
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.
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! 🔥
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?
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.