Chargeback Reason Codes: Visa vs Mastercard

Stripe files a Mastercard 4853 "goods or services not provided" dispute under product_unacceptable, while the equivalent Visa 13.1 lands in product_not_received. The same customer complaint on two networks reaches your code as two different categories. If your dispute logic branches on the PSP category alone, it is already making wrong decisions.

Most pages ranking for chargeback reason codes are code catalogues written for merchants. They list 10.4 and 4837, suggest "better customer service", and stop. None of them say what the codes look like once they reach an API, which deadlines your PSP actually gives you, or which codes the schemes quietly retired. This guide covers both halves: the scheme rules as they stand in September 2026 (Visa Core Rules of 18 April 2026, Mastercard Chargeback Guide of 19 May 2026) and the way Stripe, Adyen and Checkout.com expose them.

What Are Chargeback Reason Codes?

A reason code is the card scheme's label for why an issuer reversed a transaction. The issuer picks it when it raises the dispute, and it decides three things that matter to engineers:

• Which evidence can win. A fraud code wants proof the cardholder made the purchase. A "not received" code wants proof of delivery. Sending the wrong bundle loses by default.
• Which workflow runs. Visa splits disputes into two flows with different steps. Mastercard sends some codes straight to arbitration.
• Which clock applies. Issuer windows run from 120 days to 540 days depending on code.

Visa Chargeback Reason Codes: The Full 2026 List

Visa Claims Resolution (VCR) groups disputes into four categories. The April 2026 Core Rules contain these condition codes:

Two corrections to most published lists. 12.1 Late Presentment no longer exists. It applied to transactions up to 12 April 2024; after that, late presentment moved into 11.3. And 12.6 carries two sub-reasons (duplicate processing, paid by other means), which Stripe surfaces as 12.6.1 and 12.6.2.

The Allocation vs Collaboration split changes your state machine. In Allocation (categories 10 and 11) there is no "dispute response" step: the issuer's dispute moves liability straight away, and your acquirer's first move is a pre-arbitration attempt within 30 days. In Collaboration (12 and 13) the acquirer files a dispute response within 30 days, and the issuer then decides whether to go to pre-arbitration. That 30 days is the acquirer's limit, not yours. Your PSP keeps a buffer, so your real window is shorter.

Mastercard Chargeback Reason Codes in 2026: Which Are Still Active?

Mastercard has spent years folding codes together. The May 2026 Chargeback Guide has four categories and a small active set:

The guide says each legacy code "may be used; however, this code will eventually be eliminated". Three codes are absent from the guide entirely: 4840, 4842 and 4863. Plenty of reference pages still list 4863 ("cardholder does not recognise") as active. Stripe's own mapping table labels 4842 and 4846 deprecated.

The practical upshot: a Mastercard 4853 can mean not received, not as described, credit not processed, cancelled recurring or counterfeit. The top-level code tells you almost nothing. You need the sub-reason, and not every PSP passes it through.

Visa vs Mastercard Chargebacks: Timeframes Compared

What PSPs pass on is tighter. Stripe says merchants usually get 7 to 21 days. Checkout.com gives typically 20 days, sometimes 10, and 5 days to escalate a Visa allocation dispute to arbitration. Adyen's merchant defence window for Mastercard is 40 days.

Visa Compelling Evidence 3.0: The Data You Must Store

CE 3.0 took effect in April 2023 and is the one chargeback rule that is really a data-retention requirement. A 10.4 dispute is invalid if you can show:

1. Two prior transactions on the same card or token, not reported as fraud, processed more than 120 and no more than 365 days before the dispute. 2. A description of the goods or services for all three transactions. 3. Matching identifiers: at least one of device ID, device fingerprint or IP address, plus one or more of account/login ID, full delivery address, device ID/fingerprint or IP.

The format rules are where teams fail. Visa requires a device ID of at least 15 characters in clear text (an IMEI qualifies), a fingerprint of at least 20 characters built from two or more hardware or software properties (hashing allowed), and the cardholder's public IP address, unhashed. If your checkout logs sha256(ip) for privacy, you cannot use CE 3.0. If your fraud vendor keeps the fingerprint and you never store it against the order, you cannot either.

