Visa Compelling Evidence 3.0 in 2026: How High-Risk Merchants Must Redesign Their Transaction Data Architecture to Win Fraud Disputes

For most of the past decade, friendly fraud sat in a grey zone. Cardholders disputed legitimate transactions, merchants absorbed the cost, and the chargeback ratio stayed just manageable enough to avoid triggering acquirer monitoring programmes. It was an operational nuisance, expensive, frustrating, but survivable.

That calculus has changed in 2026. Visa’s VAMP thresholds are tightening. Acquirers are under portfolio-level scrutiny. High-risk merchants operating near the tolerance ceiling are facing reserve increases, payout delays, and in some cases, direct offboarding conversations. The margin for error has narrowed to a point where a sustained spike in dispute rates is no longer a revenue problem; it is an existential threat to the acquiring relationship itself.

Visa Compelling Evidence 3.0 (CE3.0) is the most powerful tool available to card-not-present merchants for fighting back against fraudulent dispute claims. But it is not a policy update to note and move on from. For high-risk merchants, CE3.0 is an architectural requirement. Using it consistently and at scale demands a fundamental rethink of how transaction data is captured at checkout, stored in your systems, and retrieved in real time when a dispute arrives. Merchants who have not made those changes are leaving their most effective defence unused not because they chose not to use it, but because their data infrastructure does not support it.

What CE3.0 Actually Does And What It Doesn’t

CE3.0 applies specifically to Visa chargeback Reason Code 10.4 Fraud: Card-Absent Environment. This is the code used when a cardholder claims they did not authorise a transaction. It is the dominant dispute code in digital commerce and the primary vector for friendly fraud.

CE3.0 does not apply to Reason Code 13.2 (cancelled recurring transaction), 13.3 (not as described), or other common dispute categories. Understanding this scope is important because CE3.0 is a targeted tool, not a universal chargeback defence.

The mechanism is straightforward in principle: if a merchant can demonstrate that the cardholder has previously completed two undisputed, non-fraudulent transactions with the same business, the current dispute becomes very difficult for the issuer to sustain. Liability shifts to the issuer. The chargeback is reversed. Critically, the merchant’s fraud ratio is protected though the dispute ratio may still register the event.

The Historical Footprint Explained

The two qualifying historical transactions must meet precise criteria:

• They must be dated between 120 and 365 days before the disputed transaction
• They must both be undisputed and not reported as fraudulent (no active TC40 flags)
• Across all three transactions the two historical and the one disputed at least two data elements must match:
  • Customer account or login ID
  • Delivery or shipping address
  • Device ID or device fingerprint
  • IP address
• At least one of those two matching elements must be the IP address or device ID/fingerprint account ID and delivery address alone are not sufficient

If those criteria are met, the evidence qualifies and the liability shifts. If they are not met because the data was not captured, was captured inconsistently, or cannot be retrieved fast enough the merchant has no CE3.0 defence and the dispute proceeds on standard terms.

The 2025–2026 Rule Changes That Raise the Stakes

CE3.0 launched in April 2023, but two developments in late 2025 and early 2026 have significantly changed its importance for high-risk merchants.

From October 17, 2025, Visa began automatically qualifying transactions processed through Visa Secure (3DS) and Visa Data Only for CE3.0 across all major regions.

Merchants on 3DS-authenticated checkout flows now have their transactions pre-qualifying for CE3.0 matching a structural advantage over merchants still running unauthenticated card-not-present flows.

From April 2026, CE3.0 is being extended to apply to non-disputed TC40 fraud reports. This is a significant shift. TC40 reports are internal fraud flags raised by issuing banks that damage a merchant’s fraud ratio without any formal dispute being filed. Until now, merchants had no mechanism to challenge them. From April 2026, CE3.0 qualifying evidence can be used to neutralise TC40 flags before they accumulate and push the merchant toward VAMP monitoring thresholds.

Why the TC40 Extension Changes the Game for High-Risk Merchants

High-risk verticals gaming, subscriptions, digital goods and adult content accumulate TC40 reports at rates that bear no relationship to the volume of actual disputed transactions. A cardholder who regrets a purchase and calls their bank to flag it as suspicious generates a TC40 without ever filing a formal chargeback. These silent fraud flags have been one of the most damaging and least visible threats to a high-risk merchant’s compliance standing.

The April 2026 extension means a merchant with clean CE3.0 data can proactively defend against these flags reducing fraud ratio inflation that would otherwise push them toward VAMP penalties or acquirer review.

