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_failed fires
• 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.