Dunning Email Generator: Create Payment Recovery Emails From Billing Context
Dunning copy has a narrow factual surface. An AI generator can help with tone and variants, but billing state, payment facts, grace periods, and account consequences must come from the billing system.
Inputs
| Input | Required rule |
|---|---|
| Payment attempt | Stable ID and timestamp |
| Failure category | Use provider data or a generic fallback |
| Amount and currency | Settled or attempted value from billing |
| Retry date | Actual scheduled retry |
| Account state | Active, grace period, limited, or canceled |
| Consequence | Approved product policy |
| Secure action | Authenticated billing portal |
Output specification
Ask for:
- subject and preheader;
- factual explanation;
- one primary payment action;
- retry and grace-period wording;
- suppression rules;
- an escalation variant;
- unsupported-claim warnings.
Safe prompt
Write a failed-payment email from the supplied billing event.
Use only the failure category and account consequence provided.
Do not mention card details, invent urgency, or threaten suspension.
Return copy, variables, exit conditions, and QA cases.Guardrails
- Generic failure means generic wording.
- A successful payment cancels all future dunning.
- A dispute routes to billing support.
- An expired card uses payment-method language.
- A security or bank-authentication step must be described accurately.
- Duplicate webhook events do not duplicate the sequence.
Evaluation
Review amount, currency, account state, dates, link authorization, and tone. Test payment success between every message, missing failure reason, canceled subscription, and manual payment plan.
The dunning email template is the implementation reference; this page describes how to generate its specification safely.
Map billing state to tone
The generator should choose language from the billing state, not from a generic “payment failed” label:
| Billing state | Useful framing | CTA |
|---|---|---|
| First soft decline, account active | “We couldn’t complete this payment” | Review payment method |
| Retry scheduled | Explain the next retry date | Update now or wait for retry |
| Authentication required | Explain the bank or issuer step | Complete secure verification |
| Grace period | State what remains available and until when | Resolve billing issue |
| Dispute or manual review | Avoid automated blame | Contact billing support |
| Canceled or closed | Confirm the final state | View account or invoice history |
The account state and consequence should be supplied by billing. The model can make the copy clearer, but it should not decide whether access is limited or when service ends.
Treat the retry schedule as data
Do not ask a language model to calculate retry dates from prose. Pass the scheduled timestamp, timezone, and account policy as typed fields. Re-read them before each message because a successful retry, manual payment, or plan change may have made the queued message obsolete.
Use an idempotency key based on payment attempt, sequence step, and recipient. A provider may retry a webhook, and a queue worker may retry a job; neither should create a second dunning sequence. Cancel pending sends on payment_succeeded, subscription_canceled, or a billing-agent hold.
Test the uncomfortable cases
Evaluate the generated draft with a generic decline, an expired card, a bank-authentication step, a disputed invoice, a zero-dollar invoice, a multi-currency account, and an enterprise account with a billing contact. Check that the amount, currency, dates, and account consequence are exact, and that secure actions link to an authenticated portal rather than asking for card details in the email.
Review guardrails alongside conversion:
| Measure | Why it matters |
|---|---|
| Payment recovery rate | Shows whether the path works |
| Recovery by attempt number | Finds a bad retry or delay policy |
| Support and dispute volume | Catches confusing or accusatory copy |
| Unsubscribe and complaint rate | Detects promotional framing on a service problem |
| Duplicate-send rate | Validates idempotency and cancellation |
The generator is successful when it makes billing policy easier to express and audit—not when it makes a failed payment sound more dramatic.