In Module 1 we traced how money reverses across the four parties. A reason code is what makes that reversal legible. When an issuer pulls funds back from an acquirer, it attaches a code, and that code is a machine-readable assertion about why the transaction is being challenged. The whole dispute machine downstream, including what counts as a valid rebuttal, is keyed off that one field.
Treat the code as a control language rather than a description. It tells you what the network is willing to argue about, who carries the burden, and which documents will actually be read. Send the wrong evidence and you lose, not because your case is weak, but because you answered a different question than the one the code asked.
The code defines the question, the rules define the answer
Each network publishes a dispute rulebook that maps every reason code to a set of permitted remedies. Visa restructured its codes under Visa Claims Resolution in 2018 into four categories: Fraud (10), Authorization (11), Processing Errors (12), and Consumer Disputes (13). The format is two digits, a period, and a third digit, so 10.4 is the fourth condition inside the Fraud category and 13.1 is the first inside Consumer Disputes.
Mastercard uses a flatter four-digit scheme inside parallel categories. Reason code 4837 is "No Cardholder Authorization," 4853 is the broad "Cardholder Dispute" bucket, and 4855 is "Goods or Services Not Provided." Mastercard has been folding 4855 into 4853 as it consolidates its dispute categories, which is a reminder that codes are versioned rules, not fixed facts. Always work from the current rulebook edition, not a cached list.
The point that matters for operations: the category determines the burden of proof. A fraud code asks "was this the real cardholder," a consumer-dispute code asks "did the cardholder get what they paid for." Those are different evidentiary worlds, and the network's systems will only accept the evidence type tied to the code.
Why the same chargeback feels different across codes
Consider one order that never showed up. If the cardholder claims they never authorized it, the issuer files a fraud code. If they admit they bought it but say it never arrived, the issuer files a consumer-dispute code. Same missing parcel, two entirely different defenses.
Under a fraud code the network wants identity and authorization signals: AVS and CVV results, 3-D Secure authentication data, prior undisputed history with the same card. Under a delivery code the network wants carrier confirmation of delivery to the cardholder's address. Submit a tracking number against a fraud code and it is largely irrelevant, because delivery does not prove the right person placed the order.
A worked example: Visa 13.1
Visa 13.1 covers "Merchandise/Services Not Received." The cardholder asserts they paid and got nothing by the expected date.
Read the rule and the constraints fall out. The issuer generally cannot file before a delivery date passes, and where no date was set, not before 15 calendar days past the transaction date. The cardholder side runs to 120 calendar days from the transaction or the expected delivery date, capped at 540 days from processing. Once the chargeback lands, the acquirer passes it to you and you typically have 30 days to respond.
The accepted evidence is narrow. To represent a 13.1 you need proof of delivery or proof the service was rendered: carrier confirmation showing delivery to the cardholder's address, signed where possible, plus the order and shipping records that tie it together. A refund issued before the dispute, or evidence the cardholder collected the goods, also closes it. What does not work is restating your terms and conditions or arguing the customer is wrong, because 13.1 does not put your policy on trial, it puts delivery on trial.
Now flip the same order to fraud code 10.4, "Other Fraud, Card-Absent Environment." Here the rulebook wants the authentication and verification trail. A perfect delivery receipt does nothing for a 10.4 on its own, because the dispute is about who, not whether. This is exactly why the first operational step on any incoming dispute is to read the code and route to the matching evidence template, never the reverse.
Building the mapping once, using it every time
The codes are stable enough to encode as a lookup. For each network and each code, capture four things: the category and what it asserts, the response window in days, the specific evidence the network accepts, and the disqualifiers that get a representment rejected. That table is the spine of a dispute-ops function, the subject of Module 9.
Two practical cautions. First, codes drift. Networks renumber, merge, and retire codes on their own release cadence, as the 4855 consolidation shows, so treat your mapping as a living document tied to a rulebook version and date. Second, the code an issuer picks is not always the most accurate one; misfiled codes happen, and sometimes a fraud code masks what is really a service complaint. You answer the code as filed, but you log the mismatch, because a pattern of miscoded fraud is a signal worth surfacing.
This is also where this course stays in its lane. The recurring-billing and SaaS cancellation cases that cluster under codes like 4853 get their own deep treatment in the sibling "Subscriptions, Billing & Dispute Defense" course. Here the relevant fact is structural: that family of codes asks about consent and cancellation, so the accepted evidence is the consent record and cancellation policy, not delivery proof.
Takeaway
A reason code is a contract about what the network will let you argue. Read it before you touch the evidence: the category sets the burden, the rulebook sets the response window, and the code sets the exact document type that will be accepted. Build the code-to-evidence mapping once, version it against the live rulebook, and route every incoming dispute through it. Everything in representment, which we cover next, depends on having answered the right question first.