The Complete Dunning Playbook for SaaS (2026)
- A dunning playbook is decline-code-aware. Hard declines, soft declines, fraud blocks, expired cards, and insufficient funds each need a different action — running one sequence for all of them is the most common and most expensive mistake.
- The window is 14–21 days, not 30. Most recoveries happen by day 14; days 21–30 produce single-digit lift and meaningful customer-trust damage.
- Three to four emails, not six. Email four onward delivers diminishing returns and increasing complaint rates that hurt domain reputation.
- Channels stack. Email + in-app banner + (for high-MRR accounts) a CSM call recovers materially more than email alone.
- Segment by MRR and account type. A €5,000/mo enterprise account that fails payment is a CSM intervention; a €19/mo prosumer account is a fully automated flow.
- Measure recovery quality, not just quantity. 90-day post-recovery retention separates real recoveries from accounts you simply delayed churning.
Most SaaS teams treat dunning as a checkbox: turn on the billing system's default retry, write three emails, ship it. Six months later they are leaving 30–50% of recoverable revenue on the table because the default settings treat all payment failures the same. They retry hard declines until the issuer escalates a fraud flag. They send the same email to a €19/mo prosumer and a €5,000/mo enterprise. And they declare victory at "we recovered 50%" without realising the best-in-class number is 80%.
This is the operator playbook — the dunning configuration that recovers 60–80% of failed payments without burning customer trust, broken into the seven pieces you actually have to get right. Everything below is implementable on Stripe Billing, Recurly, Adyen, or Chargebee in a two-week sprint.
What dunning actually is (and isn't)
Dunning is the structured process of recovering subscription payments that have failed — a combination of automated retries, customer-facing communication, and access-control decisions over a fixed window. The word comes from medieval English collections; the modern SaaS version is gentler in tone and almost entirely automated.
What dunning isn't: collections, debt recovery, or sales win-back. Dunning runs before the customer is cancelled. The customer is still under contract, still has access, and is presumed to want the product. That presumption changes the tone of every touchpoint — service, not pressure. Once access is suspended, the conversation switches to win-back, which is a different motion with different copy and different conversion benchmarks.
The line between dunning and win-back matters because it separates involuntary churn (customer didn't decide to leave; payment broke) from voluntary churn (customer chose to leave). Dunning is the only churn category that responds to engineering work alone — no product changes, no pricing changes, no positioning changes required.
The 6-phase dunning lifecycle
Every recoverable payment failure moves through six discrete phases. Naming them is the first step toward instrumenting and improving each one.
- Pre-failure prevention. Card-updater APIs (VAU/ABU) refresh expired and reissued cards before a renewal even attempts. This is the cheapest recovery on offer — no email, no friction, no customer awareness.
- Initial failure & routing. The first decline arrives. The system reads the decline code and routes to one of four paths: smart-retry (soft), customer-action (fraud/expired), no-retry (hard decline), or insufficient-funds-wait.
- Smart retries. Adaptive retry attempts on a payday-aware schedule (typically day 1, day 3, day 7). The processor's ML chooses optimal time-of-day and route per issuer.
- Customer outreach. Three to four emails over 14 days, plus in-app banner from day 5 onward. Tone is service, not sales. Every touchpoint links to a one-click update-card page.
- Access decision. Day 14–16: access is suspended on a published deadline. The customer was warned three times. This protects the business from customers who have effectively churned but kept access running.
- Win-back hand-off. Day 21+: the account is now in a separate motion. Dunning has done its job. Reactivation campaigns, sales follow-up, or scheduled-deletion happen here, with their own copy, KPIs, and timing.
Most failed dunning programs we audit are missing phase 1 (no card-updater), conflate phases 4 and 6 (still pushing recovery emails after access is cut), or skip phase 5 entirely (access never gets suspended, the account keeps stacking unpaid invoices).
Decline-code playbook (Stripe + universal)
This is the piece that separates competent dunning from naive dunning: every decline code maps to exactly one default action. Below is the universal mapping that translates cleanly to Stripe's decline_code field, Adyen's refusalReason, and Recurly's transaction error categories.
| Category | Example codes | Action | Retry? |
|---|---|---|---|
| Expired card | expired_card | Card-updater attempt. If still failing, email immediately. | After updater refresh only. |
| Insufficient funds | insufficient_funds | Smart retry on payday cycle (day 1, 3, 7). | Yes (3 retries). |
| Soft decline (issuer) | do_not_honor, generic_decline, processing_error, try_again_later | Immediate retry + scheduled retries. | Yes (3–4 retries). |
| Fraud / 3DS challenge | fraudulent, lost_card_pickup, security_violation, authentication_required | Email customer with re-auth link. Do not auto-retry. | No. |
| Hard decline | card_not_supported, lost_card, stolen_card, pickup_card, account_closed | Email asking for new payment method. | No, ever. |
| Limit / velocity | card_velocity_exceeded, withdrawal_count_limit_exceeded | Wait 24h, retry once. Email if second failure. | One retry only. |
Code names follow Stripe's nomenclature; equivalent codes exist in every major processor. Pull your distribution from your processor's analytics — your mix may differ by ±10pp.
The most expensive mistake on this table is any automated retry of a hard-decline category. Hard-decline retries fail every time, sometimes escalate to fraud-block at the issuer, and turn the customer's eventual update-card email into a hostile interaction. Wire your dunning so hard-decline is a no-retry bypass straight to email. For the broader context on why involuntary churn deserves a dedicated playbook, see our guide to involuntary churn.
Retry timing — the schedule that works
The schedule below recovers more than 80% of what a dunning sequence can recover in 2026 benchmarks. It is the same shape used by Stripe Smart Retries' default, refined for B2B SaaS specifically.
| Day | Retry | Customer touch | Goal |
|---|---|---|---|
| 0 | Initial charge fails | Service email: "We couldn't process your payment" | Inform — not pressure. |
| 1 | Smart retry (issuer-aware time-of-day) | — | Catch transient soft declines. |
| 3 | Retry (post-paycheck for NSF) | — | Catch insufficient funds. |
| 5 | — | Email 2: "Update payment method" + 1-click link | Recover the customer who needs to act. |
| 7 | Final retry | — | Last automated attempt for soft declines. |
| 10 | — | In-app banner activates; email 3 sent | Reach customers who don't read email. |
| 14 | — | Final email: "Access will be paused tomorrow" | Last clear deadline. |
| 15–16 | — | Access suspended; reactivation flow takes over | Hand-off to win-back motion. |
Let your processor's ML pick the exact time-of-day for each retry. Stripe Smart Retries, Recurly Adaptive Retries, and Adyen RevenueProtect all run on cross-merchant decline data your single account can't replicate. Read the implementation specifics in the Stripe Smart Retries documentation.
Email & multi-channel copy that recovers payments
Dunning copy is the place where most teams cost themselves the most money fastest. Three rules: service tone, not sales tone; state the failure reason explicitly; and one click to fix. Below are the three email templates that benchmark above the 30% click-through ceiling.
Multi-channel beats email-only by 15–25 percentage points on overall recovery, but only when each channel is used for what it's good at:
| Channel | When to use | Lift over email-only |
|---|---|---|
| Always — the spine of dunning. | Baseline. | |
| In-app banner | Day 5+; for customers who actually log in. | +8 to +12pp. |
| SMS | B2C only; one nudge on day 7 or 10. | +5 to +9pp. |
| CSM phone call | High-MRR (>€500/mo) only, day 7. | +15 to +25pp. |
| Slack notification | If you have a billing-Slack integration; B2B saviour. | +10 to +15pp on activated accounts. |
Segmentation: don't run one sequence for everyone
The single highest-leverage configuration choice in dunning is segmenting the sequence by MRR and account type. The same retry schedule and email copy that works for a €19/mo prosumer subscription is wrong for a €5,000/mo enterprise account, and vice versa.
The minimum useful segmentation:
- Low-MRR self-serve (<€100/mo). Fully automated. Three emails, in-app banner, hard suspension on day 14. No human intervention — the unit economics don't support it.
- Mid-MRR (€100–€500/mo). Automated emails plus a CSM Slack alert at day 7 if the account hasn't recovered. Optional one-touch human follow-up.
- High-MRR (>€500/mo). Day-3 CSM Slack alert, day-5 personal email from CSM (not the billing template), day-7 phone call. Suspension only after explicit CSM sign-off.
- Annual contracts. Different schedule entirely — the renewal failure here usually signals a procurement issue, not a card issue. CSM and AE involved from day 1.
The other segmentation that pays for itself: account-level health. An account that fails payment and has been declining behaviorally for 30 days is a different situation than an account that fails payment but is healthily using the product. The first is mostly already-churned voluntarily and dunning won't save it; the second is a true involuntary failure where dunning has high ROI. Layer your dunning on top of a working customer health score and you'll allocate human attention where it actually moves recovery numbers.
KPIs + 30-day implementation checklist
Track these seven KPIs on a single dashboard and review them weekly. The first two measure volume; the last five measure quality.
| KPI | Floor | Healthy | Best in class |
|---|---|---|---|
| Failed-payment recovery rate | 50% | 65–75% | 80%+ |
| Card-updater pre-retry recovery | 3% | 8–12% | 15%+ |
| Smart-retry first-attempt success | 20% | 35–45% | 55%+ |
| Email click-through to update page | 10% | 20–30% | 35%+ |
| Update-page conversion | 40% | 55–65% | 75%+ |
| Median days-to-recovery | ≤10 | 5–7 | ≤3 |
| 90-day post-recovery retention | 70% | 82–88% | 92%+ |
Benchmarks aggregated from public Stripe, Recurly, and Paddle reporting; vary by geo and segment. The last metric is the one most teams skip — and it's the one that distinguishes real recoveries from delayed churn.
The 30-day rollout, if you're starting fresh:
- Days 1–5. Turn on card-updater. Enable Smart Retries (or your processor's equivalent). Pull a 90-day decline-code distribution; confirm your top-3 categories.
- Days 6–10. Write the four email templates. Build the one-click update-card page (no login required; tokenised link). Wire decline-code routing — hard declines bypass retries.
- Days 11–18. Build the in-app banner component. Add the Slack alert for mid- and high-MRR accounts. Define your three MRR segments and assign sequences.
- Days 19–25. Instrument all seven KPIs. Set up the weekly recovery dashboard. Run the new flow against historical failures (shadow-mode) to sanity-check email volume.
- Days 26–30. Cut over to live. Watch the first 200 failures by hand. Iterate copy weekly for the first month.
For the broader retention context this fits inside, see our complete guide to reducing SaaS churn in 2026, the 2026 churn benchmarks by industry and ARR, and our comparison of churn prediction tools. Dunning is the operational floor; predictive scoring and customer success motions sit above it. Both matter; neither replaces the other.
Frequently asked questions
What is a dunning playbook?
A dunning playbook is the documented set of rules a SaaS uses to recover failed subscription payments. It maps each decline-code category to a specific action (retry, email, no-retry), defines the timing of retries and customer touches, sets the copy and channels, and specifies when access is suspended. A good playbook recovers 60–80% of failed renewals without burning customer trust.
How long should a dunning sequence be?
Two to three weeks is the operating window for most SaaS, with retries on days 1, 3, and 7 and customer emails on days 0, 5, 10, and 14. Shorter than 10 days misses legitimate recoveries (paychecks, card replacements). Longer than 28 days keeps access open for accounts that have already churned and creates collection issues.
Should you retry hard declines automatically?
No. Hard declines (closed accounts, stolen cards, reported lost cards) signal that the card cannot pay — period. Automated retries on hard declines never succeed, sometimes trigger fraud-block escalation at the issuer, and burn customer trust for the eventual recovery email. The right action is to email the customer immediately asking for a new payment method.
How many dunning emails should you send?
Three to four emails over the dunning window. Recovery rates fall sharply after the third email; emails four through six produce single-digit incremental recovery and meaningfully higher unsubscribe and complaint rates. The marginal email costs more in domain reputation than it produces in saved revenue.
What is smart retry?
Smart retry is adaptive payment retry logic that varies the timing of attempts based on issuer-specific patterns (time of day, day of week, soft-decline reason). Stripe Smart Retries and Recurly Adaptive Retries both use machine learning trained on cross-merchant data. Smart retries first-attempt success rates of 35–45% are healthy, 55%+ is best-in-class.
What KPIs measure dunning performance?
Track seven KPIs: failed-payment recovery rate (overall), card-updater pre-retry recovery, smart-retry first-attempt success, email click-through to update-card page, recovery-page conversion, days-to-recovery (median), and 90-day post-recovery retention. The last one matters most: a recovered customer who churns voluntarily 60 days later didn't really recover.