Visa Compelling Evidence 3.0: An Evidence-Build Guide

Direct answer

Compelling Evidence 3.0 (CE 3.0) is a Visa remedy for fighting a fraud dispute under reason code 10.4 (Other Fraud — Card-Absent Environment). Rather than arguing the disputed transaction in isolation, CE 3.0 lets a merchant submit two prior undisputed transactions from the same cardholder that share matching data elements — purchase IP, device ID/fingerprint, account/user ID, or shipping address — over a defined historical window. If the priors match the disputed transaction on the required elements, it can qualify for CE 3.0 treatment.

The operator point that gets missed: this is an evidence-readiness program, not a representment tactic. The matching data must already exist when the dispute arrives — you cannot reconstruct a device fingerprint or the purchase IP after the fact. CE 3.0 success is decided at checkout, login, and fulfilment, months before any dispute.

Visa launched CE 3.0 in April 2023; as of 17 October 2025 it added auto-qualification for transactions authenticated through Visa Secure (including Visa Data Only). Qualification is not a win — it establishes eligibility, after which Visa still reviews the evidence and the cardholder history.

What CE 3.0 is

CE 3.0 is the third iteration of Visa’s “compelling evidence” standard — the documentary proof a merchant can present to rebut a cardholder’s claim of fraud. It is narrow by design. It applies to one dispute reason code: Visa 10.4, the card-absent fraud code. (For the full Visa code map and how 10.4 sits among the fraud, authorization, processing, and consumer-dispute categories, see the Visa reason codes reference — this guide does not reproduce the code tables.)

The mechanism is comparative. A 10.4 dispute is the issuer asserting “the cardholder did not authorize this card-absent transaction.” CE 3.0 lets the merchant answer: “this cardholder has a documented history of transacting with us from the same device, IP, account, or shipping address — here are two prior transactions they did not dispute that match this one.” The argument is not “this transaction was authorized” in isolation; it is “this transaction belongs to an established, undisputed pattern.”

That makes CE 3.0 structurally different from the friendly-fraud problem it targets. When a customer who genuinely made a purchase later claims fraud to get their money back, the merchant rarely has a signed receipt or in-person proof — it was card-not-present. What the merchant does have, if it logged correctly, is the cardholder’s behavioural fingerprint across multiple legitimate prior purchases. CE 3.0 turns that history into admissible evidence. For the broader phenomenon and its non-CE-3.0 defences, see first-party and friendly fraud.

Where CE 3.0 fits in the dispute lifecycle

The single most important framing: CE 3.0 has two timelines, and only one of them is the dispute itself.

The pre-dispute timeline (where the work is). Every transaction your business processes is a potential future “prior transaction” for some later disputed one. The IP, device, account, and shipping data you capture at each checkout is the raw material CE 3.0 runs on. This is continuous, runs on 100% of traffic, and has no dispute attached to it. If this capture is incomplete, CE 3.0 is unavailable later regardless of how good your dispute team is.

The at-dispute timeline (where it gets used). When a 10.4 dispute arrives, your team (or your PSP) queries the captured history, finds two qualifying prior transactions, assembles the matching data, and submits it. This step is fast if the evidence exists and slow-to-impossible if it does not.

This is the inverse of how most merchants treat disputes. The standard mental model is reactive: a dispute lands, the team scrambles to build an evidence package. CE 3.0 breaks that model — the decisive work happened months earlier, in your logging infrastructure. The general representment lifecycle (filing, notification, response windows, pre-arbitration) is covered in chargeback representment; CE 3.0 sits upstream of all of it.

How CE 3.0 differs from normal representment

Standard representment is transaction-specific: you prove facts about the disputed transaction — delivery confirmation, IP at the time of that order, a signed terms acceptance, prior communication. The evidence is about the one transaction in dispute.

CE 3.0 is history-specific: you prove a pattern across other transactions. The disputed transaction’s own details matter less than the existence of qualifying prior transactions that match it. This is why it is an evidence-readiness program rather than an evidence-assembly one:

