Card Decline Codes: Visa vs Mastercard Retry Rules

Visa now lets a merchant retry a soft-declined card up to 20 times in 30 days, not 15. The figure sits in Table 7-2 of the Visa Core Rules dated 18 April 2026, and Adyen's own retry documentation still says 15. If the incumbent guides and one of the biggest acquirers disagree on the headline number, your retry logic is probably keyed on something older still.

Most of the pages that rank for "card decline codes" are glossaries: a list of two-digit codes with a sentence each. That is the least useful way to think about them. A decline is three separate signals (the ISO 8583 response code, a scheme-level retry category or advice code, and whatever your PSP normalises them into) and the retry rules attach to the first two, not the third. This guide works from the scheme rules and the four PSP APIs as they stand in September 2026.

What Do Card Decline Codes Actually Mean?

The issuer's answer travels back in ISO 8583 Data Element 39, the response code. 00 is approved. Everything else is a reason for not approving, and the two-character value space is shared across schemes without being fully standardised by them. Visa publishes its meanings in the Core Rules. Mastercard publishes its own, plus a second signal: the Merchant Advice Code, which tells you what to do next rather than why it failed. Secondary sources consistently place the MAC in DE 48 subelement 84; Mastercard's interface specification that would confirm it sits behind a login.

The trap is that the same code can mean different things on different networks. Code 65 is the clearest example. On Visa it is "Exceeds withdrawal frequency limit", a Category 2 soft decline. On Mastercard in the UK and EEA, issuers use 65 to demand strong customer authentication, and Stripe's docs note that its authentication_required decline on Mastercard used to surface as withdrawal_count_limit_exceeded because some issuers had not updated their systems. If you map raw codes without the scheme alongside them, you will misroute a slice of your SCA traffic.

Visa Decline Categories in 2026: 20 Retries, Not 15

Visa sorts every decline response into four categories. Issuers must "send to VisaNet the Decline Response code that most accurately reflects the reason for the decline", and merchants are bound by the category's reattempt limit.

Three details in that table surprise people. First, 59 (suspected fraud) is Category 2, so it is retryable under the rule, even though every PSP will tell you not to show the reason to the customer. Second, 83 (Fraud/Security, Visa use only) was added to Category 2 effective 25 July 2026. Third, 1A, the SCA step-up code, is Category 3 in Europe, which means every step-up retry counts against the same 20-attempt budget as your dunning schedule.

The rule on Category 1 is absolute: "a Merchant must never resubmit an Authorization Request or Account Verification for the same Payment Credential". Note the second half. A zero-amount account verification to "check if the card works now" after a 41 is itself a breach.

The rules also forbid gaming the retry. Section 1.7.2.1 says a party that reattempts "must not intentionally manipulate any data elements from the original Authorization Request", naming MCC, POS entry mode and the e-commerce indicator. Flipping a card-not-present retry to look like a different transaction type is exactly what Visa is watching for.

The fee amounts are not in the public rulebook. PayPal's merchant guidance puts them at $0.10 per excess attempt domestic and $0.25 cross-border across the US, Canada, Europe, LAC, Japan and Australia, and says Visa matches retries on acquirer, acquirer ID, card acceptor ID, PAN or token, and amount. Treat those figures as secondhand. The limit itself is primary.

Mastercard Merchant Advice Codes: What Each One Tells You

Mastercard's approach is more prescriptive. Instead of a category you derive from the response code, the issuer can send an explicit instruction.

MACs 24 to 30 apply to card-not-present recurring transactions declined with 51 (insufficient funds). They are the issuer telling you when payday is. Ignoring them and retrying at 2am on a fixed schedule is how dunning systems burn their attempt budget on cards that would have cleared on Friday.

Mastercard's excessive-retry thresholds, as quoted by Braintree and PayPal from Mastercard's Transaction Processing Excellence programme: more than 10 declined attempts on the same card in 24 hours, or more than 35 in 30 days, at the same card acceptor for the same amount. In Europe the fee applied from 1 August 2024 at €0.55 per transaction. In the US it stepped from $0.15 (2023) to $0.30 (2024) to $0.50 (January 2025). Retrying a MAC 03 or 21 decline is charged separately; TD Merchant Solutions' Canadian pass-through for that fee rose from 0.05 to 0.78 per transaction on 1 February 2026.

Visa vs Mastercard Retry Rules Compared

The practical difference: on Visa you infer intent from the code, so your mapping table is the policy. On Mastercard the issuer states intent, so your job is to obey it. A retry engine that only reads response codes is half-blind on Mastercard; one that only reads advice codes has nothing to go on for Visa.

What Does Decline Code 05 "Do Not Honour" Mean?

It means the issuer declined and chose not to say why. Visa's rules put it in Category 4 and require issuers to "limit use to transactions where no other value applies". In practice issuers use 05 for risk declines, internal limits, and anything their fraud model dislikes, precisely because it discloses nothing.

Several ranking pages call 05 a hard decline and tell you to wait 24 hours. Under Visa's rules it is retryable within the 20-attempt budget. My position: treat a bare 05 as retryable, but only a small number of times (I would cap it at three across several days) and never within the same hour. A second identical 05 on an unchanged request is strong evidence the issuer's model has made up its mind. The widely quoted statistics on what share of declines are 05 trace back to secondary blogs citing a 2016 Visa analysis I could not find, so I would not build a business case on them.

