Failed payment retries: the tactical playbook

The retry schedule: immediate, +3d, +7d, +14d

The default schedule that works for almost every consumer-goods store is four retries over 14 days with exponential spacing. Specifically: an immediate retry at T+0 (or T+~1 hour), then T+3 days, T+7 days, T+14 days. Each retry captures a different bucket of recoverable failures, and the spacing is chosen because the recovery probability decays roughly exponentially with time since failure.

1. Retry #1 (T+1h, immediate) — Catches network timeouts, processor rate limits, and transient fraud holds that the bank cleared within minutes. Cheap, fast, often invisible to the customer.
2. Retry #2 (T+3d) — Catches insufficient-funds declines that resolve after a payday (most US payroll cycles are bi-weekly). Three days is short enough to catch the next deposit, long enough to look intentional to the bank's fraud system.
3. Retry #3 (T+7d) — Catches the longer payday cycles and gives time for the dunning email to motivate a manual card update if the customer chose to action it themselves.
4. Retry #4 (T+14d) — Final attempt. Most of what's recoverable has been recovered by now. The fourth retry catches stragglers — customers who saw the email at day 10 and updated their card on day 13.

Beyond day 14 the recovery probability is low enough that you're better off pausing the subscription and moving the subscriber into a win-back flow. Some apps default to 28-day retry windows; the marginal recovery past day 14 rarely justifies the extra retry attempts (each retry is a charge attempt that some payment processors count toward fraud-risk thresholds).

Why exponential backoff beats linear

Some apps default to a linear schedule — retry every 3 or 4 days for two weeks. Linear feels simpler but recovers measurably less. The reason is a mismatch between when failures actually become recoverable and where the retries land.

Soft declines (the most retriable type) typically resolve within the first 48 hours — funds land, the bank fraud system cools down, the network issue clears. A linear schedule's first retry at T+3d misses that whole window. By the time retry #1 fires, the bank might have flagged the customer's account again because of unrelated activity, and the new attempt looks like a re-charge after a decline, which is exactly the pattern fraud systems hate.

Exponential schedules front-load attempts where the recovery probability is highest. The immediate retry costs almost nothing and captures a significant fraction of the resolvable softs. Subsequent retries get sparser because each one is fighting against decay — the customer who hasn't updated their card by day 7 is unlikely to update it on day 10 either.

Soft declines vs hard declines: branch your retry logic

Retrying every decline on the same schedule is the most common waste of recovery attempts. Soft and hard declines need different handling because their underlying causes are different.

Soft declines are caused by temporary state — funds, holds, network. The card and account are valid. Retry codes you'll see commonly include: 51 (insufficient funds), 65 (exceeds withdrawal frequency), 91 (issuer unavailable), 96 (system malfunction), R20 (processor timeout). For these, run the full 4-retry schedule.

Hard declines are caused by something only the customer (or their bank) can fix. The card itself is invalid in some way. Codes include: 04 (pickup card / lost-stolen), 14 (invalid card number), 41 (lost card), 43 (stolen card), 54 (expired card), 57 (transaction not permitted), R0/R1 (customer requested stop). For these, retries are wasted attempts — branch to dunning + portal update immediately.

Most apps expose decline-reason branching as a setting. If yours doesn't, you have two options: switch to one that does, or live with the lower recovery rate and noisier merchant ID. There's no good middle ground — the decline reason is in the response object from Shopify, and using it isn't optional in a serious system.

Smart retry timing: align with paydays

Beyond the basic schedule, there's a second tactical layer: when in the day, and when in the week, you fire retries. The basic schedule says retry 3 days after failure. Smart timing says retry 3 days after failure, but specifically at 11am local time on a Friday, because that's when payroll lands for most US workers.

Insufficient-funds declines are the single largest soft-decline bucket. They resolve when funds land. Funds land on paydays. US payroll is dominated by two patterns: bi-weekly (every other Friday) and semi-monthly (1st and 15th of the month). If you retry at a random time on a random day, you're throwing away half your attempts on accounts that won't have funds for another 4 days. If you retry at 11am the morning after a known payday, you hit accounts at their highest balance.

Most apps don't expose this level of timing control directly, but they do let you shift the retry schedule by hours or days. A simple heuristic that works for US consumer stores: if the original charge fell on the 14th or 29th, push the +3d retry to land on the 17th or 2nd (post-payday). For non-US stores, the timing varies — UK is typically end-of-month, Germany is variable per employer. If you have a multi-country subscriber base, segment the schedule by country.

Account-updater: the free 30% recovery

Account-updater (Visa Account Updater, Mastercard Automatic Billing Updater, Amex Cardrefresher) is a network-level service that pushes new card details to merchants when a card is reissued. Lost, stolen, expired, replaced — the issuing bank notifies the network, the network notifies any merchant with that card on file, and the new card details replace the old in your processor's vault. The subscriber never knows anything happened.

Roughly 30% of all failed renewals are caused by expired cards. Account-updater catches almost all of them, silently, with zero customer effort. This is the single highest-leverage component in any recovery system. If your processor supports it and you haven't turned it on, you're choosing to lose ~30% of recoverable revenue.

Support varies by processor. Shopify Payments enrolls merchants automatically (no action needed). Stripe supports it via their Card Account Updater; you may need to opt in. Most smaller gateways do not support it at all — which is one of the underrated reasons to prefer Shopify Payments or Stripe for subscription stores.

• Verify enrollment — check your processor dashboard. "Card updater", "Account updater", "Network updates" — naming varies. If it's there, enable it.
• Check the latency — most networks push updates within 24–48 hours of bank issuance, but some can take a week. Your retry schedule needs to be long enough to give updates time to propagate.
• Don't dunning-email immediately on hard decline if it's an expiration — give account-updater 24h to push the new card before bothering the customer.

