# Dunning emails: 8 examples that recover failed payments > Write a complete failed-payment sequence with eight original dunning email templates, retry-aware timing, secure payment-update links, stop conditions, and recovery metrics. - **Category:** Email examples - **Published:** August 4, 2026 - **Reading time:** 17 min read - **Author:** Maya Chen, Email infrastructure - **Canonical page:** [https://emailbump.com/blog/dunning-email-examples](https://emailbump.com/blog/dunning-email-examples) 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. > **Retry logic owns the calendar** > > If the processor will retry automatically, tell the customer the real next attempt. If a hard decline requires a new payment method, do not promise another automatic charge. Stop every reminder as soon as payment succeeds, the invoice is voided, or the subscription reaches its terminal state. ## Dunning sequence at a glance ### Retry-aware dunning sequence ```text 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 ### Expiring payment method template ```text 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 ### First dunning email template ```text 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 ### Retry scheduled template ```text 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 ### Customer action required template ```text 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 ### Grace period dunning template ```text 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 ### Final failed-payment notice ```text 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 ### Dunning recovery template ```text 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 ### Nonpayment closure template ```text 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 ### Dunning state pipeline ```text 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. ## Build lifecycle email around real product events Connect contacts, account state, transactional events, and automated flows while keeping critical billing messages observable and separate from ordinary campaigns. - Event-triggered flow entry and exit - Live customer segments and suppression - Transactional delivery events and metadata [Learn more](https://emailbump.com/docs/automations) ## Complete the billing lifecycle - [Payment confirmations](https://emailbump.com/blog/payment-confirmation-email-examples) — Confirm successful purchases, renewals, asynchronous payments, and refunds accurately. - [Stripe webhook email](https://emailbump.com/blog/send-emails-from-stripe-webhooks) — Turn signed payment events into effective-once email jobs. - [SaaS email marketing](https://emailbump.com/blog/saas-email-marketing) — Connect billing recovery to activation, adoption, retention, and expansion. - [Transactional subjects](https://emailbump.com/blog/transactional-email-subject-lines) — Write clear subjects for payment failures, receipts, and account changes. ## Sources - [Stripe Revenue Recovery](https://docs.stripe.com/billing/revenue-recovery) - [Stripe Smart Retries](https://docs.stripe.com/billing/revenue-recovery/smart-retries) - [Stripe customer emails](https://docs.stripe.com/billing/revenue-recovery/customer-emails) - [Stripe recovery analytics](https://docs.stripe.com/billing/revenue-recovery/recovery-analytics) - [Stripe webhook signatures](https://docs.stripe.com/webhooks/signature)