Chargeback Reason Codes: A Visa and Mastercard Reference
Issuers and merchants often sort the same reversed sale into different fraud and service categories. The network code alone rarely tells you the root cause.
A chargeback reason code is the card network's label for why an issuer reversed the transaction. It records the claim the issuer filed, not what the customer meant when they called the bank. The same renewal, the same missed delivery, or the same confusing descriptor can land in a fraud bucket at the issuer and a service bucket in your notes. Networks, issuers, and merchants do not share one story for that sale.
Refund every alert because the code says fraud, and you pay for delivery and billing problems a credit would have closed only when the claim was real. Fight every code because the order looked fine in your system, and you miss the cases you should have refunded before the dispute cost more than the sale.
I would read the code as a filing label, then name your own root cause before you choose a refund or a response. Match the records to the claim the code really makes: proof the cardholder authorized the sale, proof the amount and capture were correct, or proof the goods shipped and the subscription terms were clear. That package answers the label. A blanket refund does not.
Major Visa and Mastercard Reason Codes at a Glance
A printed notice rarely explains itself. Match the code on the page to a row below, read the claim in plain language, and pull the records that answer that claim. The code is the network's filing label for the reversal, separate from what the cardholder meant. Refunding every alert because the label says fraud pays for service problems you could have fixed, or for sales your records already defend.
Visa Acceptance Solutions groups causes as fraud, authorization errors, processing errors, and customer disputes. Those groups are not one bucket. A cancelled renewal, a shipment that never arrived, and a product that does not match the page are three different failures. Subscription, SaaS, and direct-to-consumer teams lose the sale and the fee when they credit all three as "customer unhappy."
| Network and code | Meaning | Category |
|---|---|---|
| Visa 10.4 | Other Fraud, Card-Absent Environment | Fraud |
| Visa 11.x | Authorization errors such as declined or missing authorization | Authorization |
| Visa 12.5 | Incorrect Amount | Processing Errors |
| Visa 12.6 | Duplicate Processing or Paid by Other Means | Processing Errors |
| Visa 12.7 | Invalid Data | Processing Errors |
| Visa 13.1 | Merchandise or Services Not Received | Consumer Disputes |
| Visa 13.2 | Canceled Recurring | Consumer Disputes |
| Visa 13.3 | Not as Described or Defective | Consumer Disputes |
| Visa 13.6 | Credit Not Processed | Consumer Disputes |
| Visa 13.7 | Canceled Merchandise or Services | Consumer Disputes |
| Mastercard 4837 | No Cardholder Authorization | Fraud |
| Mastercard 4808 | Authorization-related chargeback (dual message) | Authorization |
| Mastercard 4834 | Duplicate Transaction | Processing Errors |
| Mastercard 4853 | Cardholder Dispute | Consumer Disputes |
| Mastercard 4860 | Credit Not Processed | Consumer Disputes |
| Mastercard 79 | Goods or Services Not Received | Consumer Disputes |
| Mastercard 75 | Account Not Credited | Consumer Disputes |
Read a row in three moves. The first column is what the notice prints. The middle column is the claim you have to answer, not a verdict on the order. The last column points at the evidence set. Fraud wants card-absent and authentication records. Authorization wants the approval log. Processing errors want the capture file and any second charge. Consumer disputes want fulfillment, the cancellation timestamp, or the credit you already issued.
Mastercard does not print one number for every path. A dual-message authorization chargeback and a single-message debit notice can describe a related problem with different codes, including a long code such as 4808 and a short code such as 79 or 75. Put the message type in the lookup key, or you will attach the wrong package.
I would not refund from the code alone. Map the label to a root cause first. A missed cancel or a box still in transit can justify a timely credit. If the records already answer the claim, respond with that package instead.
Four Categories That Decide Which Evidence You Need
Mastercard's Chargeback Guide groups chargebacks into four foundational categories: authorization-related disputes, cardholder disputes, fraud disputes, and point-of-interaction errors. Visa uses four operational categories that line up in purpose but not in names: Fraud (Category 10), Authorization (Category 11), Processing Errors (Category 12), and Consumer Disputes (Category 13).
The split matters because each category asks a different question. An authorization failure is a sale completed without a valid approval. A fraud claim says the cardholder didn't authorize the payment. A merchandise dispute says goods weren't received or were defective. A point-of-interaction error is a processing mistake, such as a duplicate capture or an incorrect amount. Mastercard places numeric codes inside those groups. 4808 covers authorization-related chargebacks on many dual-message transactions, and 4853 identifies a cardholder dispute. On certain Debit Mastercard single-message transactions, related codes include 08 and 53. Inside cardholder disputes, 79 can mean goods or services weren't received, and 75 can mean an account wasn't credited.
Visa's advice is to diagnose the transaction problem rather than treat the code as the root cause. The category still decides which file you open first.
| Category | Visa reference | Mastercard examples | Evidence to pull |
|---|---|---|---|
| Fraud | Category 10, for example 10.4 | 4837 No Cardholder Authorization | Authentication results, order history, device and address data |
| Authorization | Category 11 | 4808 Authorization-related | Approval records and transaction-message data |
| Processing Errors | Category 12 | 4834 Duplicate Transaction | Settlement and reconciliation records |
| Consumer Disputes | Category 13 | 79, 75, 4853, 4860 | Delivery proof, cancellation timestamps, refund status and customer communications |
Three steps before you write a word
- Map the code to its category. A 12.6 and a 13.1 can both feel like "the customer is angry," but one is a settlement mistake and the other is a fulfillment claim.
- Pull the matching records. Authorization logs don't answer a missing-package claim, and a tracking number doesn't answer a declined-auth sale you forced through.
- Check lifecycle state. Refund status, fulfillment status, and the subscription-cancellation timestamp often show the claim is already true, or already false, before you draft a response.
Keep that packet as documentary evidence explained in a form an issuer can read, not as a folder of screenshots with no dates. Our evidence collection process is the working version of step two.
Practical rule: If the category and the lifecycle state disagree, trust the lifecycle state for the refund decision and keep the network code unchanged for the file.
Fraud Codes and Why Issuers and Merchants Disagree
The fraud labels you'll see most often are narrow on paper and wide in practice. Visa 10.4 is "Other Fraud, Card-Absent Environment." The broader 10.x family also covers EMV liability-shift cases, where a chip card was used in a way that shifts liability, plus monitoring-program flags. Mastercard 4837 is "No Cardholder Authorization." None of those phrases tells you whether a stranger used the card or the actual cardholder changed their mind.
Third-party fraud means someone other than the cardholder used the credentials. First-party fraud, often called friendly fraud, means the cardholder made or benefited from the purchase and still disputed it. The two need different files. Third-party cases lean on authentication, device, and address checks. First-party cases lean on order history, a recognizable billing descriptor, prior successful renewals, and proof the buyer used the service.
Why the visible code misleads the response
Issuers in that Datos Insights work called most chargebacks fraud. Merchants called fewer than half fraud, and they assigned a larger share to first-party than the banks did. A merchant who optimizes only for the printed label, especially "no cardholder authorization," will build the same evidence pack for three different events.
Say a subscription renews on the 14th. The cardholder doesn't recognize the descriptor, calls the bank, and the issuer files 10.4 or 4837. Your notes show a login the day before, a cancellation page that was never used, and 3-D Secure that wasn't offered on renewals. The operational cause is an unrecognized renewal or a failed authentication, not a stolen card. If you book it as an unclassified fraud write-off, prevention never sees it. If you route it to support as an ordinary complaint, you never tighten checkout.
Better code-level reporting doesn't cut disputes when the business mislabels fraud, treats first-party cases as routine service tickets, or dumps them into a write-off with no cause.
What to store, and what to turn on
Record the network code exactly as it arrived. Add a separate root-cause field your team sets from authentication results, order history, and customer records. Don't let the issuer's label overwrite that field.
Tie controls to that field, not to a blanket rule:
- 3-D Secure: Use it on first card-not-present orders and on risky renewals. A missing authentication result is a different root cause from a stolen-card pattern.
- AVS and CVV: Keep the match results on the order. A full match plus later product use points away from third-party fraud.
- Billing descriptor: Put a name the cardholder will recognize on the statement. A confusing descriptor is a prevention failure, even when the code says fraud.
I wouldn't auto-refund every fraud-coded alert. Refund when the root-cause field says the buyer couldn't have recognized the charge or you can't prove they received it. Contest when authentication, history, and usage line up.
Authorization and Processing Error Codes and Their Fixes
These codes point at your payment flow, not at the cardholder's story. They are the disputes you can stop with engineering, and they are also the ones that raise gateway cost when retries and duplicate captures pile up. Teams that cut processing costs without losing conversions still lose the sale twice if the second capture becomes a chargeback.
Authorization family
Visa's 11.x family covers authorization errors. The ones that show up in daily ops are a declined authorization you completed anyway, no authorization before presentment, and late presentment after the approval window closed. Mastercard 4808 is the dual-message authorization-related chargeback.
Fix the decline path first. If the issuer returns a decline, don't force the sale and don't keep retrying the same auth until something soft-approves. Train the gateway to stop, ask for another method, and store the decline code.
Reauthorize when shipment slips. An approval isn't a permanent permission. If the order sits past the authorization window, get a new approval for the amount you will capture. Late presentment is what you get when warehouse delay and a stale auth code meet.
Pull approval records and the transaction messages: auth code, amount, date, and the response you received. A screenshot of the order page isn't a substitute.
Processing family
Visa 12.5 means the captured amount differs from the approved amount. Tips, tax added after approval, or a partial shipment captured as the full total all land here. Capture only the authorized amount, or reauthorize before you raise it.
Visa 12.6 means the same transaction was processed twice, or the card was charged after the buyer paid another way. Mastercard 4834 is the duplicate-transaction counterpart. Use idempotency keys on every capture, and check for an existing successful charge before a retry. If the buyer switches to PayPal or a second card, void the first auth the same day.
Visa 12.7 means invalid data reached clearing. Wrong merchant category, a bad transaction-type indicator, or a mismatched date will do it. Compare what you sent with what the processor stored before you assume the issuer is nitpicking.
Settlement and reconciliation records are the evidence for this family. Show one capture, one invoice, and one auth, with amounts that match.
The single check that catches most of these is a daily reconcile of captures against authorizations and invoices. Anything captured without a matching approval, captured twice, or captured for a different amount should be reversed before the cardholder sees it.
Consumer Dispute Codes for Subscriptions and Fulfillment
A renewal that posts after cancel, a parcel that never scans as delivered, and a refund the statement never shows are three different failures. Visa groups them under Category 13, consumer disputes. That code is the network's label for the claim, not a readout of what the buyer meant. Match the transaction to the label, then decide whether the evidence supports a fight or a refund.
For card-not-present ecommerce and subscriptions, the codes that carry the volume are 13.1 merchandise or services not received, 13.2 canceled recurring, 13.3 not as described or defective, 13.6 credit not processed, and 13.7 canceled merchandise or services.
Mastercard files the same events under different numbers. 79 is goods or services not received. 4853 is a cardholder dispute. 4860 is credit not processed. 75 is an account not credited. Same business event, different filing cabinet. Build one evidence package for the event, then file it under whichever label the network used.
Non-receipt and condition
13.1 and 79 say the buyer paid and received nothing. Answer with carrier tracking, delivery confirmation, and, for digital goods, usage or download logs tied to the account. A "label created" scan is not delivery.
13.3 says the item or service was not as described or was defective. The product page, the checkout terms, and photos of what shipped carry more weight than a generic quality policy. If you already replaced or refunded, the credit record belongs in the same packet. Our guide to Visa reason code 13 walks through how these condition codes differ when you write the response.
Cancellation is not the same failure as a missing credit
Recurring teams should run 13.2 and 13.6 as separate workflows. A 13.2 claim says the cardholder canceled and you billed again. Pull the cancellation request, the timestamp, and whether any usage happened after that timestamp. A 13.6 claim says an expected refund or credit never posted correctly. Pull refund status, the processing date, and the acquirer reference. 4860 and 75 are the Mastercard versions of "you said you credited me." 13.7 sits closer to a returned or canceled one-time order than to a subscription renewal.
Each code needs its own records: delivery for non-receipt, the cancellation timestamp for 13.2, refund status for 13.6, checkout terms for not-as-described. A blanket refund on every alert drops the cases where the shipment scanned as delivered or the credit already posted.
Line the code up against lifecycle state before you contest or refund. If the cancellation timestamp is before the renewal, 13.2 is probably valid, and another fight burns the response window. If the refund posted and the issuer filed anyway, 13.6 is a representment, not a second credit. I would refund the first case and contest the second.
Prevention that leaves a paper trail
Make cancellation a one-click action and send an email that states the time it took effect. Send every refund with a dated confirmation the buyer can match to the statement. When a shipment will miss the promised window, do not wait for the bank. Proactive chat for Shopify stores gives the buyer a place to ask before they dispute, which is the only moment a 13.1 can still be solved with a tracking link instead of a reversal.
How Mastercard Codes Change Between Message Systems
4853 on a dual-message Mastercard transaction and 53 on certain Debit Mastercard single-message transactions can both arrive labeled as a cardholder dispute. They are network labels, not a transcript of what the customer meant. A case tool that stores only the words "cardholder dispute" will not know which deadline or evidence rule applied on the next processor file.
Mastercard's chargebacks guide distinguishes the Dual Message System from the Single Message System, and individual reasons can vary by message system. Dual message separates authorization from clearing. Single message, common on debit, handles them together.
Map the label to a root cause and an evidence package instead of refunding every alert that sounds like a dispute.
In dual message, 4853 is Cardholder Dispute. On related single-message debit transactions, 53 covers two reasons: Cardholder Dispute, and Defective/Not as Described. Same short code, two reasons, two packages. 4808 is the dual-message authorization-related example. 08 is the short code used on certain single-message debit transactions for that authorization-related reason.
| Dispute reason | Dual Message System | Single Message System (Debit) |
|---|---|---|
| Cardholder Dispute | 4853 | 53 |
| Defective/Not as Described | 4853 | 53 |
| Authorization-related chargeback | 4808 | 08 |
I read 53 as one debit label for two reasons, not as a second name for a single claim. Cardholder dispute wants the cancellation, the terms, or the usage log that matches the complaint. Defective or not as described wants the product page, the order description, and what was delivered. Authorization-related 4808 or 08 wants the approval message, not a shipping scan. A blanket refund throws out the cases where that record already answers the label.
The same purchase can still split into different records once the message system changes. One path wants the credit transaction. Another wants proof the original sale was reversed before clearing.
This short walkthrough shows how those two message paths split a single purchase into different records:
The dictionary that doesn't mix them up
Store the original network code exactly as received. On the same record keep network, message system, region, description, effective date, and the response deadline. Then normalize to a broader cause: fraud, authorization, processing, or fulfillment. Keep the evidence checklist separate from the code. Shipment tracking, delivery confirmation, service-usage logs, and customer acknowledgments can support several non-receipt codes, including 79, without you copying the files into a new folder every time the number changes.
That model stays auditable for the issuer and still lets you report one fulfillment rate across Visa, Mastercard, and processor labels.
How to Respond to a Chargeback Before the Deadline
The deadline on the notice sets the order of work. Everything else is optional until you know the date you will miss.
- Read the network, the code, and the response deadline. Write them on the case before you open the order. A Mastercard representment and a Visa one don't share a clock, and a late file is a loss even when the evidence is perfect. Our notes on Mastercard dispute charges are the place to confirm what that network expects in the packet.
- Find the category and the evidence package. Use the category table, not memory. Fraud wants authentication and history. Authorization wants the approval message. Processing wants settlement. Consumer disputes want delivery, cancellation, or the credit.
- Check lifecycle state. Look at refund status, fulfillment status, and the subscription-cancellation timestamp. These three fields often show the claim is valid before you spend an hour on a narrative.
- See whether a refund already issued. A second credit on top of a posted refund creates a new processing dispute. If the credit is in flight, say so with the date and reference, and don't send another one.
- Choose refund or contest. Refund when the claim matches the records, or when fighting costs more than the sale once you count time and fees. Contest when the records show the payment was authorized, the goods were delivered, or the cancellation happened after the charge you are defending.
- Assemble a response that answers the code's claim. A 12.6 response is "here are two different orders" or "here is the void." A 13.1 response is "here is delivery." A general letter about your fraud tools answers neither.
- Submit before the deadline and log the outcome. Keep the code, the root cause you assigned, the decision, and whether you won, lost, or credited.
A finished record is one file. It shows the network code as received, your root-cause field, the evidence list, and the result. That file is what you audit next month. The notice PDF alone isn't.
Build a Reason-Code Map Before Your Next Dispute
Code tables go stale. Networks add reject reasons and processors turn on intake for codes they ignored last quarter. A glossary you printed in January will apply the wrong evidence rule by autumn.
Marqeta's 2025 release notes show why a static lookup fails. Mastercard introduced reject reason 5002 for certain U.S. and Canadian "No Cardholder Authorization" disputes under its First Party Trust program, and resubmission requires mandatory documentation. The same notes say Visa dispute-intake support expanded to previously non-integrated codes including 11.2, 12.7, 13.4, 13.5, 13.7, and 13.8. Visa still groups disputes as fraud, authorization, processing errors, and consumer disputes. Mastercard doesn't use that vocabulary. If your processor lags the network, the code on the notice and the actions your dashboard offers can diverge.
The useful question isn't only what 13.2 or 4853 means. It's whether Stripe, PayPal, Shopify Payments, or your acquirer can accept, route, or act on that code today, and what happens when the workflow changes.
Fields worth keeping on one dated sheet
Build a processor-specific map and date it. One row per code you receive:
- Code and network: Store 10.4 and 4837 as different rows even when you believe the story is the same.
- Market and dispute stage: Mark U.S. and Canadian First Party Trust cases apart from the rest, and note whether you are pre-dispute, in representment, or facing a reject.
- Alert path and refund deadline: Record which alert network can see the case and the last time a credit still stops the filing.
- Evidence and resubmission: List the documents, and say yes or no on whether a rejection can be sent back. For 5002, the answer is yes only with the required documentation.
Pre-dispute alerts are the prevention layer on top of that map. Visa's Rapid Dispute Resolution and Mastercard's CDRN can surface a dispute in the window before a chargeback posts, which is when a refund still helps. When we detect a chargeback threat, we automatically process a refund to prevent the chargeback. You only pay when we prevent a chargeback from hitting your account. We don't guarantee dispute prevention, chargeback reduction, processor approval, account standing, or avoidance of reserves, monitoring programs, or account termination.
This week, list the five codes that appear most often on your notices. Confirm with each processor which of those codes it can accept today, and write the deadline and the evidence set next to each one. Update the sheet when a reject reason like 5002 shows up, instead of discovering the new rule inside a lost case.
Chargeback reason codes tell you the network's claim, not whether you should refund. Disputely connects Visa RDR, Mastercard CDRN, and Ethoca alerts to your processor so a real threat can be refunded before it becomes a chargeback, and so the cases you can win aren't credited by habit. If you want that split on the codes you already see, visit Disputely.