On the threshold side, Visa’s VAMP excessive classification is dropping from 2.2% to 1.5% in key regions from April 2026, with the standard threshold sitting at 0.9%. VAMP fees are now fully live; merchants at above-standard classification face $4 per transaction penalties at the acquirer portfolio level. Acquirers are actively managing their portfolios in response, which means high-risk merchants generating outsized VAMP exposure are facing conversations about reserves, fees, or termination.

The Data Architecture Gap Most High-Risk Merchants Have

CE3.0 requires four specific data elements to be captured at every transaction. The uncomfortable reality is that only 31% of merchants currently use device-based fraud detection tools which means the majority of businesses processing card-not-present transactions are not capturing the most critical CE3.0 data element at all.

The gaps are predictable and consistent across high-risk merchant profiles:

Guest checkout flows do not generate a persistent customer account ID. When a cardholder completes a transaction without creating an account, there is no login ID to match across historical transactions. This removes one of the four available data elements from the CE3.0 evidence set entirely.

VPN and privacy browser adoption has made IP address matching increasingly unreliable. A cardholder who uses a VPN for one transaction and their home network for another will present different IP addresses even though both transactions are genuine. IP addresses must still be captured and submitted, but merchants relying on IP matching alone as their primary CE3.0 signal will find their evidence quality degrading over time.

Billing descriptor inconsistency is a structural failure point that many merchants do not identify until they attempt CE3.0 for the first time. Visa uses billing descriptor matching to build the historical footprint to confirm that the historical transactions belong to the same merchant. If the first six characters of the billing descriptor vary across transactions because of a platform migration, a white-label arrangement, or inconsistent configuration Visa cannot match the records and the CE3.0 qualification fails.

The two-second constraint on Order Insight pre-dispute responses makes manual review structurally impossible at any meaningful transaction volume. When a pre-dispute inquiry arrives through Verifi’s Order Insight system, the merchant’s system must return qualifying CE3.0 evidence within two seconds. Any merchant attempting to handle this through a manual review process is operationally unequipped to use CE3.0 for pre-dispute deflection.

The Four CE3.0 Data Elements Every Transaction Must Capture

1. Device ID or device fingerprint: strongest and most stable signal
2. IP address: required; must be raw, per-transaction, not aggregated
3. Customer account or login ID: requires enforced account identification at checkout
4. Delivery or shipping address: stored at transaction record level, not order level only

Redesigning the Data Capture Layer

The data capture layer is where CE3.0 readiness is won or lost. The changes required are specific and non-negotiable.

Device fingerprinting is the most critical investment. A device fingerprint is generated from dozens of browser and device-level variables screen resolution, installed fonts, browser version, hardware configuration, timezone producing a highly unique and persistent identifier that remains stable across sessions, even when IP addresses change.

Device Fingerprint vs. IP Address: Why Fingerprinting Is Non-Negotiable

IP addresses are dynamic. They change when a user switches from home WiFi to mobile data, connects via a corporate VPN, or uses a privacy browser. For CE3.0 matching across transactions spanning 120–365 days, IP address consistency cannot be assumed.

A merchant relying solely on IP matching for their CE3.0 qualifying element will fail an increasing proportion of dispute cases as VPN adoption grows.

Device fingerprints are stable. The same device, used by the same cardholder across multiple transactions over a 12-month period, will produce a consistent fingerprint hash even if the IP address changes every session. This makes device fingerprinting the most reliable primary CE3.0 matching element, and Visa’s framework effectively treats it as such by requiring that at least one of the two matching data elements be either IP address or device ID/fingerprint.

Both must still be captured per transaction. The practical implication is that fingerprinting scripts must be implemented client-side, firing on page load not at payment submission. The data must exist at the moment the transaction is processed, not reconstructed retrospectively. Tools such as dedicated fingerprinting libraries or the device intelligence capabilities built into platforms like Kount, SEON, and Riskified can serve this function.

For merchants who have not yet implemented device fingerprinting, this is the single highest-priority architecture change for CE3.0 readiness.

Redesigning the Data Storage and Retrieval Layer

Capturing the right data at checkout solves half the problem. The other half is ensuring that data is stored in a structure that supports sub-two-second retrieval when a dispute or pre-dispute inquiry arrives.

What a CE3.0-Ready Transaction Record Looks Like

Every transaction record must contain and index the following fields:

