Visa CE 3.0 Evidence Readiness Guide for Merchants
Last updated: October 29, 2026. Companion to the Visa CE 3.0 Evidence Readiness Checker. This guide is written for merchants — it audits what a seller captures — and is deliberately different from the site's consumer-side Visa fraud dispute checker, which answers a cardholder's question.
Visa Compelling Evidence 3.0 (CE 3.0) is the structured defence for one narrow dispute type: Visa Dispute Condition 10.4, Other Fraud in a card-absent environment — the "I did not authorise this" claim on an online order. When the test is met, liability can shift to the issuer. When any part of it fails, the defence is not available for that dispute, and — because a CE 3.0 submission may be attempted only once per dispute — a rushed, incomplete packet burns the remedy for good. That is why readiness is a checkout problem, not a dispute-desk problem: data never logged at checkout cannot be reconstructed after the claim lands.
CE 3.0 does not cover delivery, cancellation, product-quality or processing-error disputes. If the claim is not a 10.4 card-absent fraud claim, stop here and build standard representment evidence for the actual reason code.
2. Two prior transactions, inside the window, never reported as fraud
You need at least two earlier transactions on the same card — or, for disputes processed on or after October 24, 2026, on a credential associated with that card, such as a token — each processed more than 120 and no more than 365 calendar days before dispute processing, and none reported as fraud by an issuer. Keep at least 365 days of order history; a shorter retention policy deletes usable evidence. Note the processor variant: Stripe states its field window as 120–364 days. Follow your processor's field checks when it submits for you, and ask it which window it enforces.
3. The matching pair — and the device trap
At least two elements must match across the disputed transaction and both priors, and one of them must be the IP address or the device ID/fingerprint. The eligible elements are the IP address, device ID/fingerprint, account/login ID and full delivery address. The trap, tightened on October 24, 2026: device ID and device fingerprint count as similar elements — one category, not two. A packet resting on device ID plus device fingerprint alone fails the two-element test. Pair the device or IP match with a login ID or a full delivery address instead. For digital goods with no delivery address, the realistic pair is IP/device plus login ID — which is why guest checkout with no stable login identifier is a CE 3.0 gap worth fixing before peak.
4. Format minima: clear text, lengths, properties
The IP address must be in clear text in a readable format — the real customer IP, not your server or load-balancer IP. The device ID must be at least 15 characters in clear text. The device fingerprint must be at least 20 characters and derived from at least two device or software properties, such as browser and operating-system versions. Login IDs and delivery addresses are likewise in clear text. Only the fingerprint may be hashed. A short device ID, a single-property fingerprint or a hashed IP is not a near-miss; it fails that element outright.
5. Record linkage: order number or purchase-order alternative
The submission needs a detailed description of the goods or services, or — for certain authenticated or tokenized e-commerce transactions — a qualifying purchase-order-number alternative. In practice, record an order number for every transaction and keep it linked to the IP, device, login and address fields above, so the three transactions in a packet can actually be tied together. Confirm with your acquirer whether your authenticated/tokenized flows qualify for the purchase-order alternative; do not assume they do.
6. The same-acquirer constraint — the October 24, 2026 limit
From October 24, 2026, qualifying history may come from one or more merchants, and Chile is excluded from this expanded invalid-dispute rule. That expansion tempts a misreading: that any prior purchase anywhere now defends your dispute. It does not. At pre-arbitration, an acquirer may submit only transaction data it accepted and processed. So multi-merchant priors help you only where your own acquirer processed them. A first purchase at your store can qualify under the expanded route — but only if the card has qualifying history your acquirer can actually submit. The pre-dispute route carries no equivalent footnote in the public rules summaries, so its multi-merchant assembly is unsettled: ask your acquirer, in writing, whether it can submit multi-merchant priors on your account, through which channel, and whether a pre-dispute route is active on your account.
7. One submission — then it is gone
Visa's acquirer readiness guidance is explicit: "You will only be able to attempt submission of these criteria once. Carefully compile your response before submission. If acquirers attempt responses that are incorrect or incomplete, they will be declined." Treat every CE 3.0 filing as final. Re-run the readiness checker on the actual three transactions before filing, keep the formal dispute deadline while your acquirer checks eligibility, and if the packet is short, choose standard representment or a refund decision instead of spending the one attempt.
What this guide deliberately does not claim
No fee amount for CE 3.0 qualification or submission is stated here: published fee reports vary and the binding figure sits in your merchant agreement. No win rate is stated: a readiness pass is not a forecast for any single dispute. No descriptor-match rule is asserted: first-six-characters claims appear in vendor copy only and were not verified against a processor source. And no pre-dispute multi-merchant route is asserted as settled — it is flagged above as a question for your acquirer.
Checker questions
Each prior transaction must be more than 120 and no more than 365 calendar days before dispute processing, and must not have been reported as fraud. Stripe states its own field window as 120–364 days, so confirm which window your processor enforces.
Visa requires the IP address in clear text in a readable format, and the device ID in clear text; only the device fingerprint may be hashed. A hashed or truncated IP cannot be matched as required.
Ask in writing whether it can submit multi-merchant priors on your account and through which channel, and whether a pre-dispute route is active. At pre-arbitration an acquirer may submit only data it accepted and processed.
Sources (checked October 29, 2026): Stripe — Visa Compelling Evidence 3.0 disputes documentation; Chargeflow — Visa Compelling Evidence 3.0 (CE3.0): Rules and 2026 Changes, citing Visa Core Rules April 18, 2026, sections 11.7.5.3 (Table 11-28) and 11.7.5.6 (Table 11-31); Visa — Compelling Evidence 3.0 Acquirer Readiness (visa.com PDF); Pulse CRM — Visa's Compelling Evidence 3.0 Changes on 24 October; Checkout.com — Visa Compelling Evidence 3.0 Overview. Visa's rulebooks are not public; confirm your position and route with your acquirer.
General information only — not legal or financial advice. CE 3.0 eligibility depends on your acquirer's submission route and Visa's validation, which no guide or checker can see.
Chargeback Clock