Template
Sent when the bank flagged the transaction (do_not_honor, generic_decline, call_issuer). The card is valid; the bank blocked this specific charge. Goal: explain this is a routine bank fraud flag (not a card problem) and give two clear paths to fix it.
A/B test these. Lowercase, question format, and specific-time framings consistently win.
Your bank blocked our chargeQuick - bank issue with your {{product_name}} paymentYour bank declined the {{amount}} chargeHi {{first_name}},
Your bank declined our ${{amount}} charge for {{product_name}}.
This usually happens when a recurring charge gets flagged as
suspicious - annoying, but easy to fix.
Two options:
1. Call your bank and tell them to approve charges from
"{{billing_descriptor}}"
2. Use a different card:
→ {{secure_update_link}}
Option 2 is faster for most people.
- {{sender_first_name}}Variables in {{like_this}} should be replaced with your merge fields.
Demystifies the "fraud flag" (which sounds alarming) by framing it as routine. Gives two concrete paths instead of one, so the customer picks the one they prefer. Includes the exact billing descriptor for the bank call, eliminating friction. Option 2 first because it is faster in practice.
No. Most do_not_honor flags are bank risk heuristics, not actual fraud determinations. Using the word "fraud" causes customer anxiety and support tickets. "Flagged as suspicious" is a safer, accurate framing.
At most twice, spaced at least 24 hours apart. Unlike insufficient_funds, aggressive retrying of do_not_honor hurts your merchant account standing with card networks.
Automate this with Rebounce
Rebounce detects payment failures via Stripe Connect, classifies them by decline code, and runs the optimal dunning sequence across email, SMS, WhatsApp, and in-app banners. The templates above are the exact patterns Rebounce uses out of the box - you can adapt the copy to your brand voice and Rebounce handles delivery, timing, and sequence cancellation when a retry succeeds.
Start free trialThe first email sent immediately after a payment fails, before any retry. Goal: catch the 40-60% of failures that resolve with a simple nudge, before the customer feels embarrassed or annoyed.
Sent when a payment fails with insufficient_funds. Customers in this bucket are often experiencing cash flow issues and aggressive emails here cause churn and support tickets. Goal: keep them as a customer long-term even if this payment cycle needs flexibility.
Sent when the bank requires 3D Secure / Strong Customer Authentication (SCA) before approving the charge. Almost always an EU or UK customer. Goal: explain this is standard, normalize the verification step, link to the 3DS challenge.