Recharge Dunning: A Step-by-Step Setup for Shopify Teams

Recharge dunning is the retry-and-message ladder that runs when a Recharge subscription charge fails, and for a Shopify brand doing $3M–$30M it usually means one of two different systems, configured in different places, that finish a failed charge in two different ways. Setup itself — picking a schedule, turning on a channel, saving the strategy — takes under half an hour. What actually costs teams money is not knowing which of the two systems is live on their store, and not deciding on purpose what happens when the ladder runs out.

What Do You Need Before Setting Up Recharge Dunning?

Before opening any settings screen, three things decide how much of this guide applies to a given store: which Recharge plan it runs, whether Failed Payment Recovery is already active, and what a failed charge is currently costing in recovered revenue.

Recharge prices Failed Payment Recovery itself into its Starter plan, at $99 a month — the feature is not gated behind a higher tier. What is gated is the SMS channel: Concierge SMS, the text-messaging layer Recharge’s own dunning messages can send through, is priced as an add-on available on the Plus plan, at $499 a month, and the Custom tier, not on Starter. A store planning to add SMS reminders to its dunning sequence needs to confirm the plan first, because the setup steps below stop at the email channel on Starter.

Read the “current system” row first. Recharge’s own instructions for the Basic recovery strategy state directly that they do not apply to a store already running the Advanced strategy — the two are documented as separate systems per store, not one setting with two modes. Checking which one is active is the actual first step, and it is the one most guides skip because they assume a store starts from zero.

How Do You Set Up Recharge Dunning, Step by Step?

Setting up Recharge dunning means choosing a retry engine, giving it a schedule and a channel, and deciding what it does when a charge is never recovered — six steps, done from Churn tools in the Recharge merchant portal.

Step 1: Confirm which dunning system is active on the store

Open Churn tools in the Recharge merchant portal and check whether Failed Payment Recovery is already running, since access to the Advanced, AI-timed strategy depends on plan, and a store already on Advanced cannot follow Basic-strategy instructions — its retry timing is already automated.

Step 2: Open Failed Payment Recovery

From Churn tools, select Failed Payment Recovery, then open Basic recovery strategy if the store has not been moved to the Advanced strategy. A store new to dunning configuration will usually land here by default.

Step 3: Set the retry count and frequency

Under Failed charges, set how many times a charge retries and how many days apart. Recharge’s own support documentation describes a common unconfigured default of a retry the day after the first failed attempt, then a retry every six days for six more attempts — seven attempts total, spanning roughly a month. That default was built for software billing, not for a box that has to ship: check the actual schedule live in your account, because Recharge has reorganised this settings screen recently and the exact default is worth confirming against the current article rather than assumed from memory.

Step 4: Turn on email, and SMS if the plan allows it

Customise the preset email templates Recharge provides for each stage of the ladder — most Shopify brands can move from generic wording to real subscriber-facing copy here without touching code. Add SMS only if the store is on Plus or Custom, since Concierge SMS is not available on Starter; each text is billed at $0.03 per segment domestically or $0.06 internationally, with a segment capped at 160 characters, so a longer message costs more before a single reply is sent.

Step 5: Decide what happens when the ladder ends

The end-of-ladder outcome is the step covered in full below — confirm whether the strategy auto-cancels an unrecovered subscription, or whether a separate setting leaves the charge open instead, and choose deliberately rather than inherit whichever behaviour happened to be active.

Step 6: Save, activate, and check the first live cycle

Save the strategy, then watch the next billing cycle’s charge errors directly rather than trusting the dashboard summary alone, confirming that messages actually send on schedule and that the end-of-ladder outcome fires the way the previous step configured it.

Which Step Do Most Shopify Teams Get Wrong?

The step most Shopify teams get wrong is step 5 — assuming a single, consistent thing happens when a Recharge dunning ladder runs out, when the outcome actually depends on which retry system configured it.

Recharge’s Failed Payment Recovery documents an automatic outcome at the end of its ladder: if the order is not recovered, the associated subscription is cancelled, tagged with the cancellation reason “Failed Payment flow max retries.” That is a clean, traceable outcome — a churned subscriber shows up in cancellation reporting under a specific label, ready to route into a win-back flow.

The store’s older, separate setting — under the legacy Settings → Payment configuration for “when maximum number of retries are reached” — does not default to that outcome. Left on Default or Do Nothing, a charge that exhausts its retries is marked “Closed max retries reached” and stays there: listed in the Charge errors tab and the Errors export, unresolved, until the customer reactivates the subscription themselves or someone closes the order by hand. Nothing cancels it, nothing routes it anywhere, and nothing forces a human to look at it.

A store can have both screens present in its account at once. Whichever governs a given charge decides whether an unrecovered subscriber becomes a labelled, reportable cancellation or an invisible line in an errors export nobody is scheduled to check.

The practical failure looks like this: a team configures a retry count and frequency in Failed Payment Recovery’s Basic strategy, considers dunning “set up,” and never opens the older Payment settings screen at all — reasonably, since nothing prompts them to. If that legacy setting still sits on its unconfigured default, every subscriber who exhausts the ladder without recovering does not get cancelled or flagged; the charge just closes into an error state that only an Orders – Errors export or a manual look at Charge errors reveals. Six months in, MRR reporting shows churn lower than it actually is, because a meaningful slice of lost subscribers never generated a cancellation event at all — they are still technically “active,” sitting on a closed, unresolved charge.

The fix is a single decision, made once: open both screens, confirm which one is actually governing outcomes for this store, and if it is the legacy setting, either switch it to an explicit cancel action or build a scheduled check of the Charge errors tab so an unresolved charge gets a human decision instead of silence.

What Share of Failed Recharge Charges Actually Recover by Day 3, Day 7 and Day 14?

