templates Failed Payment Email Templates
Failed-payment email should be plain, specific, and tied to a secure billing action. These templates avoid promotional copy and keep the account state clear.
last updated 2026-08-13 4 templates
implementation note
Replace variables before sending, keep one primary action per email, and connect each template to a specific trigger rather than a generic drip schedule.
01 First failed charge
Send after the first failed invoice payment. subject
Payment failed for {{product_name}}
preview
Update the payment method to keep {{account_name}} active.
body
Hi {{first_name}},
The latest payment for {{account_name}} did not go through.
Plan: {{plan_name}}
Amount: {{invoice_amount}}
Update the payment method here: {{billing_update_url}}
Access stays active during the grace period. If this looks wrong, reply to this email and billing support will check it.
{{product_name}} billing variables
{{first_name}}{{product_name}}{{account_name}}{{plan_name}}{{invoice_amount}}{{billing_update_url}}
mistakes to avoid
- ›Do not include a discount or upgrade pitch.
- ›Do not expose sensitive card details.
- ›Do not send without a secure billing URL.
02 Expired card
Send when the payment processor returns an expired-card code. subject
Card update needed for {{product_name}}
preview
The card on file appears to be expired.
body
Hi {{first_name}},
The card on file for {{account_name}} could not be charged and may be expired.
Update the payment method here: {{billing_update_url}}
The account remains active until {{grace_period_end}}. No product settings will change before then.
{{product_name}} billing variables
{{first_name}}{{product_name}}{{account_name}}{{billing_update_url}}{{grace_period_end}}
mistakes to avoid
- ›Do not guess at processor details beyond the returned code.
- ›Do not hide the grace-period date.
- ›Do not link to a generic account page when a billing link exists.
03 Grace period reminder
Send midway through the grace period if payment is still unpaid. subject
{{account_name}} billing needs attention
preview
Access stays active until {{grace_period_end}}.
body
Hi {{first_name}},
Payment for {{account_name}} is still unresolved.
Access stays active until {{grace_period_end}}. After that, the account may be paused until payment is updated.
Secure billing link: {{billing_update_url}}
Questions can be sent by replying here.
{{product_name}} billing variables
{{first_name}}{{product_name}}{{account_name}}{{grace_period_end}}{{billing_update_url}}
mistakes to avoid
- ›Do not send every day by default.
- ›Do not threaten data deletion unless that policy is accurate.
- ›Do not route replies to an unmonitored inbox.
04 Account paused
Send when the billing system pauses access after the grace period. subject
{{account_name}} is paused
preview
Update payment to restore access.
body
Hi {{first_name}},
{{account_name}} is paused because payment could not be completed before {{grace_period_end}}.
Access can be restored after the payment method is updated: {{billing_update_url}}
If payment has already been updated, reply with the invoice number {{invoice_id}} and support will check the account.
{{product_name}} billing variables
{{first_name}}{{account_name}}{{grace_period_end}}{{billing_update_url}}{{invoice_id}}{{product_name}}
mistakes to avoid
- ›Do not imply cancellation if the account is only paused.
- ›Do not omit the restoration path.
- ›Do not use marketing language in an account-status email.
reading this as developers picking email infrastructure
The question here is which one a backend engineer would rather operate. That means SDK depth in the language already in use, whether a retry can safely be replayed, how much the event log tells you when a customer says the email never arrived, and whether the pricing curve stays sane as volume grows.
Applied to failed payment email templates, that means weighing developer experience, SDK breadth, idempotency keys, and operating track record ahead of the rest, against password resets, receipts, and magic links shipped from application code.