Smart payment retries that recover revenue automatically
One toggle to enable · Decline-code aware · Fewer, smarter attempts
- 22%Average reduction in processing fees
- 12.4%Average lift in failed-payment recovery
- 2.5BAnnual orchestrated volume
- 140+Currencies supported
The opportunity
Why failed payments don't have to mean lost revenue
Up to 10% of recurring revenue is at risk from payment failure
Industry analyses put failed transactions at 5% to 15% of recurring revenue each month before any recovery. Call it 10% to be conservative: at $200K MRR, that's $20,000 of charges failing every month, most of it from customers who have no idea anything went wrong.
Most failed payments aren't fraud. They're recoverable
The bulk of declines are mundane: insufficient funds the day before payday, a reissued card, a bank being cautious with an online charge. These are soft declines (temporary conditions, not refusals), and with the right timing, a large share of them approve on a later attempt.
Retrying at the wrong time makes recovery worse and raises gateway risk
Hammering a card on a fixed timer burns attempts when they can't succeed and networks are watching. The failure's decline code tells you how to handle it. Ignore it, and you recover less while looking riskier to your own gateway.
Built into billing
How PaymentKit's adaptive retries work
Retry schedules tied to the subscription billing cycle
Timing shaped by where the customer is in their cycle, not a generic interval table.
A monthly subscriber three days into their cycle and an annual subscriber at renewal get different plans. Each retry is placed where it's most likely to succeed, and the whole schedule aims to recover the payment before the next renewal comes due.
- Schedules adapt to monthly, annual, and usage-based billing cycles.
- Soft declines get patient spacing; hard declines skip pointless attempts.
- One toggle to enable: no retry tables to build or maintain.
Automatic failure handling when all retries are exhausted
You decide what final failure means for the subscription and the invoice.
Cancel the subscription and close the books, or keep serving the customer and mark the invoice uncollectible while sales follows up. Both the subscription status and the invoice status on final failure are settings, so the ending matches how your business actually operates.
- Cancel on final failure, or keep the subscription running.
- Behavior is configurable rather than hard-coded.
- Mark invoices uncollectible without losing the customer record.
Network tokenization keeps card credentials fresh
The best retry is the one that never has to happen.
Network-level tokens replace stored card numbers with credentials the card networks keep current. When a card is reissued or expires, the token updates behind the scenes, so the renewal approves on the first attempt instead of entering the retry funnel at all.
- Stale-card declines drop before a retry is ever needed.
- Reissued and expired cards update without customer action.
- Fewer failures entering the funnel means higher recovery on what remains.
The human side
Where retries end and dunning begins
Some failures no retry can fix: the card is gone and only the customer can replace it. That's the job of PaymentKit's dunning flows, covered on the churn mitigation page. What matters here is the seam: recovery emails are timed between retry attempts as one flow, and the moment a customer updates their card, the next attempt picks up the new credentials automatically.
Retries recover the failures that fix themselves. Emails recover the ones that need the customer. PaymentKit runs both as one flow.
The opportunity
Protecting your gateway relationship
Recovery that damages your standing with processors isn't recovery. Retry volume is something card networks measure, and hold against you.
Too many failed retries can get you flagged as high-risk
Card networks cap and monitor reattempts on the same credentials; blowing past those patterns brings penalty fees on some networks and, over time, a riskier profile in your processor's eyes. High retry-failure volume is one of the signals that gets merchant accounts reviewed.
Adaptive scheduling reduces unnecessary retry attempts
Because each attempt is placed where approval is plausible, adaptive retries need fewer of them. Recovering more with fewer requests is the whole trick: your recovery rate rises while your reattempt counts, the number the networks care about, go down.
Fraud prevention rules filter out payments not worth retrying
PaymentKit's configurable fraud rules screen failures before the retry engine touches them. Stolen-card declines and other unrecoverable failures exit the funnel immediately, so retry attempts are spent only where there's revenue to recover, and your gateway never sees you re-pushing charges it had good reason to block.
The opportunity
Measure what you're recovering
Dunning performance tab inside your metrics dashboard
Recovered revenue and recovery rate live inside Revenue Metrics, native to the metrics layer, not a separate report you export and reconcile.
Track recovery rates alongside churn and retention data
The dunning tab sits next to churn cohorts and net revenue retention, so a recovery improvement shows up in the same view as the churn it's preventing.
PSP performance benchmarking to identify processor-level issues
When failures cluster on one processor, benchmarking makes it obvious, and because PaymentKit routes across processors, it's also fixable.