Decline Codes and Retry Limits: What the Visa Rules Permit
Visa publishes a retry limit for declines. Twelve codes mean never try again. Everything else allows up to 20 attempts in 30 days.
By Jeffrey Anderson
- Table 7-2 of Section 7.3.6.3 (ID# 0030640) sorts every decline code into four categories and attaches a reattempt limit to each. Categories 2, 3 and 4 permit up to 20 attempts in 30 days.
- Category 1 is a hard stop. After one of its twelve codes, a merchant must never resubmit an authorization request or account verification for the same payment credential.
- Those twelve are 04, 07, 12, 14, 15, 41, 43, 46, 57, R0, R1 and R3. The three R codes are cardholder revocation orders, so retrying a stop payment order is a rule violation rather than persistence.
- Issuers must consistently send the same decline response code after a Category 1 decline, so the answer is not meant to change between attempts.
- Category 3 carries the same 20 in 30 allowance but is labelled as a prompt to revalidate payment information. Codes 54, 55, 82, 6P and N7 call for an update request rather than a retry schedule.
- Code 83, Fraud/Security, was added on 25 July 2026 and is reserved to Visa. It means the transaction was declined during stand-in processing for high-risk or fraudulent conditions, so the issuer did not make that decision.
- Resubmission after a decline on a mobility and transport transaction runs under Section 7.3.6.2 instead, so these limits are the general case rather than the universal one.
Decline codes carry a retry limit, and Visa publishes it. One group of codes means you must never try that card again. Everything else allows up to 20 attempts in 30 days. Both numbers sit in Table 7-2 of Section 7.3.6.3 (ID# 0030640) in the 18 April 2026 rules, and almost no dunning tool tells you they exist.
If you run subscriptions, invoices or any retry logic at all, this is the ceiling you are already operating under.
The rules sort every decline into four categories
The issuer side is one sentence. An issuer that declines must send the decline response code "that most accurately reflects the reason for the decline." Then the table does the real work by grouping codes and attaching a reattempt limit to each group.
| Category | What it means | Reattempt limit |
|---|---|---|
| 1 | Issuer will never approve | Never resubmit for the same payment credential |
| 2 | Issuer cannot approve at this time | Up to 20 attempts in 30 days |
| 3 | Data quality, revalidate payment information | Up to 20 attempts in 30 days |
| 4 | Generic response codes | Up to 20 attempts in 30 days |
Category 4 is everything not named elsewhere, and the issuer is told to limit its use to transactions where no other value applies. So a generic decline is meant to be a last resort on the issuer's side, not a default.
Category 1 is a hard stop, and it is a short list
Twelve codes mean the answer will never change. The rule is blunt: after receiving a Category 1 decline response code, a merchant must never resubmit an authorization request or account verification for the same payment credential.
| Code | Meaning |
|---|---|
| 04 | Pick up card, no fraud |
| 07 | Pick up card, special condition, fraud account |
| 12 | Invalid transaction |
| 14 | Invalid account number, no such number |
| 15 | No such issuer |
| 41 | Lost card, pick up |
| 43 | Stolen card, pick up |
| 46 | Closed account |
| 57 | Transaction not permitted to cardholder |
| R0 | Stop payment order |
| R1 | Revocation of authorization order |
| R3 | Revocation of all authorizations order |
Three of those deserve attention because retry logic routinely gets them wrong. R0, R1 and R3 are the cardholder revoking permission. A stop payment order is not a soft decline to work around, and retrying one is a rule violation rather than persistence.
There is an issuer obligation attached too. After sending a Category 1 decline, issuers must consistently send the same decline response code. So the answer is not supposed to drift between attempts, which removes the usual excuse for trying again to see.
Everything else allows 20 attempts in 30 days
Categories 2, 3 and 4 all carry the same limit: reattempt permitted, up to 20 attempts in 30 days.
Category 2 is the issuer saying not now. It holds the codes most retry schedules are built around, including 51 for insufficient funds, 59 for suspected fraud, 61 for exceeding an approval limit, 91 for issuer or switch inoperative, and 96 for system malfunction. These are the ones where waiting genuinely helps.
Category 3 is different in character even though the number is the same. It covers 54 for an expired card or missing expiry date, 55 for an incorrect or missing PIN, 82 for a negative online CAM, dCVV, iCVV or CVV result, 6P where cardholder identification does not match issuer records, and N7 for a CVV2 failure.
Read the category name. It says revalidate payment information. Retrying a 54 twenty times does not make an expired card current. The limit permits attempts; the category tells you the attempts are pointless until the data changes. For anything on a stored credential, that means an account updater or a customer prompt rather than a retry schedule.
The new code is 83, and Visa sends it
Effective 25 July 2026, code 83 joined Category 2. It reads "Fraud/Security [Visa use only]", and Visa introduced it to signal that a transaction was declined during stand-in processing because of high-risk or fraudulent conditions.
Two things follow. The code is reserved to Visa, so an 83 did not come from the issuer. And because it is Category 2 rather than Category 1, it is a not-now rather than a never, carrying the same 20 in 30 allowance.
Stand-in processing is Visa answering an authorization when the issuer's own systems do not. It is the same mechanism that, from 1 April 2026, can handle refund authorizations on an issuer's behalf. An 83 therefore tells you something fairly specific: the issuer was not answering, Visa answered instead, and Visa did not like the look of the transaction.
What this means for retry logic
Four practical points:
- Twenty is a ceiling, not a target. The limit is per payment credential across 30 days, and it applies to your gateway's automatic retries as well as your manual ones. A schedule that retries daily for a month breaches it.
- Category 1 needs a hard block in code, not a policy. If your dunning tool treats every decline the same, it will eventually retry a stop payment order. Map those twelve codes to a permanent stop.
- Category 3 should trigger a data fix. Route 54, 55, 82, 6P and N7 to an update request rather than into the retry queue.
- An 83 is not an issuer decision. Do not tell a customer their bank declined them when Visa stood in and declined on its behalf.
One scope note. Resubmission after a decline on a mobility and transport transaction runs under its own rule, Section 7.3.6.2, so the limits above are the general case rather than the universal one. Separately, an authorization reversal is not a retry and does not count against the allowance.
Frequently asked questions
How many times can I retry a declined card?
Up to 20 attempts in 30 days for Category 2, 3 and 4 decline codes. For the twelve Category 1 codes the answer is zero, and the rule says a merchant must never resubmit for the same payment credential.
Which declines can I never retry?
Codes 04, 07, 12, 14, 15, 41, 43, 46, 57, R0, R1 and R3. They cover pick-up-card instructions, invalid or closed accounts, transactions not permitted, and the three cardholder revocation orders.
What is decline code 83?
A Visa-only code added on 25 July 2026, reading Fraud/Security, used when a transaction is declined during stand-in processing for high-risk or fraudulent conditions. It sits in Category 2, so reattempts are permitted within the usual limit.
Does the 20 attempt limit include automatic gateway retries?
The rule limits resubmission of the authorization request and does not distinguish who triggered it, so treat automated and manual attempts as counting toward the same total.
Should I retry an expired card decline?
It is permitted but close to useless. Code 54 sits in Category 3, which the table labels as a prompt to revalidate payment information, so the fix is new card details.
Sources: Visa Core Rules and Visa Product and Service Rules, 18 April 2026, Section 7.3.6.3 and Table 7-2.
Jeffrey Anderson, Merchant Placement Specialist
Merchant placement specialist at Gray Merchants. Jeffrey works directly with acquiring-bank underwriting teams across the firm’s 70+ banking relationships to place high-risk and hard-to-place businesses, structure multi-MID accounts, and keep flagged merchants processing. His writing draws on the placement files he works every week: what underwriters ask for, why accounts get declined, and what keeps an approved account open.