DEV Community: Swipe Again

Failed Payment Recovery for Recharge: How Conducted Retries Work

Swipe Again — Fri, 23 Oct 2026 14:34:55 +0000

Disclosure: we're the Swipe Again team. We build failed-payment recovery software, including the Recharge conductor described below. Everything here is mechanics — check it against Recharge's API docs and your own failed-charge list; it either matches or it doesn't.

When a subscription payment fails on Recharge, the default sequence is short: a fixed set of retries on a fixed calendar, a small set of email templates, and then the subscription cancels itself. None of those steps reads the decline code. That is the whole problem, because a decline code is the difference between three completely different situations:

Insufficient funds wants a retry timed to when money is likely to be there — payday, not tomorrow morning.
An expired or replaced card wants a secure card-update link. Retrying a dead card number accomplishes nothing except burning attempts.
A hard decline ("do not honor" on a closed account, stolen card) wants no retry at all — it wants the card replaced, full stop.

One fixed schedule treats all three the same. Recovery software exists to route each failure by its cause instead.

The conductor model on Recharge

Recharge exposes the piece that makes real recovery possible: POST /charges/{id}/process. Processing a charge through the API runs the charge through Recharge's own payment processing — the merchant's existing gateway, the customer's existing payment method on file, no new processor, no card data anywhere near the recovery tool.

A conductor sits on top of that endpoint and decides when each charge should be processed:

Failures stream in live. Recharge webhooks — charge/failed, charge/paid, charge/max_retries_reached, charge/deleted — deliver every failed charge with its decline reason attached.
Each failure is routed by decline code. Soft declines get a retry schedule timed to the cause (up to six attempts across roughly 16 days). Card problems get a branded card-update flow instead of blind retries. Hard declines stop wasting attempts.
Retries are check-then-act. Before any attempt, the charge's current state is re-read — if the customer already paid, updated their card, or cancelled, the retry never fires. Nobody gets double-charged because two systems raced.
Follow-up runs in the merchant's name. Branded dunning emails on days 1, 3 and 7, SMS as an opt-in channel, and a card-update page that carries the store's name and color — because a subscriber who doesn't recognize the sender doesn't update their card.
The backlog is worked, not written off. On connect, the last 90 days of failed charges are pulled in and run through the same sequences. For most stores, the first recoveries come from failures that predate the tool entirely.

One coordination rule matters: the merchant's native retry strategy and the conductor must not fight over the same charge. The check-then-act discipline above is what keeps a charge from ever being retried twice at the same time, whichever system scheduled first.

Why not just turn up Recharge's retry count?

Because the count was never the constraint. A sixth blind retry on an expired card recovers exactly as much as the fifth did: nothing. The failures split into timing problems (retry, timed well), card problems (get a new card), and dead problems (stop). More attempts applied evenly across all three mostly adds failed-transaction fees and annoyed subscribers. Routing beats volume.

The pricing shape matters too

Most recovery tools charge a percentage of whatever they recover — outcome-based pricing, as their own FAQs put it. That means the bill grows precisely when your payment problem is worst, and a good recovery month is an expensive one. We took the other position: Swipe Again runs this conductor model on Recharge for a flat $179/month, no percentage of recovered revenue — decline-code-aware retries through Recharge's own charge processing, branded dunning and card-update pages, the 90-day backfill, and cancel deflection, with a 30-day guarantee (recover $179 in 30 days, or the next 30 days are free).

Whoever runs recovery for your store, run it deliberately: read the decline code, match the response, and stop losing subscribers whose money was good.

The Cancel Click Is a Billing Event

Swipe Again — Thu, 22 Oct 2026 23:25:01 +0000

Disclosure: This post is published by the Swipe Again team. We build failed-payment recovery software for subscription businesses.

Subscription businesses split churn into two buckets: voluntary (they chose to leave) and involuntary (their payment failed). There is a third moment that gets almost no instrumentation, and it decides more revenue than either: the cancel click itself.

