Chargeback disputes are won or lost on documentation. The substantive question of whether a transaction was fraudulent matters less than whether the processor can produce, in structured form, the specific evidence that Visa and Mastercard dispute resolution processes require. Most processors lose disputes they could have won. The reason is rarely a lack of evidence — it's that the evidence exists somewhere in the system but wasn't captured in the right format at the right time.

This guide covers what the dispute process actually requires, what evidence elements matter most, and how the timing of documentation assembly affects dispute outcomes.

The Dispute Process: Visa and Mastercard Frameworks

Visa operates its dispute resolution under the Visa Dispute Resolution (VDR) framework, now integrated into Visa Claims Resolution (VCR). Mastercard uses the Mastercard Dispute Resolution Management (MDRM) framework. Both systems follow similar structural logic: the cardholder initiates a dispute through their issuing bank, the issuer submits a chargeback to the acquirer, the acquirer (or processor acting on the acquirer's behalf) has a defined response window to submit representment, and the issuer makes a final determination.

Visa's standard response window for representment is 30 days from the chargeback date. Mastercard's is similarly 45 days. These windows are not generous, particularly for processors managing disputes across large merchant portfolios. The representment package must be complete and properly formatted — incomplete submissions are typically not returned for correction; they are simply ruled in favor of the cardholder.

The acquirer and its processors carry primary liability on card-absent fraud disputes. When a dispute is submitted under Reason Code 10.4 (Visa) or the Mastercard equivalent, the liability presumption is against the merchant and processor unless evidence demonstrating authorized transaction or appropriate fraud controls can be produced. That liability presumption is the starting point — documentation is what changes it.

What Documentation Is Required

Effective chargeback representment requires a specific set of evidence elements. The exact requirements vary by reason code, but for card-not-present fraud disputes, the core documentation set includes:

Why Post-Hoc Documentation Is Weaker

Here is the operational reality that most processors underappreciate: documentation assembled after a chargeback arrives is materially weaker than documentation generated automatically at the time of transaction authorization.

The difference is credibility and completeness. A risk score pulled from a logging system six weeks after the transaction was authorized raises questions about whether the score reflects the actual state of the fraud model at that point in time — models are retrained, thresholds are adjusted, and without immutable contemporaneous records, the evidentiary value of a retroactively retrieved score is reduced. Dispute resolution reviewers are trained to scrutinize documentation that appears assembled rather than generated.

Device fingerprint data is particularly time-sensitive. Device identifiers change. Browser fingerprints evolve. IP-to-geolocation mappings are updated. A device fingerprint retrieved 60 days after the transaction from a system that doesn't maintain immutable historical records may not reflect the state of that fingerprint at the time of the transaction. If the disputing party challenges the timing or accuracy of the fingerprint evidence, the processor needs to demonstrate data provenance — which is straightforward for contemporaneously generated records and nearly impossible for retroactively assembled ones.

How Automated Decision Records Change the Quality of Evidence

The structural solution to the documentation quality problem is generating and persisting decision records automatically at the time of each authorization decision. An automated decision record captures: the full transaction attributes, the feature values used by the scoring model, the resulting risk score, the decision threshold applied, the authorization action taken, and a timestamp that is cryptographically tied to the transaction identifier.

This record is generated as a side effect of the scoring process — not assembled in response to a dispute. That means it exists for every transaction, not just transactions that later become disputed. It is immutable and timestamped. When a chargeback arrives 45 days later, the representment documentation is already assembled: pull the decision record for that transaction ID, append the authorization evidence, and the package is complete.

The dispute outcome improvement from this approach is direct. Processors running automated decision records consistently report higher representment success rates on card-absent fraud chargebacks compared to processors assembling documentation retroactively. The improvement is not because the transactions were less fraudulent — it's because the evidence quality is higher and the submission process is faster and more complete.

Evidence Requirements for Specific Reason Codes

Two reason codes account for a substantial fraction of card-absent fraud chargebacks at SMB processors and have specific evidence requirements worth detailing:

Visa Reason Code 10.4 — Other Fraud: Card-Absent Environment: This is the primary reason code for CNP fraud disputes. Visa's VCR documentation for 10.4 representment requires: proof that the transaction was completed in accordance with Visa's card-not-present acceptance requirements, evidence of cardholder participation (shipping address match, device history, email confirmation), and where 3DS authentication was used, the authentication result. If 3DS was not used on a transaction later disputed under 10.4, the liability shift does not apply and the documentation burden is higher. The risk score and device fingerprint elements are particularly important here — they go to the question of whether fraud controls were applied at authorization.

Visa Reason Code 11.3 — No Authorization: This code is used when the issuer claims no valid authorization existed. Representment requires producing the authorization code and timestamp from the card network authorization record, demonstrating that a valid authorization was obtained and that the transaction amount was within the authorized range. For processors using pre-authorization and incremental authorization flows, maintaining clean records of each authorization step is essential — a dispute under 11.3 where the processor can only produce the final capture record, not the intermediate pre-auth record, is difficult to win. The authorization trail needs to be complete.

Both reason codes benefit substantially from automated decision records that capture the full authorization flow contemporaneously. Processors building their representment capability should treat automated decision record generation as a foundational component, not an optional enhancement. The dispute outcomes justify the infrastructure investment on volume alone.