Dunning Email Template for Failed Payments and Grace Periods

Dunning is the recovery path after a billing attempt fails. The email should reduce uncertainty without shaming the customer: identify the account, give one secure action, explain the next checkpoint, and state the real consequence of inaction.

Start with the payment event

Do not write “your card was declined” when the provider only returned a generic failure. Preserve the event’s factual reason and use a safe fallback.

Event data	Copy use	Fallback
Account or workspace	“Your Acme Analytics payment needs attention”	Product name
Amount and currency	Confirm what was attempted	Omit if unavailable
Failure category	Explain expired card, insufficient funds, or generic failure	“We could not complete the payment”
Retry date	Set expectation	“We will retry soon”
Grace-period end	Explain service impact	Do not promise a date the product does not enforce
Billing portal	One primary action	Support contact if unavailable

Use the same subscription state that powers the product. If the account is still active, say so. If access is limited, say what is limited and when.

A staged sequence

Stage	Goal	Stop condition
First failure	Make the issue easy to fix	Payment succeeds or subscription is canceled
Retry reminder	Explain the next attempt	Updated method or successful retry
Grace-period notice	Explain the real deadline	Payment, cancellation, or manual review
Final notice	Confirm the consequence	No additional promotional follow-up

Avoid sending all four messages in one day. Use the provider’s retry schedule and suppress after any successful payment event.

Template

Subject: We couldn’t process your {{product_name}} payment

Preheader: Update your payment method to keep your account active.

Hello {{customer_name}},

We couldn’t complete the {{amount}} payment for {{product_name}} on {{attempt_date}}. Your account is {{account_state}} while we retry the payment.

[Update payment method]

{{failure_explanation}}

We will try again on {{retry_date}}. If the payment is not successful by {{grace_period_end}}, {{actual_account_consequence}}.

If you believe this is an error, contact {{support_email}} and include account ID {{account_reference}}. Please do not email card details.

{{company_name}}

Failure explanations

Use only values supplied by the processor:

• Expired: “The payment method on file has expired.”
• Insufficient funds: “The payment provider reported insufficient funds.”
• Generic: “The payment provider could not complete the charge.”
• Authentication required: “Your bank requires an additional verification step.”

Never expose processor codes, card data, or an unsupported claim that the customer canceled the payment.

Suppression and idempotency

The workflow needs a stable payment-attempt ID. Do not create duplicate reminders when a webhook is delivered twice. Cancel queued messages when:

• a payment succeeds;
• the customer updates the method;
• the subscription is canceled;
• the account is placed under manual billing review;
• the grace period ends and another product state owns the communication.

QA checklist

• Replay duplicate and out-of-order payment events.
• Verify currency, amount, dates, and account state.
• Test a missing failure reason.
• Confirm the update link requires the correct account authorization.
• Confirm every follow-up stops after payment success.
• Check that the message remains useful when the customer is on mobile.

For AI-assisted versions, see the dunning email generator. For a narrower card-expiration event, use the card expiration template.

Keep the sequence from becoming noise

Use the processor’s retry events as the source of truth, but add a quiet period so a burst of webhook failures does not create a burst of emails. A practical policy might be:

Situation	Communication
First failed attempt	One clear recovery email
Retry scheduled	A reminder only if the first action was not completed
Repeated failure	Explain the actual grace-period date
Customer contacted support	Pause automated escalation
Payment recovered	Confirmation or no further dunning

The exact timing belongs in the billing policy. The important point is that each message has a different job and that the customer can see which state the account is in.

Claims and compliance review

Have finance approve currency, tax, late-fee, suspension, and collection language. Have security review the billing URL and the way account references are exposed. An AI-generated sentence such as “your account will be deleted” is unacceptable unless the product really does that under the customer’s contract.

Test with customers who pay by invoice, customers on a grace period, and customers with multiple subscriptions. Those cases often require different recipients and different next actions.