Chargebee Dunning: What Actually Recovers Failed Charges

Where Chargebee dunning settings come from, and why they’re too blunt

Chargebee dunning is the retry-and-email sequence that runs automatically after a subscription charge fails: a fixed number of attempts, spaced by a fixed number of days, followed by an email and eventually a cancellation. Most accounts running it today are still using whatever schedule was set at onboarding, often by whoever configured Chargebee first and never came back to it once billing volume grew.

That schedule treats every decline the same. A card declined because the account is overdrawn until payday gets retried on the same cadence as a card reported stolen last month. Chargebee stores the decline reason code on every failed transaction, so the information to tell those two cases apart exists in the account from the first failure. The default retry logic simply doesn’t use it unless you configure something on top.

For a brand doing $3M to $30M in revenue on Shopify Plus or a comparable subscription platform, that gap is not academic. At that scale, a fixed percentage of monthly recurring revenue is failing to collect every billing cycle, and a fixed share of that failure is recoverable with better timing rather than more retries. Below the $3M mark the volume usually isn’t there to justify rebuilding the dunning logic — a brand that size is better served fixing gateway configuration basics first. This article is written for the brand past that floor, where the retry sequence itself has become the lever.

Why more retries makes recovery worse, not better

The instinct when recovery looks low is to add attempts: five retries instead of three, spread further apart, on the theory that persistence recovers more. It usually doesn’t, and it carries a cost that a flat recovery-rate dashboard doesn’t show.

Past the third or fourth attempt, additional retries mostly hit cards that were never going to clear — a hard decline retried five times still fails five times, because the account is closed or the card reported lost. What changes is the gateway’s view of the merchant. Card networks and processors watch retry behaviour per merchant account, and a pattern of repeated attempts against the same declined card reads as retry abuse regardless of intent. Some processors throttle or flag accounts that retry too aggressively, which can slow down or complicate legitimate transactions across the whole account, not just the one subscription.

There’s a second cost that’s easier to miss: every retry attempt against a card the customer has already replaced or cancelled generates a decline event the customer sometimes sees as a bank notification, which reads as the merchant repeatedly trying to charge a card they were told not to use. That erodes trust with exactly the customer you’re trying to keep. Recovery isn’t a volume game where more attempts wins — it’s a matching problem, and the obvious lever is the wrong one.

The mechanism: matching retry timing to the decline reason code

The mechanism that actually moves the recovery number is routing each retry by the decline code the gateway returned, not by a day-offset counter. This is the part Chargebee’s stock configuration doesn’t do for you, and it’s the piece worth building deliberately.

Soft declines — insufficient funds, “do not honour,” a temporary issuer hold, a network timeout — respond to timing. Insufficient funds clears fastest around a payday, so a retry fired two or three days after the original attempt, and again a week later, catches a meaningfully higher share of these than a retry fired the next morning. A network timeout or a temporary hold, on the other hand, often clears within hours, so retrying that decline code the same day recovers charges that a day-later retry would also catch, just slower — timing on those codes should be tight, not spread out.

Hard declines — card reported stolen, account closed, invalid card number — should never enter a retry queue at all. Retrying them wastes attempts that count against the account’s retry-abuse threshold and delays the one thing that would actually recover the charge: prompting the customer for a new card. Those decline codes should route straight to an update-card email on the first failure, skipping the retry sequence Chargebee would otherwise run by default.

Expired-card declines sit in between. Account updater services, offered through several card networks, can refresh an expired or reissued card number on file without the customer doing anything — but coverage depends on the issuing bank participating, so it never catches everything. The mechanism treats an expired-card decline as: attempt the account updater refresh first, retry once if the updater returns a fresh number, and fall through to an update-card email if it doesn’t. Built this way, the retry schedule stops being one sequence and becomes three, chosen by the decline code on the first failure — which is closer to what a payment recovery system does than what a billing platform’s default dunning setting was built to do.

What to change in your Chargebee dunning configuration

Start in Settings under Dunning, and separate what’s configurable natively from what needs a workflow or a webhook.

