Recharge Setup: The Settings Shopify Teams Get Wrong

Recharge is not misconfigured, it’s under-configured

Recharge, the subscription management platform that layers onto Shopify Checkout, works out of the box. That’s the problem. “Works” and “recovers the revenue it could recover” are different bars, and the gap between them is a handful of settings almost nobody touches after the initial build: the dunning retry window, the passive-cancellation toggle, and decline-reason routing. None of these are hidden. They’re one menu deeper than the settings a launch team configures under deadline, and once a store goes live, nobody goes back.

This is a setup guide for teams running Recharge on Shopify Plus, or a comparable paid subscription platform, at $3M to $30M in revenue with an existing subscriber base. If you’re choosing a subscription platform for the first time, or running under a few hundred active subscriptions, the settings below still apply, but the return on the hour it takes won’t show up the same way — passive cancellation quietly costing you money only matters once volume makes the leak visible in a monthly report. Below $3M, spend the hour on acquisition instead.

What you need before you start

You’ll need admin access to Recharge (not just Shopify), a list of your last 90 days of failed-charge events (Recharge Analytics or your data warehouse if it’s piped out), and your current subscription cycle length — 14, 30, 45 or 60 days, whatever your product actually ships on. Treat the retry window numbers in this guide as a starting point, not a rule: a brand shipping every 14 days cannot run the same retry length as one shipping every 60 without the retry eating into the next order’s lead time.

You do not need a developer for steps one through four. Step five, decline-reason routing, needs someone comfortable with Recharge’s webhooks or an integration tool that can read them — this is where most teams stop, and it’s also where most of the remaining recovery sits.

Step 1: Find your current dunning strategy

Go to Recharge admin, then Settings, then Dunning management. Most stores have one dunning strategy applied to all subscriptions; some run more than one if they segment by product type. Open the active strategy and note three numbers: retry count, the interval between retries, and what happens when retries run out. Write these down before changing anything — you’ll want the before state if you’re going to measure the after.

The default most stores launch with is three retry attempts over five days. That number comes from Recharge’s own onboarding flow, and it is tuned for getting a store live fast, not for maximum recovery. It closes the case in under a week, which sounds responsive. It is also shorter than the time many card issuers take to reissue a card after an expiry or a fraud block, which means the retry sequence often finishes before the customer’s bank has caught up.

Step 2: Extend the retry window to match your cycle, not the default

Change the retry count to four or five attempts, spread across nine to fourteen days rather than five. The reasoning: a failed charge from an expired card resolves when the customer gets and activates a replacement, and issuer reissue timelines run longer than five days more often than a launch team assumes. Spacing retries three to four days apart, rather than daily, also means each attempt lands on a different day of the week, catching different batch-processing windows some card networks run.

The trade-off is real: a longer window keeps a non-paying subscriber’s order queued longer, which can distort your near-term revenue forecast if you’re not adjusting for it. If your product ships every 14 days, a fourteen-day retry window means the customer could miss an entire cycle before you know whether the charge will ever clear. For short-cycle products, keep the window inside half the cycle length — nine days on a 14-day product is workable; fourteen is not.

Step 3: Turn off passive cancellation, turn on passive skip

This is the setting most teams don’t know they have wrong. In the same dunning strategy screen, find the outcome for “retries exhausted.” The default in many Recharge setups is passive cancellation: when the last retry fails, the subscription cancels automatically, with no decision from the customer. The subscriber didn’t choose to leave. Recharge closed the account on the store’s behalf because a card stopped working.

Switch this to passive skip instead. A skipped subscription pauses rather than terminates — the next order doesn’t ship, but the subscription record stays open, and your win-back flow can target “your subscription is paused, update your card to resume” rather than “you cancelled, come back.” The distinction matters operationally: a paused subscriber returning needs one click. A cancelled one has to rebuild their box, re-enter payment, and re-agree to terms — friction that Recurly’s Consumer Goods Churn Benchmark, and general subscription-industry reporting, associate with meaningfully lower recovery rates than a simple resume action, though the exact recovery-rate gap is not something we’ve measured on Recharge specifically and isn’t published at a level precise enough to quote here.