Field	Requirement
Device fingerprint hash	Captured client-side at page load
Raw IP address	Per-transaction, not session-aggregated
Customer account / login ID	Linked to payment credential
Delivery / shipping address	Stored at transaction level
Card BIN + last 4 digits	For credential-based historical matching
Acquirer Reference Number (ARN)	Unique per transaction, mandatory
Transaction timestamp	For 120–365 day lookback calculation
Billing descriptor	Must match exactly with historical transactions
Dispute / fraud flag status	To confirm transaction is undisputed and clean

The ARN requirement deserves particular attention. Without a unique ARN per transaction, Visa cannot locate historical records within its systems. Merchants processing through platforms that reuse or omit ARNs are structurally unable to build a verifiable historical footprint.

Retention policy: Transaction data must be retained for a minimum of 13–15 months. The CE3.0 lookback window is 365 days from the disputed transaction date, plus the time required for dispute processing. Any data purged before that window closes cannot be used as evidence.

Query optimisation: When an Order Insight pre-dispute inquiry arrives, the merchant’s system needs to identify the two best-qualifying historical transactions from potentially thousands of records and return them within two seconds. This requires indexed storage, with card credential and device fingerprint as primary query keys. A transaction database optimised for order management is not necessarily optimised for this retrieval pattern. Systems architecture teams should review and test query performance specifically against CE3.0 retrieval requirements.

Billing Descriptor Discipline and Merchant Matching

This is the CE3.0 failure point that receives the least attention and causes the most silent failures.

Visa’s merchant matching logic works by identifying transactions that share a consistent billing descriptor. If the first six characters of the descriptor vary across transactions even by a single character difference in capitalisation or spacing Visa cannot confirm that the historical transactions belong to the same merchant. The historical footprint breaks. The CE3.0 qualification fails.

Common failure points include merchants operating across multiple brands with separate descriptor conventions, businesses that migrated payment platforms and adopted a new descriptor format mid-history, and white-label or marketplace arrangements where the platform applies a dynamic or variable descriptor.

The fix is procedural but requires cross-functional enforcement: audit every billing descriptor format across every acquirer, payment method, and processing platform. Establish a single standard where the first six characters are fixed and identical. Treat any deviation as a compliance defect, not a formatting preference.

Pre-Dispute Deflection via Order Insight

The highest-value application of CE3.0 is not post-dispute representation; it is pre-dispute deflection through Verifi’s Order Insight system.

When a cardholder contacts their issuing bank to dispute a transaction, the issuer queries Order Insight before formally filing the chargeback. If the merchant can respond with qualifying CE3.0 evidence within two seconds, the dispute is deflected; it never becomes a formal chargeback. Neither the merchant’s fraud ratio nor their dispute ratio is affected. The chargeback fee is avoided. The VAMP impact is zero.

This is the outcome CE3.0 was designed to produce at scale. But it requires a live, automated API integration between the merchant’s transaction data store and the Order Insight system. Visa pre-selects between two and five candidate historical transactions from the merchant’s record; the merchant’s system must confirm the qualifying match and return the evidence within the response window.

For high-risk merchants processing hundreds or thousands of transactions daily, Order Insight integration is not an optional enhancement. It is the mechanism that makes CE3.0 operationally viable at volume. Each successful pre-dispute deflection avoids a chargeback fee, protects both fraud and dispute ratios, and reduces the cumulative VAMP exposure that determines the health of the acquirer relationship.

Conclusion

CE3.0 is the most effective dispute defence tool available to card-not-present merchants in 2026 but only for merchants whose transaction data infrastructure is built to deploy it. For the majority of high-risk businesses operating today, the gap between the tool’s potential and their actual readiness is significant.

The architecture changes required are well-defined: client-side device fingerprinting implemented at page load, per-transaction storage of all four CE3.0 data elements, indexed and query-optimised retrieval systems, consistent billing descriptor enforcement, and automated Order Insight integration capable of responding in under two seconds. None of these are technically exotic but each requires deliberate prioritisation, cross-functional ownership, and testing against the specific retrieval patterns CE3.0 demands.

With VAMP thresholds tightening from April 2026, acquirers actively managing their portfolio exposure, and CE3.0 now extending to TC40 fraud reports, the cost of remaining CE3.0-unready has never been higher. This is no longer a fraud team problem. It is a business continuity issue that sits on the desk of every Head of Payments, Risk Director, and CFO operating in card-not-present commerce.

Payment Mentors works with high-risk merchants to assess CE3.0 readiness, identify data gaps across the capture, storage, and retrieval layers, and build the operational architecture required to win disputes systematically not case by case, and not after the acquiring relationship is already at risk.

---

FAQs