Chargebee lets you set retry counts and intervals per plan or globally, and lets you attach a “smart retries” option on supported gateways that adjusts timing using the gateway’s own model rather than a flat schedule — worth turning on where the gateway supports it, since it’s the built-in version of the same idea. What it doesn’t give you natively is branching by decline code: routing hard declines away from the retry queue entirely, or timing soft-decline retries around a likely payday, both require a webhook that listens for the failed-payment event, reads the decline reason, and either lets Chargebee’s schedule run or overrides it with a custom one.

Email sequencing is the other lever worth revisiting. The first failed attempt needs no email at all — a silent retry costs nothing, often succeeds, and an email at that stage just adds noise the customer didn’t need. From the second failure onward, the email should name the actual problem. “Your payment didn’t go through” reads as a scheduling glitch; “your card was declined — update it here” tells the customer exactly what to do and links straight to the update page rather than a generic billing portal.

Account updater coverage is worth checking even if it’s already enabled, because it’s easy to assume it’s catching more than it is. It only works for participating card networks and issuing banks, so a meaningful share of expired-card declines will still need the manual email path — don’t treat it as a solved problem once it’s switched on.

What Chargebee dunning still won’t catch

Even a well-tuned retry sequence has a ceiling, and it’s worth being honest about where that ceiling sits before promising a recovery number to anyone upstream.

Chargebee’s dunning only fires after a charge has already failed. It does nothing about the charge that never should have failed in the first place — a card on file that’s already expired at the point of renewal, a currency mismatch between the plan and the card issuer, a 3D Secure prompt that the customer never completed. Those are gateway and checkout configuration problems, and no retry schedule fixes them; they need attention on the payment page itself, separate from the dunning sequence.

Chargebee’s standard churn reporting also doesn’t separate involuntary churn — cancellations caused by a failed payment — from a customer who deliberately cancelled. Both usually land in the same “cancelled” bucket unless you tag or export by cancellation reason, which most accounts never set up. That matters because involuntary churn accounts for an estimated 20–40% of subscription churn (Paddle/ProfitWell, vendor-reported), and a brand that can’t see that split is managing retention against a number that’s mixing two different problems with two different fixes.

And dunning, however well configured, only ever recovers a portion of what fails. An estimated ~9% of MRR is lost to failed payments before any recovery effort (Baremetrics, vendor-reported): dunning claws back a share of that, not all of it, and treating a well-tuned retry sequence as a solved problem rather than a partial one is how the remaining leak stays invisible on a dashboard that only shows what was recovered.

What proper dunning costs to run

Building this properly is not free, and it’s worth pricing before committing to it.

The webhook-and-routing layer is engineering time: someone has to build the listener on Chargebee’s failed-payment event, map decline codes to the three-path logic, and test it against real gateway responses rather than assumed ones, since gateways don’t all return decline codes in the same format. That’s a one-time build, then periodic maintenance whenever a gateway changes its response codes or Chargebee changes its webhook payload — which happens rarely, but does happen. Account updater services typically carry their own per-transaction or per-account fee from the card network, on top of whatever Chargebee or payment-gateway plan you’re already on — a cost to confirm against your specific provider rather than assume from a general figure. Email volume through your existing sending platform for the update-card sequence is usually marginal at this scale, but it’s not zero if you’re metered by send volume.

The honest way to size whether the build is worth it is to work out the illustrative arithmetic for your own account: take your monthly recurring revenue, apply the ~9% of MRR failed-payment estimate as a hypothetical starting point, then estimate what share of that a fixed schedule already recovers versus what a decline-code-routed sequence would plausibly add. If that difference clears the engineering and account-updater cost with room to spare, it’s worth building; if the gap is a few hundred dollars a month, the fixed Chargebee default with smart retries turned on is probably close enough.

The failed-payment calculator does that arithmetic against your own numbers rather than a hypothetical one: /tools/failed-payment-calculator — it takes your actual MRR and decline mix and works out where the recovery ceiling sits before you commit engineering time to raising it. For the wider pattern across brands at this revenue range, /benchmarks/failed-payment-and-involuntary-churn tracks what involuntary churn typically looks like once it’s separated from the rest of cancellations.

Where this sits

A retry schedule that doesn’t distinguish a soft decline from a hard one, and a churn report that doesn’t separate a failed card from a deliberate cancellation, are both symptoms of the same gap: payment recovery treated as a billing-platform default rather than a system someone owns. Chargebee’s dunning settings are a starting point, not a finished answer, and closing that gap is what /services/payment-recovery is built to do.