When a subscriber clicks cancel, they are rarely saying "this product has no value." They are saying one of four things: it's too expensive right now, I don't use it enough this month, I'm overwhelmed, or I'm annoyed about something specific. Three of those four have an answer that isn't a cancellation — a pause, a smaller plan, a skipped cycle, a fix. But most cancel flows offer exactly one button, so every one of those subscribers becomes the same statistic.

Treating cancellation as a billing event means three things change:

The save happens before the confirm. One screen, one honest offer matched to the reason they picked. Pause for "too busy." A downgrade for "too expensive." A skip for "I have too much." Discounts belong last, not first — leading with a discount trains your best customers to click cancel every renewal.

The offer must be real. A pause that still charges, a downgrade that doesn't exist, a "skip" that ships anyway — subscribers learn fast, and the second time they click cancel they mean it. Deflection built on dark patterns buys a month and costs the relationship.

Failed-payment cancellations are different. A subscriber whose card declined and who then cancels from a dunning email is not a save-offer candidate; they're a card-update candidate who took the wrong exit. Their flow should route back to updating payment details first. Mixing the two populations is how save rates get understated and dunning gets blamed.

None of this requires being clever. It requires deciding that the moment of cancellation is part of the billing system — measured, sequenced, and honest — instead of a formality at the bottom of a settings page.

It's one of the layers we built into Swipe Again: https://swipeagain.com

Dunning Emails That Actually Get Cards Updated

Swipe Again — Thu, 22 Oct 2026 23:24:20 +0000

Disclosure: This post is published by the Swipe Again team. We build failed-payment recovery software for subscription businesses.

Most dunning emails fail for a boring reason: they ask the customer to do something hard, in a moment of mild embarrassment, with no clear payoff. "Your payment failed. Please update your billing information." That is the whole genre, and it converts like it.

A dunning email that works treats the failed payment as what it usually is — an accident, not a decision. Cards expire. Banks reissue. Accounts hit a limit on the wrong day. The customer did not churn; their card did. The email's job is to make fixing it take thirty seconds.

Four things separate the emails that recover cards from the ones that get archived:

Send from the merchant, not the tool. The subscriber bought from a brand they chose. An email from that brand's name and domain gets opened; an email from a billing vendor gets scanned and skipped. Dunning is a customer-relations moment wearing a payments costume.

Say what happens next, in one line. "Your access continues until Friday. Update your card before then and nothing changes." A concrete grace window beats urgency theater. People act on deadlines they believe.

Link to a page that does one thing. The card-update page should show the plan, the amount, and the card fields — nothing else. No login wall if you can avoid one (a secure, tokenized link from the email), no navigation, no upsell. Every extra element is a place for a willing customer to give up.

Sequence with the retries, don't duplicate them. If the retry engine will try the card again in two days, the email should not scream on day one. A workable cadence: a friendly note on day 1, a firmer one with the deadline on day 3, a last call on day 7 — while the retries run underneath on their own schedule. Email asks for a new card; retries catch the cards that were never broken, just temporarily declined.

The metric that matters is not the open rate. It is how many subscribers update a card before the final retry fails — because after that, you are not doing dunning anymore. You are doing win-back, at ten times the cost.

We wrote up how the full recovery sequence fits together here: https://swipeagain.com/pages/how-it-works

Recovery Starts With the Failures That Already Happened

Swipe Again — Thu, 22 Oct 2026 22:08:48 +0000

Disclosure: we're the Swipe Again team. We build failed-payment recovery software, and a 90-day backfill on connect is part of what we sell — so treat this as an argument to evaluate, not a finding to cite. Deliberately, there are no recovery statistics in this post. The case below is built from mechanics, and it's labeled as reasoning throughout. If the mechanics don't convince you, no chart we invented would deserve to.

Picture the day a subscription business finally sets up payment recovery. New tool connected, retries armed, dunning emails branded and ready. From that moment forward, every failed payment gets the full treatment.

And the failures from last month? The ones from six weeks ago, eight weeks ago? In most setups, they get nothing. The tool watches the future. The backlog — which is where the recoverable money is densest — sits untouched, aging.

We think that's exactly backwards. Here's the mechanical case.

A failed payment decays

