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.