Stripe exposes the structure directly. The evidence object looks like this:

"enhanced_evidence": {
  "visa_compelling_evidence_3": {
    "disputed_transaction": {
      "customer_account_id": "acct_8812",
      "customer_device_fingerprint": "f3a9c1...(>=20 chars)",
      "customer_purchase_ip": "81.2.69.160",
      "merchandise_or_services": "services",
      "product_description": "Annual plan, 1 seat",
      "shipping_address": { "line1": "...", "city": "...", "postal_code": "...", "country": "GB" }
    },
    "prior_undisputed_transactions": [
      { "charge": "ch_...", "customer_purchase_ip": "81.2.69.160", "...": "..." },
      { "charge": "ch_...", "customer_purchase_ip": "81.2.69.160", "...": "..." }
    ]
  }
}

The array must hold exactly two entries. Stripe reports readiness in evidence_details.enhanced_eligibility.visa_compelling_evidence_3.status (not_qualified, qualified, requires_action) with actions such as missing_prior_undisputed_transactions. It also enforces a stricter reading than the current Visa text: device ID and fingerprint together cannot be your only identifiers.

What Changes in Visa CE 3.0 on 24 October 2026

The April 2026 Core Rules schedule four changes for disputes processed from 24 October 2026:

• The two prior transactions may come from one or more merchants, not just yours.
• Device ID and device fingerprint count as one element. You cannot pair them to meet the two-identifier bar, which is the rule Stripe already enforces.
• Login IDs held by an agentic payment provider count as account identifiers.
• More e-commerce routes (Visa Token Service with TAVV, Visa IDX Match Key) can use a purchase order number instead of a description.

Mastercard's closest equivalent, First-Party Trust, works differently. The network itself rejects a 4837 with reason code 5002 before it reaches you, using data from Identity Check Insights and Ethoca Consumer Clarity. It covers US cards since October 2024, added Canada and Latin America in January 2026 and Asia Pacific in April 2026. It does not yet cover Europe or the UK. For UK Mastercard volume, 4837 defence still means a second presentment with registered-account evidence, and guest checkouts have no compelling-evidence route at all.

How Stripe, Adyen and Checkout.com Map Reason Codes

Each PSP flattens the scheme codes into its own vocabulary, and each keeps the raw code somewhere else.

The mapping has gaps. On Stripe, Visa has no code mapped to unrecognized at all. Mastercard 4834 maps to duplicate, but 4831, with the same sub-descriptions, maps to general. Discover's "does not recognise" also lands in general. Checkout.com states the problem plainly in its spec: its evidence list and categories "will change over time" and your logic should not hard-code them.

Adyen's deadline is the sharp one. defensePeriodEndsAt arrives as 2021-05-24T16:05:30+03:00 style strings, and flags such as defendable arrive as the strings "true" and "false", not booleans. Parse "false" as truthy and you will auto-defend disputes you meant to accept. Stripe's due_by can be 0, meaning the issuer allows no response; treat that as "no deadline" and your queue will sort it first forever.

Evidence submission is one-shot everywhere. Stripe: "you may only submit evidence once." Adyen: after INFORMATION_SUPPLIED, documents cannot change. Checkout.com: evidence cannot be amended once submitted. Stripe's submit parameter defaults to true, so a client that means to stage evidence and omits the flag sends a half-built case. Always pass submit=false until the bundle is complete.

Webhook names differ too: Stripe fires charge.dispute.created and charge.dispute.funds_withdrawn, Adyen sends NOTIFICATION_OF_CHARGEBACK then CHARGEBACK, Checkout.com sends dispute_evidence_required. Verify each one properly; the webhook signature guide covers the differences.

Chargeback Fees in the UK: Stripe, VAMP and Mastercard ECP

Stripe charges £20 per dispute in the UK (€20 in the eurozone, $15 in the US). Since 17 June 2025 it adds a £20 counter fee when you contest, returned only if you win. So a £15 order that you fight and lose costs £55 before goods. For Visa and Mastercard compliance cases Stripe collects a 500 USD network fee, refunded on a win.