• Normal representment can sometimes be reconstructed after the fact — you can pull a delivery receipt or an order log when the dispute arrives.
• CE 3.0 cannot be reconstructed if the matching elements were never captured. A device fingerprint that was not recorded at the time of the prior purchase is gone. There is no retroactive capture.

The practical consequence: CE 3.0 readiness is a data-engineering and logging problem owned by product and platform teams, not a dispute-operations problem owned by the chargeback desk. The chargeback desk can only spend the evidence that the rest of the business banked.

Evidence categories operators need to capture

CE 3.0 matches on a defined set of data elements. Below is what each is and why it matters for matching. The precise required combination is set by Visa and summarized in the next section; here the focus is what to log and why.

The capture rule of thumb: log the device ID/fingerprint and purchase IP on every transaction, persist your account/user ID against every order, and keep shipping address and product description with the order record — indefinitely enough to cover the historical window. A 200-day-old transaction is only useful as CE 3.0 evidence if its matching elements are still on file.

Historical transaction evidence and matching logic

This is the part to state carefully, because the exact thresholds are set by Visa rules that evolve and are partly gated. The mechanics below are as documented by Visa’s merchant-readiness material and consistently reflected in PSP implementations (Stripe, Checkout.com) — but confirm the current numbers against the live Visa rules and your acquirer, because Visa adjusts dispute rules periodically.

As documented, CE 3.0 qualification requires:

• Count: at least two prior undisputed transactions from the same cardholder (using the same payment credential), in addition to the disputed transaction.
• Age window: those prior transactions must fall in a window of roughly 120 to 365 days older than the disputed transaction’s date. (Stripe’s implementation states 120–364 days; Visa material is cited as 120–365. The intent is “older than 120 days, within a year.” Confirm against current Visa rules.)
• Matching rule: the disputed transaction and the two prior transactions must share at least two matching data elements from the set (IP address, device ID/fingerprint, user/account ID, shipping address), and at least one of those must be the IP address or the device ID/fingerprint. Equivalently, as PSPs frame it: either two “main” elements (purchase IP + device fingerprint/ID), or one main element plus one secondary (account ID or shipping address). Note that “device fingerprint and device ID” is not treated as two distinct elements.

The matching must hold across all three transactions (the disputed one and both priors) — a match on the priors alone, or on only one prior, does not qualify. Each transaction must also be individually identifiable to the network (an ARN per transaction in the Visa-side process).

The 17 October 2025 auto-qualification update. Per Visa Business News (cited as a July 2025 bulletin, Article ID AI15461, with rollout across AP, CEMEA, Europe, LAC, Canada, and the U.S.), from 17 October 2025 Visa began automatically qualifying transactions for CE 3.0 where authentication ran through Visa Secure, including Visa Data Only. Where this applies, the authentication metadata can attach CE 3.0 eligibility to the dispute without the merchant manually assembling the two-prior-transaction packet at representment time. The exact regional rollout and acquirer support vary; treat this as a path to confirm with your acquirer, not a universal default. The primary Visa bulletin is member-gated, so the date and mechanics here are corroborated across multiple independent sources rather than quoted from Visa directly — confirm against current Visa rules.

Checkout / account / device / fulfilment logging checklist

This is PaymentBrief operator guidance — the capture work that makes CE 3.0 available later. Instrument each stage so the matching elements exist before any dispute.

At checkout (every transaction):

• Capture and persist the purchase IP address — the real client IP, resolved past any CDN/proxy (use the forwarded-for header correctly, validated against your edge).
• Capture and persist the device ID/fingerprint from your fraud/device-intelligence tool, stored against the order.
• Record the product/service description on the order, not just a SKU code.
• Store the payment credential reference and the PSP charge/transaction reference so the order is individually addressable later.

At account / login (account-based businesses):

• Bind every order to your account/user ID, and ensure that ID is stable across a customer’s lifetime (not regenerated per session).
• Persist login-time device and IP signals against the account, not just the order, so you can demonstrate continuity.

At fulfilment (physical goods):

