Visa Compelling Evidence 3.0: An Evidence-Build Guide

Direct answer

Compelling Evidence 3.0 (CE 3.0) is a Visa evidence route for an eligible reason-code 10.4 card-absent fraud dispute. Rather than arguing the disputed transaction in isolation, it uses two qualifying prior transactions that were not issuer-reported as fraud and share the data Visa requires over the applicable window. Meeting those conditions can qualify the case for consideration; it does not decide the outcome.

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. Its published US-region update began automatic qualification for eligible Visa Secure and Visa Data Only cases on 17 October 2025. Qualification is not a win; check the regional and acquirer workflow before using the route.

A change lands 24 October 2026 — build for it now

Everything below describes the rule as it stands today, in which the two qualifying prior transactions must be with your merchant. Visa's Core Rules (18 April 2026 edition) carry a replacement taking effect for disputes processed on or after 24 October 2026: "The same Card or a Payment Credential associated with that Card (for example: a Token) was used at one or more Merchants in 2 previous Transactions".

That widens the evidence base beyond your own transaction history. If you are specifying logging or evidence-capture work now, specify it against the wider rule — the data elements do not change, but which transactions can supply them does.

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 asserts that the cardholder did not authorize a card-absent transaction. CE 3.0 can show that the same payment credential appeared in qualifying prior transactions with the specified matching data. Those prior transactions must satisfy Visa's rule conditions, including the issuer-fraud-report condition; matching alone does not prove the disputed transaction was authorized.

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 qualifying prior transactions using the same card or associated payment credential, in addition to the disputed transaction; the issuer-fraud-report and other rule conditions apply.
• Age window: ordinarily, the prior transactions must have been processed more than 120 calendar days before dispute submission and no more than 365 calendar days before dispute processing. Visa's 120-day minimum does not apply to qualifying original credit transactions. Check the effective rule and the acquirer's case details.
• 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. Visa's public US-region merchant digest confirms automatic qualification for eligible Visa Secure and Visa Data Only cases from that date. Qualification can reduce manual assembly in an eligible acquirer flow, but it does not decide the dispute. A secondary report attributes a wider AP, CEMEA, Europe, LAC and Canada rollout to a member-gated bulletin; that regional claim is not independently established by the public Visa notice reviewed here. Confirm coverage, requirements and current fees with the acquirer before relying on it.

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 transactions in the applicable dispute-date window, on the credential required by the current rule. Check issuer fraud-report status and the original-credit exception.
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 may destroy evidence needed for the rule's older-than-120-day prior transactions. Set retention against the applicable upper bound, dispute latency and privacy requirements.
• 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, prior transactions, timing and matching, plus the published US-region 17 October 2025 auto-qualification update. (b) PSP / fraud-vendor implementation — Stripe and Checkout.com submission flows and field names, which vary by provider. (c) Merchant/operator evidence capture — checkout/account/device/fulfilment logging. (d) PaymentBrief operator guidance — the checklist, scorecard, workflow and vendor questions are our 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-date scope. CE 3.0 launched in April 2023. Visa's public US-region merchant digest confirms the 17 October 2025 auto-qualification date for eligible cases; claims of a wider rollout come from secondary reporting of a member-gated bulletin and require acquirer confirmation.
• Thresholds to confirm against current Visa rules. The public 18 April 2026 Visa Core Rules specify two prior transactions, an ordinary minimum of more than 120 days before dispute submission, a 365-day upper bound measured to dispute processing, and an original-credit exception to the minimum. Confirm the applicable edition, matching elements and acquirer process before relying on them operationally.