Last updated: July 2026
Every Stripe SaaS already has a free recovery tool: Smart Retries. Before paying for anything else, it's worth knowing exactly what they do, how to switch them on, and the specific places they leave recoverable MRR on the table. This page is the plain-English version, with the honest limits included.
Short version: Smart Retries are genuinely good at re-charging the same card at smart times. They're not built to run a branded email cadence, to rescue an expired card, or to tell you per-customer what came back. That's the gap a dedicated dunning layer fills — on top of, not instead of, Smart Retries.
When a recurring invoice fails, Stripe doesn't give up on the first "declined". With Smart Retries enabled, it re-attempts the charge several times over a window — and the clever part is the timing. Instead of retrying on fixed intervals, Stripe uses a machine-learning model trained on its network's enormous volume of retry outcomes to pick moments when a given card is most likely to clear: after a bank's temporary hold typically lifts, around when a paycheck usually lands, and so on.
For the biggest bucket of involuntary churn — soft declines like insufficient funds or a jittery risk hold — this is exactly the right tool, and it costs you nothing. If your failures are mostly these, native Smart Retries plus Stripe's failed-payment emails already recover a real share, and you may not need anything else.
Five steps, all inside Stripe — no code. Stripe occasionally relabels these screens, so match the intent if a menu name differs:
Open Billing settings
In the Stripe Dashboard, go to Settings, then Billing, then "Manage failed payments" (sometimes shown under Subscriptions and emails). This is where all retry behaviour for recurring invoices lives.
Choose Smart Retries
Under the retries section, pick "Smart Retries" rather than a fixed custom schedule. Smart Retries lets Stripe's machine-learning model choose the retry times instead of you setting fixed intervals.
Set the retry window
Choose how many times Stripe may retry and over how long — commonly up to 4 attempts across roughly two weeks. Stripe distributes those attempts across the window at the times its model predicts are most likely to succeed.
Decide what happens when retries are exhausted
Tell Stripe what to do if every retry fails: cancel the subscription, mark it unpaid, or leave it past-due. This is the moment involuntary churn becomes final, so choose deliberately.
Enable the failed-payment emails
Separately, switch on Stripe's built-in emails to customers on failed payments and add your logo and brand colour under Settings → Branding. These are basic templates, but they beat sending nothing alongside the silent retries.
Verify each toggle against Stripe's live UI at stripe.com/docs — the exact labels and defaults change over time.
This is the part Stripe's marketing understandably skips. Smart Retries are a card re-charge engine — nothing more. Four concrete gaps:
No custom email cadence
You get Stripe's single failed-payment template, styled with your logo and colour. There's no multi-step sequence, no per-step copy, no A/B testing, and no way to write the email per customer. The email is what makes a customer fix an expired card — and this is the weakest part of the native setup.
No flow for expired / hard-declined cards
Smart Retries re-attempt the same card. If that card is expired, has the wrong number, or was reported lost, every retry will fail by definition — the customer has to enter new details. Native retries don't branch on the decline code, so they burn attempts on cards that can never clear, while nothing pushes the customer to update.
Card-updater doesn't cover every card
Stripe's automatic card updates refresh saved cards when the issuing network pushes new details (a reissued Visa/Mastercard, say). That helps, but it only works for participating networks and card types — it's not a guarantee that an expired card gets silently fixed. Plenty still need the customer to act.
Thin per-customer recovery reporting
Stripe shows an aggregate revenue-recovery figure. What it doesn't give you cleanly is a per-customer record: which subscriber failed, what was tried, whether an email was opened, and exactly what came back. Without that, you can't tell a genuinely recovered dollar from one Stripe would have retried anyway.
Side by side, on capability — not marketing. The point isn't that Smart Retries are bad; it's that they cover one column well and leave the customer-facing recovery flow to you.
| Capability | Native Stripe Smart Retries | Dedicated dunning layer (SaveMyMRR) |
|---|---|---|
| Card retries | Yes — ML-timed, up to ~4 attempts over ~2 weeks | Yes — plus a published schedule you can read and tune |
| Retry timing you can inspect | No — the ML schedule is opaque | Yes — fixed 0/24/72/120/168h cadence, printed |
| Email cadence & copy | Fixed Stripe template, one email style | Multi-step sequence, per-step copy, per-customer on Pro |
| Emails from your own brand/domain | Logo + colour only; sent by Stripe | Full own-brand sending on Pro |
| Different flow for expired vs soft declines | Same retry logic; retrying an expired card can't work | Every email carries a one-tap card-update link for hard declines |
| Per-customer recovery reporting | Aggregate revenue-recovery view; thin per-customer detail | Per-recovery dashboard: opened, retried, recovered, amount |
| Detect-only / measure-the-lift mode | No | Yes — watch and retry nothing, then compare |
| Cost | Included with Stripe Billing | Flat fee on top — only worth it if recovered MRR beats it |
The SaveMyMRR column comes straight from this codebase; the Stripe column reflects documented native capability in mid-2026 — Stripe iterates on Billing often, so confirm current behaviour on their docs.
The rule of thumb is simple: Smart Retries win soft declines, customers win hard declines. The more of your failures need the customer to do something, the more native retries alone under-recover.
| Failure type | Native retries? | What actually recovers it |
|---|---|---|
| Insufficient funds | Strong — ML times the retry to payday | A well-timed retry (native does this) |
| Temporary bank / risk hold | Strong — spaced retry clears most | A retry after the hold lifts |
| Processing / network error | Strong — usually transient | Any retry soon after |
| Expired card | Fails every time — same card | An email that gets the customer to re-enter a card |
| Incorrect number / CVC | Fails every time | Customer must correct the details |
| Lost / stolen / do-not-honor (hard) | Fails — card is dead | A branded email + easy update link |
Everything in the bottom half of that table is where a dunning layer earns its fee: it doesn't waste retries on dead cards, it puts a branded, well-written email in front of the customer with a one-tap update link, and it tracks whether that specific recovery came back. Involuntary churn runs at roughly a fifth to two-fifths of total churn for subscription businesses; the hard-decline tail inside it is precisely what native retries can't reach.
The one honest caveat both ways: some cards clear on Stripe's free retries regardless, so any paid tool's raw "recovered" total slightly flatters it. The clean read is to run detect-only first, then switch the extra layer on and compare — a truer number than any headline percentage.
Before adding anything to Stripe's free retries, it's worth knowing how much is actually at stake. The involuntary-churn calculator turns your MRR and failure rate into a yearly recoverable figure entirely in your browser — nothing leaves the page. If that number dwarfs a flat monthly fee, a dunning layer pays for itself; if it doesn't, Stripe's free retries alone are probably enough, and this page just saved you a subscription.
Add branded emails and an expired-card flow on top of Smart Retries.
Connect Stripe — freeRestricted key only, encrypted at rest. Keep Smart Retries on — this works alongside them. See the mechanics or the email templates.
When a subscription payment fails, Smart Retries is Stripe automatically re-attempting the charge on the same card at times its machine-learning model thinks are most likely to succeed — for example when a bank hold is likely to have lifted or a paycheck has landed. Instead of you picking fixed retry intervals, Stripe spreads a handful of attempts (commonly up to 4) across a window of roughly two weeks. It's part of Stripe Billing's automatic collection and it's included, so most Stripe SaaS already have it.
In the Stripe Dashboard go to Settings → Billing → Manage failed payments, choose Smart Retries over a fixed custom schedule, set how many retries and over how long, and decide what happens when they're exhausted (cancel, mark unpaid, or leave past-due). Separately switch on the failed-payment customer emails and add your logo under Branding. The step-by-step is on this page above the FAQ.
For pure card re-attempts, Stripe's ML timing is generally as good as or better than a hand-set schedule, because it's trained on a huge volume of network data about when retries clear. That's the one thing native Smart Retries does well. Where they leave money on the table is everything around the retry: the email cadence, own-brand emails, handling expired cards that no retry can fix, and per-customer reporting. A dedicated dunning layer keeps Stripe's retries (or runs its own on a schedule you can read) and adds those.
Four things worth knowing. (1) No custom email cadence — you get Stripe's single template, not a multi-step sequence you control. (2) No special flow for expired or hard-declined cards, where retrying the same card can never succeed and the customer must re-enter details. (3) Stripe's automatic card updater only covers cards on participating networks, so it doesn't rescue every expired card. (4) Thin per-customer recovery reporting — you get an aggregate recovered-revenue view, not a clear per-subscriber record of what was tried and what came back.
It complements them. You don't have to turn Smart Retries off. SaveMyMRR connects on a restricted Stripe key, watches your failed invoices, and layers a readable retry-plus-email sequence on top — retrying the card with invoices.pay at set steps and sending recovery emails the customer actually acts on. Think of native Smart Retries as the silent card re-attempt and the dunning layer as the customer-facing recovery flow around it.
Mostly when the failure needs the customer, not just another charge attempt. An expired card, a wrong number, a card reported lost — no amount of ML-timed retrying clears those; someone has to re-enter a card, and that only happens if an email prompts them. Native Stripe emails are basic and un-branded beyond a logo, so their click-through is lower than a proper sequence. If a meaningful share of your failures are hard declines, that's exactly the gap a dunning layer fills.
Involuntary churn is commonly estimated at 20–40% of total churn for subscription businesses, and a good chunk of failed charges are recoverable because they're temporary. Native Smart Retries alone claw back a real slice; adding a branded email sequence and an expired-card flow on top captures more of the hard-decline tail. The only honest number is your own — run the involuntary-churn calculator with your MRR and failure rate to bound what's on the table before you add any paid tool.