Reason it through from the customer's side, because a failed payment is not a static asset. The day a renewal fails, the subscriber is in the warmest possible state: they were recently being charged successfully, the card problem is fresh, and in most cases they don't even know anything went wrong. They still think of themselves as a subscriber.

Every week after that, the failure gets colder, for reasons that have nothing to do with anyone's software:

The card on file gets replaced or the situation changes. The fix that would have worked in week one — a well-timed retry, a quick card update — has a shelf life. Accounts close, cards roll over, people reorganize their finances.
The customer re-decides. A subscriber who failed to pay in March and heard nothing has, by May, effectively made a decision — they've lived without the product for two months and built their habits around its absence. You're no longer recovering a payment; you're re-selling a subscription, at a much worse conversion rate.
The trail goes quiet. The dunning window where a simple "your card needs updating" reads as a helpful heads-up closes. The same email, sent two months late, reads as a collections notice from a company they'd forgotten about.

None of this requires a statistic. It's just what time does to an unresolved transaction: the failure doesn't wait politely at the same value. It decays.

The backlog is the near end of the decay curve

Now invert it. If failures decay with age, then at any given moment the most recoverable failures in your account are the recent ones — and the day you connect a recovery tool, you are sitting on up to a few months of them, already accumulated, already past the point where your old setup did anything about them.

That's the backfill: on connect, work backward through the recent failed payments — in our case, 90 days' worth — and run the recovery sequence on failures that already happened, not just the ones that happen next. The 90-day window isn't magic; it's a judgment about the decay curve. Recent enough that the card on file might still be fixable and the customer still considers themselves a subscriber. Old enough to actually contain a backlog worth working.

A tool that only watches future failures starts at the slowest possible point: zero backlog, waiting for new failures to trickle in one billing cycle at a time, while the densest recoverable pool in the account quietly finishes decaying in the corner.

What a backfill has to do differently

Working a backlog isn't identical to working fresh failures, and doing it carelessly is worse than not doing it:

Triage by decline code first. A 90-day backlog contains every species of failure — timing problems that a retry can still fix, replaced cards that need a customer email, and hard declines that should never be touched again. Running one schedule across all of them sprays attempts at dead cards. The backfill has to sort before it acts.

Respect the age gradient. The two-week-old failures deserve the full sequence. The eighty-day-old failures deserve a lighter touch — a graceful, final card-update invitation rather than an aggressive retry ladder. Age isn't just context; it's instructions.

Don't double-drive. If your billing platform's native retries are still churning on some of these failures, two systems retrying the same charge on independent schedules is how customers get double-charged and issuers get suspicious. One driver per failure, with a shared attempt ceiling.

The honest limits

A backfill is not a resurrection machine. Some of the backlog is genuinely gone — decided customers, closed accounts, cards that no email will revive. Recovery on old failures will always underperform recovery on fresh ones, and any vendor who quotes you a backlog recovery rate before seeing your data is inventing it.

What the mechanics support is narrower: of the failures a recovery tool will ever touch, the ones already in your account on day one are the warmest it will ever get — and they're the ones most setups ignore.

We built Swipe Again with the backfill as a first-class step — here's how the whole sequence fits together — because starting recovery at tomorrow's failures felt like installing a smoke detector and ignoring the smell of smoke already in the kitchen. Whatever tool you use, ask it one question before you connect: what happens to the failures I already have? If the answer is "nothing," you're starting at the slowest point in the system, and the fastest money in your account is aging while you wait.

What Your Decline Codes Are Actually Telling You

Swipe Again — Thu, 22 Oct 2026 22:07:47 +0000

Disclosure: we're the Swipe Again team. We build failed-payment recovery software, so we read decline codes the way mechanics read engine noises. Everything below is the taxonomy itself — check it against your own billing data; it either matches or it doesn't.

Ask most subscription businesses why a payment failed and you'll get one answer: "the card was declined." It sounds like a single event. It isn't. A decline code is your bank's compressed explanation of why a transaction didn't happen, and the major families of codes describe completely different situations — different causes, different fixes, different odds. Treating them as one problem, with one response, is the most common and most expensive mistake in payment recovery.

