Stripe Failed Payments: The Recovery Playbook
Most SaaS founders have a dashboard for MRR. Almost none have a dashboard for involuntary churn — and that's where 9-15% of revenue silently dies every month. This is the playbook we built after recovering 38% of failed payments across five SaaS in our portfolio.
The numbers behind the silence
Stripe publishes that 7-15% of monthly subscription charges fail. The breakdown of failure reasons (2024 industry data):
- Insufficient funds — 31%
- Card expired — 18%
- Issuer decline (no reason) — 22%
- Authentication / 3DS — 11%
- Lost or stolen card — 7%
- Card not supported / fraud rules — 11%
The rescuable bucket: ~62% of failures (insufficient + expired + 3DS + issuer no-reason). The non-rescuable: ~31% (lost/stolen, hard fraud declines).
Stripe Smart Retries — what it does, what it misses
Smart Retries is Stripe's built-in attempt to retry charges 1-4 times over up to 4 weeks. It uses ML to time retries when issuers are most likely to approve. Recovery rate from Smart Retries alone: typically 21-26%.
What it doesn't do:
- Email the customer
- Update card via Stripe Card Updater (auto-renewal of expired cards)
- Send a payment recovery link
- Show in-product warnings to the user
- Track the recovery funnel
- Distinguish recoverable from unrecoverable
You leave 50%+ of recoverable revenue on the table by relying on Smart Retries alone.
The 4-step dunning sequence (38% recovery)
This is the sequence we run for our portfolio:
Day 0 — Failure event
- Stripe webhook
invoice.payment_failedfires - App marks subscription as
past_due(NOT cancelled) - User keeps full access — kicking users out of a paid product they're trying to pay for is the #1 churn accelerator
- In-app banner appears with "Update payment method" CTA
Day 0 +30 minutes — First email (informational)
Subject: We couldn't charge your card — easy fix inside
Hi [Name],
Your last payment for [Product] didn't go through. This often happens with expired cards or temporary holds — the most common fix is updating your card details.
Update your payment: [Stripe Customer Portal link]
If you've already updated, ignore this email.
Day 1 — Card Updater + Smart Retries kicks in
Stripe handles automatically.
Day 3 — Second email (action-oriented)
Subject: Your [Product] subscription needs attention
Hi [Name],
We tried again on [date] and the payment still didn't process. Two common causes:
- Your card may have expired (check expiry date)
- Your bank may need 3DS authentication
Quick fix (2 min): [Stripe Customer Portal link]
Day 7 — Third email (last call)
Subject: [Product] access pauses in 24 hours
Hi [Name],
We've tried three times to process payment. To avoid pausing your account tomorrow, please update your card here: [link]
Already cancelled? You can ignore this email — your account will pause automatically.
Day 8 — Pause access
Subscription moves to paused (or canceled per your config). User keeps data for 90 days. One final email.
Day 30 — Win-back
Subject: Come back to [Product] — your data is still here
Just an FYI: your subscription paused but your data is preserved for 60 more days. Reactivate any time: [link]
The metrics you should track
Build these into a dashboard:
- Recovery rate = recovered failed charges ÷ total failed charges (target: 35-45%)
- Email CTR per stage (1st email typically 28%, 2nd 15%, 3rd 8%)
- Time to recovery (median 2.4 days in our portfolio)
- Revenue at risk (sum of failed charges × probability of recovery by reason)
- Recovered MRR/quarter (the dollar value, not just the rate)
What we built
We needed this for our own SaaS portfolio (5 products on Stripe). Building it as a feature of every SaaS was duplicate work, so we extracted it into paymentrescue.dev. It connects to your Stripe account, runs the 4-step sequence, and gives you a dashboard. Free ROI calculator and demo data on the homepage.
Whether you use a tool or build it yourself, the math is the same: if your MRR is $20K and 10% of charges fail monthly, recovering 38% adds $760/month to your run-rate. Compounded annually, that's $9,120 of MRR you weren't capturing.
The wrong way to do dunning
Don't:
- Lock users out immediately on first failure (50%+ of failures resolve themselves in 24h)
- Use scary subject lines ("ACCOUNT SUSPENDED")
- Hide your retry schedule from users (transparency raises trust)
- Send all 3 emails on day 1
- Use "no-reply@" addresses (kills deliverability + reply rate)
- Forget to handle 3DS — always include the recovery link, never just an email summary
The takeaway
Involuntary churn is the silent revenue killer because it doesn't show up in surveys, NPS, or product analytics. It hides in failed invoices and ignored emails. Building a 38% recovery rate isn't sophisticated — it's a 4-step email sequence and a customer portal link. Most SaaS that don't do it leave $5K-50K/year on the table by accident.
Antonio Altomonte builds revenue tooling at DevToolsmith. Failed payment recovery scanner: paymentrescue.dev.
Top comments (0)