Visa's Four Decline Categories: Which Codes You May Never Retry, and the 20-in-30 Limit

Every retry engine encodes a belief about which declines are worth trying again. Visa's rules encode one too, and it is more specific than most retry engines — it names every code, sorts them into four categories, forbids resubmission outright for one of them, and puts a numeric cap on the rest.

The cap is 20 attempts in 30 days. If you have been working from 15, keep reading.

The rule, in one sentence each

Section 7.3.6.3 of the Visa Core Rules places a duty on both sides of an authorization.

On the issuer:

An Issuer that declines an Authorization Request or an Account Verification request must send to VisaNet the Decline Response code that most accurately reflects the reason for the decline, as specified in Table 7-2, Decline Response Code Use.

On the merchant:

Unless otherwise specified in Section 7.3.6.2, Resubmission Following a Decline Response to a Mobility and Transport Transaction, a Merchant that receives a Decline Response may resubmit the Authorization Request or the Account Verification request only as follows:

What follows is Table 7-2. Note two things before reading it. The rule covers account verification requests as well as authorizations — a zero-amount check counts as an attempt. And the one carve-out is mobility and transport transactions, which follow their own resubmission rule in 7.3.6.2.

Table 7-2: the four categories

The Category 1 rule's scope is the part operators get wrong.

After receiving a Category 1 code, the table states that

a Merchant must never resubmit an Authorization Request or Account Verification for the same Payment Credential

The same payment credential. Not the same transaction, not the same customer. A closed account (46) or a revoked authorization (R1) attaches to the card; a new card from the same person is a new credential. Conversely, a different order against the same closed card is still forbidden.

And the table's footnote closes a loophole from the issuer side:

After sending a Category 1 Decline Response, Issuers must consistently send the same Decline Response code.

An issuer cannot return 46 today and 05 tomorrow for the same dead account. Once the credential is in Category 1, it stays there.

Why Categories 2 and 3 share a limit but should not share a strategy

Both permit up to 20 attempts in 30 days. The labels tell you why the behaviour should differ.

Category 2 — "Issuer cannot approve at this time". These are conditions that can change without any action from you: 51 not sufficient funds, 61 exceeds approval amount limit, 65 exceeds withdrawal frequency limit, 91 issuer or switch inoperative, 96 system malfunction, 78 account temporarily blocked. Repeating an identical request later is a rational use of the reattempt budget. This is the category retry scheduling is actually for.

Category 3 — "Data quality - Revalidate payment information". 54 expired card, 55 PIN incorrect, 82 negative CVV results, 6P verification failed, N7 CVV2 failure — and in the CEMEA and Europe regions, 70 PIN data required and 1A additional customer authentication required. Repeating an identical request is permitted and futile. The rule's own label is an instruction: fix the data. A 54 wants the updated expiry from your account updater feed; a 1A wants a customer-present authenticated retry, not a scheduled one. Spending Category 3 budget on unchanged retries is how a merchant reaches an excessive-reattempt assessment while recovering nothing.

Category 4 is the residual: any decline code not listed above, with the same 20-in-30 ceiling. The most common code here is 05 do not honor — which is exactly why 05 is so hard to act on. It carries no diagnostic, and the issuer instruction for the category is to "Limit use to transactions where no other value applies".

15 or 20 — what changed, and what did not

A large share of operator-facing material puts the reattempt cap at 15 in 30 days. That includes acquirer disclosures, PSP documentation, and — until this article — an earlier PaymentBrief reference on dunning that, honestly, hedged the figure as "roughly 15" from acquirer disclosures rather than from the rule.

The rule as retrieved says 20, three times, once per permitted category. Its section carries a "Last Updated: Apr 2026" stamp.

What this article does not claim is that Visa raised the number in April 2026. The edition's own change log for section 7.3.6.3 records one change only — the new code 83 — and says nothing about attempt counts. So one of two things is true: the limit moved in an earlier edition and secondary sources never caught up, or 15 was always a simplification. The public document does not settle which, and neither should you.

What to do with that: a retry configuration built around 15 is conservative, not wrong. But if you are disputing an excessive-reattempt assessment, or negotiating one, the number in the operative rule is 20.

The new code: 83

Effective 25 July 2026 — in force — Visa added a Visa-only response code. Its summary of changes describes it as:

a dedicated Visa-only response code (RC 83 - Fraud/Security [Visa use only]) to signal when a Transaction has been STIP-declined due to high-risk or fraudulent conditions

Two things follow. First, an 83 did not come from the issuer. It came from Visa's stand-in processing, which means the network's own risk assessment declined the transaction. Second, Table 7-2 places 83 in Category 2, so reattempt is technically permitted — but the label "cannot approve at this time" is doing less work here than usual. Repeating an identical request into a network fraud decline is not a retry strategy; it is a way to spend budget confirming the same answer.

If your decline-code handling has a fixed list of known codes, 83 is probably not on it. Add it, and route it away from automatic retry.

What the rules do not tell you

Fee amounts. Table 7-2 sets the reattempt limits. It does not say what an excessive reattempt costs. That lives in fee schedules and acquirer agreements, and the figures in circulation vary. This article states none, and you should take yours from your acquirer's current schedule rather than from any published estimate.

Mastercard. This is Visa's rule. Mastercard's merchant advice codes and transaction-processing-excellence framework are a separate regime with separate categories and limits. Mastercard's rulebook could not be retrieved for this article, so nothing about it is stated here. Do not assume the code lists or the 20-in-30 figure carry across.

How your PSP maps raw codes. Most PSPs translate ISO response codes into their own decline reasons before you see them. The mapping is not always one-to-one, and a PSP-level "card_declined" may be hiding a 46 that your retry logic would otherwise refuse. If you cannot see the raw code, ask for it.

A scheduled change to watch

Visa's change log lists, effective 24 April 2027, an AP-region package of subscription management controls in selected countries that "also includes the alignment and revision of Decline Response Codes R1 and R3" — both currently Category 1 revocation codes. The rule it names as impacted is section 4.1.19.3 (subscription management controls), not Table 7-2, and the entry sits under Asia-Pacific region-specific changes with several large AP markets excluded. This article does not describe its content. Treat it as a reason to re-read Table 7-2 after April 2027, not as evidence that the Category 1 list is changing globally.

What an operator actually does differently

• Hard-code Category 1 as never-retry, keyed on the credential. Not on the transaction ID, not on the customer record. The rule is per payment credential.
• Separate Category 2 from Category 3 in your retry engine. Same limit, opposite logic. Category 2 retries wait; Category 3 retries need changed data first.
• Count account verification requests against the budget. The rule says so explicitly. A zero-amount check is an attempt.
• Move to 20 in your rule reference, and keep 15 if it is your operating margin. The rule says 20; a tighter internal cap is a choice, not a compliance requirement.
• Add 83 to your code tables and route it away from auto-retry. It is in force and it comes from the network, not the issuer.
• Get the raw code from your PSP. A generic wrapper can hide a Category 1 decline behind a retryable-looking label.
• Treat 05 as the code that tells you nothing. Issuers are supposed to use generic codes only where no other value applies; when you see one, the useful information is elsewhere.

For the retry and dunning mechanics that sit on top of these rules, see failed payment recovery and dunning operations. For the credential-level lifecycle that determines whether a Category 3 retry has any hope, see card credential lifecycle and account updater operations. For what the legacy two-digit codes are and are not, see the decline codes glossary.