SaveMyMRR
Log inStart for free

Last updated: July 2026

7 dunning email templates you can paste in today

A ready-to-ship library of failed-payment emails — first failure, soft reminder, card expired, grace period, final notice, win-back and a recovery confirmation — each with a subject line, alternates for A/B testing, and a note on why the copy is written the way it is. Built for SaaS founders billing on Stripe, not generic accounts-receivable.

Every template maps to a specific point in the retry timeline further down the page, so you know not just what to send but when — tied to when Stripe re-attempts the card.

Automate this sequence — freeWatch it run

Copy them for free below, or connect Stripe to send them automatically.

The merge fields, once

Every template uses the same handful of placeholders. Swap them for your billing system's merge tags (Stripe Billing, Postmark, Resend and SaveMyMRR all expose equivalents):

Merge fields used across the dunning email templates
PlaceholderWhat it becomes
{first_name}Customer's first name (fall back to a neutral greeting if empty)
{business}Your product / brand name — never your dunning tool's name
{amount}The invoice total in its real currency, e.g. $29.00
{update_url}Stripe Customer Portal or hosted invoice link to re-enter a card
{deadline_date}The date access pauses — a concrete day, not "soon"

The templates

Copy the subject and body straight out. Each card also lists two alternate subject lines to A/B test, and a short note on the one thing that template is doing that a generic "your payment failed" email doesn't.

1. First failure — friendly heads-up

Day 0, within minutes of the decline

Subject

Your payment to {business} didn't go through

A/B alternates

  • Quick fix needed: your {business} payment failed
  • {first_name}, your card was declined

Hi {first_name},

We tried to charge {amount} for your {business} subscription today, but your card was declined. This is almost always something small — an expired card, a temporary bank block, or not quite enough in the account at that moment.

You can fix it in a few seconds with the secure link below. Nothing changes on your account in the meantime.

[ Update payment method → {update_url} ]

We'll try again automatically, so if you sort it out on your side there's nothing else to do.

Thanks, The {business} team

Why it's written this way: Lead with the fact, not an apology. Naming the amount and the likely cause (expired card / bank block) removes the fraud-scare reflex that makes people ignore the email. No deadline yet — this is a nudge, not a threat.

2. Soft reminder — still no fix

Day 3, after the first retry has failed

Subject

Still can't process your {business} payment

A/B alternates

  • Reminder: {amount} is still outstanding
  • {first_name}, a quick reminder about your card

Hi {first_name},

Just following up — we still weren't able to charge {amount} for your {business} subscription. Your access is active for now, but it will pause if the payment can't be collected.

Updating your card takes under a minute:

[ Update payment method → {update_url} ]

If you've already updated it, ignore this — the next automatic retry will pick up the new card.

Thanks, The {business} team

Why it's written this way: Introduce the consequence ('access will pause') without a hard date. Keep it a single action. The 'if you've already updated it, ignore this' line cuts support replies from customers who fixed it between emails.

3. Card expired — the hard-decline variant

Send instead of #2 when the decline code is expired_card / incorrect_number

Subject

Your card on file with {business} has expired

A/B alternates

  • Time to update the card on your {business} account
  • {first_name}, your saved card is out of date

Hi {first_name},

The card we have on file for your {business} subscription has expired, so we can't collect the {amount} due. Retrying the same card won't help here — we just need the new expiry date or a new card.

[ Update card → {update_url} ]

It takes about 30 seconds and keeps your subscription running without a break.

Thanks, The {business} team

Why it's written this way: For an expired or invalid card, retrying is pointless — say so. This template exists because a generic 'payment failed' email wastes the one clear action (re-enter the card) on a customer whose card literally cannot be retried. If your tool can't branch on the decline code, send this whenever Stripe returns expired_card.

4. Grace period — access still on, deadline set

Day 5, framing a concrete cut-off

Subject

{first_name}, your {business} access pauses in 2 days

A/B alternates

  • 2 days left to keep your {business} subscription active
  • Action needed before {deadline_date}

Hi {first_name},

We've tried a few times to collect {amount} for your {business} subscription and it hasn't gone through. To avoid losing access on {deadline_date}, please update your payment method:

[ Keep my subscription → {update_url} ]

Everything you've set up stays exactly as it is — you just need a working card on file.

If money's the issue and you'd rather pause or change plan, just reply and we'll sort something out.

Thanks, The {business} team

Why it's written this way: The concrete date ({deadline_date}) is the single biggest lever in dunning copy — a vague 'soon' converts far worse than 'pauses on Thursday'. The 'reply and we'll sort something out' line quietly saves voluntary churners who'd otherwise walk.

