Defending 10.4 disputes: The Compelling Evidence 3.0 checklist that banks actually accept

When a customer opens a Visa chargeback under Dispute Condition 10.4 ("Other Fraud: Card-Absent Environment"), most engineering teams respond by dumping 30 pages of server logs, terms of service agreements, and customer service chat transcripts into Stripe or their payment gateway.

Nine times out of ten, the issuing bank rules against the merchant anyway.

The reason isn't that the merchant is wrong; it's that issuing banks don't read unstructured 30-page PDFs. Under Visa's Compelling Evidence 3.0 (CE3.0) framework, fraud liability only shifts back to the cardholder if you satisfy explicit, deterministic data matching rules.

Here is the exact technical criteria your logging infrastructure must capture if you want to overturn 10.4 disputes systematically.

---

1. The Historical Anchor Rule (120–365 Days)

To invoke CE3.0, you cannot just prove the disputed transaction was legitimate. You must prove the cardholder has a verified history of legitimate purchases on your platform with the same credential.

The framework requires:

• At least two qualifying prior transactions made with the identical card credential (same primary account number).
• Both prior transactions must be older than 120 calendar days from the dispute date, but no older than 365 calendar days.
• Neither prior transaction can have had a reported fraud dispute or chargeback.

If your payment database only indexes transactions by internal order ID without an immutable hash of the payment method fingerprint, you cannot automatically surface these qualifying historical anchors when a dispute alert hits.

---

2. The Core Data Point Match (2 of 4)

Once two qualifying historical transactions are established, Visa requires you to prove that at least two of the following four core identity attributes match identically across both historical transactions AND the disputed transaction:

1. Customer Device ID / Fingerprint: The unique client fingerprint hash calculated during session initiation.
2. Customer IP Address: The client IP captured during authorization (excluding shared VPN egress blocks when possible).
3. Customer Account Login / User ID: The unique authenticated user identifier associated with the active subscription or checkout.
4. Physical Delivery Address: If physical goods are shipped, matching postal coordinates.

For SaaS and digital goods, items 1, 2, and 3 are your primary defence.

---

3. What to Change in Your Checkout Telemetry Today

Most SaaS apps store payment records in isolation from application audit logs: Stripe retains the charge, while application telemetry sits in Datadog or CloudWatch. When a dispute arrives 90 days later, bridging the two requires manual forensic queries across multiple databases.

To make dispute defence reliable:

• Persist authorization metadata at the moment of charge: Capture ip_address, device_fingerprint_hash, and authenticated user_uuid directly into your internal billing transaction ledger at the exact second the webhook confirms charge authorization.
• Store timestamped event streams: Record the post-checkout telemetry: service usage, API key generation, or download confirmations tied to that specific session.
• Format rebuttal packets deterministically: Present a 1-page structured comparison table showing the disputed transaction alongside the two historical qualifying transactions with highlighted matching attributes.

Issuing banks look for matching key-value pairs that fit the scheme criteria, not emotional explanations. Capturing the right three metadata fields on every authorization turns a chaotic manual chore into a deterministic operational check.