• Record the shipping/delivery address with the order, and keep it queryable for the full historical window.
• Keep delivery confirmation with the order record (useful for the standard-representment fallback even when CE 3.0 does not apply).

Retention:

• Retain all matching elements for at least the full historical window plus dispute filing latency — practically, well beyond 365 days. A common failure is purging IP/device logs on a 90-day cycle, which silently destroys CE 3.0 eligibility.

PSP and fraud-tool coordination model

CE 3.0 evidence has to be assembled from three systems that rarely share a schema, then submitted through the dispute channel. The coordination model (PSP examples are implementation illustrations and may change — verify with your provider):

• Your platform / order system owns the account/user ID, product descriptions, shipping address, and the transaction ledger.
• Your fraud / device-intelligence tool owns the device ID/fingerprint and often the resolved purchase IP. These must be written back to the order record at transaction time — if they live only in the fraud tool’s own store, you need a join key (the charge reference) to retrieve them later.
• Your PSP / acquirer owns the dispute case and the submission path. As an implementation example, Stripe exposes a CE 3.0 flow where the merchant supplies, per prior transaction, the prior charge reference, customer_purchase_ip, customer_email_address, and product_description, plus disputed-transaction fields like customer_device_fingerprint/customer_device_id, shipping_address, and customer_account_id; Stripe then reports an eligibility status (requires_action, qualified, not_qualified). Checkout.com and other PSPs expose equivalent flows. The field names and qualification logic differ per provider — do not assume one PSP’s schema maps to another’s.

The integration requirement that falls out of this: the matching elements must be co-located or join-able at submission time. The most common architecture failure is a device ID stranded in the fraud tool with no stable key back to the PSP charge, so the dispute team can technically see the device match but cannot package it into the CE 3.0 submission.

Evidence readiness scorecard

PaymentBrief operator guidance — a self-assessment. Score each row honestly; any “No” is a gap that makes CE 3.0 partially or fully unavailable.

For a broader dispute-and-risk metric set (dispute rate, win rate, response timeliness, cost per dispute), see the chargeback operations KPIs scorecard; this readiness check is CE-3.0-specific and sits alongside it, not in place of it.

Operational workflow for dispute teams

PaymentBrief operator guidance — what to do when a 10.4 dispute arrives and CE 3.0 may apply.

1. Confirm the code is 10.4. CE 3.0 applies only to Visa reason code 10.4. If it is any other code, route to standard representment — do not waste the window attempting CE 3.0.
2. Check the auto-qualification path first. If the disputed transaction was authenticated through Visa Secure / Visa Data Only and falls in the post-17-October-2025 scope, eligibility may already attach. Confirm whether your acquirer surfaces this before assembling a manual packet.
3. Query the cardholder’s history for two prior undisputed transactions on the same payment credential, in the 120–365-day window.
4. Run the matching test. Verify the disputed transaction and both priors share at least two matching elements, including at least one of IP or device ID/fingerprint. If the match fails, CE 3.0 does not qualify — fall back to standard evidence.
5. Assemble and submit through the PSP/acquirer flow, including completeness fields (product descriptions, charge references).
6. Always attach standard evidence as a fallback. PSPs (Stripe explicitly) recommend filling the standard dispute-evidence object too, so that if the CE 3.0 submission is not approved, the dispute still goes through standard representment rather than defaulting to a loss.
7. Record the outcome against your readiness scorecard — a not_qualified result usually points to a capture gap to fix upstream, not just a lost case.

Common mistakes