Here's the field guide we work from.

1. Insufficient funds: a timing problem

The most misunderstood decline in subscriptions. "Insufficient funds" rarely means the customer has no money. It usually means the money wasn't in that account at that moment — the charge ran before payday, before a transfer settled, on the wrong side of a rent payment.

The correct response is the one most default retry setups get wrong: wait, then retry. A funds decline retried in six hours is the same decline again. The same charge run days later, after the account's rhythm has moved, is a genuinely different attempt. This family rewards patience and punishes speed, and it's why retry timing should be set by the decline reason rather than by a fixed calendar cadence.

2. Do-not-honor and generic declines: the bank isn't saying

do_not_honor and the catch-all generic_decline are the issuer declining to explain itself. Behind the opacity there's usually something — a risk rule, an account restriction, a velocity limit, a pattern the bank doesn't like — but the bank deliberately doesn't tell you which, partly for fraud reasons.

We wrote up what a generic decline actually is and how to respond in more depth, but the short version: this family deserves a limited number of retries, spaced out. Some of these clear on a later attempt once whatever tripped the rule has passed. Some never will, and because the bank won't distinguish the two for you, the discipline is a hard ceiling — a few attempts, then stop and let the human route (a dunning email, a new card) take over. Unlimited retries against an opaque decline don't recover revenue; they just spend attempts and goodwill with the issuer.

3. Expired or replaced cards: the credential is gone

This is the family where retries are not merely wasteful — they're nonsensical. When a card expires, or a bank reissues it after a fraud alert and the new number never reaches you, the credential you're charging no longer exists. You could retry it hourly until the heat death of the universe and recover exactly nothing.

The only fix is a new card from the customer, which makes this a communication problem, not a scheduling problem: a clear email in your name, landing on a hosted card-update page with no login maze between the subscriber and the form. Every day a replaced-card failure sits in a retry queue instead of a customer's inbox is a day wasted — the system should recognize this family instantly and skip straight to asking for the new card.

4. Authentication required: the customer has a job to do

Some declines — common with Strong Customer Authentication regimes — mean the transaction needs the cardholder to confirm it's really them: approve a prompt, complete a challenge, verify with their bank. No retry succeeds on its own, because the missing ingredient is a human action only the customer can take.

The response is a prompt, fast and specific: tell the subscriber exactly what their bank is asking for and make it easy to complete. This family fails silently in a lot of setups because the failure looks identical to every other "payment failed" in the dashboard — while the actual remedy is sitting in the customer's banking app, waiting to be noticed.

5. Hard declines: stop means stop

Stolen card. Closed account. Fraud flags. A small set of codes mean the payment method is dead or dangerous, and the correct number of further attempts is zero. Retrying hard declines doesn't just fail — it can make things worse, training issuer risk systems to associate your charges with bad traffic and raising the odds that your legitimate renewals get scrutinized.

A recovery system that can't tell a hard decline from a timing problem isn't being thorough. It's being careless at scale.

The taxonomy is the strategy

Lay the five families side by side and the pattern is obvious:

Family	Real cause	Correct response
Insufficient funds	Timing	Wait, then retry
Generic / do-not-honor	Bank opacity	Limited, spaced retries, then stop
Expired / replaced	Credential gone	Ask for a new card — don't retry
Authentication required	Customer action needed	Prompt the customer, fast
Hard decline	Dead or dangerous card	Zero further attempts

Five causes, five different plays. A single fixed retry schedule — same attempts, same spacing, applied to everything — gets at most one of these right. This is why we built Swipe Again's retries to be decline-code-aware: up to six attempts over about 16 days for the failures worth retrying, timed to the reason, with the card-update route taking over the moment the code says the problem is the card and not the calendar.

But the tool matters less than the habit. Pull your last month of failed payments, group them by decline code, and look at what you've actually got. Most businesses find their failures concentrate in one or two families — and that the fix for their dominant family is different from the generic advice they've been following. Read the codes first. They're the cheapest diagnosis in your entire billing stack, and they're already sitting in your data, telling you exactly what's wrong.