5. Final notice — last email before stop

Day 7, before the sequence gives up

Subject

Final notice: {business} access ends today

A/B alternates

  • Last chance to keep your {business} subscription
  • {first_name}, this is the last reminder

Hi {first_name},

This is the last reminder about the {amount} we couldn't collect for your {business} subscription. Without a working card, your access ends today and the subscription will be cancelled.

You can still keep everything by updating your card now:

[ Reactivate now → {update_url} ]

If you meant to cancel, no action is needed and there's nothing more you'll hear from us.

Thanks, The {business} team

Why it's written this way: Firm, not aggressive. State the outcome plainly. The 'if you meant to cancel, no action needed' close is honest and stops the email reading like debt collection — which is the fastest way to turn an involuntary churner into a chargeback.

6. Win-back — after the subscription lapsed

Day 14–30 after cancellation, one-off

Subject

We kept your {business} data — come back any time

A/B alternates

  • Your {business} account is still here
  • {first_name}, pick up where you left off

Hi {first_name},

Your {business} subscription lapsed a couple of weeks ago because a payment couldn't be collected. We've kept your account and data intact in case it was a card issue rather than a decision to leave.

If you'd like to pick back up, one click restarts everything on a fresh card:

[ Reactivate my account → {update_url} ]

And if it's not the right time, no worries at all — thanks for having been a customer.

Thanks, The {business} team

Why it's written this way: A win-back is not a dunning email — send it once, later, and never chase. Its job is to catch the sizeable share of involuntary churners who never realised their card had failed. 'We kept your data' is the hook; framing it as their choice keeps it from feeling like nagging.

7. Recovery confirmation — close the loop

Immediately after the retry succeeds

Subject

You're all set — {business} payment received

A/B alternates

  • Payment confirmed for {business}
  • Thanks {first_name}, your card went through

Hi {first_name},

Good news — we've successfully charged {amount} for your {business} subscription and your access is fully restored. Nothing else to do.

Thanks for sorting that out.

The {business} team

Why it's written this way: Most sequences forget this one. A one-line confirmation stops the customer wondering whether they've been double-charged (a real chargeback trigger) and ends the sequence on a positive note instead of silence.

The send schedule, mapped to Stripe retries

Templates are only half the job — timing is the other half. Below is the cadence SaveMyMRR actually runs, with each step showing whether the card is retried, whether an email goes out, and which template it should carry. Retrying the card is silent; the email is what makes the customer act, so they're paired.

