The Complete Guide to
Dunning Management for SaaS

At its core, dunning management sits at the intersection of billing operations and customer success. When a customer's payment fails, they haven't decided to leave — their card expired, their bank blocked a transaction, or they hit a temporary limit. Dunning is the system that bridges that gap before it becomes permanent churn.

According to Maxio (2025), the best dunning systems combine empathy with automation: they treat every failed payment as a customer service event, not a collections event. The tone matters as much as the timing.

What Dunning Management Covers

Modern dunning management spans three layers that work together:

The 6 Most Common Payment Failure Reasons

What It Actually Costs Your Business

For a company at $10M ARR, involuntary churn from failed payments represents $130,000–$150,000 in preventable annual losses (Slicker HQ, 2025).

Involuntary churn happens when a subscription lapses because of a payment failure, not a cancellation decision. The customer still wants your product. According to Dodo Payments (2026), 70% of involuntary churn originates from failed transactions rather than explicit cancellation decisions.

The Compounding MRR Effect

A single failed payment is a one-time event. But when multiplied across your subscriber base, even a 2% monthly payment failure rate against $500K MRR costs you $10,000 every single month — $120,000 a year — from customers who never intended to cancel. Each month you don't fix it, the hole gets bigger.

The difference in outcome isn't incremental — it's 3–4x. Churn Buster's 2026 benchmark data shows that companies moving from passive to active dunning see median recovery rates jump from 27% to 71% within 90 days of switching.

Decline Code Reference

Phase 1: Pre-Dunning (Prevention)

Pre-dunning is the most underused phase. Expired cards alone account for 42% of all payment failures, and every single one is preventable with a 30-day advance expiration alert. Account Updater services automatically refresh card details when a customer gets a new card — recovering up to 20–30% more invoices before a retry is even needed (Stripe Resources, 2026).

Phase 2: Active Dunning (The Recovery Sequence)

The active dunning window is typically 14 days. After 14 days, recovery rates drop sharply. The sequence should be: immediate retry → email 1 (friendly) → retry 2 → email 2 (reminder) → retry 3 → email 3 (urgency) → email 4 (final). Every email must contain a one-click payment update link that bypasses login — this single change typically lifts recovery by 15–20 percentage points.

Phase 3: Resolution & Escalation

When the active sequence ends unresolved, always pause — never delete. A paused account can be reactivated; a deleted account is gone forever. High-LTV accounts (top 20% by MRR) should be escalated to a human CS rep for personal outreach. A grace period of 30 days with in-app messaging often recovers an additional 8–12% of accounts.

The math is stark. Moving from retries-only (23%) to a full dunning system (70%) on a base of 100 monthly failures at $100 ARPU means recovering an additional 47 customers per month — $56,400 per year from a one-time setup.

Smart retries solve the technical problem (should we try charging again?). Dunning emails solve the human problem (does the customer know there's an issue, and can they fix it easily?). You need both. According to Paraglide AI (2026), AI-led follow-ups that combine timing optimization with personalized messaging consistently outperform pure retry logic by 2–4x.

The Recovery Email Sequence Ladder

Without webhooks, you're polling for payment status or waiting for a daily batch job. With webhooks, you know about a failure the instant it happens and can begin the recovery sequence before the customer even notices.

Key Webhook Events to Listen For

Stripe Webhook Implementation (Node.js)

// Install: npm install stripe express
const stripe = require('stripe')(process.env.STRIPE_SECRET_KEY);
const express = require('express');
const app = express();

app.post('/webhook', express.raw({ type: 'application/json' }), async (req, res) => {
  const sig = req.headers['stripe-signature'];
  let event;
  try {
    event = stripe.webhooks.constructEvent(req.body, sig, process.env.STRIPE_WEBHOOK_SECRET);
  } catch (err) {
    return res.status(400).send(`Webhook Error: ${err.message}`);
  }

  switch (event.type) {
    case 'invoice.payment_failed': {
      const invoice = event.data.object;
      const declineCode = invoice.last_payment_error?.decline_code;
      const isHardDecline = ['expired_card', 'lost_card', 'stolen_card'].includes(declineCode);
      await startDunningSequence({ customerId: invoice.customer, invoiceId: invoice.id, declineCode, isHardDecline });
      break;
    }
    case 'invoice.payment_succeeded': {
      await cancelDunningSequence(event.data.object.customer);
      await restoreFullAccess(event.data.object.customer);
      break;
    }
    case 'payment_method.updated': {
      await retryOpenInvoices(event.data.object.customer);
      break;
    }
    case 'customer.subscription.deleted': {
      await startWinBackSequence(event.data.object.customer);
      break;
    }
  }
  res.json({ received: true });
});

Always verify webhook signatures before processing. Use idempotency keys to prevent duplicate actions on webhook retry.

Key Integration Points (Both Platforms)