Recharge does not publish a day-by-day recovery curve for its own retry schedule — no support article or product page breaks down what share of failed charges clear by day 3 versus day 7 versus day 14, so the honest answer is that the figure does not exist as a published number, and it has to be built from your own store’s data.

The method: export Orders – Errors from the Recharge merchant portal (Exports → Create export → Orders - Errors), which carries the charge date and current status for every failed order. Bucket that export by days elapsed since the first failed attempt, then compare the recovered count in each bucket against the schedule actually configured in step 3 above. That comparison answers a more useful question than an industry average would: which of the retry attempts your store pays processor fees on are actually earning their keep, and which are firing well past the point most recoverable declines would have cleared on their own.

To show the shape of that comparison, here is a worked cohort against the common unconfigured default schedule — day 1, then every six days for six more attempts. The numbers are invented for illustration, not measured from any real store, and the schedule should be checked against your own account before drawing conclusions from it:

Recomputed: 22 + 14 + 9 + 7 = 52 recovered of 100, leaving 48 unrecovered at the end of the ladder in this illustration — plug in your own Orders – Errors export in place of these numbers to get the real curve for your store.

The pattern worth checking for, once real numbers replace these, is whether the later attempts — day 19 and day 25 in the default schedule — are contributing anything close to the earlier ones. A retry ladder that recovers most of its total in the first two attempts and almost nothing after is spending processor fees and message sends on a tail that is not working, which is exactly the kind of finding the failed-payment recovery calculator cannot show on its own, because it works from monthly recurring revenue and subscriber counts, not attempt-by-attempt outcomes.

What Does a Recharge Dunning Sequence Actually Cost Per Failed Charge?

No page publishes a single “cost per dunning sequence” figure, because the real answer depends on channel mix and store volume — but two of the three inputs are public, sourced numbers, not an estimate.

Email is priced inside the Recharge plan fee itself: Recharge’s own pricing pages list a per-segment charge for SMS and no separate per-message fee for dunning email, so a sequence run on email alone adds no marginal cost beyond the $99-a-month Starter plan that already includes Failed Payment Recovery. SMS is the metered line: $0.03 per 160-character segment sent domestically, $0.06 internationally, on top of the $499-a-month Plus plan that the channel itself requires.

To make the marginal cost concrete, here is a worked example with an invented monthly volume, since the actual number of failed charges a store sees each month is store-specific and not something to plug a generic figure into:

Recomputed: the marginal SMS spend at this invented volume is $6 a month — a rounding error next to the $499 Plus plan fee that actually gates the channel. The real cost of adding SMS to dunning is almost entirely the plan upgrade, not the per-message rate, unless failed-charge volume is high enough to make the segment cost material on its own.

That ratio is the useful finding: a store weighing whether SMS dunning is worth it should not be pricing the segments, which cost pennies, against the value of a single recovered subscriber’s remaining order. It should be pricing the $499-a-month plan step-up — which buys SMS across the whole store, not only dunning — against what that single channel adds to recovery on top of email alone, a comparison the failed-payment benchmarks page’s ~9%-of-MRR figure (Baremetrics) helps size but cannot answer for a specific store without that store’s own before-and-after recovery rate.

How Is Recharge Dunning Different From a Generic Retry Schedule?

Recharge dunning is one platform’s specific implementation of the retry-and-message practice covered generally in what dunning management actually is — the mechanics above are Recharge’s, not a description of dunning as a concept, and a store running Skio, Smartrr or Stay AI underneath Shopify instead will find a different settings screen with a different default schedule.

What carries across every platform is the constraint that makes subscription-box dunning harder than software dunning: the ladder has to recover a charge before that cycle’s fulfilment cutoff, not just before the next invoice date, or the warehouse is left making a ship-skip-or-bill-anyway call the retry schedule was never built to inform. Recharge’s documented seven-attempt, roughly month-long default schedule was clearly not designed around a 3-to-5-day pick-and-pack window — most of its later attempts fire well after a physical order would already have needed a decision.

About 9% of recurring revenue is lost to failed payments before any recovery system runs (Baremetrics), and 20–40% of subscription churn is involuntary — caused by the payment, not the customer (Paddle/ProfitWell). Recharge’s own reporting puts the first-attempt failure rate at roughly 7% of recurring charges, vendor-reported, and claims its AI-timed Advanced strategy can recover up to 23% more failed transactions than “the alternatives,” also vendor-reported — a claim worth testing against a store’s own before-and-after numbers rather than assumed, the same way the day-3/7/14 curve above has to be built from real data instead of taken from a marketing page.

How Do You Verify Recharge Dunning Is Actually Working?

Verifying Recharge dunning means checking three things separately, because each can look fine while another silently is not: that messages are actually sending, that the retry schedule matches what was configured, and that the end-of-ladder outcome fires the way step 5 set it.

Trigger or wait for one real failed charge and confirm the customer-facing email — and SMS, if it is on — actually arrives, not just that the Recharge dashboard shows the message as sent; a template referencing a broken merge field can show as delivered while reading as garbled to the customer. Cross-check the retry dates on that same charge against the schedule set in step 3, since a settings change made after a charge already entered the ladder does not always apply retroactively to charges mid-sequence. Finally, let one test charge run all the way to its last attempt and confirm the outcome matches the decision made in step 5 — either the cancellation reason “Failed Payment flow max retries” appears, or the charge sits correctly in Charge errors for the handling process you built around it, not a default nobody chose.

A dunning ladder that sends the right messages on the right days and then does something nobody decided at the end is not fully configured, whatever the setup screen says. Getting that last mile right — the schedule checked against the fulfilment cutoff, the terminal outcome chosen on purpose, the recovered-versus-lost split actually measured rather than assumed — is payment recovery as a build, not a settings screen filled in once and left alone.