Dunning emails: best practices, templates, and timing
Copy-paste templates and a day-by-day schedule for recovering failed payments without sounding like a debt collector.
THE SHORT ANSWER
Dunning emails recover failed subscription payments by telling the customer their card did not go through and giving them a one-click way to fix it. The sequence that works: a same-day notice, a helpful reminder on day 3, an urgency email from a human sender on day 7, and a pause warning on day 14.
What dunning email best practices actually come down to
Dunning is the process of collecting a payment that failed. In SaaS, that almost always means an expired card, an issuer decline, or an insufficient-funds error on a subscription renewal. The customer did not decide to stop paying you. Their card did.
That single fact should shape every email in your sequence. You are not chasing a debtor. You are notifying a customer about a technical problem they probably do not know exists. Most people have no idea their card was declined until you tell them.
The best practices, condensed:
- Assume good faith. The customer usually does not know the payment failed.
- Make fixing it one click. Link straight to the card update page, no login maze.
- Say what happens if nothing changes, and when.
- Escalate tone gradually: informational, then helpful, then urgent, then consequential.
- Coordinate the emails with your payment retries so they do not contradict each other.
20-40%of failed payments recover from a decent dunning sequence (Stripe, Recover failed payments)
Stripe's own guidance on recovering failed payments puts recovery from combined retries and dunning in that range. If you send nothing today, this is the cheapest revenue you will recover this quarter.
Why tone matters more than copywriting
The most common dunning mistake is writing like a collections agency: "Your account is past due. Remit payment immediately." That tone converts a billing hiccup into a relationship problem, and it gives an on-the-fence customer a reason to let the subscription lapse.
Write every email as if you are helping the customer keep something they want. Because you are. They chose to pay for your product; a bank computer interrupted that choice. Your job is to make the interruption as short and painless as possible.
The one-sentence tone test: would this email be embarrassing if the payment failure turned out to be your bug? Card networks misfire, billing systems double-charge, and issuers decline valid cards. Write every dunning email so it still reads fine when the failure was not the customer's fault. It often is not.
The 4-email sequence, with templates
Four emails over 14 days is enough. More than that trains customers to ignore you; fewer leaves money unrecovered. Copy these, swap in your product name, and edit the voice to match yours.
Email 1: same-day notice (day 0)
Send within an hour of the first failed charge. Purely informational, zero pressure.
Subject: Payment issue on your [Product] account
Hi [First name],
Quick heads-up: the payment for your [Product] subscription did not go through today. This is usually an expired card or a bank decline, nothing to worry about.
You can update your card here in about 30 seconds: [update payment link]
We will also retry the charge automatically over the next few days, so if your bank was just having a moment, you may not need to do anything.
Nothing changes with your account in the meantime.
[Your name] at [Product]
Email 2: helpful reminder (day 3)
Still friendly. Add the most common causes, because "expired card" solves half of these on its own.
Subject: Still seeing a payment issue on your [Product] account
Hi [First name],
We retried the payment for your [Product] subscription and it did not go through again. The usual causes:
- The card on file expired
- The bank flagged the charge (a quick call to them fixes this)
- The card was replaced after being lost or stolen
Updating your card takes about 30 seconds: [update payment link]
Your account is still fully active. If something on our end looks wrong, just reply to this email and a human will look at it.
[Your name] at [Product]
Email 3: urgency, from a human (day 7)
Switch the sender. Emails 1 and 2 can come from billing@; this one should come from a named person with a real reply-to, ideally a founder or the account's CS contact. Reply rates jump when a person, not a system, is asking.
Subject: Your [Product] account needs attention this week
Hi [First name],
[Your name] here from [Product]. Your subscription payment has failed a few times over the last week, and I wanted to reach out personally before it affects your account.
If the payment is not resolved by [date, day 14], we will pause your account. Your data stays safe and nothing gets deleted, but your team will lose access until billing is fixed.
Updating your card takes under a minute: [update payment link]
If budget or an invoicing change is behind this, reply and tell me. We can usually work something out.
[Your name]
Email 4: pause warning (day 14)
Final email. State the consequence plainly, and make the path back easy.
Subject: Your [Product] account will be paused today
Hi [First name],
This is the last note about the failed payment on your [Product] subscription. We were not able to collect it after several attempts, so your account will be paused today.
Paused means: your data is safe, your settings are saved, and nothing is deleted. Update your card and everything comes right back: [update payment link]
If you meant to cancel, no hard feelings, and you can ignore this. But if you are still using [Product], one minute fixes it.
[Your name]
How do you time dunning emails against smart retries?
Your billing system retries failed cards on its own schedule. Stripe, Chargebee, and Recurly all do machine-timed "smart retries" that pick moments when the charge is most likely to succeed, such as just after typical payday deposits.
The mistake is running emails and retries on separate clocks. Then the customer gets "please update your card" an hour after a retry already succeeded, which reads as either broken or greedy.
Coordinate them with three rules:
| Rule | Why | | --- | --- | | A successful retry cancels the rest of the email sequence immediately | Nothing erodes trust faster than dunning a customer who already paid | | Send each email after that day's retry, not before | Give the automatic fix a chance first; only ask the customer when the machine failed | | Front-load retries in week one, emails 3 and 4 in week two | Days 0 to 5 recover the transient declines silently; the human asks handle what is left |
Most billing systems expose retry outcomes as webhooks. Wire the email sequence to those events rather than to a fixed calendar, and the two systems stop fighting.
Email is not enough: use in-app banners too
Dunning emails land in promotions tabs, spam folders, and the inboxes of ex-employees who set up the account. An in-app banner does not have that problem: it reaches whoever actually uses the product, at the moment they are using it.
Show a dismissible banner from day 3 ("There is a payment issue on this account, update the card here"), and make it persistent from day 7. The person who sees the banner is often not the person who owns billing, and that is fine. "Hey, can you fix the card on our [Product] account?" sent internally is one of your best recovery channels.
When should a human pick up the phone?
For high-ACV accounts, automation is the wrong tool past day 7. If an account is worth $10,000 or more a year, a failed payment deserves a call or a direct message from their CS contact, not just email 3.
Two reasons. First, at that contract size the "failure" is often procurement friction: a new PO process, a switch to invoicing, a finance team that needs a W-9. Email templates cannot navigate that; a person can. Second, the cost math is absurd in your favor. Fifteen minutes of a human's time against five figures of ARR is the easiest trade in your company.
Set a simple threshold: above $X in ARR, a failed payment creates a task for a human on day 5. Below it, the sequence runs on its own.
What happens at the end of the sequence?
Pause the account. Do not silently cancel it.
Silent cancellation converts a fixable billing problem into permanent churn, and it burns customers who were on vacation, on leave, or waiting on their finance team. A paused account preserves everything: data, settings, history. The customer can come back with one card update, weeks later, and nothing is lost.
Cancellation, if it happens at all, should come after a further dormancy window (30 to 60 days paused) and one final notice. The customer who genuinely left will not care. The customer who was in the hospital for three weeks will care a great deal, and they will remember which kind of company you were.
The two metrics that matter
Skip the vanity metrics (open rates, click rates) and track two numbers:
- Recovery rate: of the payments that failed this month, what percentage did you eventually collect? Combine retries and dunning into one number, because the customer experiences them as one system. If you are below 20 percent, your sequence or your retry configuration is broken. Well-run setups reach 40 percent or better per Stripe's recovery guidance.
- Time-to-recovery: how many days from first failure to successful charge? Shorter is better for cash flow, but it also tells you which email in the sequence does the work. If most recoveries happen after email 3, your first two emails need stronger links or better subject lines.
Review both monthly. Dunning is a system you tune, not a set of emails you write once.
Related resources
RELATED
01 ·Involuntary churn: the cancellations you can fix with plumbing
A meaningful share of your churn is failed payments, not unhappy customers. Here is the recovery stack, in order, and a 30-minute audit to find your leak.