A dunning engine is the machinery that runs after a recurring charge fails: the retry schedule, the customer outreach, and the scoreboard that tells you whether either is working. Most teams treat it as an afterthought bolted onto the billing system, then wonder why involuntary churn quietly eats single-digit percentages of monthly recurring revenue. The typical subscription business loses on the order of 9 percent of MRR to failed payments and the churn that follows, and almost all of that is recoverable with a properly tuned engine.
The module on involuntary churn covers why payments fail. This lesson is about the response: when to retry, where to reach the customer, and how to measure the result so you are optimizing recovered dollars rather than vanity metrics.
Retry on the decline code, not on a fixed clock
The single biggest improvement most teams can make is to stop retrying on a flat schedule and start retrying based on why the charge failed.
Declines split into two families. A soft decline is temporary: the card is valid and the account is live, but something transient blocked the charge. Insufficient funds is the dominant case, accounting for close to half of all failed transactions. A hard decline is permanent: the issuer is telling you this card will never work again, as with a reported-lost or fraud-flagged card. The vast majority of declines, roughly 80 percent or more, are soft, which is why retries recover so much.
The two families demand opposite responses. Soft declines should be retried, with timing matched to the cause. Insufficient funds clears when a paycheck lands or a monthly limit resets, so spacing a retry a few days out tends to beat hammering the card immediately. Stripe's published guidance recommends timing the first retry roughly 24 hours after a soft decline rather than reattempting immediately, and spreading a few additional attempts across the dunning window rather than clustering them.
Hard declines should not be retried at all. They need a new card from the customer, so the correct response is outreach, not another authorization attempt.
Reading the network signals
Both Visa and Mastercard publish decline-category data that tells your engine what to do. Visa groups responses into categories such as "never retry," "wait and retry," and "correct and retry." Mastercard's Merchant Advice Codes carry the same intent, with codes like 03 ("do not retry, fraudulent") and 21 ("do not retry, lost or stolen card") that your logic must respect. Wire these into the retry decision rather than treating every decline as a generic failure.
This is also where the acquirer monitoring lesson connects. Retrying blind is not just ineffective, it is penalized. Visa's excessive reattempt rule charges a fee on each reattempt past the 15th in a 30-day period for transactions returning a wait-and-retry or correct-and-retry code, and assesses fees on never-retry declines that are reattempted at all. Mastercard's 2026 update to its excessive authorization rules adds per-transaction penalties, in the range of a few cents up to roughly $0.50, for retrying after do-not-retry advice codes within 30 days. A dunning engine that ignores these signals manufactures fees while recovering nothing.
Channels: reach the human, not just the card
Retries handle the cases where the card will eventually clear on its own. Everything else requires the customer to act, which makes outreach a core part of the engine rather than a courtesy email.
Match the channel to the failure. A soft decline that you are retrying needs little or no customer contact; the card will likely clear. A hard decline or an expired card needs a clear, mobile-friendly prompt to update payment details, because the only path to recovery runs through the customer. Email remains the workhorse, but in-app and push prompts reach customers who never open billing emails, and a logged-in update flow converts far better than a link buried in an inbox.
Two practices raise the floor here. First, run card lifecycle tools, covered in the next lesson, so that expired and reissued cards update automatically before they ever reach a dunning sequence. Second, segment outreach by customer value. A $500-per-month account and a $5-per-month account should not receive the same sequence; the high-value account warrants earlier, more personal contact and possibly a human follow-up.
Measure recovered revenue, not open rates
Here is where most dunning programs go wrong. Teams report email open rates and click rates because their email tool surfaces them, but those numbers say nothing about whether you kept the money. The only metric that matters is recovered revenue: the MRR that would have churned involuntarily but did not, because a retry succeeded or a customer updated their card.
Track these, in order of importance:
- Recovery rate. Failed-payment dollars recovered divided by failed-payment dollars attempted, measured over a full retry window. Comprehensive dunning recovers roughly 50 to 80 percent of failed payments; well-timed retries alone recover 45 to 70 percent of soft declines. Stripe reports an average around 55 percent across its Billing base, though real-world results vary widely by business type, so benchmark against your own trend, not a headline figure.
- Recovered MRR. The absolute dollars saved per month. This is the number to put in front of the finance team, and it ties straight back to the recurring-revenue P&L from the opening lesson.
- Time to recovery. How many days, on average, a recovered account spends in the dunning state. Shorter is better for cash flow and for customer experience.
- Penalty leakage. Fees incurred from excessive or do-not-retry reattempts. This should trend toward zero; if it does not, your retry logic is ignoring network signals.
A worked example
Take a SaaS business with 10,000 subscribers at $50 per month, so $500,000 in MRR. Suppose 4 percent of charges fail each month, which is $20,000 of MRR at risk. A naive engine that retries every failed card three times on a fixed 2-day cadence might recover 40 percent, saving $8,000 and letting $12,000 churn.
Now rebuild it on decline-code logic. Hard declines, say 15 percent of the failures or $3,000, are routed straight to a card-update sequence across email and in-app rather than wasted on retries. Soft declines are retried on cause-matched timing, with the first attempt pushed to 24 hours and extra attempts spread across the window. Recovery on the soft-decline pool climbs toward 65 percent, and the targeted outreach pulls back a meaningful slice of the hard declines. Blended recovery moves from 40 percent to roughly 60 percent. That is $12,000 recovered instead of $8,000, an extra $4,000 of MRR per month, or $48,000 a year, from logic and timing changes alone, with lower penalty exposure because do-not-retry codes are never reattempted.
The takeaway
A dunning engine is not an email sequence. It is a decision system that reads the decline code, retries only when the card can clear, routes the rest to the right channel, and reports the dollars it saved. Build it on network signals, not a fixed clock, and judge it on recovered MRR, not open rates. Done well, it converts a quiet 9-percent leak into your cheapest source of retained revenue, and it sets up the dispute-defense modules ahead by keeping accounts current before a failed charge ever turns into a chargeback.