• Trying to assemble CE 3.0 evidence only after the dispute arrives. The matching data must already exist. If it was not captured at transaction time, there is nothing to assemble. This is the defining mistake.
• Purging device/IP/account logs before the historical window closes. A 90-day log-retention policy silently destroys CE 3.0 eligibility for the 120–365-day window the program needs. Retention must outlast the window plus dispute latency.
• Assuming qualification equals a win. CE 3.0 qualification establishes eligibility; Visa still reviews the evidence. Stripe’s docs are explicit that the CE 3.0 status does not change the dispute status. Treat a qualified packet as a strong submission, not a settled outcome.
• Confusing CE 3.0 with general representment. They are different layers. Standard representment proves facts about the disputed transaction; CE 3.0 proves a matching history across prior transactions. Applying CE 3.0 logic to a non-10.4 code, or standard logic where CE 3.0 would qualify, both waste the response window.
• Missing the October 2025 auto-qualification path. Merchants not using Visa Secure / Visa Data Only forgo the auto-qualification route and do manual packet assembly on every case. Check whether enabling it fits your authentication strategy.
• Stranding the device fingerprint in the fraud tool. If the device ID has no stable join key back to the PSP charge, the match exists but cannot be packaged. Write it back to the order record at transaction time.

Questions to ask PSPs and fraud vendors

PaymentBrief operator guidance — questions that surface whether CE 3.0 is actually operable on your stack:

• Do you expose a CE 3.0 submission flow for Visa 10.4 disputes, and what exact fields do you require for the disputed and prior transactions?
• How do you determine and report CE 3.0 qualification status, and what does a not_qualified (or equivalent) result tell me about which criterion failed?
• Do you support the 17 October 2025 Visa Secure / Visa Data Only auto-qualification path, and in which regions / for which acquirers?
• Where is the device ID/fingerprint stored, and what is the stable key to join it back to a specific charge months later?
• What purchase IP do you record — the true client IP or an edge/proxy IP — and is it the value submitted to Visa?
• If a CE 3.0 submission is not approved, do you automatically fall through to standard representment, or does the case default to lost?
• What is your retention period for the matching data elements, and does it cover the full CE 3.0 historical window?

Be skeptical of any vendor that quotes a CE 3.0 “win rate” or “acceptance rate” as if it were a guaranteed outcome — those figures are self-reported, vary by portfolio, and qualification is not a win. Ask instead about coverage and field requirements.

Related references

• Chargeback representment for merchants — the general dispute lifecycle and at-dispute evidence mechanics CE 3.0 sits upstream of.
• Visa reason codes reference — the full Visa code map; CE 3.0 applies to 10.4.
• First-party and friendly fraud — the fraud category CE 3.0 is built to counter, and its non-CE-3.0 defences.
• Chargeback operations KPIs — the dispute-and-risk metric scorecard this readiness check complements.
• AI chargeback representment automation — how automation assembles evidence packages at scale.

Scope note

• Four layers, kept separate. (a) Visa rule/program mechanics — reason code 10.4 scope, the prior-transaction count, the historical window, the matching-element logic, and the 17 October 2025 auto-qualification change — sourced from Visa material and corroborating references. (b) PSP / fraud-vendor implementation — Stripe and Checkout.com submission flows and field names — given as implementation examples that vary by provider. (c) Merchant/operator evidence capture — the checkout/account/device/fulfilment logging. (d) PaymentBrief operator guidance — the logging checklist, readiness scorecard, dispute-team workflow, common mistakes, and vendor questions are PaymentBrief’s framing, not Visa rules.
• No outcome statistics asserted. This guide does not assert any win-rate, issuer-acceptance-rate, or liability-shift figure as fact. Vendor pages that publish such numbers are self-reported and portfolio-dependent; they are not repeated here. Qualification establishes eligibility, not a reversal.
• Effective dates sourced from Visa material. CE 3.0 launched April 2023 (effective ~15 April 2023). The 17 October 2025 auto-qualification change is attributed to Visa Business News (cited July 2025 bulletin, Article ID AI15461); the primary bulletin is member-gated, so the date and mechanics are corroborated across multiple independent sources rather than quoted from Visa directly.
• Thresholds to confirm against current Visa rules. The exact prior-transaction count, the precise age window (sources cite both 120–364 and 120–365 days), and the exact matching-element combinations are set by Visa rules that change periodically and are partly gated. Confirm the live numbers against the current Visa Core Rules / Dispute Resolution Procedures and with your acquirer before relying on them operationally.