Above that sit the scheme programmes. Visa's VAMP, consolidated in June 2025, uses one ratio: fraud reports (TC40) plus disputes (TC15), divided by settled card-not-present transactions. The Excessive merchant threshold in Europe, the US, Canada and Asia Pacific dropped from 220 to 150 basis points on 1 April 2026, with a floor of 1,500 fraud-plus-dispute events a month. Fraud reports count even when no chargeback follows, so refunding a fraudulent order does not clean up the ratio.

Mastercard's Excessive Chargeback Program counts chargebacks against the previous month's transactions: 100 chargebacks and 1.5% for an Excessive Chargeback Merchant, 300 and 3% for the High tier. The thresholds now sit in a non-public Mastercard manual; the published fee schedule starts at 1,000 in month two and reaches 100,000 to 200,000 a month for persistent offenders.

Chargeback vs Section 75 in the UK

Chargeback comes from scheme rules, not law, and it applies to debit and credit cards with no amount limit. Section 75 of the Consumer Credit Act makes a credit card issuer jointly liable for purchases over £100 and up to £30,000. UK consumers often use both. For merchants the difference matters because a Section 75 claim is not a chargeback: it never produces a reason code, never reaches your dispute API, and you cannot defend it through your PSP.

The PSR's APP fraud reimbursement (from 7 October 2024, capped at £85,000) covers Faster Payments and CHAPS only. Card payments are out of scope, so for UK card fraud the chargeback route still carries the whole load.

My Take: Store the Network Code, Not the PSP Category

This is opinion, but I have seen it go wrong twice. Teams build dispute handling around the PSP's normalised category because it is the friendliest field. Then they add a second acquirer, and the categories do not line up: Stripe's 15 reasons, Checkout.com's 9 categories and Adyen's raw scheme text cannot be joined. Worse, the normalisation loses the one distinction that matters for evidence selection, as the 4853 example shows.

Store (network, reason_code, sub_reason) as the primary key of your dispute taxonomy and treat the PSP category as a display label. My prediction: once CE 3.0 accepts evidence across merchants from 24 October 2026, PSPs will start assembling prior-transaction evidence from network data themselves, and the merchants who win 10.4s will be the ones whose own logs are clean enough to be trusted when the network's data is missing.

What This Means for Payments Engineers

1. Log CE 3.0 fields at checkout now. Public IP in clear text, a 20+ character device fingerprint, account ID and full delivery address, stored against the charge for at least 365 days plus your dispute window. 2. Key logic on the network code. Map 10.4, 4837, 13.1 and friends yourself, with a fallback for codes you have never seen. Retired codes like 4863 still appear on old cases. 3. Normalise deadlines to UTC on ingest, subtract a buffer, and treat Stripe's due_by = 0 as "cannot respond". 4. Stage, then submit. Pass submit=false on Stripe and use Checkout.com's PUT before POST. One submission is all you get. 5. Track the VAMP ratio yourself, counting fraud reports, not only chargebacks. Early fraud warnings from Stripe convert to fraud disputes about 40% of the time. 6. Decide the fight-or-accept threshold with the counter fee included. Below a certain order value, auto-accepting is cheaper. If you want to talk through a multi-acquirer dispute pipeline, you can reach me via Tom Wang.

Key Takeaways

• Visa has 23 condition codes across four categories; 12.1 was retired in April 2024. Categories 10 and 11 skip the dispute response step.
• Mastercard's active set is small: 4808, 4834, 4837, 4849, 4853, 4870, 4871 plus regional codes. 4840, 4842 and 4863 are gone.
• Visa CE 3.0 needs two undisputed transactions 120 to 365 days old and matching IP, device or account data in clear text. From 24 October 2026 those transactions can come from other merchants.
• Mastercard First-Party Trust auto-rejects qualifying 4837s but does not cover the UK yet.
• Stripe, Adyen and Checkout.com each normalise codes differently; the raw code lives in network_reason_code, chargebackReasonCode and reason_code.
• Every PSP allows exactly one evidence submission, and Stripe submits by default.
• UK Stripe disputes cost £20 received plus £20 to counter; VAMP's Excessive threshold is now 150 bps.