Dunning send schedule mapped to Stripe card-retry attempts
WhenRetry the card?Send email?Which template
On failure (0h)NoYesFirst failure (#1)
Day 1 (24h)Yes — invoices.payYesSoft reminder (#2) / Card expired (#3)
Day 3 (72h)NoYesSoft reminder (#2)
Day 5 (120h)Yes — invoices.payYesGrace period (#4)
Day 7 (168h)Stop — mark churnedNoFinal notice (#5) already sent at day 7 — sequence stops

Why day 0/1/3/5/7 and not daily for two weeks? Soft declines — insufficient funds, a jittery bank hold — usually clear within a few days once a payday lands, and a card that hasn't recovered after a week rarely does. Spacing the retries this way targets the recoverable window without training customers to ignore you. See the same cadence run on sample data on the demo, or read the full mechanics in how it works.

Subject-line rules that move recovery rate

A dunning email that never gets opened recovers nothing, so the subject line is doing more work than the body. Five rules, each tied to a concrete reason rather than generic advice:

Subject-line best practices for dunning emails
RuleWhy it matters
Name the brand, not "SaveMyMRR" or your toolThe customer recognises the product they pay for, not your dunning vendor. Subjects starting with the merchant's own name get opened; a stranger's name gets marked spam.
Say what happened in the subject — don't tease"Payment failed" or "card declined" beats "Important account notice". Curiosity-gap subjects read as phishing on a money email, which is exactly when people are wariest.
Put the amount or a deadline in later emails"{amount} outstanding" and "access pauses in 2 days" give a reason to act now. Concrete beats vague at every step past the first.
Personalise with the first name once, not every sendOne {first_name} in the subject lifts opens; using it on all five reads as automated and loses the effect. Rotate it in for the reminder and final notice.
Avoid ALL CAPS, "URGENT", and multiple !!!Gmail and Outlook spam filters weight these heavily on transactional-looking mail, and they push a legitimate recovery email into the promotions tab or spam — where it earns nothing.

A/B testing without a big list

Failed-payment volume is low, so classic 50/50 subject splits take forever to reach significance. Two practical shortcuts for a small SaaS:

Tone: keep the customer, don't sound like collections

The single most expensive mistake in dunning copy is treating an involuntary churner like a debtor. Most failed payments aren't someone dodging you — it's an expired card or a bank hold they haven't even noticed. Copy that reads like a debt notice turns a recoverable customer into a chargeback or a spam complaint.

Do

  • "It happens — usually an expired card."
  • "Your access is active for now."
  • "If money's tight, reply and we'll sort it out."
  • "Ignore this if you've already updated it."

Avoid

  • "Outstanding balance" / "amount owed"
  • "Final demand" / "debt"
  • ALL CAPS, "URGENT", triple exclamation marks
  • Guilt or threats about "your account standing"

Escalate firmness gradually — friendly at day 0, a clear deadline by day 5, plain about the outcome at day 7 — but never cross into collections language. There are also card-network rules on how you may dun a customer; staying courteous keeps you on the right side of them.

When to stop copy-pasting and automate

These templates are genuinely enough to start — paste them into Stripe Billing's custom emails or your transactional provider and you'll recover revenue you're losing today. But manual dunning breaks down at a predictable point:

That's exactly what SaveMyMRR automates: it watches your failed Stripe invoices on a restricted key, runs the day 0/1/3/5/7 cadence above, retries the card with invoices.pay at the right steps, and on Pro writes each email per-customer instead of a fixed template — falling back to copy like the templates above if the AI call fails.

Send this whole sequence automatically — free to start, no card.

Connect Stripe & recover

Or see what you're losing first with the involuntary-churn calculator.

Dunning emails — FAQ

How many dunning emails should I send, and over how many days?

For most SaaS, five touches over about a week is the sweet spot: a heads-up at failure, a reminder around day 3, a deadline email at day 5, and a final notice at day 7 before you stop. That window matches how long a spaced-out card retry stays useful — soft declines like insufficient funds usually clear within a few days when a payday lands, and after ~7 days a card that hasn't recovered rarely will. A separate win-back email 2–4 weeks later catches people who never noticed. Sending daily for two weeks trains customers to ignore you and raises spam complaints.

Should each email fire at the same time as the Stripe retry?

Not exactly — offset them. Retrying the card is silent; the email is what prompts the customer to act. A good pattern is: email immediately on failure (no retry yet), retry the card at day 1 with a reminder, remind again at day 3, retry once more at day 5 with a deadline, then a final email at day 7. That way each card retry has a fresh email behind it nudging the customer to fix an expired or wrong card, which no retry can recover on its own. SaveMyMRR ships exactly this cadence.

What tone works best — friendly or firm?

Escalate. Start genuinely friendly and assume the best ("it happens — usually an expired card"), because most failed payments are involuntary, not people dodging you. Get firmer and more specific as the sequence goes on, adding a concrete deadline by the grace-period email. Never sound like collections: language like "outstanding balance", "debt" or "final demand" turns an involuntary churner into a chargeback and can breach card-network rules on how you dun a customer. The goal is to keep the customer, not to win an argument.

Do dunning emails actually recover much revenue?

Involuntary churn — failed payments rather than cancellations — is commonly estimated at 20–40% of total churn for subscription businesses, and a meaningful slice of those failures are recoverable because they're temporary (a bank hold, a payday timing miss, a card that just needs re-entering). A dunning sequence that pairs card retries with clear emails is how you claw that back. The honest caveat: some of those cards would have cleared on Stripe's own retries anyway, so measure the lift, not just the raw recovered total.

Can I just use Stripe's built-in payment-failed emails?

You can, and for a very small SaaS it's better than nothing. But Stripe's default emails are limited: a fixed template, Stripe's branding unless you configure your logo, no custom cadence, and no per-email A/B testing. The templates on this page give you copy you control and a send schedule you can tune. When maintaining that by hand gets old, that's the point to automate it — which is what SaveMyMRR does on a restricted Stripe key.

What should the call-to-action link point to?

A single action: update the payment method. On Stripe, the cleanest target is a Billing Customer Portal link or the hosted invoice page, both of which let the customer re-enter a card and pay without logging into your app. Use one button, repeated once in the body if the email is long — multiple competing links lower click-through. Never bury the update link below other content or navigation.

Related reading: how Stripe Smart Retries work, the Stripe dunning tool overview, and the reduce involuntary churn playbook.