What a well-designed payment recovery system needs to get right

The Paypers sat down with payment expert Avadhut Thakar to discuss what payment recovery involves, how merchants can balance recovered revenue against cost, risk, and customer experience, and what a well-designed recovery system needs to get right.

When merchants talk about payment recovery, they often focus on retrying a failed transaction. How would you describe what payment recovery actually involves, and where does the retry fit into the bigger picture?

To understand payment recovery, we need to understand how the payment lifecycle works. When a customer makes a digital purchase, some merchants complete an authorisation and capture together, while some authorise the card upfront and only capture the charge once the goods or services are delivered. In the first method, retries are synchronous. In case of failure, the system tries to retry quick transient network errors before displaying an order confirmation or a decline screen. Payment recovery primarily comes into play in the second method where the initial authorisation succeeds, but the capture or final settlement request fails.

Payment recovery should not be viewed as different from the core payment system and is directly associated with it. The key difference is time to respond (TTR). At checkout, a customer is waiting on a screen for an immediate response, whereas recovery is an entirely asynchronous, backend process where attempts happen behind the scenes without the cardholder ever knowing how many transient failures the transaction has seen. 

The architecture differs from company to company. Some build recovery as one end to end service, ingesting failed authorisations, deciding retry strategy, and sending settlement requests to the PSP. Others design recovery as a standalone system that just guides the payment ecosystem when to retry. In both cases the retry is part of the payment ecosystem making sure the transaction will reach the conclusion, either collected or written off in the system. 

Not every decline deserves a second attempt. How should merchants think about which failed payments are worth retrying and when? And at what point does the cost of recovery outweigh the value of the payment being recovered?

Every decline costs money, so your decline strategy needs to start with a clean split between soft (retryable) vs hard (nonretryable) error codes. Hard declines should never see a second attempt. Networks have very strict guidelines on hard declines and attempting on those error codes results in heavy network fees. If you get a hard decline, stop immediately. Also, for certain soft declines there are only a fixed number of attempts that are allowed within a fixed number of days. Violating those rules can result in heavy fees and risk of your merchant ID being flagged. 

Soft declines and network errors (transient errors) are the only error codes where retries make sense. At the same time, the timing of the retry matters as much as the error code – e.g. sending multiple requests to the issuer with an immediate retry on insufficient balance errors are unlikely to succeed. In practice, we need a dynamic backoff rather than just a static strategy of running a cron job after every few hours or days and just keep attempting or sending multiple requests to the issuer. 

As far as when to stop the retry, it comes down to the available amount to collect and the transaction size. Every failed charge attempt incurs processing fees from networks. On a USD 1 or USD 2 order, for example, the network fees from two or three failed attempts can exceed margins, and further attempts can wipe out the entire recovery completely.

From my experience, engineering, DS, and product teams often underestimate how much retry fees can add to merchant's monthly network bill when they reattempt failed transactions without guardrails. You have to constantly monitor/audit your decline code mappings, track your net recovery rate against overall attempt fees, and set strict limits on retry attempts – such as max attempts in a particular span, max attempts for small collection – before you conclude that recovery is not possible.

Beyond retries, what recovery approaches do you think merchants tend to overlook or underuse? And how should they balance the opportunity to recover more revenue against fraud, dispute, and other payment risks?

In my experience, merchants tend to underuse modern payment infrastructure and rely on legacy, static logic-based systems. Teams typically build a recovery engine and then rarely revisit or upgrade it until network fees spike drastically. That is a missed opportunity. Every dollar recovered is indirectly a profit, so engineering, product, operation, and data science teams should always treat recovery as an evolving product, increasing net collection rates and finding opportunities to lower retry fees.

Another underused area is risk signals. Many systems do not use signals such as early chargeback or other risk features into the recovery workflow. Signals like TC40 data, SAFE reports, or pre-arbitration alerts give you immediate visibility into payment instrument behaviour. If another transaction has already been flagged by an issuer or a consumer as potentially fraudulent, continuing to retry that payment instrument is useless. Using these signals as a decision maker allows the system to immediately stop retries, saving both the penalty fees and the inevitable chargeback costs as well.

Never assume a transaction is safe just because it passed initial risk checks. Risk checks must be a part of every retry attempt. A customer’s risk profile or account state can change between previous attempt and latest attempt. For example, if the last attempt was a transient network error, but a subsequent attempt turns it into hard decline, retrying further makes no sense. If you isolate recovery from your risk engine, you might recover revenue in the short term only to lose it in the long term along with risk of receiving disputes/chargebacks.

From the customer's perspective, what does good recovery look like, and where do merchants most often get it wrong?

The less customers know about recovery, the better, unless and until customer intervention is actually required. If a charge request is failing due to internal system errors, transient errors, or network failures where no user action is needed, it should be resolved silently. Sending multiple alerts or warnings only creates panic and friction, and may end up triggering an unnecessary dispute.

A good product should always differentiate between backend errors and actual customer-actionable errors. Wherever customer action is required, e.g updating an expired card, updating a billing address, or completing required 2FA, it makes complete sense to send a clear notification. At the same time, not informing users when action is required leads to a bad customer experience, especially if you decide to ban the user from accessing the service. But notifying them on every retry attempt is frustrating and confusing, and that is where merchants often get it wrong. Backend issues should be handled quietly, and in many non-fraud cases, treated as fail-open.

Speaking as an engineer, what does a well-designed payment recovery system need to get right? What technical or operational pitfalls can undermine recovery, even when the overall strategy looks sound? 

A well-designed recovery system starts with the initial payment system. The primary authorisation/charge system should be effective to achieve the highest possible first-attempt success rate, sending as few transactions downstream i.e. to the recovery system. Recovery should be a safety net for unavoidable network drops and transient errors and should not be treated as an alternative to initial payment systems or checkout systems. 

Once a transaction is part of the recovery system, the engineering SLAs are different. At checkout, you are bound by strict sub-second latency SLAs because a customer is waiting on a screen. In recovery, the system retries asynchronously or silently. There are no customers waiting for recovery to finish. That extra time should be used intentionally to evaluate the risk. Instead of relying on a simple time bound cron job that keeps retrying blindly using some static schedule, the system should run deep risk checks and follow dynamic scheduling logic before sending the next collection call.

From an engineering standpoint, this is where predictive routing makes a measurable impact. Building models that evaluated historical network and PSP authorization trends helped predict the possible retry window. Rather than just keep retrying, dynamically selecting the PSP or timing the attempt around success patterns significantly boosts recovery success rates.

There are always multiple challenges when building these systems, but the most critical one is avoiding duplicate charges. The system must be capable of verifying whether a transaction actually settled or is still in an unsuccessful state before sending a new request to avoid double charges. While idempotency is essential here, handling it without affecting customer experience is what matters in this case. Otherwise, a double charge quickly triggers an unrecognised transaction dispute and expensive chargeback fees and also downgrades the customer experience.

About  the author

Avadhut Thakar is a Staff Software Engineer specialising in payment risk, fraud prevention, and transaction recovery infrastructure. With 15+ years of experience across leading global technology platforms, he designs scalable distributed systems that mitigate payment fraud early and maximise financial recovery. Avadhut focuses on building resilient fintech architectures that solve high-throughput dispute, chargeback, and money-movement challenges.