The self-service payment-method update flow

When automated layers don't recover, the subscriber needs to act. The job of the payment-method-update flow is to make that action as frictionless as possible. The single largest drop-off in this flow is the login wall — most subscribers don't remember their password and abandon at the forgot-password link.

Magic-link entry solves this. The dunning email contains a single button: Update payment method. Click it, land directly on a one-page form with the current card masked and a field for the new card details. No login, no password reset, no account-lookup. The link is signed and time-limited (typically 7 days) for security.

The form itself should ask for one thing: a new card. Don't bundle in upsells, surveys, or address-confirmation steps. Each extra field drops conversion by single-digit percentage points. The address Shopify has on file is almost always still correct; ask for it only if you have evidence it's stale.

1. Email button → magic-link URL with signed token
2. Lands on /portal/update-payment with current card masked, no login required
3. Single Shopify Payments / Stripe card form (use the processor's hosted element — PCI is their problem, not yours)
4. On submit: vault the new card, retry the failed charge immediately, redirect to success page
5. If retry succeeds: confirmation + show next renewal date
6. If retry fails again: human follow-up — the new card is also declining, something's wrong

The give-up rule: when to stop retrying

Retries can't go on forever. At some point you have to stop, and the question is exactly when. Stop too early and you miss late recoveries; stop too late and you damage your merchant standing with the card networks plus annoy the subscriber into voluntarily cancelling.

The rule that works: stop after the 4th retry (T+14d), pause the subscription (don't cancel — pause), send one final notification saying we've paused your subscription because we couldn't process payment, click here to reactivate when you're ready, and move the subscriber into a 30/60/90-day win-back cadence.

Pause-not-cancel is important. Cancelling outright loses the subscription history, the discount the subscriber was on, any custom configuration, and signals to the subscriber that the door is closed. Pause keeps everything intact — when (if) they come back, they're back on their old terms with one click. The reactivation conversion rate is roughly 3x higher from paused than from cancelled.

Dunning email cadence alongside the retries

Retries and dunning emails run in parallel, not in series. The retry schedule operates silently; the dunning sequence is the customer-facing communication that tells the subscriber what's happening and gives them a way to help. The two cadences need to harmonise.

1. Email #1 (T+1d, after immediate retry fails) — Friendly notice: heads up, your card didn't go through. We'll try again automatically, no action needed unless you want to update your card now.
2. Email #2 (T+4d, after retry #2 fails) — Mild urgency: we're still trying. Update your card here to skip the queue.
3. Email #3 (T+8d, after retry #3 fails) — Active prompt: your subscription will pause in 6 days if we can't process payment. Update card here.
4. Email #4 (T+14d, after final retry) — Pause notice: we've paused your subscription. Click here to reactivate when you're ready.

Tone is everything. Each email should read like a friendly nudge from a store the subscriber likes, not a debt-collection letter. Subject lines like "Action required: your account is past due" make subscribers feel like deadbeats and trigger cancellation out of pride. Subject lines like "Quick — your card didn't go through" frame it as a friendly heads-up. Tone differences here measurably affect recovery rates. Full copywriting patterns live in our dunning emails guide.

Edge cases that quietly damage recovery rate

Past the main schedule, a handful of edge cases consistently degrade recovery rate for stores that don't handle them. Each one is small individually; together they explain why two stores with the same app and the same MRR see 50% vs 75% recovery rates.

• Currency mismatches — Subscriber moves country, address updates, charges now go through a different acquirer with stricter fraud rules. Some charges fail not because of the card but because of the routing. Solution: verify your processor's multi-currency settings.
• Subscription created during a free trial — Some processors mark the first real charge as a fresh transaction with no history, triggering fraud holds. Pre-authorize a $1 hold at trial signup to establish the card with the network.
• Subscribers using prepaid cards — Recharged monthly with whatever's left. About 5% of consumer subscribers use them. They fail constantly and are not recoverable via retries — only via dunning + customer action. Flag them in your analytics so you don't over-invest in retry attempts.
• Anniversary-billing month boundaries — A subscriber who signed up on the 31st bills on the 28th or 30th in February-March. Some apps mis-handle this and skip a renewal entirely, then double-bill the next month. Check your app's behaviour explicitly for end-of-month signups.
• Time-zone misalignment between retry scheduler and subscriber — Scheduler runs in UTC; subscriber is in Los Angeles. The morning retry intended for 11am LA fires at 3am LA. Configure local-time retries if your scheduler supports it.

Measuring whether your tactics are working

If you can't measure each layer of the recovery stack individually, you can't improve it. The end-state metric is recovery rate, but the diagnostic metrics tell you which layer to fix.

• Recovery rate by retry attempt — what % of recoveries happened on retry #1 vs #2 vs #3 vs #4. If recovery #1 is low, the immediate retry isn't enabled or fires too late. If recovery #4 is high, you might be giving up too early.
• Recovery rate by decline reason — group recoveries by the original decline code. Card-expired should be near 100% (account-updater + dunning); insufficient-funds should be 60–80% (retries); fraud-blocks should be ~0% (never recoverable).
• Recovery rate by source — automated retry vs account-updater vs customer card update vs human follow-up. If account-updater is 0%, it's not enabled. If customer card update is 5%, your dunning or magic-link flow is weak.
• Time-to-recovery distribution — median and 90th percentile. Median 3 days is healthy. Median 10+ days suggests the retry cadence is too sparse or dunning is too tentative.
• Cancel-after-pause rate — what % of subscribers paused by failed payment never reactivate. High (>70%) suggests pause messaging is too final-sounding; lower (50%) suggests the win-back sequence is doing its job.