Four families of dispute, four kinds of evidence.

Fictional scenarios and synthetic data. Reviewed 6 November 2026.

Tomas has ninety disputes in the Brightwater Tickets queue and a representment deadline on a third of them. He is sorting by amount. Ines asks him to sort by the first two digits of the reason code instead. The queue becomes four piles, and three of them turn out to need no evidence hunt at all.

What is actually being decided.

A dispute is an issuer, on behalf of a cardholder, asking the merchant to justify a charge. The decision for the merchant is not "do we fight this" but "what is being asked, and do we hold the thing that answers it". Each actor carries something. The cardholder carries the claim. The issuer carries the obligation to classify that claim and raise it correctly. The acquirer carries the funds movement and the deadline. The merchant carries the burden of reply, and with it the cost of either answer: concede and lose the sale, or reply and spend an analyst's hour on a case that may not be winnable.

The lifecycle is the part most people learn first and then forget to use. In Visa’s dispute-resolution guidance, the issuer raises the dispute, the disputed amount and a fee are withdrawn from the merchant's balance, the merchant has a limited window to submit evidence or accept, and the issuer then rules. A ruling in the merchant's favour returns the amount; a ruling against is final at that stage. That document is our source for the lifecycle; the fee level depends on the acquirer and the scheme, and we do not quote figures we cannot source. Confirm your own window and fee with your acquirer.

What the lifecycle does not tell you is what the issuer is asking. The reason code does.

The family is the question.

Visa groups its dispute reason codes into four categories, and the leading digits name the family: Fraud (10.x), Authorisation (11.x), Processing Errors (12.x) and Consumer Disputes (13.x). We describe them in general terms here; the individual codes, their conditions and their time limits are in the scheme's own rules, which your acquirer will summarise for you.

Fraud (10.x) asks who. The cardholder says they did not authorise the transaction. The useful reply supports the relevant authorisation question, or that liability for the question has already moved elsewhere, as with an authenticated 3DS transaction. For card-absent fraud under 10.4, the Compelling Evidence 3.0 framework, as summarised by Visa’s published CE3.0 material, lets a merchant point to prior undisputed transactions on the same credential with a matching footprint. We treat that in Two prior transactions and a matching footprint.

Authorisation (11.x) asks whether. Was there a valid authorisation for this amount on this card at this time? The reply is the authorisation record, or there is no reply. This family is rarely about the customer at all. It is about the merchant's own payment flow: declined authorisations that were captured anyway, captures that exceeded the authorised amount, expired authorisations.

Processing Errors (12.x) asks what. Was the right amount charged once, in the right currency, to the right card, for the right thing? Duplicate captures, wrong currency, a credit that was processed as a debit. Again the evidence is already in the merchant's records, if the records were kept.

Consumer Disputes (13.x) asks why. The cardholder agrees they made the purchase but says something went wrong: goods not received, not as described, a cancelled recurring charge that continued, a refund not processed. The reply is the service record: delivery, terms shown at checkout, cancellation handling, the refund that was or was not issued.

The observation is the family. The inference is what happened. A 10.4 dispute is an issuer's classification of a cardholder's claim; it is not proof that a stranger used the card. Some of that pile will be first-party misuse, which we take up in When the cardholder is the customer.

A worked month at Brightwater.

In this illustration, Brightwater Tickets receives 90 disputes in a month. Sorted by family: 54 Fraud, 3 Authorisation, 6 Processing Errors, 27 Consumer Disputes. That is 54 + 3 + 6 + 27 = 90, and the fraud family is 60 per cent of the queue.

The three Authorisation disputes are checked against the authorisation log in ten minutes. Two have a clean authorisation and are replied to with the record; one was captured after a decline and is conceded, with a ticket raised to engineering. The six Processing Errors are five duplicates from a checkout retry bug and one currency mismatch; all six are conceded and refunded, and the retry bug is the real finding of the month.

The 27 Consumer Disputes split again. Nineteen are "event cancelled, refund not received"; the refunds were issued but after the dispute was raised. Eight are "not as described" around seat categories. These need the service record, which Brightwater holds, but each reply has to be assembled by hand.

The 54 Fraud disputes are where the analyst time goes, and where the evidence question is sharpest. Brightwater sells to repeat buyers, so a portion will have prior transactions on the same card. A portion will have been authenticated through 3DS. The rest are a decision about cost: how much time to spend assembling evidence that may not qualify.

The alternative explanation we keep alive: a 60 per cent fraud share may mean a fraud problem, or it may mean that the issuer's cardholder-service flow makes "I don't recognise this" the easiest button to press. The mix across families, tracked month on month, tells you more than the count. If 13.x climbs while 10.x is flat, inspect fulfilment, billing and customer-experience changes before assuming a fraud-control failure.

The reply is only as good as the record.

Every family has an evidence type that is either held on the day of the sale or not held at all. Authorisation records, capture amounts, delivery confirmation, the terms shown at checkout, the device and IP at the time of purchase: none of these can be recovered later if they were not captured then. The practical implication is that dispute readiness is a logging decision made at the point of sale, not a research task after the dispute arrives. The articles on case notes someone can audit and Volume 01's evidence before action make the same point from the investigation side.

A failure mode to watch.

Treating all ninety disputes as one problem called "chargebacks" and measuring them as one ratio. The ratio matters for the scheme programmes, and we take that up in Two ratios, two denominators, one portfolio. But operationally, a month of duplicate captures and a month of card-absent fraud need different people, different fixes and different evidence, and a single number hides which one you have.

A way to work it.

1. Sort the queue by family before anything else. Note the count in each.
2. For Authorisation and Processing Errors, check your own records first. Concede what you cannot support and raise the engineering ticket the same day.
3. For Consumer Disputes, assemble the service record: terms shown, delivery, cancellation and refund timeline.
4. For Fraud, check first for 3DS authentication and then for prior undisputed transactions on the same credential. Decide per case whether the reply is worth the hour.
5. Record, per family, what the reply needed and whether you held it at the time of sale.
6. Review the family mix monthly. Treat a shift of more than a few points as something to explain, not just report.

Take it to the desk.

For each reason-code family, which single piece of evidence do we already hold on the day of the sale, and which do we only start looking for after the dispute arrives?

Try it: A merchant's ratio heads toward the threshold and, from Volume 01, Dispute spike. Look up: reason code, representment, dispute.

Fictional scenario. Synthetic data. No real customer records.

Edited 6 November 2026. Primary references are listed above; fictional scenarios are not claims about Antifrog customers or operating experience.