Found this after a client asked why their merchant account got flagged for "excessive decline rate" despite every individual transaction eventually succeeding.
Their retry logic resubmitted a declined authorization up to 4 times with short backoff, same card, same amount, hoping a soft decline would clear. It usually did, on attempt 2 or 3. From the app's point of view, that's a success story.
From the network's point of view, that's 4 authorization attempts, 3 of them declined. Visa and Mastercard both run decline-rate monitoring at the merchant level, counting declines over total auth attempts in a rolling window, not unique transactions. Retries inflate the denominator and the decline count together. Cross a threshold (ballpark 15% triggers a warning tier on some programs) and the merchant account itself gets reviewed, sometimes rate-limited by the acquirer regardless of how clean the actual approval-after-retry outcome looks.
Fix was capping retries to 1 for hard declines, routing only specific soft-decline codes (51, 65) into a delayed retry queue, and treating anything else as terminal on first attempt.
Anyone tracking their decline ratio as "attempts" vs "unique transactions" separately, or is this usually invisible until the acquirer calls?
Top comments (1)
In our experience it's invisible until the acquirer calls — because almost every billing stack reports outcomes per invoice, not per attempt. The invoice view says "recovered on attempt 3," which reads as a win. The network's view is the one you describe: 4 attempts, 3 declines, and your ratio moved.
The practical fix we've landed on is tracking both numbers side by side. Declined attempts ÷ total attempts is the ratio the networks watch; failed invoices ÷ total invoices is the business number. They only diverge when retry policy is aggressive, so watching the gap between them is basically watching your retry policy's cost.
Your fix — hard declines capped at one attempt, only specific soft codes (51, 65) into a delayed queue — matches what we do. One addition: split the attempts ratio by decline class. A rising ratio driven by insufficient-funds retries is a timing problem and usually self-corrects; a rising ratio driven by do_not_honor re-presents is the one that draws scrutiny, because the networks treat re-presenting a "never again" card as a merchant-behavior signal, not bad luck. Same headline number, very different conversations with your acquirer.
(Disclosure: we build Swipe Again, failed-payment recovery software — this monitor is half the reason our retry ceiling exists. Every attempt has to earn its place in the ratio.)