Stripe Dunning Best Practices: How to Recover 40%+ of Failed Payments

Every SaaS business on Stripe already has a dunning system. It is called Smart Retries, and it is free. For a business at €5k MRR with a handful of payment failures per month, it is probably sufficient. For a business at €50k MRR losing 2% of subscribers per month to billing failures, it is leaving significant money on the table.

The gap between Stripe's default behaviour and an optimised dunning setup is approximately 15–20 percentage points of recovery rate. On a business with 500 customers and 10 payment failures per month, moving from 25% to 42% recovery means 1.7 additional customers retained per month. Over a year, that is 20 additional retained customers at essentially zero marginal cost beyond a few hours of one-time setup.

This guide covers every layer of Stripe dunning optimisation: understanding Smart Retries' limits, reading decline codes correctly, building the right retry logic, writing recovery emails that work, proactive prevention, and when to move beyond Stripe to a dedicated tool.

How Stripe Smart Retries works — and where it stops

Stripe Smart Retries uses machine learning across billions of payment attempts on the Stripe network to time retries optimally. Rather than retrying on a fixed day-3 / day-7 / day-14 schedule, Smart Retries analyses patterns in successful recoveries and schedules the next attempt when success probability is highest based on network-wide signals.

This is genuinely useful. Stripe has access to more payment data than any independent tool can match, and that timing advantage produces a meaningful improvement over naive fixed schedules. Enabling Smart Retries — and doing nothing else — is the highest-ROI single change available to a business currently using Stripe's basic retry behaviour.

The ceiling: Smart Retries achieves roughly 40–50% success rate on retried payments — but that is only the retry dimension. Of all failed payments, many require the customer to actively update their card (expired cards cannot be retried at all). The overall recovery rate from retry alone is 20–25% of all payment failures. The remaining 15–25% gap requires recovery emails with direct update links.

Decline codes: the most underused data in your billing stack

Every failed Stripe payment returns a decline_code in the API response. Most businesses log it and ignore it. This is a significant mistake — the decline code is the most actionable signal in your entire dunning process. It tells you why the payment failed, which determines what the right response is.

Building decline-code-specific logic with Stripe webhooks

Stripe's dashboard settings apply retry behaviour universally — you cannot configure different schedules per decline code without code. To implement the right strategy for each failure type, you need to listen to the invoice.payment_failed webhook event and read the last_payment_error.decline_code field.

// Stripe webhook handler — invoice.payment_failed
export async function POST(req: Request) {
  const event = stripe.webhooks.constructEvent(
    await req.text(), req.headers.get('stripe-signature')!, secret
  );

  if (event.type === 'invoice.payment_failed') {
    const invoice = event.data.object as Stripe.Invoice;
    const code = invoice.last_payment_error?.decline_code ?? 'unknown';

    switch (code) {
      case 'expired_card':
        // No retry — card is dead. Send update email immediately.
        await cancelScheduledRetries(invoice.id);
        await sendCardUpdateEmail(invoice.customer_email!, 'expired');
        break;

      case 'insufficient_funds':
        // Retry near payday (1st or 15th of next month)
        await schedulePaydayRetry(invoice.id);
        await sendSoftPaymentEmail(invoice.customer_email!);
        break;

      case 'processing_error':
        // Technical issue — retry in 24h, usually self-resolves
        await scheduleRetry(invoice.id, 24 * 60 * 60 * 1000);
        break;

      default:
        // card_declined, do_not_honor, etc.
        await scheduleRetry(invoice.id, 48 * 60 * 60 * 1000);
        await sendModerateUrgencyEmail(invoice.customer_email!);
    }
  }
}

This implementation takes one to two hours to build and delivers a step-change improvement in recovery rate that persists indefinitely. It is the single most impactful technical investment in your billing infrastructure for any SaaS doing meaningful payment failure volume.

The payday timing strategy

Insufficient funds is the most common decline code for consumer-facing and lower-price-point B2B SaaS. The key insight: people get paid on predictable schedules. A payment that fails on the 23rd because the account is running low near the end of the pay cycle will almost certainly succeed if retried on the 1st or 2nd of the following month, when the paycheck has cleared.

A retry scheduled for the 1st or 15th of the month — the two most common payday dates across most markets — consistently outperforms a day-3 or day-7 retry by 20–30 percentage points for this specific decline code. The implementation is simple: when you detect insufficient_funds, calculate the next payday date and schedule the retry for that date rather than a fixed interval.

Writing recovery emails that convert

Three emails over twelve days is the established best practice for payment recovery. Fewer leaves recovery rate on the table. More tips into harassment and starts damaging your sender reputation.