Involuntary Churn, Explained: The Customers Who Wanted to Stay

Swipe Again — Thu, 22 Oct 2026 20:43:55 +0000

Every subscription business has two kinds of churn, and they could not be more different.

Voluntary churn is a decision. The customer weighed your product, decided it wasn't worth it, and cancelled. That churn is feedback. You argue with it using a better product, better pricing, better onboarding.

Involuntary churn is an accident. The customer never decided anything. Their card expired. Their bank replaced the card after a fraud alert and the new number never reached you. Their account was short on the specific morning the charge ran. A bank's risk system declined a transaction it would have approved on a different day. The subscriber still wants the product. You still want the subscriber. A failed transaction ended the relationship anyway — often silently, with the customer finding out later, or never.

If you've never separated these two numbers in your own billing data, it's worth an afternoon. Voluntary churn tells you about your product. Involuntary churn tells you about your plumbing — and plumbing is fixable in a way opinions aren't.

What a decline actually is

"Payment failed" is not one event. It's a category of very different events that happen to share a label:

The card is gone. Expired, replaced, reissued. No retry schedule on earth recovers this payment — the credential itself no longer exists. The only fix is a new card from the customer.
The money wasn't there at that moment. Insufficient funds is frequently a timing problem, not a solvency problem. The same charge, run days later, succeeds.
The bank said no without saying why. Issuers decline transactions for risk reasons they deliberately don't disclose. Some of these succeed on a later attempt; some never will.
The charge looked wrong. Amount, timing, or merchant pattern tripped a fraud heuristic — often on a perfectly legitimate renewal.

Treating these four situations as one problem, with one response, is where most recovery efforts quietly fail. Retrying a replaced card six times recovers nothing and trains banks to like you less. Emailing "update your card!" to a customer whose only problem was payday timing is noise they learn to ignore.

The recovery stack, in plain terms

Real payment recovery is four layers, and each one exists because the others have a hole in them.

Smart retries. Retry the failures that are worth retrying, when they're most likely to succeed. "Smart" means the schedule reads the decline code: a funds problem gets time, a hard decline gets few or no further attempts, and the retry count has a ceiling — ours is up to six attempts over about 16 days. The dumb version of this — retry everything, on a fixed schedule, forever — is barely better than nothing and occasionally worse.
Dunning emails. When a payment fails, the customer has to hear about it from you — in your name, in your branding, in a tone that sounds like a heads-up rather than a collections notice. Most people don't know their payment failed. A clear email at the right moments in the retry window turns "silent cancellation" into a thirty-second fix.
Card-update pages. The email has to land somewhere. A hosted, branded page where the subscriber enters a new card — no login maze, no support ticket, no "call us during business hours." Every extra step between "my card expired" and "here's the new one" is a place subscribers abandon a subscription they meant to keep.
Backfill. The day you set up recovery, you already have a backlog: failed payments from the last weeks and months, subscribers mid-drift toward cancellation. A backfill works that existing backlog — in our case, 90 days of it on connect — instead of only protecting you from tomorrow's failures. For most businesses, the backlog is the fastest money in the whole system, because it's already there.

What recovery can't do

Honesty matters here, because this category oversells. Recovery cannot save a customer who has decided to leave — that's voluntary churn wearing a payment costume, and chasing it with retries is how you earn chargebacks. It cannot fix a product people don't want. And it cannot recover a payment from a card that no longer exists until the human attached to it hands you a new one, which is why layers two and three exist.

What it can do is narrower and more valuable: make sure that the subscribers who wanted to stay, and whose money was good, don't disappear because a transaction failed at the wrong moment. That's not a growth hack. It's maintenance — the unglamorous work of not leaking customers you already earned.

The takeaway

Pull your billing platform's failed-payment list and read the decline codes before you do anything else. Sort them. You'll find the four situations above, and each one has a correct response. If your current setup applies one response to all of them — or worse, has no response and lets the platform's default cancellation do the talking — that's the leak.

