Resources

Recharge Dunning: Failed Payment Recovery Guide

Recharge runs your subscriptions. Its native failed-payment handling retries a declined renewal and notifies the customer — a reasonable baseline, and where most Recharge stores stop. When a renewal charge fails, what happens next decides whether that subscriber comes back, and the native path treats every failure the same way: same retry rhythm, same message, whether the card was declined for insufficient funds or is gone for good.

What Recharge does natively

Recharge retries failed charges on its own schedule and sends dunning notifications so the customer can update their card. For the simplest failures — a temporary processing error, a balance that clears in a day or two — that is often enough. The limits show up with the harder declines. A native schedule cannot read a decline code and change its mind: an insufficient-funds decline wants a retry timed to when money lands, an expired card wants an update request instead of another attempt, and a hard decline wants the attempts to stop entirely.

Where the native path stops

Three gaps matter. First, timing: fixed-interval retries fire whether or not the retry has a chance. Second, the backlog: native dunning works failures as they happen; the failures already sitting in your store from the last 90 days are not re-worked. Third, the exit: when a billing failure turns into a cancellation, the native flow has no save offer to make. The subscriber who might have stayed for a pause or a credit just leaves.

How a recovery layer works on Recharge

Swipe Again works alongside Recharge through its documented third-party integration: your subscriptions stay in Recharge, and the recovery layer reads each failure as it happens. Retries are scheduled by decline type. Reminders go out in your brand, linking to a card-update page built for a phone. Run one recovery system at a time — if a third-party tool is working your failures, Recharge's native dunning should be off, so subscribers are never chased by two voices at once. When you connect, the last 90 days of failures are backfilled and worked, which is usually where the first recovered revenue sits. The merchant-facing details are on our Recharge dunning page.

The cancel click, too

Recovery is only half the leak. Recharge subscribers who click cancel meet a cancel deflection flow: one question about the reason, one matched offer — discount, pause, or credit — and the exit always one click away. Failed payments and cancellations are the same subscriber at two moments of doubt; working only one of them leaves the other open.

Swipe Again is $179/month flat for both halves — no percentage of recovered revenue, no MRR tiers — with a self-serve 14-day trial. Judge it the honest way: on your own store's failed payments.

Working the failure report, weekly

The difference between stores that recover well on Recharge and stores that don't is rarely the tooling — it's whether anyone reads the failed-charge report as a weekly habit. Fifteen minutes is enough. Sort the week's failed charges by decline type and count them before you read a single customer name: if hard declines are climbing, your problem is card staleness and the fix is earlier card-update prompts, not more retries. If one decline code suddenly dominates, suspect plumbing before customers — a gateway credential or integration fault fails every charge identically and masquerades as a churn spike. Then look at the ages: failed charges older than the recovery window that are still sitting unresolved are process failures, not payment failures, and each one is a subscriber who was saveable when the charge first declined. Finally, check the recovered number against last week's — recovery rate is a trend, and a quiet slide usually traces to one change: a new email template, a portal tweak, a migration. The stores that treat this as a standing fifteen minutes catch in a week what the others find in a quarter.

Related reading: Recharge involuntary churn

How a failed payment flows on Recharge

A Recharge renewal starts as a charge. When a subscription comes due, Recharge creates the charge and places it in a queue for its billing run. Every Recharge charge moves through three states. Queued means the charge exists and is waiting for its turn. Processing means Recharge has sent it to your payment gateway, against the customer's card on file. From processing, the charge lands in one of two places: success — or error, where the declined charge sits carrying the processor's reason for the failure.

That error state is where recovery is won or lost. The charge record holds the decline information the processor returned, and every later retry is a fresh attempt against the same charge and the same customer. Nothing about it fixes itself: left alone, the subscription moves toward cancellation and a customer who never decided to leave becomes a churn statistic. Most industry estimates put first-attempt failures at roughly 5–15% of monthly charge value, so the error queue is a standing population that needs a deliberate process run against it.

The gaps that cost renewals

Stated as gaps — the specific places recoverable renewals leak out of the native path — they are these four.

A fixed native schedule

Native retries fire on the cadence in your settings, whether or not that timing fits the failure. An insufficient-funds decline retried before a pay cycle turns fails for the same reason it failed the first time — and spends one of a finite number of tries. A temporary issuer decline, by contrast, often clears within days. One calendar cannot be right for both: a fixed schedule is reliably early for the failures that need patience, and persistent with failures that need a different action entirely.

No decline differentiation in third-party mode, without a layer

Recharge supports a documented third-party mode for failed-payment recovery, and its defining rule is that the merchant's native failed-payment recovery stays off while a third-party system works the failures. That trade only makes sense if the layer taking over actually reads declines. Without one, third-party mode is just the native path switched off: nothing routes an expired card to an update request instead of a retry, and nothing stops attempts on a hard decline.

No backfill

Native handling works failures as they occur, from the day it is configured. The failures already sitting in your charge history are never re-worked. Some of those subscribers are genuinely gone; others failed on a soft decline or a replaced card and would renew today if a proper sequence ran against their failure. Native dunning never finds out which.

No cancel deflection in the billing layer

