A declined card on a subscription renewal is not the end of the story. It is the beginning of a short window — typically 10 to 14 days — during which you can recover the payment and retain the customer before the subscription cancels automatically. What happens in that window is entirely determined by how you respond to the failure, how quickly you respond, and whether your emails make updating a card feel easy or frustrating.
Most SaaS businesses send one email and do not think much about it. Stripe sends a generic notification. The customer may or may not see it. The card may or may not get updated. This is leaving a recoverable 15–20% of failed payments on the table, every month, indefinitely. This guide covers the complete card declined recovery email system — the sequence, the copy, the technical requirements, and the decline-code nuances that change everything.
What you will learn
- Why one email is never enough — the three-email sequence explained
- Full copy examples for each email in the sequence
- How to vary copy by decline code type
- The direct update link requirement that doubles completion rates
- Subject lines that get opened vs. subject lines that get ignored
- What to do after the email sequence ends without recovery
📋 In this article
Why one email is not enough
Stripe sends one payment failure notification. It has generic copy, it links to a login page, and it arrives once. If the customer does not see it, does not act on it immediately, or ignores it planning to deal with it later, the subscription marches toward cancellation with no further prompting.
The data on payment recovery email sequences is consistent: a single email recovers approximately 15% of actionable failures. A three-email sequence over twelve days recovers 35–50%. The improvement comes not from pestering customers but from timing and context — the second email arrives when the customer may have missed the first, and the third arrives when the deadline is real and concrete.
The three-email sequence
Email 1 — Day 1: Soft notification
Timing: Send within 1–2 hours of the failed payment, while the customer may still have their banking app open following the declined transaction notification from their bank.
Subject lines that work:
- Action needed: payment issue on your [Product] account
- Your [Product] payment didn't go through
- Quick heads-up about your [Product] billing
Subject lines that do not work:
- URGENT: Your account is about to be cancelled!! (alarm language at day 1 signals desperation)
- We need your help (vague — gets ignored)
- [Product] billing update (too generic — no action implied)
Subject: Action needed: payment issue on your account
Hi [Name],
We had trouble processing your payment for [Product]. This happens sometimes — expired cards, bank restrictions, or temporary issues on our end.
Click below to update your payment details. It takes about 30 seconds and your subscription continues without interruption.
Update payment method →No login required — this link takes you directly to the payment update page.
Why this works: Matter-of-fact tone. Acknowledges it might not be their fault. One action. No alarm. The "no login required" note is important — it preemptively removes the most common friction objection.
Email 2 — Day 5–7: Moderate urgency with a deadline
Subject lines:
- Your [Product] account will be affected on [specific date]
- Payment still pending — your access ends [date] if unresolved
- Update needed before [date] to keep your account active
Subject: Your account will be affected on May 14 if unresolved
Hi [Name],
We sent you a note on [date] about a payment issue on your account. We haven't been able to process your payment yet.
Your account will be affected on May 14 if we can't collect payment. It takes 30 seconds to update your card — please do it before then.
Update before May 14 →The specific date is critical. "Your account will be affected soon" converts significantly worse than "Your account will be affected on May 14." The specific date creates a concrete, actionable deadline. Customers who read "soon" can defer. Customers who read "May 14" know exactly when they need to act.
Email 3 — Day 10–12: Final warning with loss framing
Subject lines:
- Last chance: your [Product] data is at risk
- Your account cancels tomorrow — update now to keep your history
- [Name], your [X months] of [Product] data will be lost tomorrow
Subject: Last chance — your account cancels tomorrow
Hi [Name],
Your [Product] account will be cancelled tomorrow due to an unresolved payment issue. Your [X months] of data, settings, and history will no longer be accessible after that.
Update your payment now — it takes 30 seconds and restores everything.
Update now and keep my data →If you're intentionally cancelling, you can ignore this email. We'll keep your data for 30 days in case you change your mind.
Loss framing is legitimate here. By day 10–12 the customer's account genuinely is about to cancel. Stating this specifically — "your X months of data will no longer be accessible" — is not manipulation. It is accurate information about a real consequence that the customer may not be fully aware of. The footnote acknowledging intentional cancellers is important: it reduces unsubscribes from customers who know they are leaving and just want to be left alone.
Varying copy by decline code
The standard three-email sequence works for most failure types. Two decline codes warrant different approaches:
expired_card: Customers whose card expired know exactly what the problem is — they need to add their new card. The email copy can be more direct and less apologetic: "Your card on file has expired. Add your new card below to continue without interruption." No need for "this sometimes happens" softening language. Skip retries entirely — an expired card cannot be charged. Send this email immediately, same day as the failure.
insufficient_funds: The tone here should be notably softer. The customer has not done anything wrong — their account is temporarily low. Do not send alarming subject lines. The first email can simply say: "We had a small issue processing your payment — we'll try again shortly." If retries on payday timing fail and you need to send a card update email, keep it factual and non-judgmental.
fraudulent / stolen: Do not send standard dunning copy to a customer whose card was reported stolen. They are dealing with a stressful situation. If you send any email at all, it should be empathetic and waiting for them to initiate: "We noticed an issue with your payment — when you're ready, updating your payment details will restore access."
The direct update link: the most important technical detail
Every card declined recovery email must link to a payment update page that works without the customer logging in first. This single requirement has more impact on recovery completion rates than any copy improvement you can make.
Customers who receive a payment failure email are reading it on their phone. When they click "update payment method" and land on a login page, most do not complete the login. They intend to come back to it. Most do not. The payment recovery window closes.
Stripe's hosted invoice page format — https://invoice.stripe.com/i/[invoice_id] — opens directly to the payment update form without requiring login. You can extract this URL from the invoice object in the invoice.payment_failed webhook event. Include this URL directly in your recovery emails.
✅ How to get the direct update URL from the webhook
invoice.hosted_invoice_url — available directly on the invoice object in the payment_failed event. This URL opens the hosted invoice page where the customer can update their payment method without logging in. Store it in your database alongside the dunning sequence and include it in every recovery email for this invoice.
After the sequence ends
If all three emails fail to produce a card update and the subscription cancels, the customer moves into a different category: they have involuntarily churned. The next communication should not be another payment failure email — it should be a reactivation message: "Your account was paused due to a payment issue. Your data is still here. One click to restore access."
This is different from a standard win-back campaign. The customer never made a decision to leave. The messaging should reflect that: no "we miss you," no discount to overcome resistance. Just a frictionless path back to an active subscription. See the involuntary churn guide for the full reactivation sequence.
Automate your card declined recovery sequence
Retainly sends the three-email sequence automatically, with direct update links, on the right schedule for each decline code. Free to start.
Start for free →Frequently asked questions
How many emails should I send when a card is declined?
Three emails over twelve days: day 1 (soft notification with direct update link), day 5–7 (moderate urgency with specific deadline date), day 10–12 (final warning with loss framing). A single email recovers approximately 15% of actionable failures. A three-email sequence recovers 35–50%. More than three emails starts generating spam complaints.
What should a card declined email say?
Email 1: matter-of-fact, non-alarming, one direct action with a login-free update link. Email 2: moderate urgency with a specific date the account will be affected. Email 3: loss framing — "your data is at risk" — with the strongest CTA. Each email should have one CTA only, linking directly to a payment update page that works without login.
Should I send the same email for all decline codes?
No. Expired card failures should receive a direct, specific email immediately — the customer needs to add their new card, and retrying the old one is pointless. Insufficient funds failures should use a softer tone, since the issue is temporary and not the customer's fault. Fraudulent or stolen card failures require careful, empathetic handling — not standard dunning copy.
Why does my recovery email need a direct update link?
Requiring customers to log in before they can update their card eliminates 50–70% of completions, especially on mobile. Most customers read payment failure emails on their phone. A login screen between "click" and "update form" causes most to defer — and most deferrals never complete. Use Stripe's hosted invoice URL or a tokenised direct-update link in every recovery email.
What happens to customers who don't update their card after three emails?
Once the subscription cancels, send a reactivation email — not a win-back campaign. These customers never chose to leave. The reactivation email acknowledges the billing issue, reassures them their data is intact, and provides a one-click reactivation link. Copy: "Your account was paused due to a payment issue. Your data is still here. Click to restore access." No discount needed.
Recovery email deliverability
A card declined recovery email that lands in spam is worth nothing. Deliverability is the invisible factor in payment recovery performance — a well-written three-email sequence with a direct update link and optimal timing will still fail if the emails are not reaching inboxes.
| Deliverability factor | What to do | Impact |
|---|---|---|
| SPF record | Authorise your sending service in DNS | Prevents "sent via thirdparty" labels |
| DKIM signing | Enable cryptographic email signing | Major spam filter trust signal |
| Subject line | Avoid URGENT, ALL CAPS, exclamation spam | Prevents promotional/spam folder routing |
| Send volume ramp | Do not suddenly send 1,000 dunning emails from a new domain | Prevents spam flag from volume spike |
Retainly sends recovery emails from your own domain using your Resend or SMTP configuration, ensuring the emails appear to come from you — not from a third-party service — and arrive with your full domain reputation.
Testing your recovery email sequence
Before sending recovery emails to real customers, test the complete sequence end-to-end with a test Stripe subscription. Create a test customer, fail a payment intentionally (using Stripe's test card numbers for specific decline codes), and verify that each email in the sequence fires at the right time with the correct dynamic content — customer name, specific account details, correct direct update link.
Common issues caught in testing: the hosted invoice URL expiring before the third email sends (Stripe's hosted invoice pages have time-limited URLs — regenerate them fresh for each email), personalisation tokens failing for customers with unusual characters in their names, and mobile rendering issues with email templates.
For the card declined scenario specifically: test with both 4000000000000002 (generic decline) and 4000000000000069 (expired card) test card numbers to verify that your decline-code logic routes the expired card correctly to immediate card update outreach rather than the standard retry sequence.
Tracking recovery rates by decline code
Once your three-email recovery sequence is running, the metric to track monthly is recovery rate by decline code. Your headline recovery rate is the average of many different failure types behaving differently — looking at the breakdown tells you where the system is working well and where it needs adjustment.
| Decline code | Expected recovery rate | If below: likely cause |
|---|---|---|
| expired_card | 40–60% | Email not sent immediately; update link requires login |
| insufficient_funds | 55–70% | Not using payday timing for retries |
| card_declined | 35–50% | Retrying too frequently; emails going to spam |
| processing_error | 85–95% on retry | Not retrying within 24 hours |
If your expired_card recovery rate is below 35%, the most likely cause is that your recovery email requires login before the update page. If your insufficient_funds rate is below 40%, you are probably retrying on a fixed day-3 schedule rather than payday timing. Both are configurable in Retainly's payment recovery settings.
Connecting recovery to win-back for unrecovered failures
The customers who do not update their card during the recovery window — approximately 50–65% of all failed payments, even with an optimised sequence — do not simply disappear. They are former customers whose last known intent was to stay subscribed. The right follow-up for this segment is a reactivation email, not a standard win-back campaign.
The reactivation email for a failed-payment churner should acknowledge the billing issue specifically, reassure about data retention, and provide a one-click reactivation link. No discount needed — no persuasion needed. The customer wants the product; they just need the friction removed.
Send this email 3–7 days after the subscription cancels, when the customer has had time to notice the loss of access but before they have fully adapted to its absence. Reactivation rates for involuntary churners via this email consistently run 18–30% — among the highest of any retention email type, precisely because there is no resistance to overcome.
For the complete reactivation sequence for involuntary churners, see the involuntary churn guide.
International card declines: special cases
SaaS businesses with international customer bases encounter a specific payment failure pattern that domestic-only businesses rarely face. International cards are declined more frequently than domestic cards for several structural reasons:
Bank fraud prevention flags. Many issuing banks flag recurring charges from foreign merchants as potentially suspicious, particularly for the first few billing cycles. A customer in Germany whose card is processed through a US-based Stripe account may see recurring charges declined on the basis of geographic mismatch rather than any actual fraud. These declines typically appear as do_not_honor or card_declined.
Currency conversion friction. Cards issued in one currency that are charged in another may hit bank-imposed limits on foreign currency transactions, or may decline when the converted amount exceeds a threshold the customer's bank has set.
The most effective solution for international card declines is Stripe's local payment method support — offering payment methods native to the customer's region (SEPA Direct Debit for Europe, iDEAL for the Netherlands, Bancontact for Belgium) in addition to card payments. Customers who pay via local methods have significantly lower failure rates than customers on international cards.
For businesses that cannot implement local payment methods immediately, the standard recovery email sequence remains the right approach — but the copy should acknowledge that international transactions sometimes require customer contact with their bank to whitelist recurring charges. "Your bank may have flagged this charge as unusual — a quick call to them is often all that's needed to resolve it" is a genuinely useful addition to the recovery email for do_not_honor failures from international customers.
Related: Stripe Dunning Best Practices · Failed Payment Recovery · Involuntary Churn Guide · What Is Dunning?