How to Build a Dunning Management System That Recovers More Failed Payments

Failed payments are one of the most recoverable sources of revenue loss in SaaS. Industry benchmarks suggest 20–40% of failed payments can be recovered with the right retry logic and communication sequence. Most SaaS companies recover far less than that because they're running Stripe's default dunning settings: three retries over two weeks and an automated cancellation email.

Default dunning is better than nothing. A custom dunning management system — with intelligent retry scheduling, segmented communication sequences, and an ops dashboard your billing team can actually use — is worth building once you're past $500k ARR and payment failures are a recurring ops problem.

Why default Stripe dunning isn't enough

Stripe Smart Retries uses machine learning to pick retry timing based on card network signals. This is genuinely useful. The limitations are in the communication layer and the ops visibility layer.

On communications: Stripe's default failed payment emails are generic. They don't know whether the customer is an annual contract worth $24,000 or a month-to-month account at $49/month. They don't know whether the account has an open support ticket, a renewal call scheduled, or a history of payment issues. A custom dunning system can segment on all of these dimensions and send the right message — or route to a human — based on account value and context.

On ops visibility: Stripe's dashboard shows you failed payment events, but not a unified view of accounts currently in dunning, their retry status, recovery probability, and which ones your billing ops team needs to intervene on manually.

Anatomy of a dunning system

A dunning system has three layers. The first is retry logic: when and how many times to retry a failed charge. Smart retries with exponential backoff (retry at 3 days, 7 days, 14 days) outperform fixed schedules for most card failure types. High-value accounts warrant more retries and longer grace periods.

The second is the notification sequence: what communication goes out to the customer at each retry stage. The first message should be transactional and low-friction ("your payment failed, update your card here"). Later messages should escalate — involve account ownership context, reference the value the customer is getting, and offer a direct line to a human if the issue is more than a card problem.

The third is the ops dashboard: a view of all accounts currently in a dunning state, segmented by days since first failure, account value, retry count, and recovery probability. This is what your billing ops team uses to decide which accounts get a personal outreach and which go through the automated sequence.

Building the recovery dashboard

The ops dashboard is where a custom dunning system pays for itself. It surfaces: accounts in dunning right now (with retry timeline and current status), accounts at risk of cancellation in the next 7 days, recovery rate by segment (so you can see whether enterprise accounts recover at a higher rate than SMB), and revenue recovered this month versus revenue lost to hard failures.

Critically, it needs a "take action" surface — the ability to mark an account for manual CS outreach, extend the grace period, or apply a credit — without going into the Stripe dashboard directly. When a CSM gets a call from a customer whose card just failed but who is about to sign an expansion deal, they need to resolve the billing issue immediately without waiting for engineering.

Metrics to track

The primary metric is recovery rate: the percentage of failed payment revenue that is ultimately collected. Secondary metrics include time-to-recovery (how many days from first failure to successful charge), recovery rate by failure type (insufficient funds recovers differently than expired cards), and the split between automated vs. manual recoveries.

A well-implemented dunning system with smart retries and a human escalation workflow typically recovers 30–50% of initially failed payments, compared to 15–25% on Stripe defaults alone. At $100k MRR with a 2% monthly failure rate, that difference is $300–$500 per month in recovered revenue — and the benefit compounds.