When the billing sequence ends, it ends. There is no save moment inside the billing layer: no single offer matched to why this subscriber is leaving, presented at the moment they move to cancel. A subscriber whose payment failed and who then clicks cancel meets the same plain exit as one who simply lost interest — though the first never wanted to leave.

Layering decline-aware recovery on Recharge

The layered model keeps your subscriptions in Recharge and adds a recovery system that owns the failure window. The merchant-facing setup is on our Recharge dunning page; the operating sequence is this.

Step 1: Classify every failure on arrival

Each failed charge is read for its decline type before anything else happens. Soft declines enter a retry track. Expired and replaced cards enter an update track. Hard declines skip retries entirely and go straight to a request for new card details. Every later step is only as good as this routing.

Step 2: Run a decline-aware schedule through the Recharge API

Retries execute through the Recharge API — a processing call against the failed charge (POST /charges/{id}/process) — so the attempt runs on Recharge's rails, against the card Recharge holds, and the result lands back on the same charge record. Timing follows the decline: attempts are capped at eight per failure, and insufficient-funds declines follow a payday ladder out to roughly day 25, instead of burning every attempt in the first week. Where the underlying processor is Stripe, attempts are coordinated against Stripe's native schedule under a combined cap of 15.

Step 3: Send branded outreach that asks for one action

In parallel, the subscriber hears from your store — not from a platform. Dunning emails go out on days 1, 3 and 7, each asking for exactly one thing and linking to a secure, branded card-update page. SMS follows the same sequence, capped at three messages, each ending with "Reply STOP to opt out".

Step 4: Backfill the backlog

On connect, the last 90 days of failed charges are pulled in and worked through the same classification, schedule and outreach as new failures. Expect recent soft declines in that backlog to behave like fresh failures, and the oldest entries to mostly need new cards.

Step 5: Deflect before the cancellation lands

For subscribers who reach the end of recovery still unresolved, and for subscribers who move to cancel directly, present one save offer matched to the stated reason — a discount, a pause, or a credit — with the exit kept one click away at all times. A billing failure that ends in a save is a renewal; one that ends at a plain cancel button is a loss chosen by omission.

Coordination rules so the layers do not collide

• Native failed-payment recovery stays off. In third-party mode this is the documented arrangement, so exactly one system works each failure.
• One system owns the retry. Every failed charge has a single schedule with a single owner. Two systems attempting the same charge on overlapping calendars helps nothing.
• One message stream. The subscriber receives one sequence, in your brand's voice. Duplicate warnings teach customers to ignore both.
• Both layers agree on the end state. A recovered charge continues the subscription in Recharge as normal; an unrecovered one ends the same way for every system watching it.

What the layer costs

Swipe Again is $179/month flat — no percentage of recovered revenue, no tiers — covering failed-payment recovery and cancel deflection, with a self-serve 14-day trial. Judge it against the bands most industry estimates use for recovery: roughly 5–15% of failed payments with nothing working them, 25–40% with processor-native handling, 45–60% with a dedicated layer. Recover $179 in 30 days, guaranteed — or Swipe Again is free the next 30 days.

The bottom line

Recharge's native handling is a reasonable baseline with four gaps: a fixed schedule, no decline differentiation once native recovery hands off, no backfill, and no save offer in the billing layer. A decline-aware layer run in Recharge's documented third-party mode closes those four.

What Recharge payment recovery costs

Option	Cost
Recharge’s native retry settings	Included in your platform bill
Swipe Again	$179/mo flat — no percentage of recovered revenue
Revenue-share recovery tools	Typically 5–15% of whatever they recover

Prices checked October 2026. The full pricing-model comparison is on the flat-fee dunning comparison page.

Frequently asked questions

Does Recharge retry failed payments on its own?

Yes — Recharge's native handling retries a failed charge on its configured schedule and notifies the customer. The limit is differentiation: the same rhythm and message regardless of why the charge failed. And in the documented third-party mode, native recovery is switched off by design, because a connected recovery system has taken the job over.

Who runs the retry when a recovery layer is connected?

The recovery layer schedules it, and Recharge executes it. Attempts are placed through the Recharge API against the failed charge, so the charge runs on Recharge's rails with the payment method Recharge holds, and the outcome is recorded on the same charge. Your subscriptions and customer records never leave Recharge.

Will my subscribers hear from two systems at once?

They should not, and on Recharge the arrangement is explicit: native failed-payment recovery stays off while the layer works, so the subscriber gets one retry schedule and one message stream, in your store's name. Both voices running at once is a configuration error, worth fixing the day you spot it.

How much does Swipe Again cost for Recharge stores?

$179/month flat, with no percentage of recovered revenue — covering decline-aware retries through the Recharge API, branded dunning email and SMS, secure card-update pages, the 90-day backfill, and cancel deflection. The 14-day trial is self-serve; the test that matters is your own store's failed charges.

See also Seal Subscriptions Dunning: Recovery Guide for the companion detail on this side of the problem.

One more piece of the same puzzle: Skio Dunning: Failed Payment Recovery Guide.

Related: Loop Subscriptions Dunning: Recovery Guide covers the neighbouring case in full.

For the full picture, pair this with Recharge Involuntary Churn.

Updated November 2026.