SIMPLIA cardholder says they never received their order. Depending on the network, that complaint arrives under a different code, with different rules, a different clock and different evidence expectations. For a merchant working across both schemes, this is where time and winnable cases are lost.
Six allegations behind many codes
Codes vary, but most disputes fall into a small set of allegations. Mapping codes to allegations gives analysts a common language and a clear evidence target.
| Allegation | Visa example | Mastercard example | Typical proof |
|---|---|---|---|
| Fraud, card absent | 10.4 | 4837 | Authorisation, device, IP, order history |
| Not received | 13.1 | 4855 | Carrier tracking, proof of delivery |
| Not as described | 13.3 | 4853 | Listing, policy, customer messages |
| Cancelled recurring | 13.2 | 4841 | Terms, cancellation log, usage |
| Credit not processed | 13.6 | 4860 | Refund and payment ledger |
| Duplicate charge | 12.6.1 | 4834 | Order and settlement match |
What changes in practice
- Evidence rules differ. For example, Visa Compelling Evidence 3.0 allows merchants to use previous undisputed transactions, with matching data such as device, IP address and delivery address, to answer certain card absent fraud disputes.
- Monitoring programmes matter. Visa's VAMP combines fraud reports and disputes into one monthly ratio, and in most regions the merchant excessive threshold tightened to 1.5% from April 2026.
- Time limits are short. Response windows differ by scheme and by processor, so a missed date can mean a lost case.
Build a playbook per allegation
For each allegation, define the evidence required, where it lives, how to score it and which deadline applies. Then attach scheme specific variations. Analysts follow one routine, and the platform handles the differences.
The takeaway
Classify by allegation first, then apply the scheme variation. It reduces rework, speeds up evidence collection and keeps responses inside the right rules.