Most guides to Compelling Evidence 3.0 stop at the qualification rules: match two of four data elements across three transactions, make sure one is IP or device ID, and file under reason code 10.4. If you meet those criteria, the liability shift is automatic.
But not every fraud dispute qualifies for CE 3.0. When it doesn't, you're back to standard representment, where the evidence you submit actually gets weighed. This piece covers Visa's four mandated data elements for CE 3.0, then walks through six additional evidence points that matter for the disputes CE 3.0 doesn't cover.
The rule, compactly
CE 3.0 applies to Visa card-not-present disputes filed under reason code 10.4 ("Other Fraud: Card-Absent Environment"). The merchant must supply two prior undisputed transactions on the same payment credentials, each between 120 and 365 days old relative to the dispute date. At least two of four core data elements (User ID, shipping address, IP address, or device ID) must match across all three transactions, and one of the two must be IP address or device ID.
Source: Visa Compelling Evidence 3.0 Merchant Readiness document.
The four data elements Visa mandates
CE 3.0 qualification requires at least two of four data elements to match across all three transactions (the disputed one and both prior undisputed ones). One of the two matches must be IP address or device ID.
- User ID match. Whatever identifier the merchant uses for the cardholder's account on file. Must be consistent across all three transactions.
- Shipping address match. Ship-to address on all three transactions. Minor differences (unit numbers, punctuation) can be problematic; most acquirers want exact match.
- IP address match. IP captured at the time of purchase for all three transactions. ISP-level match is acceptable to most issuers; exact address is stronger.
- Device ID match. Device fingerprint captured at checkout on all three transactions. Must be produced from the same source to be treated as deterministic. A browser fingerprint combines dozens of non-sensitive signals (screen resolution, timezone, language settings) into a stable hash that persists across sessions, incognito mode, and cleared storage.
A fifth field, the primary account number (PAN), is the foundation. Same PAN across all three transactions is a prerequisite, not one of the four matching elements. Tokenised PANs count if the token reference is stable across sessions.
Beyond CE 3.0: six evidence points for disputes that don't qualify
If your dispute meets the CE 3.0 criteria, the liability shift is automatic. You don't need anything beyond the four mandated data elements to win.
But not every fraud dispute qualifies for CE 3.0. The reason code might not be 10.4, you might not have two prior undisputed transactions in the 120 to 365 day window, or the data elements might not match cleanly enough. For those cases, you're back to standard representment, where the issuer does weigh the evidence and make a judgment call. These six evidence points are what make the difference in that process:
- Billing descriptor first-6 consistency. The first six characters of the billing descriptor across your transactions should be identical so the acquirer treats them as the same merchant from the cardholder's perspective. Descriptor drift between initial and recurring charges is one of the most common reasons CE 3.0 qualification fails, and it weakens standard representment too.
- Authentication record. Visa Secure or Visa Data Only attached to the transaction. In a standard representment this demonstrates the cardholder authenticated, which undercuts a fraud claim. In a CE 3.0 context it may trigger auto-qualification.
- Delivery or fulfilment confirmation. For physical goods, a tracking number and signed delivery proof. For digital goods, an IP-matched session showing access to the content. This is standard representment evidence that directly contradicts "I didn't receive this."
- Prior transaction timing pattern. A history of transactions that shows a plausible customer relationship, not two purchases clustered artificially. In standard representment, this establishes the cardholder's pattern of legitimate use.
- Session continuity signals. Evidence that the same browser session or device was used to browse, add to cart, and complete payment. This ties the transaction to a real user session rather than a single data point at checkout. Device fingerprinting built for CE 3.0 can produce this kind of session-level continuity natively.
- Merchant dispute profile. A merchant with a clean dispute history gets the benefit of the doubt in standard representment. A merchant with a long record of reversed cases faces harder scrutiny even on strong evidence.
Where each evidence point comes from
User ID and shipping address come from your order database. Billing descriptor and authentication come from your payment processor and 3DS configuration. IP address and device ID (the two that determine whether you qualify for CE 3.0) come from the checkout session, and most merchants do not capture them reliably.
Visa-mandated elements:
| Data element | Source | Usually captured at representment time? |
|---|---|---|
| PAN (prerequisite) | Order DB / payment processor | Yes |
| User ID | Order DB | Yes |
| Shipping address | Order DB | Yes |
| IP address | Checkout session | Sometimes (inconsistent) |
| Device ID | Checkout session | Rarely (needs instrumentation) |
Additional evidence points:
| Evidence point | Source | Usually captured at representment time? |
|---|---|---|
| Billing descriptor first-6 | Payment processor config | Yes |
| Authentication record | 3DS flow | Yes where 3DS active |
| Fulfilment / delivery | OMS / carrier | Yes |
| Prior transaction timing | Order DB + dispute response tool | Yes |
| Session continuity | Checkout session | Rarely (needs instrumentation) |
| Dispute profile | Acquirer | Implicit |
IP address and device ID are where most representment cases fail on the merits. They are checkout-session data, not order-database data. A server-side chargeback tool cannot reconstruct them after the fact. If the instrumentation was not present at the moment of purchase, the data is simply not there.
The browser-layer evidence requirement
Device ID and IP at CE 3.0 qualification standard mean the same device and network signature on the prior and disputed transactions. That signature is captured at checkout, in the browser, at the moment the cardholder submits payment. No post-hoc system can produce it.
cside's Chargeback Evidence product captures the browser-layer data at checkout. The device identity is stable across sessions on the same merchant, which is what allows a prior transaction from eight months ago to be matched deterministically to a disputed transaction today. The IP captured is the IP the cardholder actually used at purchase, not a later-inferred IP.
For the evidence packet as a whole, browser-layer capture closes the two mandated fields that server-side tools cannot (IP address and device ID) and strengthens delivery confirmation by tying fulfilment access to the same device. The packet presented to the issuer reads as a complete evidence chain rather than a paperwork assembly.
What this means operationally
Start by auditing whether your disputes can qualify for CE 3.0 at all. If the four mandated data elements match, the liability shift is automatic and you don't need to build a broader case. The highest-impact fix is making sure you can actually capture IP and device ID at checkout so more disputes qualify.
For disputes that fall outside CE 3.0, audit the six supporting evidence points. The cheapest fixes are billing descriptor first-6 alignment and 3DS coverage. The most impactful is browser-layer evidence capture, which gives you session-level data to support standard representment.
A thirty-minute audit:
- Pull ten recent reason code 10.4 disputes. For each, check whether you had the four Visa-mandated data elements available. How many could have qualified for CE 3.0 but didn't because IP or device ID was missing?
- For the ones that didn't qualify, check which of the six supporting evidence points you could have submitted in a standard representment. The pattern is usually clear: device ID and IP are either both missing or both low-quality, and descriptor first-6 is drifting across billing cycles.
- Compare your win rate on CE 3.0-qualified disputes (which should be close to 100%) against your standard representment win rate. The gap tells you how much revenue is at stake in the disputes CE 3.0 doesn't cover.
The Merchant Risk Council's 2025 Global Fraud and Payments Report found that the majority of surveyed merchants are now using the Compelling Evidence programme. The merchants at the top of that cohort are the ones who instrumented the browser layer, qualifying more disputes for CE 3.0 in the first place. The merchants at the bottom are missing IP and device ID, which means fewer automatic wins and weaker standard representments.
Common mistakes
The three most common CE 3.0 mistakes are descriptor drift across billing cycles, relying on server-side IP capture (which often reflects the load balancer rather than the client), and treating device fingerprints as opportunistic. Each of these can prevent a dispute from qualifying for CE 3.0 in the first place, and each weakens your position in standard representment too.
Descriptor drift. Payment processors sometimes rewrite descriptors between initial and recurring transactions, or vary them by currency. Even a one-character change in the first six breaks qualification.
Server-side IP capture. Many merchants log IP from the server receiving the checkout POST, which in modern architectures often records a load balancer or CDN edge rather than the client. The IP must be captured client-side at the browser layer to match reliably.
Opportunistic device fingerprints. A device fingerprint captured through a third-party script that happens to load on checkout is not the same as a deterministic checkout-session fingerprint. If the merchant cannot reproduce the fingerprinting logic on demand, the issuer may discount the match.
Further reading on cside
About the author
Mike Kutlu is Head of GTM at cside, where he works with Heads of Payments, Risk, and Finance on instrumenting browser-layer chargeback evidence for Compelling Evidence 3.0 representment. He writes about VAMP, friendly fraud, and the mechanics of dispute evidence for enterprise merchants.
