Dunning is not a word most founders encounter until they start losing customers to payment failures. At that point it becomes very important very quickly. This guide explains what dunning is, why it matters for SaaS businesses specifically, and how to build a dunning system that actually recovers the customers you would otherwise lose.
The short version: dunning is the process of communicating with customers whose subscription payments have failed in order to recover the payment and retain the subscription. The word itself dates to the 17th century — a "dunner" was a debt collector who would persistently pursue payment. In modern SaaS, dunning has nothing to do with debt collection and everything to do with serving customers who lost access to a product they want to keep through no decision of their own.
What you will learn
- What dunning means in a SaaS context and why it exists
- Why 20–40% of SaaS churn is involuntary and how dunning addresses it
- How a complete dunning system works from payment failure to recovery
- The difference between hard and soft declines — and why it matters
- What good dunning looks like vs. what most businesses have
- How to set up dunning correctly from scratch
📋 In this article
What dunning means for subscription businesses
In a SaaS context, dunning refers to the automated process of detecting payment failures, retrying the payment on an appropriate schedule, and communicating with the customer to help them resolve the billing issue before their subscription cancels.
The word carries negative connotations from its historical meaning, but modern SaaS dunning is the opposite of harassment. Done correctly, it is a customer service function: you are helping someone who wants to continue using your product maintain access to it, despite a billing problem they may not even know about.
Consider the typical scenario: a customer's credit card expires. Their bank issues a new card with a new number and expiry date. Stripe attempts the next subscription renewal, gets a decline code of expired_card, and the payment fails. The customer did not decide to cancel. They may not even know the card expired. Without a dunning system, their subscription cancels automatically after the grace period, and from their perspective, the product just stopped working.
With a good dunning system, the customer receives an email the same day with a direct link to update their card. 40–60% of them update immediately. The subscription continues without interruption. The customer never experiences a gap in service.
📋 Dunning vs. voluntary churn: completely different problems
Dunning addresses involuntary churn — customers lost to payment failures. Voluntary churn — customers who chose to cancel — requires a cancel flow. These are fundamentally different problems that need different solutions. A dunning system does nothing for customers who decided to leave, and a cancel flow does nothing for customers who lost access to a billing failure. Both need to be in place to address your full churn.
Why involuntary churn is bigger than most founders realise
Payment failure rates on subscription billing are structurally higher than most founders expect. Stripe reports average card failure rates of 10–15% across all transactions. For subscription billing specifically — where the same card is charged month after month without the customer actively re-authorising each payment — the failure surface is wide:
Cards expire on known schedules. Cards get replaced after fraud on completely unrelated transactions — the customer's card number used at a compromised merchant gets cancelled, and the replacement card has new details. Corporate cards get deactivated when employees leave. Cards hit spending limits near the end of billing cycles. Banks flag recurring international charges as unusual and decline them.
The result: a meaningful fraction of your monthly churn is customers who never decided to leave. They want to keep using your product. The relationship is intact. The only thing preventing renewal is a billing mechanism failure — and that failure is recoverable if you act on it correctly and quickly.
Hard declines vs. soft declines
Not all payment failures are equal. Understanding the distinction between hard and soft declines is the foundation of any effective dunning strategy.
Soft declines are temporary. The payment failed for a reason that may resolve on its own or with a well-timed retry. Insufficient funds, temporary bank restrictions, and processing errors are soft declines. The card is still valid — the circumstances around it are temporarily preventing the charge. A retry at the right time will often succeed.
Hard declines are permanent. The card cannot be charged again regardless of timing. Expired cards, cards reported stolen or fraudulent, and closed accounts are hard declines. Retrying a hard decline is pointless and can be counterproductive — multiple failed charges on a dead card can trigger fraud flags at the issuing bank. For hard declines, the only path to recovery is getting the customer to add a new payment method.
| Type | Examples | Retry? | Action |
|---|---|---|---|
| Soft decline | insufficient_funds, do_not_honor, processing_error | Yes — with appropriate timing | Schedule payday-timed retry + soft notification email |
| Hard decline | expired_card, stolen_card, account_closed | No — skip retries entirely | Immediate card update email with direct link |
Components of an effective dunning system
A complete dunning system has three layers that work together: payment retries, customer communications, and proactive prevention. Most businesses have only the first layer in any form — Stripe Smart Retries handles the timing automatically. The second and third layers are where most of the recoverable revenue is left.
Layer 1: Payment retries
Retries are attempts to charge the same payment method again after a failure. For soft declines, a retry at the right time will often succeed without any customer action required. Stripe Smart Retries handles this automatically using machine learning to time retries optimally. For businesses that want more control — specifically, payday-timed retries for insufficient_funds failures — a webhook-based retry scheduler built on top of Smart Retries delivers meaningfully higher recovery rates.
The key constraint: maximum three to four retries per payment failure. More retries increase the risk of triggering the issuing bank's fraud detection for suspicious repeated charge attempts. If three optimally-timed retries have not succeeded, escalate to customer communication rather than continuing to retry.
Layer 2: Recovery emails
Recovery emails prompt the customer to update their payment method before the subscription cancels. Three emails over twelve days is the established best practice. The sequence: a soft notification on day 1, a moderate-urgency follow-up with a specific deadline on day 5–7, and a final warning on day 10–12 that mentions what the customer will lose.
The most critical technical requirement: every email must link directly to a payment update page that works without login. Requiring a customer to log in before they can update their card eliminates 50–70% of completions, particularly on mobile. Use Stripe's hosted update pages or build a tokenised direct-update link.
Layer 3: Proactive prevention
Proactive outreach addresses payment failures before they happen. Card expiry warnings — sent 30 days before a card on file expires — prevent 30–50% of expiry-related failures. Annual renewal reminders — sent 14 days before a large annual charge — reduce the bank declines that large infrequent charges sometimes trigger and eliminate most customer surprise disputes.
This layer requires the least ongoing effort of the three. It is configured once and runs forever. The ROI per setup hour is the highest of any retention intervention in a SaaS billing stack.
What most businesses have vs. what they should have
| Component | What most SaaS businesses have | What best practice looks like |
|---|---|---|
| Retries | Stripe default or Smart Retries — same schedule for all failure types | Decline-code-specific logic: payday timing for insufficient_funds, zero retries for expired_card |
| Recovery emails | Single Stripe notification email, generic copy, links to login page | Three-email sequence over 12 days, direct update links, escalating urgency |
| Proactive prevention | None — reactive only | 30-day card expiry warning + 14-day annual renewal reminder |
| Recovery rate | 20–25% of failed payments | 40–50% of failed payments |
Dunning and cancel flows: the complete retention picture
Dunning addresses one category of churn: customers who lost access due to payment failures. A cancel flow addresses the other: customers who actively decided to cancel. A complete retention system needs both.
The practical implication: if your current monthly churn is 5%, roughly 1–2% of that is likely involuntary. A dunning system can recover 40–50% of those — reducing your total churn by perhaps 0.5–0.8 percentage points. That sounds small but compounds significantly: at €50k MRR, 0.5% less monthly churn is €250/month in additional retained revenue, every month, growing as your MRR grows.
A cancel flow, running simultaneously, recovers 25–45% of voluntary cancellation attempts. Together, both tools address the full spectrum of monthly customer loss. For more on cancel flows, see the cancel flow best practices guide.
Set up complete dunning automation in under 10 minutes
Retainly handles decline-code-specific retries, three-email recovery sequences, and proactive expiry outreach — all automatic after a one-time Stripe connection. Free to start.
Start for free →Frequently asked questions
What is dunning in SaaS?
Dunning in SaaS is the automated process of recovering failed subscription payments. When a customer's payment card fails — due to expiry, insufficient funds, bank decline, or other reasons — a dunning system retries the payment on an optimised schedule and sends the customer a sequence of emails prompting them to update their payment method before the subscription cancels.
What is involuntary churn?
Involuntary churn is customer loss caused by payment failures rather than a deliberate cancellation decision. The customer wants to continue subscribing, but a billing mechanism failure — expired card, bank decline, spending limit — causes the subscription to lapse. Involuntary churn accounts for 20–40% of total SaaS customer loss and is addressed through dunning rather than retention offers or product improvements.
What is the difference between dunning and a cancel flow?
Dunning recovers customers who lost access due to payment failures — they never decided to leave. A cancel flow intercepts customers who are actively trying to cancel — they made a decision to leave. These are different problems requiring different solutions. Most SaaS businesses need both to address the full scope of monthly customer loss.
Does Stripe handle dunning automatically?
Stripe provides Smart Retries (automatic retry timing optimisation) and a basic notification email as part of Stripe Billing — both free. This handles the retry dimension of dunning but does not provide decline-code-specific strategy, multi-email recovery sequences, direct card update links, or proactive expiry outreach. These gaps are where 15–20 percentage points of additional recovery rate are available.
What is a dunning email?
A dunning email is an automated message sent to a customer whose subscription payment has failed, prompting them to update their payment method. Best practice is a three-email sequence over 12 days: a soft notification on day 1, a moderate-urgency follow-up with a specific deadline on day 5–7, and a final warning on day 10–12. Every email should link directly to a payment update page that works without requiring the customer to log in.
Dunning in practice: what the full system looks like
A complete dunning system for a SaaS business on Stripe has three operational layers that work together. Understanding the full picture helps clarify what each component achieves and why each is necessary.
Layer 1 — Stripe Smart Retries (automatic)
Smart Retries is enabled in the Stripe Billing dashboard and runs automatically. It uses machine learning across Stripe's network to time retry attempts for maximum success probability. For soft declines — insufficient funds, temporary bank restrictions, processing errors — Smart Retries handles the timing of each attempt without any action on your part. This is your baseline: enable it if it is not already on.
Layer 2 — Decline-code-specific handling (webhook-based)
Built on top of Smart Retries using the invoice.payment_failed webhook. For expired cards: immediately cancel retries and send a card update email with a direct update link. For insufficient funds: schedule a payday-timed retry. For processing errors: retry within 24 hours without emailing. This layer recovers 15–20 additional percentage points beyond Smart Retries alone.
Layer 3 — Recovery email sequence
Three emails over 12 days: a soft notification on day 1, a moderate-urgency follow-up with a specific deadline on day 5–7, and a final warning on day 10–12. Every email links directly to a payment update page that works without login. This layer covers the customers who will not update through a retry alone — the ones who need a prompt and a frictionless path.
| Layer | What it recovers | Cumulative recovery rate | Setup effort |
|---|---|---|---|
| Smart Retries only | Soft declines via optimal retry timing | 20–25% | One setting |
| + Decline-code logic | Payday timing + expired card skip | 30–35% | 1–2 hours webhook |
| + Recovery email sequence | Customers who need a prompt | 40–50% | 2–4 hours email setup |
Dunning vs. debt collections: an important distinction
The historical meaning of "dunning" — a debt collector pursuing overdue payment — is far removed from what modern SaaS dunning does. Traditional debt collection is adversarial: a creditor pursuing a debtor who owes money and may be unwilling to pay. SaaS dunning is a customer service function: a business helping a customer who wants to continue paying resolve a billing obstacle that is preventing them from doing so.
This distinction matters for how you write dunning emails. The tone should never be threatening, accusatory, or pressure-based. The customer is not a debtor who owes you money they are refusing to pay — they are a subscriber whose billing mechanism failed. Your job is to make the fix as easy as possible. A dunning email that reads like a collections notice will generate more unsubscribes than card updates.
Dunning configuration checklist: set this up correctly once
For most SaaS founders, the hardest part of setting up dunning is knowing what "done" looks like. Here is the complete checklist of what needs to be configured for a production-ready dunning system:
| Item | Where | One-time or ongoing |
|---|---|---|
| Stripe Smart Retries enabled | Stripe Dashboard → Billing → Automatic collection | One-time |
| Automatic card updater enabled | Stripe Dashboard → Billing → Automatic card updates | One-time |
| Grace period set to 14–21 days | Stripe Dashboard → Billing → Subscription lifecycle | One-time |
| invoice.payment_failed webhook handler | Your backend | One-time |
| Decline-code-specific retry logic | Your backend or Retainly | One-time |
| 3-email recovery sequence with direct update links | Your email tool or Retainly | One-time setup, monitor quarterly |
| Card expiry warning (30 days before) | Cron job querying Stripe cards or Retainly | One-time |
| Recovery rate tracking (monthly) | Retainly dashboard or custom query | Ongoing — monthly review |
With all of these in place, a dunning system is effectively complete for a business at any scale up to €500k MRR. The ongoing maintenance requirement is minimal — a monthly glance at recovery rate by decline code to confirm performance is stable, and an annual review of email copy to keep it current. See the full Stripe dunning best practices guide for implementation details on each item.
For businesses that prefer not to build and maintain this system themselves, Retainly handles all of the above — decline-code logic, email sequences, direct update links, and recovery analytics — as a fully managed system on top of your existing Stripe account.
Common dunning mistakes that cost recovery rate
Running a dunning system is straightforward. Running one correctly requires avoiding a handful of specific mistakes that consistently reduce recovery rates across SaaS businesses of every size.
Retrying expired cards. This is the single most common and most damaging mistake. An expired card returns a clear decline code — expired_card — and retrying it wastes attempts that will never succeed, delays the card update outreach that could recover the payment, and risks triggering fraud flags at the issuing bank. The moment you see expired_card, stop retrying immediately and send a card update email.
Linking recovery emails to the login page. Customers who receive a payment failure email on their phone and land on a login screen abandon at rates of 50–70%. Every recovery email must link to a payment update page that works without requiring login. Stripe's hosted invoice pages handle this natively.
Sending more than three emails. Four or more recovery emails over the dunning window generates spam complaints that damage your domain reputation for all outgoing email — including your marketing campaigns, product announcements, and customer success communications. Three emails over twelve days is the established ceiling.
No proactive expiry outreach. The highest-ROI dunning action is prevention. Customers who receive a "your card expires next month" email 30 days before expiry update their card proactively, preventing the failure entirely. Without this, every expiry-related failure is a reactive scramble that could have been avoided with a single automated email.
Related: Stripe Dunning Best Practices · Failed Payment Recovery Guide · Cancel Flow Best Practices · How to Reduce SaaS Churn