Most billing systems retry failed charges on a fixed schedule: day 1, day 3, day 5, day 7. It is simple, and it is wrong for roughly 60% of failures. A card declined for insufficient_funds on the 28th of the month does not behave like a card declined for do_not_honor at 3am on a weekend. Treating them the same is how subscription businesses leak eight-figure revenue every year.
# What the failure code is actually telling you
Card networks return a decline reason for every failed authorization. The reasons cluster into three groups that each want a completely different retry policy:
| Group | Example codes | What it means | Retry policy |
|---|---|---|---|
| Soft, timing-sensitive | insufficient_funds, card_velocity_exceeded | The card can pay, just not right now | Retry aligned to paycheck / cycle boundaries |
| Soft, issuer-side | do_not_honor, issuer_not_available, try_again_later | Issuer's risk engine or infra hiccup | Retry within 24–72h, off-hours |
| Hard | stolen_card, lost_card, pickup_card, no_such_card | The card will never succeed | Do not retry — request a new instrument |
Retrying a hard decline is worse than doing nothing. It costs a network fee, teaches the issuer's fraud engine to distrust your merchant descriptor, and delays the conversation you actually need to have with the customer.
# Paycheck-aware retries for insufficient funds
insufficient_funds is the single largest recoverable bucket for most B2C subscription businesses. It is also the bucket where fixed schedules fail hardest, because the recoverability of the charge is a function of the customer's cash flow, not yours.
A retry policy that respects paycheck patterns typically looks like:
- First retry 48 hours after the original attempt, in the customer's local morning (9–11am).
- Second retry aligned to the next likely paycheck date — the 1st, the 15th, or the last business day of the month, whichever comes first.
- Third and final retry 3 days after that paycheck window.
Businesses that switch from a fixed 3/5/7 schedule to a paycheck-aware schedule see recovery on insufficient_funds failures rise by 15–25%, with fewer total attempts.
# Off-hours retries for issuer-side declines
Issuer-side declines are frequently transient. The best retry window is when issuer authorization systems are least loaded — typically 2am–6am in the issuer's local timezone, not the merchant's. If your billing system retries at "3am UTC" it is hammering European issuers during peak hours and completely missing American ones.
Route retries through the BIN → country → timezone mapping you already have. If you do not have one, build it — it is a few hundred lines of code and it is worth eight figures a year at scale.
# Never retry a hard decline
If the network returns a hard decline code, do not schedule another attempt. Immediately branch to the payment method update flow: email + in-app + (where consented) SMS or WhatsApp, with a one-click link to update the card. Every retry against a stolen_card decline is negative EV and moves you closer to a merchant-account review.
# Measuring retry effectiveness
Track three numbers per failure code:
- Recovery rate: successful retries ÷ total retries for that code.
- Cost per recovery: network + gateway fees ÷ recovered revenue.
- Customer-experience score: complaint rate, unsubscribe rate, and support tickets attributed to retries.
If recovery rate is climbing but CX score is falling, you are recovering revenue you will lose next quarter as churn. Optimize both.
# The RRLabs default policy
The Revenue Recovery Labs engine ships with a policy that encodes the rules above per failure-code family and per BIN geography. Teams can override any node, but the defaults are designed to be safe: never retry a hard decline, never retry more than three times, never retry inside the issuer's peak hours, and always align the last attempt to the customer's likely liquidity window.
Smart retry timing is not glamorous. It is a spreadsheet dressed as a system. But it is the single highest-leverage change most subscription businesses can make to their billing stack — often worth more than every other recovery tactic combined.