Dunning management is the sequence of retries and customer messages a business runs after a recurring charge fails, aimed at recovering the payment before the subscription cancels itself. The word comes from debt collection — “to dun” means to press someone for payment — and the practice inherited collections’ tone along with its name, which is most of why the emails so often read like an overdue notice even though the customer never chose to stop paying. For a Shopify brand running Recharge, Skio, Smartrr or Stay AI underneath a subscription or replenishment programme, dunning management is the layer that decides which failed charges get a second attempt, on what schedule, and what the customer sees while that attempt is pending.
What Counts as Dunning Management, and What Doesn’t?
Two things sit next to dunning and get folded into it out of habit, and neither one is dunning itself. Prevention — a card-expiry warning sent before the charge, an account updater catching a reissued card silently — happens before a charge ever fails, so nothing has been dunned yet; a subscriber who never sees a decline was never in the dunning sequence at all. Payment recovery is the broader term for the whole system: prevention, dunning, the self-serve card-update page and the reporting that ties them together. Dunning management is one component inside that system, not a synonym for it, and a Shopify brand shopping for “a dunning tool” is usually looking for the whole four-part system rather than the retry ladder in isolation.
Dunning management also only applies inside an existing billing relationship. A card declining at first checkout is a conversion problem, worked by the checkout flow and the payment gateway’s own retry logic — there is no subscriber yet, so there is nothing to dun. Dunning starts at the second charge and every one after it: the moment a business is trying to keep collecting from a customer it already has, rather than trying to win one it doesn’t.
What Changes When Dunning Has to Beat a Shipping Cutoff, Not Just a Billing Date?
Dunning management for a Shopify subscription or replenishment box carries a constraint that dunning management for software billing does not: the retry has to succeed before the fulfilment cutoff for that cycle’s order, not merely before the next invoice date.
Almost everything published about dunning is written for software subscriptions, where recovering a failed charge at any point before the next billing date avoids a churn event — there is no physical object waiting on the outcome, so a two-week retry ladder costs nothing beyond the processor fee on each attempt. A box or replenishment order changes that. Typically one to five days after the charge attempt — the exact window is carrier- and category-specific, and no single source publishes it as a norm — a warehouse has to pick, pack and hand the order to a carrier to hit its promised delivery window, and that pick-pack-ship cutoff does not wait for a card to clear.
Miss the cutoff with the charge still unresolved and there are three options, and a subscription platform’s default configuration rarely makes the choice on purpose. Ship the order anyway against an unpaid balance, which is a credit decision dressed as a shipping decision — accepted for a low-cost consumable refill more often than for an expensive box. Skip the cycle and wait for the card to clear before the next one, which means a subscriber who was genuinely about to fix their card gets nothing this month and may cancel out of frustration rather than the payment failure itself. Or hold the order past the cutoff and reship late, which usually means missing the delivery promise the product page made.
None of the three is free, and the choice should be made from a number most Shopify brands have never calculated: how many retry attempts actually fit inside the gap between the charge date and the fulfilment cutoff. A five-attempt retry ladder checked against a 3-day fulfilment cutoff makes that tradeoff concrete: it is illustrative, invented for this example rather than measured from a real cohort — plug in your own charge date, cutoff and retry cadence and the conclusion can move — but the pattern holds for most box subscriptions.
| Retry attempt | Day after charge date | Falls before the cutoff? |
|---|---|---|
| 1 | Day 0 (same day) | Yes |
| 2 | Day 3 | On the cutoff — depends on the hour |
| 3 | Day 6 | No |
| 4 | Day 9 | No |
| 5 | Day 13 | No |
A generic five-touch schedule spread across roughly two weeks — the shape most subscription platforms ship with by default — puts three of its five attempts structurally after a 3-day cutoff, regardless of whether they would eventually have recovered the charge.
Carried through to a cohort, invented for illustration: a coffee subscription box sends 1,000 orders in a cycle, with a 6% initial decline rate — 60 failed charges. If the generic two-week ladder above eventually recovers half of those over its full run, 30 orders, but only the first attempt reliably lands before the 3-day cutoff, and that single attempt accounts for a fifth of the eventual total — 6 orders — then 60 minus 6 leaves 54 subscribers still unresolved at the exact moment the warehouse needs an answer for this cycle. Those 54, not the 6 already recovered, are the ones the ship, skip or bill-anyway decision actually has to be made for.
The fix is not a faster retry schedule across the board — a hard decline retried on day 1 instead of day 5 still fails, it just fails sooner. It’s splitting the ladder in two: a compressed set of attempts, timed to land before the cutoff, reserved for decline reasons likely to clear quickly on their own — an issuer-side hold is the clearest case — and a second, slower track that starts once the cutoff has passed and the ship-or-skip decision is already made, aimed at recovering the subscriber for next cycle rather than saving this one’s box. A retry that lands after the cutoff can still save the relationship; it just cannot save the shipment.
Sorting a decline into the compressed pre-cutoff retries or the slower post-cutoff track is a question about the cutoff, not just about the reason. An insufficient-funds decline is ordinarily worth a quick same-day and a next-day attempt, because the failure is a timing problem that a compressed pair of retries can plausibly beat. An expired-card decline belongs in neither track as a retry — no attempt count fixes it — and instead needs the fastest possible message asking for a new number, because the cutoff clock is running against a fix only the customer can make. A card-network reissue sits between the two: an account updater catching it before the charge even runs removes the need to sort it at all, which is the strongest argument for treating prevention as the first thing to fix on a tight-cutoff subscription, ahead of the retry ladder itself.
The failed-payment calculator turns monthly recurring revenue and subscriber count into the dollar value of a recovery-rate gap, which is useful for sizing the exposure — it doesn’t model a fulfilment cutoff, though. Modeling that takes the same retry-ladder-versus-cutoff calculation worked through for the 1,000-order cohort — where only the same-day attempt reliably clears before the cutoff — run against your own ship calendar rather than a generic input.
How Should a Dunning Sequence Be Timed Against Shopify’s Own Order Emails?
A dunning message and a Shopify order-confirmation email can legitimately go out for the same failed charge, on the same order, within minutes of each other — and whether that happens depends on one setting most operators have never looked at: the payment-processing policy on the subscription billing attempt.
Shopify’s native subscription billing API exposes a paymentProcessingPolicy on every billing attempt, and it decides whether an order gets created at all when a charge fails. The default, FAIL_UNLESS_VALID_PAYMENT_METHOD, blocks order creation until a payment method actually charges successfully — no order exists yet for anything in Shopify’s own automation to fire against, so a customer hears from the dunning sequence and nothing else until the charge clears (Shopify developer changelog, 1 April 2026). The alternative, SKIP_PAYMENT_AND_CREATE_UNPAID_ORDER, creates the order regardless of whether the charge succeeded — which means an unpaid order can sit in Shopify triggering whatever order-created automation the store has wired up, including a workflow that treats every new order as confirmed, at the same moment the subscription app’s dunning sequence is telling that same customer the payment failed.
Dunning itself is not a feature Shopify configures once and forgets about — Shopify’s own reference documentation for subscription apps is explicit that the retry logic and the emails belong to the subscription management app built on top of the billing primitive, not to Shopify’s core system. That split is exactly where the collision happens: the app owns the dunning sequence, Shopify owns whatever fires on order creation, and nothing forces the two to check with each other before sending.
Two questions settle it in practice. First, which payment-processing policy the subscription app has set — Recharge’s own documentation describes an order being created in Recharge only after a successful charge, which mirrors the safer default, so most Recharge and Skio stores running standard configurations are not exposed to this collision unless a custom app or workflow was built against unpaid orders on purpose. Second, if unpaid orders are in use for any reason — a deliberate ship-now-bill-later policy, for instance — every automation triggered on “order created” needs auditing, and anything that reads as a confirmation to the customer should exclude unpaid orders, so the only message that goes out before payment clears is the one deliberately written as a dunning message.
A dunning message needs the same kind of check: fulfilment status, not just payment status, has to be read before it sends. If a cycle’s box ships against an unpaid balance under the ship-anyway option from the previous section, the shipping-confirmation email is accurate and should still go out — what breaks trust is a dunning message that arrives afterward and reads as though the box has not shipped, when the subscriber’s driveway already has it. Sequencing solves this cheaply: check fulfilment status before a dunning touch sends, and change the copy, not the schedule, for anyone whose order has already gone.
A brand running both SKIP_PAYMENT_AND_CREATE_UNPAID_ORDER and a ship-anyway policy has compounded the same decision twice without meaning to: the billing attempt creates an order Shopify’s own automation treats as confirmed, and the warehouse ships it, both ahead of the charge clearing. Getting either decision wrong on its own is recoverable with a copy fix; getting both wrong at once means every downstream system — Shopify, the 3PL, the dunning app — is telling the customer something different about the same charge on the same day.
How Is Dunning Management Different From Payment Recovery and Involuntary Churn Prevention?
Dunning management is one lever inside payment recovery, not another name for it, and payment recovery is in turn one of the things that lowers involuntary churn rather than the whole of it.
Involuntary churn is the outcome — a subscriber cancelled by a failed card rather than by choice — and it accounts for somewhere between 20% and 40% of all subscription churn (Paddle/ProfitWell). Payment recovery is the system built to reduce that number, and dunning management is the middle third of it: the part that runs after a charge fails and before the account either recovers or is written off. Roughly 9% of recurring revenue is lost to failed payments before any of that system runs at all (Baremetrics), which is the figure payment recovery as a whole is built against.
None of the decisions that separate dunning, payment recovery and involuntary churn is a copywriting problem, even though the visible part of dunning management is an email sequence. The decision that actually moves the recovery rate is a retry ladder that reads the decline code and the ship cutoff before it decides when to try again, and a rule about which system is allowed to speak to the customer first when an order and a failed charge exist at the same time. That is systems work, not messaging work, and it is what payment recovery means as a build for a Shopify brand running a subscription or replenishment programme — the retry logic, the account updater, the update page and the reporting, built once against your own ship calendar rather than copied from a software default.
Sources
The 9% recurring-revenue figure is Baremetrics’ published finding across the subscription businesses it tracks; the 20–40% involuntary-churn share is Paddle / ProfitWell’s, across the same type of population. Both are cited elsewhere on this site’s own failed-payment benchmarks page, with the same sourcing. The paymentProcessingPolicy behaviour on Shopify subscription billing attempts is drawn from Shopify’s own developer changelog, dated 1 April 2026, and the claim that dunning logic belongs to the subscription app rather than to Shopify’s core system is drawn from Shopify’s reference documentation for subscription apps. The note that Recharge creates an order only after a successful charge is drawn from Recharge’s own documentation. The fulfilment-cutoff arithmetic and the split-ladder recommendation are written from first-hand payment-recovery and ops-automation builds on Shopify subscription and replenishment programmes; the cohort numbers in the worked example are explicitly invented for illustration, not measured, and no recovery-rate figure is quoted because none of the platforms or aggregators involved publishes one that would survive being checked against a primary source.