Failed payment recovery: 5 email automations that actually work

For a subscription business, failed payments are the cheapest churn to prevent — most are cards that expired, not customers who wanted to leave. But the default Stripe dunning email is generic, and most CRM-driven "payment recovery" campaigns are either too aggressive or too quiet. Here are five concrete email automations that recover 30–60% of involuntary churn, with the exact Stripe events each one should trigger on.

Why failed payments matter more than you think

Involuntary churn — failures caused by expired cards, insufficient funds, or bank declines — typically accounts for 20–40% of total churn at any SaaS with credit card billing. At a $500k ARR company, that's $100k–$200k in revenue leaking out of the business annually. And almost all of it is recoverable, because the customer didn't actually want to cancel. Their card just expired.

Stripe's default dunning does something — it retries the charge and sends a generic email — but the conversion rate on Stripe's built-in email is low because it reads like a bank notification, not a message from the business the customer actually bought from. Replacing it with five targeted automations, triggered off the right Stripe webhooks, is the highest-ROI email work most SaaS businesses can do.

The Stripe events you'll be working with

Each automation below triggers off one of these webhooks:

• invoice.payment_failed — fires when a recurring charge fails. Includes attempt_count so you can differentiate first-failure from retry-failure.
• customer.source.expiring — fires when a saved card is within 30 days of its expiration date.
• invoice.upcoming — fires a configurable number of days before a renewal attempt.
• customer.subscription.trial_will_end — fires 3 days before a trial converts to paid.
• invoice.payment_action_required — fires when 3DS or similar authentication is needed.

If your CRM doesn't have first-class Stripe event triggers, you'll need to wire these through Zapier — which is fragile and laggy. Sambandh's Stripe integration exposes all of these as direct campaign triggers. The Stripe CRM guide covers the event model in depth.

Automation 1: "Your card expires in 2 weeks"

Trigger: customer.source.expiring with 14 days of lead time. Target: All active paying customers whose stored card expires soon. Recovery rate: 40–60% of at-risk cards are updated before the first failure ever happens.

Template:

Hey ,

Just a heads up — the card we have on file for your subscription is expiring on .

If you don't update it before then, your subscription will pause. It takes 30 seconds: update card here.

If you've already updated it — ignore this email, you're all set.

Keep it under 80 words. This is the single highest-ROI email in the list because it catches the problem before Stripe's retry machine has a chance to start.

Automation 2: "Your first payment just failed"

Trigger: invoice.payment_failed with attempt_count = 1. Target: Customer whose first recurring payment attempt just failed. Recovery rate: 25–35%.

Template:

Hey ,

Looks like your card on file couldn't be charged for your subscription this month. This is usually a bank-side thing — expired card, wrong zip code, or the bank flagging the charge.

You can update it in 30 seconds here: fix payment

If you want help, just hit reply — .

Send from the founder's real email address (not a no-reply). Deliverability is better and response rate is 10× a generic "failed payment" notice.

Automation 3: "Last try before we pause your subscription"

