What Is Payment Recovery?
A decline is an answer. Payment recovery is the practice of working out when the question was wrong.
A decline is not always a refusal
Payment recovery is the practice of finding card declines that did not describe a real problem with the card, and getting those transactions approved. It covers several different techniques: resubmitting a transaction the issuer could not answer at the moment it arrived, correcting data the issuer read as a mismatch, refreshing a credential that has gone stale, changing how a transaction is identified in the authorization message. What they have in common is the premise. The decline was an answer to a question, and the question was badly formed.
That premise is what separates payment recovery from collections. Nobody is being chased for money they do not have. In the cases that matter here, the cardholder intended to pay, the account was in good standing, and the authorization came back negative for a reason that had nothing to do with either of those facts.
Declines fall into categories, and the category decides what you may do next
Visa groups authorization response codes into categories that tell the merchant what is permitted after a decline. In Visa's rules on declined transaction resubmission, Category 1 covers declines where the issuer will never approve the transaction, and the merchant is not permitted to reattempt it. Category 2 covers declines where the issuer cannot approve at this time, which is a materially different statement, and those may be reattempted. Category 3 covers data quality problems, where something in the message itself was wrong rather than something about the account.
Category 2 is where most of the available value sits. "Cannot approve at this time" is the issuer saying that the answer might be different later: a velocity rule that has since reset, a balance that has since moved, a risk model that saw an unfamiliar pattern. The transaction was not refused on its merits. It was refused on its timing.
Category 3 is the one merchants most often misread. A data quality decline is a message defect, and sending the identical message again produces the identical answer. The fix is to the message.
The networks set hard limits, and they are lower than most teams assume
A Category 2 decline may be reattempted up to 15 times in 30 days under Visa's rules. That is a ceiling, not a target, and a merchant who treats it as a target is paying for 15 authorization attempts to buy one answer they could usually have predicted after the first.
Some codes carry a flat prohibition. Response Code 14, invalid account number, appears in both Category 1 and Category 3, and the instruction is unambiguous: a merchant must not reattempt any transaction using the same account number after a 14. The account number is wrong. Sending it again cannot make it right.
Mastercard communicates the equivalent instruction through merchant advice codes, defined in the Mastercard Transaction Processing Rules, which sit alongside the decline code and say in plain terms whether a retry is permitted, whether to wait, or whether to stop entirely. We went through how to read them in Merchant Advice Codes in Card Payments.
There is also a cost to getting this wrong at scale beyond the wasted attempts. Visa monitors acquirer and merchant performance through the Visa Acquirer Monitoring Program, and sustained poor authorization behaviour is visible to the acquirer whether or not the merchant is watching it.
Retrying is scheduling. Recovery is deciding.
The two words get used interchangeably and they describe different work.
A retry strategy answers the question "when do we send this again?" It is a scheduler. It sees a decline, consults a rule about intervals and attempt counts, and queues another attempt. A good one is better than a bad one, and retry orchestration is a real discipline, but the whole exercise assumes the decision to resend has already been made.
Payment recovery answers an earlier question: should this transaction be sent again at all, and if so, should it be sent differently? That is a decision about the individual decline, taken from the response code, the merchant advice code, the transaction's history, the credential's age, how it was flagged, and what the same issuer did with comparable transactions recently. Most declines fail that test. The ones that pass it do not need 15 attempts.
The distinction matters commercially because the two have opposite failure modes. A scheduler that is too aggressive burns attempts, irritates issuers and degrades the merchant's standing. A decisioning layer that is too conservative leaves approvals on the table. Neither problem is solved by changing the interval between attempts.
Some declines are about the credential, not the transaction
A separate class of decline has nothing to do with timing or risk. The stored card has expired, been reissued, or been replaced after loss. Nothing about the purchase is wrong; the merchant is holding a number that no longer points anywhere.
Visa Account Updater exists for exactly this. Participating issuers share changed account details with Visa, merchants query before billing, and the billing file is refreshed rather than the transaction retried. Visa describes it as covering account number changes, new expiration dates, account closures, and product and brand conversions.
Network tokens address the same failure from the other direction, by replacing the stored card number with a credential the network keeps current. The two tools overlap and are not interchangeable, which we worked through in Network Tokenization vs Account Updater.
A fourth class is about identification rather than the credential: the same charge, on the same card, can get opposite answers depending on whether it was flagged as cardholder-initiated or merchant-initiated. That one is covered in What Is a Merchant-Initiated Transaction.
What payment recovery does not do
Being precise about the limits is the only way the term stays useful.
It does not overturn a genuine refusal. If the issuer has decided this card should not be used for this purchase, no amount of resubmission changes that, and the rules forbid trying.
It does not create funds. A decline for insufficient balance is a true statement about an account at a moment in time. Sometimes the moment changes, which is why NSF declines are worth timing rather than hammering. Often it does not.
An approval is not a settlement. A positive authorization response means the issuer has agreed to hold funds. Capture, clearing and settlement are separate steps, and any of them can still fail.
It is not a fraud control. Recovering declines and screening for fraud pull in opposite directions, and a recovery layer that ignores the difference will eventually approve something it should not have.
What to look at in your own data
A short diagnostic, in the order worth running it:
- Split declines by response code, then by merchant advice code. If you are not storing the advice code, start there, because the rest of the analysis is guesswork without it.
- Separate Category 1 from Category 2. Count how many attempts you are currently spending on Category 1 declines. For most merchants the number is not zero.
- Check your 14s. Any reattempt on the same account number after a 14 is a rule breach, not an optimisation.
- Look at credential age on your recurring book. Declines concentrated in cards over two years old are usually an updater problem, not a retry problem.
- Check CIT and MIT flagging on stored-credential charges before concluding that an issuer is declining you unfairly.
- Measure authorization rate on first attempt separately from blended authorization rate. The two move independently and only one of them tells you whether your decisioning is working.
Better is a payment recovery platform built as a machine learning approval layer. It scores each decline in real time and acts on the ones that describe a timing problem rather than a refusal, inside the merchant's existing payment flow. That covers both sides of the problem: cardholder-initiated declines, where the decision has to be made while the customer is still at the checkout, and merchant-initiated declines on recurring charges, where the decision is about which attempt to make and when.
Frequently Asked Questions
Is payment recovery the same as dunning?
No. Dunning is a billing and communications process aimed at the customer, usually a sequence of emails and retries after a subscription payment fails. Payment recovery is a decision taken on the authorization itself, before and independently of anything the customer is told. A business can run both, and many do.
Is it allowed to retry a declined card?
It depends entirely on the decline. Under Visa's resubmission rules, Category 2 declines may be reattempted up to 15 times in 30 days, Category 1 declines may not be reattempted at all, and a Response Code 14 must never be resubmitted with the same account number. Mastercard's merchant advice codes carry the same kind of instruction. Retrying without reading the code is a rule breach waiting to happen.
How is payment recovery different from an account updater?
An account updater fixes a stale credential: the card number or expiry the merchant holds is out of date, and the updater supplies the current one. Payment recovery is broader and covers declines where the credential is perfectly good and the problem was timing, risk scoring, flagging or message data. The two solve different declines and work well together.
Does a recovered approval mean the money has arrived?
No. An approval is the issuer agreeing to hold funds for the transaction. Capture, clearing and settlement happen afterwards and can still fail for unrelated reasons, which is why approval rate and settled revenue should be measured separately.