Soft Declines 1A and 65: SCA Declines in the UK and EU

Under PSD2 and the UK's SCA rules, an issuer that wants a challenge returns a soft decline rather than a hard one: 1A on Visa, 65 on Mastercard. Adyen documents both as "Authentication Required" and automatically retries the payment through 3D Secure unless you set executeThreeD=false. Checkout.com surfaces the same condition as 20154 ("3DS authentication required"); 20150 is a different thing, a card not enrolled in 3DS.

The engineering consequence is that the retry is a new authorisation with authentication data attached, and it counts towards Visa's Category 3 limit. If your exemption strategy (TRA, low-value, merchant-initiated) produces a high rate of 1A responses, you are spending retry budget and adding friction at the same time. I covered which exemptions issuers actually honour in the SCA exemptions guide.

How Stripe, Adyen, Checkout.com and Braintree Expose Decline Codes

Every major PSP normalises declines into its own vocabulary, and every one of them can also give you the raw scheme code. The differences are field names and whether you have to ask.

None of them returns a Visa category as a field. Adyen and Braintree publish mapping tables in their docs; you implement the lookup.

Stripe's outcome object on an issuer decline shows how the layers stack. This is from Stripe's own documentation:

"outcome": {
  "network_decline_code": "54",
  "network_advice_code": "03",
  "network_status": "declined_by_network",
  "reason": "expired_card",
  "advice_code": "confirm_card_data",
  "risk_level": "normal",
  "type": "issuer_declined"
}

Raw 54 (expired, Visa Category 3), raw advice 03 (do not try again), and Stripe's own advice confirm_card_data. Those are three answers to "can I retry?" and they are consistent here only because the card is genuinely expired. When type is blocked instead, network_status is not_sent_to_network: Radar stopped it, the issuer never saw it, and no scheme retry counter moved.

Adyen's refusal list has one entry worth knowing: reason 46, "Transaction blocked by Adyen to prevent excessive retry fees". Adyen runs its own counter and will refuse your retry before it reaches Visa. That is helpful, but the counter only sees Adyen traffic, and its documentation still cites the 15-attempt figure.

The PSPs' built-in retry defaults sit well inside the scheme limits. Stripe recommends "a maximum of eight retries" and its Smart Retries default is 8 attempts in 2 weeks. Checkout.com's retry.dunning defaults to 6 attempts over 30 days and caps max_attempts at 15. Adyen's Auto Rescue takes a maxDaysToRescue of 1 to 48, with 30 recommended.

How Should You Retry a Declined Card Payment?

This is opinion, built from the rules above. Key your retry decision on the raw scheme code plus the MAC, and treat the PSP's normalised code as display text only. Normalised codes are lossy by design: Stripe's generic_decline covers both an issuer's unexplained decline and a payment its own Radar or Adaptive Acceptance blocked, which have completely different retry economics.

A decision order that survives both schemes:

1. If the PSP says the issuer never saw it (not_sent_to_network, Adyen 20, Checkout.com 4xxxx), it is your risk rules, not a scheme decline. Fix or review; no scheme counter applies. 2. If Mastercard sent a MAC, obey it. 03 and 21 stop; 24–30 set the next attempt time; 01 goes to the account updater first. 3. If Visa and the raw code is Category 1, stop permanently for that credential, including zero-amount verifications. 4. If 1A or Mastercard 65 in the UK or EEA, retry once with 3DS, immediately, in session if the customer is present. 5. Otherwise, retry on a schedule you control, counting attempts per card, merchant ID and amount across every PSP you route through, and stop well below 10 per day and 20 per 30 days.

Point 5 is where multi-PSP setups get hurt. Adyen's reason 46 protection, and any similar guard, only sees the traffic routed through that PSP. Your dunning job, your customer-initiated retries and your failover path each look reasonable on their own, and nobody owns the total. Keep the counter in your own ledger, next to the idempotency records you already store (see idempotency keys in payment APIs).

I expect the gap between normalised and raw codes to widen. Visa added a new fraud code this July and Mastercard added sanctions MAC 42 in 2024; PSP enums lag these changes by months. Teams that store the raw pair now will be able to act on new codes the day they appear.

What This Means for Payments Engineers

• Store the raw pair on every decline. Persist the scheme, raw response code and MAC alongside the PSP's normalised code. On Adyen, tick Raw acquirer result under Developers > Additional data, or refusalCodeRaw never arrives.
• Update your Visa limit to 20, and do not aim for it. The rule changed; the fees did not go away. A retry schedule that reaches 20 attempts on one card in 30 days is recovering almost nothing by the end.
• Treat 65 as scheme-dependent. Route it to 3DS on Mastercard in Europe, to a delayed retry on Visa.
• Never "test" a Category 1 card. A zero-value verification after 41 or 43 is a resubmission under Visa's wording.
• Honour MAC 24–30 timings for recurring 51 declines. They are free data about when the money arrives.
• Keep customer messaging generic for fraud codes. Stripe and Adyen both tell you not to reveal fraudulent, stolen_card or lost_card to the shopper; show the same text you use for generic_decline.