Dunning Emails: How to Recover Failed Payments Automatically
Dunning emails recover failed SaaS payments without a support ticket. Get the cadence, subject lines, and trigger logic that turn declines into renewals.
Junaid KhalidAugust 4, 202612 min read
Dunning emails are the automated messages a SaaS company sends when a subscription payment fails, prompting the customer to update their card or retry the charge before access is cut off. Done well, they recover a meaningful share of failed payments without a support ticket, because most declines are not a customer choosing to leave: they are an expired card or a bank's temporary block.
That distinction matters. A customer who churns because your product stopped solving their problem is a lost cause. A customer whose card expired last month while busy shipping their own product is not. Dunning tells these two apart and gives the second group an easy way to keep paying you.
Key takeaways
- Dunning emails recover failed payments by combining automated payment retries with a timed sequence of emails, spaced over roughly three to four weeks.
- Most failed payments are "soft declines," temporary issues like insufficient funds or a bank flag, not a customer rejecting the charge. Soft declines are worth retrying; hard declines (stolen card, closed account) are not.
- Recovery is heavily front-loaded: the highest share of recoverable revenue comes back in the first 72 hours to two weeks, then decays sharply.
- A good dunning sequence is behavioral, not just scheduled: it should stop the moment the customer updates their card or the invoice is paid, and it should escalate tone only as the deadline approaches.
- Card expiration is predictable and preventable. A pre-dunning email sent 7 to 14 days before a card expires avoids a chunk of failures before they happen.
- Dunning is one lifecycle sequence among several. If you have not mapped your full trial-to-paid and renewal lifecycle yet, that is worth doing before you build dunning in isolation.
Why payments fail in the first place
Before you write a dunning sequence, you need to know what you are dunning for, because the right response depends on the failure type. Payment processors classify declines into two broad buckets.
Soft declines are temporary and often resolve on a later attempt: insufficient funds, a bank's fraud-detection hold, a temporary processing error, or the card issuer's system being briefly unavailable. Visa's card network rules permit up to 15 to 20 retry attempts within a rolling 30-day window for soft declines, which is why retry logic, not just emails, is half the recovery equation.
Hard declines are final: a stolen or reported card, a closed account, or a card flagged for fraud. Network rules do not allow retries on these. The only path to recovery is asking the customer for a new payment method.
The most common individual cause, by a wide margin, is simple expiration: the card on file expired and the customer forgot to update it. That is the easiest decline to deal with, because it is often preventable, which is covered below. Payment failures also sit next to a related problem: your renewal or receipt email getting flagged as spam before the customer sees it. If your email deliverability is shaky, no dunning cadence fixes a message that never reaches the inbox.
The anatomy of a dunning sequence
A dunning sequence is not one email. It is a coordinated set of retries and messages spread over three to four weeks, with each touchpoint doing a different job.
A widely cited structure (Baremetrics' analysis of dunning cadences) runs six to seven emails across 27 to 30 days, weighted toward the first two weeks, because failed-payment recovery is highest in the first 72 hours and decays sharply after about two weeks. Front-loading your best copy and most retries into that window matters more than spacing everything evenly. A practical version of that cadence:
| Day | Message | Tone | Purpose |
|---|---|---|---|
| 0 (immediate) | Payment failed notice | Friendly, informative | Tell them what happened and give a one-click way to fix it |
| 2 to 3 | First reminder | Helpful, low pressure | Reinforce the fix, in case the first email was missed or filtered |
| 7 | Second reminder | Slightly more direct | Note what happens if it is not resolved |
| 14 | Retry result + warning | Direct, specific | State the access-loss date clearly |
| 21 | Final notice | Urgent but respectful | Last chance before downgrade or cancellation |
| 25 to 30 | Access change confirmation | Neutral, factual | Confirm what happened, with a reactivation path |
The exact day count matters less than the shape: gentle at first, clearer about consequences as the deadline nears, always ending with a door left open. A customer who churns involuntarily today can often be won back later, so "final notice" should mean final for this billing cycle, not forever.
Copyable dunning email examples
Generic subject lines like "Payment Failed" get opened less often because they create alarm without giving the reader a reason to act right away. Specificity does more work than urgency.
Email 1: Immediate notice (day 0)
Subject: We couldn't process your payment for [Product] Hi [First name], Your payment of [$amount] for [Plan name] didn't go through. This usually happens because of an expired card or a temporary hold from your bank, not because of anything you did. [Update your payment method] and we'll retry the charge automatically. It takes about a minute. If you have questions, just reply to this email.
Email 2: First reminder (day 2 to 3)
Subject: Quick reminder: your [Product] payment is still pending Hi [First name], We're still unable to process your last payment. Your account is active for now, but we wanted to flag it before it becomes a problem. [Update payment method] Takes under a minute, and you'll keep everything exactly as it is.
Email 3: Warning with a deadline (day 14)
Subject: Action needed: your account access changes on [date] Hi [First name], We've tried a few times to process your payment for [Product] without success. If we can't collect payment by [specific date], your account will move to [restricted access / read-only / paused], and [specific consequence, e.g. "your team will lose access to shared dashboards"]. [Update payment method now] If your card is fine and this is a mistake on our end, reply and we'll sort it out directly.
Email 4: Final notice (day 21 to 25)
Subject: Last chance to keep your [Product] account active Hi [First name], This is the final reminder before your account changes to [consequence] on [date]. We'd rather keep you as a customer than lose you over an expired card. [Update payment method] If you've decided to cancel, no hard feelings. Just let us know and we'll take it from here.
Notice what is constant across all four: the customer is never blamed, the fix is always one link away, and every email states plainly what happens next. That combination of clarity and low friction is what separates dunning emails that convert from ones that get archived.
Prevention beats recovery: the pre-dunning email
The best dunning email is the one you never have to send because the payment never failed. Card expiration is predictable months in advance: processors know the expiry date on file and can flag it before the renewal date arrives.
A pre-dunning email sent 7 to 14 days before a card's expiration date, asking the customer to update their payment method proactively, prevents a chunk of failures before they happen. "Card expiration date is within N days" is a simple condition to check on a schedule, and it costs one calm email instead of an entire recovery sequence.
Example pre-dunning subject line:
Subject: Your card on file expires this month, here's a 1-minute fix Hi [First name], The card you have on file for [Product] expires at the end of [month]. Update it now and you won't see any interruption to your account. [Update payment method]
Pair this with card network account updater services, which many payment processors offer, and refresh expired or reissued card details automatically in the background. Prevention and recovery work together: account updaters catch what they can silently, and pre-dunning emails catch the rest before it becomes a failed charge.
Building the trigger logic behind dunning
Dunning only works as automation: manually tracking who is on day 3 versus day 14 of a failed payment does not scale past a handful of customers. The trigger logic behind a dunning sequence needs a few real signals, not just a calendar:
- Entry trigger: a payment/invoice webhook reports "failed" or "declined" status from your billing provider (commonly delivered via Stripe, Chargebee, Paddle, or similar).
- Decline-type branch: soft declines enter the full retry-and-email sequence; hard declines skip straight to "update your payment method" messaging, since a retry is pointless.
- Exit condition: the moment the invoice is marked paid, the contact should be pulled out of the sequence immediately. Nothing damages trust faster than a "your payment failed" email landing an hour after the customer already fixed it.
- Escalation condition: tone and subject line shift as the deadline approaches, but the underlying trigger, still unpaid, stays the same.
This is the same pattern as any other behavioral email: a billing event happens, it enters someone into a triggered sequence, and their behavior determines what they see next and whether they stay enrolled. If your dunning emails are still a manual export-and-send process, that is the gap most worth closing first: payment-failed customers did not choose to leave, and most still want the product.
Dunning tools compared
Dedicated dunning tools, billing platforms, and lifecycle email platforms approach this differently. None is right for every stack:
| Tool type | Example | Strength | Limitation for dunning |
|---|---|---|---|
| Dedicated dunning/recovery add-on | Baremetrics Recover, Stunning | Purpose-built retry schedules and dunning-specific analytics | Adds another vendor and cost on top of your billing and email stack |
| Billing platform native dunning | Stripe Smart Retries, Chargebee, Recurly | Retry logic lives next to the charge, no separate integration | Email design and behavioral branching are usually basic |
| Lifecycle/behavioral email platform | Meisa, Customer.io, Encharge | Dunning is one sequence among onboarding, activation, and win-back, on the same webhook infrastructure | Requires wiring up the billing webhook yourself |
If your billing provider's native retry logic is solid but its emails are generic, routing the payment-failed webhook into a proper lifecycle sequence is often the fix that matters most: the same tool that already reacts to signup and trial events can react to a billing failure with the same branching and exit logic.
FAQ
What is a dunning email?
A dunning email is an automated message sent to a customer after a subscription payment fails, asking them to update their payment method or retry the charge. The word comes from the older, broader "dunning" process of following up on any overdue payment; in SaaS it refers specifically to the email and retry sequence tied to a failed recurring charge.
How many dunning emails should I send?
Most SaaS dunning sequences run four to seven emails over roughly three to four weeks, weighted toward the first two weeks when recovery odds are highest. Fewer than three emails leaves recoverable revenue on the table; many more than seven risks annoying a customer who has already decided to leave.
What is the difference between a soft decline and a hard decline?
A soft decline is temporary (insufficient funds, a bank hold, a processing glitch) and is worth retrying automatically. A hard decline is final (stolen card, closed account, fraud flag) and should skip retries entirely in favor of asking for a new payment method, since card network rules do not permit retrying a hard decline.
Does dunning actually recover revenue, or do most customers just leave?
A meaningful share of failed payments are recoverable specifically because the customer did not choose to cancel: their card expired, or their bank issued a temporary hold. Recovery rates vary by product and audience, so treat any specific percentage you see quoted with skepticism unless the source names its methodology. What is consistent across published analyses is that recovery is heavily front-loaded into the first one to two weeks after a failure.
Should dunning emails come from support or from billing?
Either can work, but consistency matters more than the specific sender. Use a sender identity your customers already recognize (the same one your receipts or other transactional email already comes from) rather than a generic "billing@" address they have never seen, and keep your domain's authentication (SPF, DKIM, DMARC) correctly configured so these time-sensitive emails do not land in spam when they matter most.
Can I prevent failed payments instead of just reacting to them?
Yes, partially. Expiring cards are predictable, so a pre-dunning email 7 to 14 days before expiration catches a portion of failures before they happen. Account updater services offered by many payment processors silently refresh reissued card numbers in the background. Neither eliminates failed payments entirely, since fraud holds and insufficient funds are not predictable in advance, but both reduce the volume your recovery sequence has to handle.
If you are still running dunning as a one-off export or a single generic email, Meisa lets you build the sequence above as a real trigger off your billing provider's payment-failed event, branch on decline type, and stop the moment the invoice is paid, alongside the rest of your onboarding and lifecycle email.