Step 4: Rebuild the dunning email sequence around the pause, not the cancellation

Once passive skip is live, your dunning emails need to stop implying the account is at risk of disappearing and start making the resume action obvious. A three-email sequence works for most catalogues: the first email, sent at the first failed charge, says the card didn’t go through and links straight to the payment-update page — no marketing copy, no upsell. The second, around the midpoint of your retry window, repeats the ask with more urgency and states plainly what happens if it isn’t resolved (a pause, not a loss). The third, sent when the window closes, confirms the pause and gives a one-click resume link that pre-fills the subscription, not a generic “manage your subscription” link that dumps the customer into a portal.

Keep the emails from your regular marketing sends separate — a failed-payment notice competing for attention against a promotional campaign in the same inbox on the same day gets ignored more often, though we haven’t measured that specific interaction and it’s a reasonable operating assumption rather than a cited figure.

Step 5: Route by decline reason — the step teams get wrong

This is the proprietary part almost no Recharge setup does, because it isn’t a toggle — it’s a build. Recharge’s failed-charge webhook carries a decline reason code alongside the failure event: insufficient funds, expired card, card declined by issuer, and a handful of others depending on the payment processor. The default dunning flow ignores this entirely and sends the same email regardless of cause.

That’s a mismatch. An expired-card decline needs an immediate “update your card” prompt — there’s nothing to wait for, the old card will not start working again. An insufficient-funds decline is different: retrying immediately just repeats the failure, and the better move is delaying the next retry attempt by a few extra days to increase the odds the account has been topped up, while sending an email that doesn’t ask the customer to do anything except be aware a charge is coming.

Building this requires reading the decline code off the webhook payload and branching your email and retry-timing logic on it — either through a Recharge integration partner that exposes this, or a custom endpoint that receives the webhook and calls Recharge’s API to adjust the next retry date. It is the single highest-effort item on this list and, based on where recovery rates plateau after steps one through four, the one most likely to move the number further once the easy settings are already fixed.

How to verify the changes worked

Don’t trust the settings screen alone — check behaviour. Pull failed-charge events from the 30 days before your change and the 30 days after, and compare two things: the percentage of failed charges that eventually recovered (cleared on a retry) and the percentage of subscriptions that ended in cancellation versus pause. If recovery rate is flat but cancellations dropped, passive skip is doing its job even if the retry window isn’t yet — the two settings solve different parts of the same problem. If neither moved, check that the dunning strategy you edited is actually the one applied to the subscriptions you’re measuring — stores with more than one active strategy sometimes edit the wrong one and see no change at all.

For a fuller read on where your recovery sits against comparable DTC consumables brands, /benchmarks/subscription-churn-dtc-consumables lays out the comparison points, and /tools/subscription-churn-calculator turns your own failed-charge counts into a monthly revenue-at-risk figure without needing a spreadsheet built from scratch.

This logic is not specific to any one platform’s marketing terms: it applies whether the vendor calls it dunning, retry logic, or payment recovery, and whether the storefront in question is running Recharge, a Recharge alternative, or a native Shopify subscription app with comparable controls. What’s specific to Recharge is where the settings live and what ships as default.

Subscription businesses built for scaling brands, particularly those in the $3M-$30M range covered at /for/scaling-brands, tend to treat payment recovery as a set-and-forget item from the Shopify Plus build phase. It isn’t. It’s a retention lever that degrades quietly the longer default settings sit untouched, and it belongs to whoever owns subscription retention at the company, not whoever built the storefront.

A failed charge isn’t churn until you decide it is. Every setting above changes whether that decision gets made automatically by a default, or deliberately by the team that owns the outcome — which is the whole case for treating this as a subscription retention problem rather than a one-time technical setup, and for revisiting /services/subscription-retention once the settings above are live and the recovery numbers start moving.