We build Swipe Again (https://swipeagain.com), which runs this stack — decline-code-aware retries, branded dunning, card-update pages, and a 90-day backfill — across the major subscription platforms for a flat monthly fee. But the stack matters more than the vendor. Whoever runs it for you, run it deliberately: read the decline, match the response, and stop losing the customers who never meant to leave.

Percentage-of-Recovered Pricing Is a Tax on Your Worst Month

Swipe Again — Thu, 22 Oct 2026 20:42:07 +0000

Disclosure: we're the Swipe Again team. We sell the flat-fee option in this comparison, so don't take our word for any of it — the math below is the whole argument, and you can run it with your own numbers in about two minutes.

Percentage-of-recovered pricing has the best pitch in SaaS: "You only pay when we recover money for you."

It sounds perfectly aligned. If the software recovers nothing, you pay nothing. If it recovers a lot, well, you're happy to share. And this pricing model is real, not hypothetical — established recovery providers publicly price their service at 10–20% of whatever revenue they recover for you.

Here's the thing nobody puts in the pitch: the percentage is charged on your worst month, at the worst rate, precisely because it's your worst month.

Run the math

Say your subscription business has a bad month — a bank changes its risk rules, a card network has an issue, a batch of annual renewals hits expired cards. Failed payments pile up, and your recovery software does its job and recovers $10,000 of it.

At 10% of recovered revenue, that month costs you $1,000.
At 20%, it costs you $2,000.

Now a genuinely terrible month — the kind where recovery matters most. $25,000 recovered:

At 10%: $2,500.
At 20%: $5,000.

A flat fee of $179 costs $179 in both months. And in the good months. And in the catastrophic ones. The bill never reads your Stripe dashboard and decides to grow.

The alignment runs backwards

The pitch says the vendor only wins when you win. But look at what the meter is actually attached to. A percentage-of-recovered vendor earns more when more of your payments fail and get recovered. Their best month is your worst month, monetized twice: once by whatever caused the failures, and once by the recovery fee on top.

It also quietly penalizes the merchants with the biggest problem. A store with sloppy card hygiene and a high failure rate pays a fortune in recovery fees. A store with the same revenue and a low failure rate pays almost nothing — for the same software, running the same retries. The price isn't attached to the product. It's attached to the size of your leak.

And there's a subtler cost: you can't budget it. Nobody can tell you in January what recovery will cost in October, because it depends on how badly October goes. Flat infrastructure — your billing platform, your email tool — doesn't work this way. You know the number before the month starts.

The honest case for the percentage

We're not going to pretend the percentage model has no place, because it does:

Zero fixed cost is real. If you're pre-revenue or tiny, paying something only when money comes back is genuinely easier than a monthly bill.
It's a low-commitment trial. Percentage pricing lets a skeptic test recovery without a subscription decision.
For very small recovery volumes, it's cheaper. If a service recovers $300 for you in a month, 20% is $60 — less than our $179.

That last point is the honest break-even, and it's worth doing on your own numbers. At 10% of recovered, the percentage model costs more than $179 the moment a service recovers more than $1,790 in a month. At 20%, the line is $895 a month of recovered revenue. If your failed payments are anywhere near those figures — and for a subscription business doing even modest volume, a bad week can get there — the "aligned" pricing is the expensive option wearing the friendly costume.

What we'd actually check before buying either model

Your monthly failed-payment volume. Not your revenue — the dollar value of payments that fail and are realistically recoverable. That's the base both models charge against.
What the recovery includes. Retries alone aren't recovery. Are dunning emails, card-update pages, and a backfill of your existing failures in the price, or add-ons?
What happens in the worst month, in writing. Multiply your worst plausible recovery month by the percentage. That's your real price ceiling — or rather, it has no ceiling, which is the point.

We built Swipe Again (https://swipeagain.com) to be the boring option here: failed-payment recovery across Stripe, Recharge, Chargebee, Recurly, and the other major subscription platforms for $179 a month flat — no percentage, no tiers — because we think recovery is infrastructure, and infrastructure should have a price you can say out loud in January.

But run your own numbers first. If your recoverable volume is small, the percentage might honestly be cheaper for now. Just know exactly where your break-even sits — because your worst month will find it.