Write a complete failed-payment sequence with eight original dunning email templates, retry-aware timing, secure payment-update links, stop conditions, and recovery metrics.
A dunning email tells a customer that a payment failed or remains unpaid, explains the service consequence, and gives them a safe way to resolve it. Good dunning is synchronized with the billing system: each message reflects the current invoice, retry schedule, payment method, subscription state, and access policy rather than firing from a generic marketing delay.
The sequence below covers pre-failure prevention, the first failure, scheduled retry, action-required failure, grace period, final notice, recovery, and cancellation. Every example is original. Replace bracketed fields from authoritative billing state and remove timing or service claims your product cannot guarantee.
Dunning sequence at a glance
EVENT / STATE MESSAGE PRIMARY ACTION
Card expiring soon Preventive notice Update method
First payment failure Clear, low-alarm notice Review billing
Retry scheduled Reminder with exact retry date Update before retry
Action required Authentication/new method needed Complete secure action
Grace period nearing end State service consequence Resolve balance
Final attempt / notice Exact deadline and next state Pay now or contact support
Payment recovered Resolution confirmation No action
Subscription ended Factual closure Restore or export if eligible
The processor event advances state; opening an email does not.What every dunning email should contain
- Recognizable product, merchant, workspace, and billing sender.
- Current amount and currency tied to a customer-facing invoice or billing reference.
- Plain-language state: failed, retry scheduled, action required, past due, paid, or canceled.
- Exact retry or service deadline with date, time, and timezone when it matters.
- Masked payment method when it helps recognition, never full account or card data.
- One secure route to authenticated billing or a processor-hosted payment-update page.
- The real product consequence under the current grace and access policy.
- Monitored support for disputes, purchase-order processes, or a customer who cannot self-serve.
1. Card-expiration prevention email
Subject: Your [Product] payment method expires this month
Hi [First name],
The [card brand] ending in [last four] for [Workspace] expires in [month/year].
Your next [amount currency] renewal is scheduled for [date].
Update the payment method before then to avoid an interruption.
[Review billing securely]
If your bank has already updated this card automatically, no action may be needed.
You can confirm the current method on the billing page.This is prevention, not a failed-payment notice. Send it only when the stored method and renewal are still relevant. Stripe can send card-expiration notifications for default methods; if both Stripe and your application send, coordinate them so the customer does not receive duplicate warnings.
2. First payment failure
Subject: We couldn’t process your [Product] payment
Hi [First name],
We couldn’t process the [amount currency] payment for [Workspace / invoice].
Your account is still [active during the grace period / in its actual state].
Payment method: [brand] ending in [last four]
Invoice: [reference]
Next attempt: [date and timezone, or no automatic retry]
[Review payment details]
Banks do not always tell us the exact reason. Your billing page shows the safest
next step. If you have already updated the method, you can ignore this message.Lead with the failed state, not blame. Decline messages are often generic, and translating them into a false explanation such as insufficient funds can embarrass the customer and be wrong. Show only a processor-supported reason when it is suitable for the customer.
3. Automatic retry reminder
Subject: We’ll retry your [Product] payment on [date]
Hi [First name],
Your [amount currency] invoice for [Workspace] is still unpaid. We plan to retry
the [masked method] on [date and timezone].
No action is needed if the payment method is now valid. To use a different
method before the retry, update it here:
[Update payment method]
Current service status: [accurate status]
Invoice: [reference]Read the next attempt from the billing provider rather than calculating it from the email sequence. Stripe exposes retry state through invoice events and fields, with details that can differ when automations are enabled. Treat the billing record as authoritative.
4. Action-required payment email
Subject: Action required to complete your [Product] payment
Hi [First name],
Your [amount currency] payment for [Workspace / invoice] needs your confirmation
or a new payment method before it can complete. We cannot finish this step for you.
[Complete payment securely]
The secure page shows the action requested by your payment provider. This link
expires under the billing-page policy. Support will never ask for your card details
or the full link by email.
Service status: [accurate state and deadline]Some failures cannot be fixed through repeated charging. Stripe documents hard-decline conditions where a new method is needed before another execution can succeed. Make the call to action match that state instead of telling the customer to wait for a retry that cannot run.
5. Grace-period reminder
Subject: [Workspace] has [number] days to resolve its balance
Hi [First name],
Invoice [reference] for [amount currency] remains unpaid. Under your plan's
billing policy, [specific capability or account] will change on [date and timezone]
if the balance is not resolved.
Until then: [precise access state]
After that date: [precise consequence]
[Resolve the balance]
Need a purchase order, billing contact change, or help with the invoice?
Contact [monitored billing support].Describe the consequence narrowly. Do not threaten immediate deletion if the product only pauses paid features, and do not promise preserved data if retention policy says otherwise. Enterprise billing often needs a human route because the reader may not control the payment method.
6. Final dunning notice
Subject: Final notice: resolve [Workspace] billing by [date]
Hi [First name],
We have not received the [amount currency] payment for invoice [reference].
The current recovery period ends on [date and timezone].
If payment remains unresolved, [subscription/account] will [exact configured state].
[State data access or retention only if confirmed by policy.]
[Pay or update payment method]
If this invoice is disputed or being handled by your finance team, contact
[billing support] before the deadline and include [safe reference].Final must mean final under the configured sequence. Continuing to send identical final notices destroys trust and creates operational confusion. If the deadline changes, send a clearly labeled correction with the new state and reason.
7. Payment recovered
Subject: Payment received—[Workspace] billing is current
Hi [First name],
We received the [amount currency] payment for invoice [reference] on [date].
[Workspace] is now [active / actual current state], and no further payment action
is required for this invoice.
Payment method: [masked method]
Next renewal: [date, if known]
[View receipt and billing history]
Thanks for taking care of it.Trigger this from verified payment success and cancel pending reminders atomically with the billing-state update. A browser return page is not sufficient evidence. If access restoration is asynchronous, say payment received and explain when restoration will complete rather than claiming it already happened.
8. Subscription ended after nonpayment
Subject: [Workspace]’s [Product] subscription has ended
Hi [First name],
The recovery period for invoice [reference] ended without payment, and the
subscription changed to [canceled / unpaid / actual state] on [date].
Current access: [specific state]
Data availability: [verified retention/export policy]
Outstanding balance: [amount currency and status]
[Review billing or restore service, if eligible]
For a billing dispute or help retrieving eligible data, contact [support].Cancellation, unpaid, and past_due are different states. Stripe lets businesses configure what happens after retries are exhausted. Render the state actually chosen for that account and stop retry language once the final attempt has ended.
Wire dunning to billing events
PAYMENT PROVIDER WEBHOOK
verify signature -> deduplicate event -> retrieve current invoice/subscription
|
v
BILLING STATE TRANSACTION
record attempt + next attempt + access state + unique message intent
|
v
EMAIL WORKER
re-check current state -> render exact facts -> send idempotently
|
v
SUCCESS / TERMINAL EVENT
cancel queued reminders -> send one resolution message -> preserve audit trail- Verify webhook signatures against the raw request body and deduplicate provider event IDs.
- Expect events to arrive late or out of order; re-read current invoice and subscription state before sending.
- Give each invoice-state transition one stable message intent and make provider submission retry-safe.
- Suppress a scheduled dunning email if payment succeeded, the invoice was voided, or the account changed before send time.
- Separate billing lifecycle from promotional automation and protect it from campaign frequency caps or pauses.
- Store message IDs and delivery outcomes where billing support can search them using a safe invoice reference.
What to measure
- Recovery rate and recovered amount by attempt, message, payment method, plan, and customer segment.
- Time from first failure to successful payment and to restored service.
- Payment-update completion—not email click rate alone.
- False or stale reminders sent after payment, cancellation, void, or manual resolution.
- Delivery delay, bounce, and complaint rate for billing owners versus other recipients.
- Support contacts, disputes, voluntary cancellations, and involuntary churn after the final state.
Attribute recovery conservatively. Stripe's recovery analytics separates recovered payments associated with retries, emails, and other paths. A recipient may update a card without clicking the email, or a retry may succeed without an update. Optimize for accurate recovery and customer continuity, not for inflating email attribution.
Frequently asked questions
What does dunning mean?
Dunning is the process of communicating about and recovering an unpaid balance. In subscription software it usually combines payment retries, failed-payment emails, a grace or access policy, self-service payment updates, support escalation, and a terminal subscription state.
How many dunning emails should I send?
Use only the messages justified by meaningful billing-state changes: first failure, scheduled retry or required action, approaching consequence, and final outcome. The right count depends on retry duration, price, customer type, payment method, access policy, and sales motion. More reminders are not automatically more recovery.
When should dunning emails stop?
Stop immediately when the payment succeeds, invoice is voided or forgiven, subscription ends under policy, customer leaves the collection path, or a support-controlled process takes ownership. Queue cancellation and send-time state checks should both enforce the rule.