Smart dunning: how to recover 40%+ of failed payments without an ops team

Most SaaS founders know their MRR. Most don’t know their card decline rate — and they’re systematically losing revenue because of it.

Here’s the math: if your card decline rate is 6% (the industry median, per Stripe’s data) and you’re recovering 0% of those failures, you’re running 6% below your potential MRR permanently. On $100k MRR, that’s $6,000/month walking out the door not because customers wanted to cancel, but because a card expired, a bank issued a soft decline, or corporate procurement switched cards and nobody updated the subscription.

A well-configured dunning sequence recovers 40–50% of that. On $100k MRR, that’s $2,400–$3,000/month recovered from automation you build once. The SaaS Snapshot pays for itself from this workflow alone — typically within the first billing cycle.

Why most dunning sequences underperform

The most common dunning implementation is a single email that says “your payment failed, please update your card” — sent once, on the day of failure. This recovers roughly 15–20% of failures. The rest silently churn.

Effective dunning requires three things:

1. Multiple touches across multiple channels. Email, SMS, and in-app messaging each reach different users at different moments. The customer who ignores an email will respond to an SMS. The customer who dismisses both will see the in-app banner every time they log in. All three channels are required — single-channel dunning is structurally capped.

2. Urgency that escalates deliberately. The first touch should be friendly and factual. Urgency should build through the sequence, culminating in explicit access suspension messaging. Teams that lead with high urgency see lower recovery rates on Touch 1 (customers feel accused), and lower credibility on Touch 4 (if you cried wolf on Day 0, the Day 12 suspension message won’t be believed).

3. Frictionless card update. Every message must link directly to the payment update screen — not your dashboard homepage, not a general settings page, not a login screen. The customer is already mildly stressed about a billing issue. A direct link to the card update form converts measurably better than any amount of persuasive copy.

The four-touch sequence

Touch 1 — Day 0: In-app banner + email

In-app banner: A persistent, non-dismissable yellow banner on every page: “Your payment on [date] didn’t go through. Update your billing info here to avoid interruption.” Direct link to billing portal.

Email subject: "Action required: your [Product] payment didn't process"

Email content: Factual. Non-alarming. Explains what happened (a specific failure reason if your billing provider sends it — “Your card ending in 4242 was declined”), provides the direct card-update link, notes that access continues for 14 days while the issue is resolved.

What to avoid: Subject lines with all-caps, exclamation points, or words like “URGENT” on Touch 1. First-touch dunning emails that lead with alarm convert 15–20% below emails that lead with “here’s what happened and here’s the easy fix.” Save the urgency for Day 10–12.

Expected Touch 1 recovery: 25–35% of accounts that will recover do so on Touch 1 alone, within the first 48 hours. This is mostly the “I didn’t even know” segment — customers who simply hadn’t noticed the card expired.

Touch 2 — Day 3: SMS + email

Timing: 72 hours after the failed payment, for all contacts who haven’t updated their card.

SMS: "Hi [Name], just a reminder — there's a payment issue on your [Product] account. Update here: [direct link]" Keep it under 160 characters. The SMS should feel like a message from a person, not a marketing blast.

Email: A lighter follow-up with a clear CTA button and one social proof element: “Most customers resolve this in under 2 minutes using the direct link below.” Why social proof? It normalizes the action and implicitly communicates “you’re not in trouble, this is normal.”

Why SMS here and not Day 0? Touch 1 is discovery-oriented — the customer may not have known there was an issue. Touch 2 is the first acknowledgment that they’ve seen Touch 1 and haven’t acted. SMS on Day 3 catches the “meant to deal with it” segment who read the email, intended to update their card, and got distracted.

Touch 3 — Day 8: Final friendly escalation

Email subject: "Last reminder: update billing to keep your [Product] access"

This email introduces the suspension date explicitly for the first time. The tone shifts from informational to gently urgent. It names the specific date access will pause: “Your access will pause on [exact date] if payment isn’t resolved. Here’s the direct link to update your card — it takes about 2 minutes.”

Why Day 8 and not Day 7? Weekends. If the payment failed on a Friday, Day 7 is another Friday. Day 8 hits Monday, when people are at their computers. This timing improvement alone tends to add 3–5 percentage points to Touch 3 recovery rate.

Also on Day 8: Add a secondary CTA — if their card is truly expired or they want to discuss plan options, offer a “reply to this email” or “schedule a quick call” option. A meaningful portion of late-dunning recoveries happen through a human conversation, not just a link click.

Touch 4 — Day 12: Final warning (48 hours before suspension)

Email + SMS: “Your [Product] access pauses in 48 hours. Update your billing to keep your account active.”

This is the highest-urgency message. It includes:

• The exact suspension date and time.
• A direct card update link (for the fourth time — repetition of the link is intentional).
• A note that data is preserved for 30 days after suspension.
• Contact information for support if there’s a specific issue beyond a standard card update.

The data preservation note matters. Customers are more likely to update their card if they know their work won’t be deleted. It removes the fear of loss as a reason to disengage from the process.

The success branch

When a customer updates their card at any point in the sequence, GHL must:

1. Immediately suppress all remaining dunning touches. This is the most operationally critical piece. A customer who updates their card on Day 2 should never receive Touch 3 or 4. Failing to suppress feels like harassment and damages the customer relationship.
2. Confirm payment via billing webhook. Wait for invoice.payment_succeeded (Stripe), subscription.payment.succeeded (Paddle), or payment_succeeded (Chargebee) before triggering the success branch — don’t rely on the card-update event alone (card updated ≠ payment successfully retried).
3. Send a recovery confirmation email. Short, warm, no fanfare: “All sorted — your [Product] access continues normally. [Optional: here’s your invoice for your records.]” Three sentences max. No CTAs.
4. Remove the in-app banner.
5. Log the recovery event with touch number (dunning_touch_count at recovery). This data powers your recovery rate reporting — essential for optimizing which touch is most effective and which accounts are most recoverable.

Billing provider webhook configuration

The dunning sequence requires two webhook events from your billing provider:

Stripe: invoice.payment_failed (starts the sequence) and invoice.payment_succeeded (triggers success branch). Also configure customer.subscription.deleted — to exclude voluntarily cancelled accounts from dunning. You don’t want to chase a payment from someone who already cancelled.

Paddle: subscription.payment.failed and subscription.payment.succeeded.

Chargebee: payment_failed and payment_succeeded.

The SaaS Snapshot ships pre-configured webhook receivers for all three providers with field mapping to the relevant GHL custom fields. Configure the webhook endpoint in your billing provider’s developer settings, then run a test failed-payment simulation before going live.

What this workflow recovers — realistic numbers

Based on snapshot deployments:

• Touch 1 alone: recovers ~30% of recoverable accounts (the “didn’t notice” segment).
• Full 4-touch sequence: recovers 45–55% of recoverable accounts.
• Unrecoverable (remaining 45–55%): accounts where the card issue is genuinely unresolvable (closed account, card the customer won’t update) OR accounts where the customer was already planning to cancel and the failed payment was a convenient exit. This second segment — accounts that let the failed payment become a cancel — often shows declining health scores in the 30 days before the failure. Layering health score monitoring with dunning catches them earlier.

The accounts you won’t recover with dunning alone: customers who are dissatisfied and using the payment failure as an exit. For these, you need a separate win-back sequence with different messaging — focusing on re-engagement, not billing mechanics.