Chargeback Evidence and Representment: The Operator Reference by Dispute Scenario
What evidence to assemble for fraud, non-receipt, not-as-described, cancellation, duplicate, and credit-not-processed chargebacks — and in what order.
Reason-code references say which code applies. This reference sorts evidence by scenario instead — fraud, non-receipt, not-as-described, cancellation, duplicate, credit-not-processed — so operators know what to assemble and which claims are scheme rule vs. judgment call.
There is no single evidence checklist for chargeback representment — the right packet depends on the dispute scenario: fraud/unauthorised, not received, not as described, recurring cancellation, duplicate processing, credit not processed, or an authorisation/processing error. Each draws a different mix of proof of purchase, authentication data, delivery or access logs, policy disclosure, and communication history. Visa and Mastercard differ too: Visa's 10.4 fraud code has a formal Compelling Evidence 3.0 remedy with no Mastercard equivalent, Mastercard's 45-day response window is 15 days longer than Visa's 30, and similar claims — duplicate charges, credit not processed — route through differently structured code sets on each network. This reference sorts evidence by scenario and tags every requirement as a scheme rule, a code-specific requirement, or general practice.
A reason-code lookup answers "what does 13.1 require." It does not answer the question an operator actually starts with: a customer says the item never showed up, or says they cancelled and got charged anyway, or a card network flags the transaction as unauthorised — before any of that has been mapped to a code, the dispute desk already needs to know what evidence to start pulling. This reference is organised around that starting point: seven dispute scenarios, what actually goes in the evidence packet for each, in what order, and — the part existing code references don't do — which of those requirements is a Visa or Mastercard rule, which is specific to one reason code's remedy, and which is operator judgment dressed up as if it were a rule.
That last distinction is the point of this article. Scheme rules are narrow and specific: Visa's Compelling Evidence 3.0 applies to exactly one reason code. Mastercard has no equivalent mechanism at all. A response window is 30 days on Visa and 45 on Mastercard — not "about a month" on both. Treating a code-specific remedy as if it generalised, or treating good operational habit as if a scheme required it, is the single easiest way to publish chargeback guidance that's confidently wrong. Every evidence item below is tagged Scheme rule, Code requirement, or Good practice, and scheme rules are attributed to Visa or Mastercard specifically, never both by default.
Why scenario, not code
Visa reason codes and Mastercard's Mastercom categories are the correct canonical map of what each code requires, and this article doesn't reproduce those tables — use the reason-code lookup tool for that. What neither reference does, because it isn't their job, is tell you what to assemble before you know the code. An issuer assigns the reason code; the merchant only sees it after the dispute lands. But the dispute desk usually knows the scenario — non-receipt, cancellation, duplicate charge — from the customer's own complaint or the transaction pattern, often before the formal code arrives. Building the packet scenario-first, then confirming it against the assigned code's specific requirements, is faster than waiting on the code to tell you what evidence exists. The general dispute lifecycle — filing, notification, response windows, escalation to pre-arbitration — is covered in chargeback representment for merchants; this reference sits downstream of that, at the evidence-assembly step.
The evidence toolkit
Twelve evidence categories recur across the scenarios below, in different combinations and different orders. Defining them once here keeps each scenario section to what's specific about that scenario, rather than re-explaining each category seven times.
| Category | What it is |
|---|---|
| Proof of purchase | Order confirmation, itemised receipt, or invoice matching the disputed amount and item |
| Authentication (3DS, AVS, CVV) | 3DS2 authentication result and transaction ID, AVS/CVV match results at time of purchase |
| Device and account history | Device fingerprint, IP address, account/user ID, and their consistency across the customer's transaction history |
| Delivery/fulfilment proof | Carrier tracking, signed delivery receipt, or service-completion record (booking confirmation, appointment log) |
| Digital-goods access and usage logs | Login timestamps, download records, feature or content access post-purchase |
| Communication history | Support tickets, emails, or chat logs between merchant and customer before the dispute was filed |
| Refund and cancellation policy disclosure | The policy text itself and proof the customer saw or agreed to it at checkout or sign-up |
| Recurring-payment consent | Signup record showing the customer agreed to recurring billing and its terms |
| Prior undisputed transactions | Transaction history from the same cardholder/device/IP that was never disputed |
| Customer acknowledgement | Timestamped acceptance of terms, a signature, or an explicit confirmation at the point of transaction |
| Cancellation-attempt evidence | System logs showing whether — and when — the customer did or didn't submit a cancellation request |
| Merchant response chronology | A dated internal timeline showing the merchant acted (shipped, refunded, responded to support) within its own stated windows |
Fraud or unauthorised (card-not-present)
Codes: Visa 10.4 (Allocation workflow) · Mastercard 4837 (No Cardholder Authorisation)
Scheme rule (Visa): 10.4 is the only Visa code eligible for Compelling Evidence 3.0 — two prior undisputed transactions from the same cardholder, sharing matching data elements, dated 120–365 days before the disputed transaction. As of October 17, 2025, this qualifies automatically for merchants on Visa Secure or Visa Data Only. Outside 10.4, no Visa code carries this mechanism — do not build a 13.2 or 13.1 packet expecting a CE 3.0-style automatic resolution.
Scheme rule (Mastercard): No equivalent exists. Mastercard's 4837 defence relies entirely on transaction-level evidence submitted through ordinary representment — there is no historical-transaction auto-qualification path, and no amount of prior-transaction evidence resolves the dispute automatically the way CE 3.0 can on Visa.
| Evidence item | Why it matters | Tier |
|---|---|---|
| Authentication result | 3DS2 authentication result is the strongest single signal that the cardholder participated | Good practice |
| Device and account history | AVS/CVV match, device fingerprint, IP consistency with prior orders | Code requirement (4837) |
| Prior undisputed transactions | Two priors, 120–365 days old, matching device/IP/account/shipping | Scheme rule — Visa 10.4 only |
| Communication history | Any pre-dispute contact where the customer engaged with the order | Good practice |
| Customer acknowledgement | ToS acceptance timestamp, especially for subscriptions or digital goods | Good practice |
The first-party and friendly fraud article covers why this scenario dominates dispute volume and the baseline capture requirements (device fingerprint, IP, session metadata, ToS acceptance) in more depth than is useful to repeat here — this section is the packet, not the underlying phenomenon.
Goods or services not received
Codes: Visa 13.1 (Collaboration workflow) · Mastercard 4855 (Goods or Services Not Provided)
Scheme rule: Both codes run their scheme's standard non-fraud workflow — Visa's Collaboration (30-day response, up to 100-day resolution, genuine back-and-forth) and Mastercard's 45-day response window. Neither carries a code-specific automatic remedy; this is a straight evidentiary contest.
| Evidence item | Why it matters | Tier |
|---|---|---|
| Delivery/fulfilment proof | The primary defence for physical goods — carrier tracking with delivery timestamp matched to the cardholder's address | Code requirement (13.1 / 4855) |
| Digital-goods access and usage logs | For digital goods and SaaS, replaces delivery proof — login/access timestamps after purchase | Code requirement (13.1 / 4855) |
| Proof of purchase | Establishes what was ordered and when, as the baseline the delivery evidence attaches to | Good practice |
| Communication history | Any pre-dispute enquiry from the customer about a delayed or missing order | Good practice |
| Refund and cancellation policy disclosure | Relevant if delivery was delayed and a remedy was already offered | Good practice |
Authentication data (3DS, AVS, CVV) does not belong in this packet — it addresses whether the cardholder authorised the charge, not whether the goods arrived, and including it adds bulk without addressing the claim.
Goods not as described or defective
Codes: Visa 13.3 (Collaboration workflow) · Mastercard 4853 (General Cardholder Dispute)
Code requirement: 4853 is explicitly Mastercard's catch-all — its own defence notes call it "the hardest code to defend without category-specific evidence," and generic templates perform worse here than on any other code. Visa's 13.3 is similarly harder to win than 13.1: the merchant has to demonstrate the item matches its description and that the customer's claim is inconsistent with their own usage data, not just that something was delivered.
| Evidence item | Why it matters | Tier |
|---|---|---|
| Proof of purchase / product description | The description the customer saw at time of sale, to compare against the item delivered | Good practice |
| Delivery/fulfilment proof | Condition-at-shipment records — photos, inspection notes — for physical goods | Good practice |
| Digital-goods access and usage logs | Usage inconsistent with a "defective" claim (e.g., extended use after the claimed defect) | Code requirement (13.3 / 4853) |
| Refund and cancellation policy disclosure | Whether a return was offered and declined matters directly to the outcome | Good practice |
| Communication history | The specific claim the customer made — this packet must answer that claim, not a generic one | Code requirement (4853) |
The operational discipline that matters most here isn't a document type — it's addressing the customer's specific stated complaint. A packet built for "not as described, generic" loses more often on 4853 and 13.3 than on any other code in this reference, per both cluster reason-code articles' defence notes.
Recurring or subscription cancellation
Codes: Visa 13.2 (Collaboration workflow) · Mastercard 4841 (Cancelled Recurring Transaction or Digital Goods)
Scheme rule: Standard Collaboration/45-day workflows apply — no CE 3.0-style shortcut exists for either code. Prior renewal history is ordinary supporting evidence in this scenario, not a qualifying mechanism; conflating it with CE 3.0 (which is scoped to Visa 10.4 only) misapplies the rule.
| Evidence item | Why it matters | Tier |
|---|---|---|
| Recurring-payment consent | Signup record showing the customer agreed to auto-renewal and its terms | Good practice |
| Cancellation-attempt evidence | System logs showing no cancellation request was submitted before the billing date — or exactly when one was | Code requirement (13.2 / 4841) |
| Digital-goods access and usage logs | Continued use of the service after the disputed charge undercuts a "didn't want it" claim | Good practice |
| Refund and cancellation policy disclosure | The cancellation path and deadline as presented at signup | Good practice |
| Prior undisputed transactions | A billing history of prior renewals the customer never disputed | Good practice |
Prevention outperforms defence in this scenario more than in any other — pre-renewal notification with an easy cancellation link converts many would-be disputes into cancellations at no chargeback cost. That prevention playbook belongs to first-party fraud and friendly fraud, not this packet reference; the point here is only what to submit once the dispute has already landed.
Duplicate processing or already-refunded
Codes: Mastercard 4834 (Point-of-Interaction Error, duplicate-processing sub-condition) · Visa's duplicate-transaction claims route through the Processing Errors category generally
Code requirement (Mastercard 4834): the merchant needs distinct order IDs and timestamps proving two separate transactions, or confirmation a refund was already issued for the genuine duplicate.
On the Visa side, this reference has a documented limitation rather than a confident claim: PaymentBrief's own Visa reason-code table doesn't currently track a duplicate-processing sub-code, and a direct attempt to read Visa's public Core Rules PDF this pass returned an unreadable compressed file rather than parseable text. Vendor documentation (Chargebacks911, and separately Stripe's own network dispute-code mapping) describes a Visa duplicate-processing code historically numbered 12.6.1 (Duplicate Processing) and 12.6.2 (Paid by Other Means), with a vendor-reported requirement — effective October 19, 2024 — that acquirers supply two separate transaction receipts to rebut a duplicate claim. That requirement is presented here as vendor-reported, not as an independently confirmed Visa rule; confirm current code numbering and the receipt requirement with your acquirer before relying on it operationally.
| Evidence item | Why it matters | Tier |
|---|---|---|
| Distinct transaction records | Separate order IDs, timestamps, and line items proving two genuine transactions, not one duplicated | Code requirement (4834) |
| Refund records | If a true duplicate occurred, proof it was already reversed closes the claim outright | Code requirement (4834) |
| Pre-authorisation and settlement proof | Distinguishes an authorisation hold that later cleared from an actual second charge | Good practice |
| Merchant response chronology | A dated log of batch submissions helps rule out merchant-side double-submission as the cause | Good practice |
Credit not processed
Codes: Mastercard 4853 explicitly includes "credit not processed" among its General Cardholder Dispute triggers, per PaymentBrief's own Mastercard reference. Both networks also maintain a more narrowly scoped dedicated code for this claim — Visa 13.6 and Mastercard 4860 — per Stripe's network dispute-code documentation; neither of those specific code numbers is currently in PaymentBrief's own per-code reference tables, so treat them as PSP-documented rather than independently confirmed against each scheme's primary rulebook this pass.
| Evidence item | Why it matters | Tier |
|---|---|---|
| Proof of refund issuance | Refund transaction log, confirmation number, and processing date — the single most dispositive item for this scenario | Good practice |
| Bank or processor statements | Show the refund actually posted, matched against the disputed charge | Good practice |
| Refund and cancellation policy disclosure | The terms the customer agreed to on when a refund would or wouldn't apply | Good practice |
| Communication history | Any exchange where a refund was promised, denied, or its timeline explained | Good practice |
| Delivery/fulfilment proof | Relevant only if the claim involves a returned item — proof the return was or wasn't received | Good practice |
This is the one scenario in this reference where almost every line is tagged good practice rather than scheme rule or code requirement — not because the claim is unimportant, but because the evidence that resolves it (did the refund post or not) is a factual question the scheme rulebook doesn't need to specify evidentiary form for. A dated refund confirmation either exists or it doesn't.
Authorisation and processing-error disputes
Codes: Visa 11.x (Authorization, Allocation workflow) and 12.x (Processing Errors, Collaboration workflow) · Mastercard 4808 (Required Authorization Not Obtained) and 4834's non-duplicate sub-conditions (amount differs from authorised, late presentment, ATM error)
Scheme rule (Visa): 11.x runs Allocation — a one-shot submission with no structured re-presentment step, unlike Collaboration codes. Defence is genuinely limited on several sub-codes: 11.1 and 11.2 are described in PaymentBrief's own Visa reference as having a narrow merchant action surface, because they reflect an acquirer/processor-stage error rather than something the merchant controls.
Scheme rule (Mastercard): since June 11, 2024, Mastercard requires a Transaction Linkage ID (TLID, 22 characters) across authorization, clearing, and single-message systems to link original and related transactions. This is Mastercard-specific — Visa carries no equivalent requirement in its reason-code set — and PSPs that haven't updated their integration will produce matching failures specifically on recurring and related-transaction disputes.
| Evidence item | Why it matters | Tier |
|---|---|---|
| Authorization approval record | The auth code obtained before capture, from PSP or acquirer logs | Code requirement (11.x / 4808) |
| Capture-vs-authorization amount match | Confirms the settled amount didn't exceed what was authorised | Code requirement (12.x / 4834) |
| Processing timestamps | Demonstrates timely presentment where late presentment is the claim | Code requirement (11.3 / 4834) |
| TLID linkage | Required for Mastercard transaction matching on recurring/related-transaction disputes | Scheme rule — Mastercard only |
Packet structure: what order actually helps
None of what follows is a scheme requirement — Visa and Mastercard both accept whatever format the acquirer's submission channel specifies, and neither publishes a mandated evidence order. This is operator practice, useful because issuer reviewers read fast and a scattered packet reads as a weak one.
- Lead with the single most dispositive item for the scenario — delivery proof for non-receipt, the refund confirmation for credit-not-processed, the cancellation-log timestamp for subscription disputes. That's the one fact that, alone, could resolve the claim.
- Follow with identity/authentication evidence where the scenario is fraud-adjacent — device, IP, AVS/CVV, 3DS2 result. This is out of place in a non-receipt or credit-not-processed packet and belongs near the top only for the fraud scenario.
- Add policy and consent evidence — the terms the customer agreed to, and proof they saw them, particularly for cancellation and not-as-described claims where the dispute often turns on what was disclosed.
- Close with communication history and a dated chronology — tying the other evidence into a timeline is what turns a folder of documents into a rebuttal an issuer reviewer can follow in one pass.
Scheme rule, code requirement, or good practice — the recap
| Claim in this article | Tier | Scope |
|---|---|---|
| CE 3.0 two-prior-transaction remedy | Scheme rule | Visa 10.4 only — no Mastercard equivalent |
| Visa 30-day / Mastercard 45-day merchant response window | Scheme rule | Scheme-wide, both networks, different numbers |
| TLID transaction linkage | Scheme rule | Mastercard only, effective June 11, 2024 |
| Delivery proof as primary defence for non-receipt | Code requirement | Visa 13.1 / Mastercard 4855 |
| 4853/13.3 requiring claim-specific (not generic) evidence | Code requirement | Mastercard 4853, and Visa 13.3 by extension |
| Visa 12.6.1/12.6.2 duplicate-processing codes and receipt rule | Vendor-reported, unconfirmed | Not in PaymentBrief's own Visa code table this pass |
| Packet ordering (lead with dispositive evidence, close with chronology) | Good practice | Operator judgment, not scheme-mandated |
| Prior undisputed transactions as supporting evidence outside 10.4 | Good practice | Useful everywhere; qualifying mechanism only on 10.4 |
Sources and limitations
Mastercard's own domains returned HTTP 403 on every path attempted this pass, consistent with the constraint noted across PaymentBrief's Mastercard-adjacent articles — Mastercard-specific claims here are drawn from PaymentBrief's own already-sourced Mastercard Mastercom reference (which itself flags that Mastercard's primary rulebook sits behind merchant-registration access) rather than a fresh primary fetch. A direct fetch of Visa's public Core Rules PDF (usa.visa.com/dam/VCOM/download/about-visa/visa-rules-public.pdf) returned a 7.2MB file whose text could not be extracted from its compressed internal structure — no reason-code-level claims in this article are sourced from that document. Where a claim could not be confirmed against either scheme's primary material, it is either omitted or explicitly marked vendor-reported/unconfirmed above, not hedged with a generic verification note.
What to read next
- Visa reason codes reference — the canonical per-code Visa map this reference draws its Visa evidence notes from.
- Mastercard Mastercom dispute categories reference — the canonical per-code Mastercard map.
- Chargeback representment for merchants — the dispute lifecycle and win-rate context this evidence reference sits downstream of.
- Visa Compelling Evidence 3.0 evidence-build guide — the deep capture-and-readiness guide for the one code with a formal automated remedy.
- First-party fraud and friendly fraud — why the fraud scenario dominates dispute volume and the baseline capture requirements behind it.
Sources & methodology (6)
Stripe's network dispute-reason-code documentation for Visa, Mastercard, and Amex, including Visa 13.6 (Credit Not Processed), Visa 13.7 (Cancelled Merchandise or Services), Visa 12.6.1/12.6.2 (Duplicate Processing / Paid by Other Means), and Mastercard 4860 (Credit Not Processed) — codes not currently tracked in PaymentBrief's own per-code reference tables
PSP-compiled mapping of network reason codes to evidence categories, not a primary Visa/Mastercard rulebook citation. Used to identify scenario-relevant codes and evidence categories outside PaymentBrief's currently tracked Visa (15-code) and Mastercard (7-code) reference tables.
Checked:
Visa reason code 12.6.1 (Duplicate Processing) evidence requirements, including an October 19, 2024 acquirer requirement to provide two separate transaction receipts to rebut a duplicate-processing claim
Vendor secondary source; page dated August 2020 but references an October 2024 rule change within its own text, so treat the page's currency as uncertain. Not confirmed against Visa's primary rulebook — a direct fetch of Visa's public Core Rules PDF this pass returned an unreadable compressed stream. Code 12.6.1/12.6.2 is not part of PaymentBrief's own Visa reason-code reference table; confirm current numbering and requirements with your acquirer.
Checked:
CE 3.0 applies only to Visa reason code 10.4; requires two prior undisputed transactions from the same cardholder sharing matching data elements over a 120–365 day window; no Mastercard equivalent exists
Reused from PaymentBrief's own sourced CE 3.0 reference; see that article for the full Visa/PSP citation chain.
Checked:
Visa VCR Allocation vs Collaboration workflow mechanics, per-code triggers, and the 30-day/70-day/100-day filing and resolution deadlines
Checked:
Mastercard Mastercom code triggers, defence notes, 45-day merchant response window, and the June 11, 2024 TLID (Transaction Linkage ID) requirement
Checked:
Baseline card-not-present evidence set (device fingerprint, IP, session metadata, 3DS2 authentication result, ToS acceptance timestamp) and the fight/accept decision framework by dispute value
Checked:
Source types explained in our Methodology.
By Shaun Toh · Director, Digital Payments · Razer