Dunning is the automated process a SaaS uses to recover a subscription payment after the customer's card is declined: it retries the charge on a schedule and sends a sequence of reminder emails asking the customer to fix their payment method. Done well, dunning recovers a large share of failed renewals that would otherwise become silent cancellations. The core idea is simple — most failed payments are not customers trying to leave, they are expired cards, hit limits, or temporary bank declines, so the job is to retry at the right moments and make fixing the card effortless.
This guide is part of the SaaS Billing and Payments series. If you have not set up your subscription engine yet, start with Stripe subscription billing for SaaS — dunning is a layer you add on top of a working billing flow, not a replacement for it.
Key takeaways
- Failed payments split into two types. Voluntary churn is a customer who chooses to cancel; involuntary churn is a payment that fails for technical reasons (expired card, insufficient funds, bank decline). Dunning targets involuntary churn, which is recoverable.
- Most failures are recoverable. A declined card is usually a card problem, not a relationship problem. The fix is a good retry schedule plus clear, friendly emails — not aggressive nagging.
- Retry timing matters more than retry count. Spacing retries across days (to clear temporary holds and align with payday cycles) recovers more than hammering the same card hours apart.
- Make updating the card a one-click action. The recovery email should link straight to a hosted card-update page. Every extra step loses customers.
- Use your processor's built-in tooling first. Stripe's Smart Retries and automatic card updater handle the heavy lifting; you layer your own emails and in-app banners on top.
What is dunning and why does it matter for SaaS?
Dunning is the communication-and-retry workflow that kicks in when a recurring charge fails. In a one-off-sale business a failed payment is a lost transaction. In SaaS it is a lost customer — and the lifetime value of a recurring customer is far higher than a single charge, so quietly losing them to an expired card is one of the most wasteful ways to lose revenue.
The reason it matters is that involuntary churn is invisible. A customer who actively cancels at least tells you why. A customer whose card expires just stops paying, keeps assuming the product still works, and may not even notice until they get locked out weeks later. Without dunning, that account silently lapses. With it, you catch the failure, nudge them, and most of them come back.
Recovered revenue is also the cheapest revenue you will ever make. You already paid to acquire and onboard that customer; recovering a failed renewal costs a few automated emails. No ad spend, no sales call.
Voluntary vs involuntary churn: what is the difference?
This distinction drives every dunning decision.
Voluntary churn is intentional: the customer clicks cancel, lets a trial lapse, or downgrades. The fix for voluntary churn is product value, onboarding, and a cancellation flow that offers alternatives — not retries. Pestering someone who deliberately left is a fast way to earn a chargeback or a bad review.
Involuntary churn is accidental: the payment fails but the customer never intended to leave. Common causes are expired cards, insufficient funds, a card flagged for fraud, a hit credit limit, or a bank that declines recurring merchants. These customers still want your product — they just need a working card on file.
Dunning is exclusively an involuntary-churn tool. Before you send a single recovery email, make sure you are not aiming it at someone who already chose to leave. A clean billing system tags the failure reason so your sequence only fires for genuine technical declines.
How should a retry schedule be timed?
The single most important lever in dunning is when you retry the card, not how many times.
A naive system retries the failed card every few hours. That mostly fails again, because the underlying cause (no funds, a hold, a limit) has not cleared. A better schedule spreads attempts across several days so the customer has time to get paid, free up their limit, or notice the email. A common shape is an immediate retry, then attempts spaced over the following week or so, tapering off rather than giving up after one miss.
Two timing details earn outsized returns:
- Align with payday cycles. Insufficient-funds declines often clear at the start of the month or mid-month when salaries land. Retrying then beats retrying at a random hour.
- Avoid hammering the same card. Card networks penalise merchants who retry declined cards too aggressively. Smart, spaced retries protect your processing reputation as well as your recovery rate.
If you use Stripe, its Smart Retries feature uses machine-learning signals to pick retry times that have historically recovered similar cards, which usually beats a hand-coded fixed schedule. Configure the window and number of attempts, then let it run and watch the recovery numbers.
What makes a recovery email actually work?
The retry handles the silent recoveries. The email handles everyone who needs to do something — replace an expired card, approve a charge with their bank, or move funds.
Good recovery emails share a few traits:
- Lead with the action, not the apology. "Your card was declined — update it here" beats a paragraph of throat-clearing. One clear button to a hosted card-update page.
- Be specific and calm. Tell them which card (last four digits), what happened, and what they need to do. Avoid threatening language on the first email; most failures are honest mistakes.
- Escalate gently across the sequence. First email: gentle heads-up. Middle emails: clear that access is at risk. Final email: state when the subscription will be cancelled if the card is not fixed. The deadline is the part that drives action — but only after you have given them a fair chance.
- Mirror the message in-app. A non-blocking banner inside the product ("Your payment failed — update your card") catches customers who do not read billing emails. People ignore email far more than they ignore the app they are actively using.
Keep the whole sequence short. Three to four emails over the retry window is plenty; more than that crosses into nagging and invites unsubscribes.
Which tools reduce failed payments before dunning even starts?
The cheapest failed payment is the one that never happens. Two processor features prevent a lot of declines upfront:
- Automatic card updater. Visa, Mastercard, and others run account-updater networks that quietly refresh a card's expiry date or number when the bank reissues it. Stripe and most major processors plug into these, so a customer whose card was reissued never even sees a failure. Turn this on first — it is the highest-impact setting in the whole flow.
- Network tokens and retries with updated credentials. When a card is tokenised at the network level, the processor can often complete a charge even after the physical card number changes. This raises authorisation rates on every renewal, not just failed ones.
Beyond the processor, a few product decisions cut involuntary churn:
- Send an expiry reminder before the card dies. If you know a card expires next month, email the customer to update it before the renewal fails. Prevention beats recovery.
- Offer annual billing. A customer on annual billing only exposes their card to one renewal a year instead of twelve, which mathematically cuts the number of failure opportunities. This ties directly into how you structure plans — see building a B2B SaaS pricing page that converts.
How I handle payments in real client SaaS products
I build payment flows into production SaaS, so this is not theory. Callidus, a clinic SaaS I built solo over roughly ten weeks (mid-February to late April 2026), runs on React, TypeScript, and Firebase with per-tenant Firestore security rules driven by JWT tenantId claims, and uses Stripe Connect Standard so each clinic gets its own payout account. That project actually replaced a failed FlutterFlow attempt that had piled up around 200 errors — rebuilding it on a proper React + Firebase stack is what made a reliable billing layer possible in the first place.
BookBed, a booking SaaS built on Flutter and Firebase with Stripe, runs from a single codebase across six OS platforms (iOS, Android, Web, macOS, Linux, Windows) and includes bidirectional iCal sync to keep external calendars in step. It is priced at EUR 9/month for up to 20 units and was built solo over about six months. When a subscription is that affordable, every recovered renewal matters, because the margin for wasted involuntary churn is thin.
The pattern across both: lean on Stripe's retry and card-updater tooling for the mechanics, then add product-side signals (in-app banners, expiry reminders) so customers are never surprised by a lapse. Security matters here too — billing touches sensitive data, so the same per-tenant isolation that protects clinic records also keeps payment state scoped correctly. More on that in SaaS security and compliance.
Conclusion
Dunning is one of the highest-return systems in a subscription business, and most of it is set-and-forget once configured. Turn on the automatic card updater, configure smart spaced retries, write a short escalating email sequence with one-click card updates, and mirror the message in-app. Then make sure you only fire it at involuntary failures, not customers who chose to leave. Get that right and you recover revenue you already earned — at almost no marginal cost.
FAQ
How long should a dunning sequence run before cancelling? Most SaaS run retries and emails over roughly one to two weeks. That window gives temporary declines (holds, low balance) time to clear and aligns with payday cycles, while still being short enough that you are not carrying unpaid accounts indefinitely. State the final cancellation date clearly in the last email.
Does Stripe handle dunning automatically? Stripe handles the retry mechanics (Smart Retries) and can send basic recovery emails through its built-in tools, plus it runs the automatic card updater. Most teams layer their own branded emails and in-app banners on top for better recovery and a consistent voice, but the core retry engine is built in.
Will retrying a declined card hurt my account? Retrying too aggressively — same card, many times, hours apart — can flag you with card networks and lower your authorisation rates. Spaced, intelligent retries avoid this. Use your processor's smart-retry feature rather than a tight fixed loop.
What is the difference between dunning and a cancellation flow? Dunning recovers involuntary churn — payments that failed for technical reasons. A cancellation flow handles voluntary churn — customers actively choosing to leave, where you offer pauses, downgrades, or save offers. They solve different problems and should not be wired to the same triggers.