Email 1 — Day 1: Low urgency, direct action. Subject: "Action needed: payment issue on your account." Body: one sentence saying the payment failed, one direct link to update the card. No alarm language. No consequences mentioned yet. Many customers update immediately when they see a clear, frictionless path.

Email 2 — Day 5–7: Moderate urgency with a specific date. "Your account will be affected on [specific date] if we cannot process your payment." The specific date — not "soon" or "shortly" — consistently outperforms vague urgency. Customers respond to a concrete deadline in a way they do not respond to abstract warnings.

Email 3 — Day 10–12: Final warning, loss framing. "Your data and [X months] of history are at risk." Loss aversion is more motivating than the equivalent gain — the prospect of losing something already possessed outweighs the prospect of gaining something equivalent in value. This is the email that converts the customers who ignored the first two.

Proactive prevention: outreach before failure

The highest-ROI dunning action is one that prevents the payment from failing at all. Stripe provides card expiration data — you can identify customers whose cards expire in the next 30–60 days before any failure occurs.

A "your card on file expires next month" email sent 30 days before expiry prevents 30–50% of expiry-related failures. This is permanently one of your highest-performing automated emails: low drama, clear action, immediate benefit. Setup is one-time. It runs forever.

For annual billing: send a renewal reminder 14 days before the charge. Annual amounts are large enough to trigger bank fraud flags or customer surprise. A simple heads-up email — "your annual subscription renews on [date] for €[amount]" — prevents most of these issues and dramatically reduces dispute rates on annual charges.

Measuring dunning performance

Three metrics tell you whether your dunning system is working:

Overall payment recovery rate: failed payments that are eventually collected divided by total failed payments. Target above 40%. Below 25% means the current setup is leaving significant recoverable revenue unused.

Recovery rate by decline code: the overall rate hides important variation. Expired card recovery should be 40–60% with good email outreach. Insufficient funds with payday timing should hit 55–70%. If any code is significantly below benchmark, the strategy for that code needs adjustment.

Email engagement by sequence step: which email in the three-email sequence generates most of the card updates? If Email 1 drives 50%+ of completions, your Email 2 and 3 timing and copy may be improvable. If Email 3 drives most completions, consider whether earlier urgency would help.

When to upgrade beyond Stripe dunning

Corporate card failures: a different challenge

B2B SaaS has a payment failure pattern that consumer-facing products largely do not encounter: corporate card lifecycle events. When an employee whose corporate card is on file for a company subscription leaves the organisation, the card is typically deactivated within 24–48 hours of their departure. When a company changes its banking provider or switches corporate card issuers, every card is cancelled simultaneously — potentially taking down multiple SaaS subscriptions at the same moment.

These failures appear in your Stripe logs as card_declined or do_not_honor, indistinguishable from other temporary bank declines at the code level. But the underlying cause is different: no retry will succeed because the card is permanently deactivated. The right response is the same as for expired_card — skip retries and go directly to a card update email — but nothing in the standard decline code tells you this is the reason.

A signal that can help: corporate card failures often cluster. If you see multiple failures from the same company domain within a short window, it is likely a card replacement event. Route those to immediate billing contact outreach rather than the standard dunning sequence.

Measuring dunning effectiveness over time

The metrics that actually tell you whether your dunning system is working — and where to improve it — go beyond the headline recovery rate:

Email deliverability: the hidden factor in stripe dunning

Dunning emails have a structural deliverability challenge that marketing emails do not. They are transactional in nature — triggered by billing events, sent to a specific customer about a specific account action — but they are often sent from the same domain and infrastructure as marketing emails. If your marketing email sending has generated spam complaints or bounces, those reputation signals can affect the deliverability of your dunning emails.

The most common deliverability mistakes in dunning sequences:

Sending from a shared IP pool. If your email provider uses shared sending infrastructure, a bad sender on the same pool can affect your deliverability. For dunning emails — which generate their most value when they arrive immediately — a dedicated IP or a high-reputation sending service is worth the cost.

Missing SPF and DKIM records. Emails sent without proper authentication are more likely to land in spam. Every domain used for sending dunning emails needs correctly configured SPF and DKIM records. This is a one-time setup that takes 15 minutes and permanently improves deliverability.

Subject line spam triggers. Words like "URGENT," "ACT NOW," and excessive exclamation points are flag words for spam filters. Dunning subject lines should be calm and factual — "Action needed: payment issue on your account" rather than "URGENT: Your account will be deleted!!" The latter pattern gets spam-filtered and never seen.

Related: What Is Dunning? · Failed Payment Recovery Guide · How to Reduce SaaS Churn · Churnkey Alternatives