Trigger: invoice.payment_failed with attempt_count >= 3. Target: Customers where Stripe is running out of retry attempts. Recovery rate: 15–25% (lower than #2 because the card is truly bad).

Template:

Hey ,

We've tried to charge your card a few times for your subscription and it keeps getting declined. After one more try (tomorrow), we'll have to pause your account.

I'd really rather not do that. Update payment here — it takes a minute.

If your situation has changed and you need to cancel, reply and let me know — we can talk. No hard feelings.

The "no hard feelings, we can talk" line matters — it converts some involuntary churn into conversations where you learn why, and some of those become saves.

Automation 4: "Your subscription is paused" (the last chance)

Trigger: customer.subscription.updated with status transitioning to unpaid or past_due. Target: Customers whose subscription is now suspended. Recovery rate: 10–20%.

Template:

Hey ,

Your subscription is paused — we weren't able to charge your card after multiple attempts.

Everything you've built in is still here. As soon as you update payment, you're back in: resume here.

If you need a pause for legit reasons (business is slow, you're between jobs, etc.) — reply and I'll give you a free month. Your data won't be deleted.

The "free month if business is slow" offer is a cheap insurance policy against permanent churn. The cost is low (one month of hosting) and the upside is a customer who remembers you treated them well.

Automation 5: "We're refunding your failed charge" (optional, high-trust)

Trigger: invoice.payment_failed where the underlying charge actually completed but the invoice is marked failed due to a race condition or 3DS timeout — these are rare but they happen. Target: Customer who sees a charge on their statement but whose subscription shows failed. Recovery rate: 100% customer saves; trust-building.

Template:

Hey ,

Our billing system had a hiccup with your payment today — the charge went through on your card but didn't register on our side. We've just refunded you, and we'll try again tomorrow when the issue is resolved.

Sorry for the weirdness. If you see anything odd on your statement, hit reply and we'll sort it.

This is for edge cases, but it's the email that turns a one-star review into a "these folks are honest, I'm keeping my subscription" story.

Measuring what works

For each automation, track:

• Open rate — but don't trust it too much (Apple Mail Privacy Protection inflates opens).
• Click-through rate on the "update payment" link — higher-signal than opens.
• Recovery rate within 72 hours — the real number that matters. Sambandh reports this natively.
• Churn rate for customers who received the email vs a holdout control group (if you have enough volume).

The email outreach guide covers these metrics in more depth.

Where the automation lives

In Sambandh, each of these automations is a single rule: "when Stripe event X fires, send template Y." No Zapier, no webhook endpoint to maintain, no BCC-the-CRM hack. See the Stripe CRM landing page for the full event-trigger list.

In a generic CRM, each one is a Zapier zap + a template in a separate email tool + hope that nothing breaks. Over a quarter, things break. These are the automations you want on the most reliable surface you have.

What NOT to do

• Don't send more than 3 recovery emails before the subscription pauses. Beyond 3 it feels harassing.
• Don't use a no-reply address. People reply. When they do, you want the reply to reach a human.
• Don't use merge fields you can't verify. A broken {{first_name}} showing as {{first_name}} in a billing email looks unprofessional and kills trust.
• Don't test on real customers. Use a staging Stripe account and a test email list until the sequence is right.

What about Paddle, LemonSqueezy, or Polar?

All three emit analogous webhook events. The naming is different (Paddle uses subscription_payment_failed, LemonSqueezy uses subscription_payment_failed, Polar uses subscription.canceled), but the pattern is the same: wire your recovery emails to the events, not to a timer.

Sambandh's Paddle CRM, LemonSqueezy CRM, and Polar CRM integrations expose equivalent triggers.

Frequently Asked Questions

How many of my customers have cards that will expire this month?

In Sambandh: one filter — "card expires before ." This is a data you already have (Stripe stores it), you just need a CRM that exposes it as a filter. Most don't. See the Stripe CRM guide.

What's a reasonable retry schedule on Stripe's side?

The default is 3 retries over 21 days. Most SaaS businesses should use Smart Retries (Stripe's ML-driven schedule) — it's typically 5–15% better than manual schedules.

Should I send these from my founder's email or a team email?

Founder email for under 10k customers. It's personal, replies land where they should, and the response rate is measurably higher. Over 10k customers, use a team alias (like support@) that's actively monitored.

Will these automations hurt my email deliverability?

No — they're transactional, triggered by a specific customer action (failed payment), so they have very low spam complaint rates. The email outreach guide covers deliverability in depth.

What about customers who churn on purpose?

Voluntary churn (the customer clicked "cancel") isn't a payment failure — different webhook, different automation. Those get a cancellation confirmation + a brief "what happened?" survey, not dunning emails.

---

Ready to wire these automations to real Stripe events? Start a free trial and connect Stripe — most teams have all five running within an hour.