When those conditions are met, Visa treats the dispute as invalid and liability moves back to the issuer. That makes Compelling Evidence 3.0, often shortened to CE 3.0, one of the strongest tools against first party misuse, the situation where a real cardholder makes a purchase and later reports it as fraud. This article explains each requirement, the data you need to store, and how qualification works before and after a dispute is filed.
What Visa Compelling Evidence 3.0 is
Visa introduced Compelling Evidence 3.0 in April 2023 as an update to its dispute rules for reason code 10.4, Other Fraud in a card absent environment. Earlier versions of compelling evidence let merchants argue that the cardholder made the purchase, but the outcome depended on how each issuer weighed the documents. CE 3.0 replaced that judgment with a defined test. If your data passes the test, the issuer cannot hold you liable for that fraud claim.
The test rests on a simple idea. If the same card was used with you before, by the same person, on the same device or from the same network, and the cardholder never disputed those earlier purchases, then the new purchase is very likely genuine too.
The Compelling Evidence 3.0 requirements one by one
- 1 The dispute is a Visa dispute under reason code 10.4, Other Fraud, card absent environment.
- 2 You can identify at least two prior transactions on the same payment credential with the same merchant.
- 3 Those prior transactions took place between 120 and 365 days before the disputed transaction.
- 4 Neither prior transaction was reported as fraud or disputed by the cardholder.
- 5 Each prior transaction shares at least two data elements with the disputed transaction from the list of qualifying elements.
- 6 At least one of the matching elements is the IP address or the device ID or fingerprint.
- 7 You describe the goods or services in the disputed transaction.
If any condition fails, the dispute does not qualify for CE 3.0. You can still respond with traditional evidence, but the automatic liability shift does not apply.
Qualifying data elements
Visa defines four data elements that can match. You need two matches per prior transaction, and one of them must come from the first two rows of the table.
| Data element | What to store | Counts toward the IP or device rule |
|---|---|---|
| IP address | The public IP address used when the order was placed | Yes |
| Device ID or fingerprint | A stable identifier of the device used at checkout | Yes |
| Shipping address | The full delivery address for physical goods | No |
| Customer account or login ID | The user ID or account the order was placed under | No |
For example, a disputed order and two older orders that all come from the same customer account and the same device qualify, as long as the timing and history conditions are met. Two orders that only share a shipping address and an account ID do not qualify, because neither is an IP address or a device ID.
Common reasons merchants fail to qualify
-
The IP address or device ID was never stored at checkout, so the most important match cannot be proven.
-
Prior orders are too recent. A loyal customer who buys every month has many orders inside the last 120 days, and those do not count.
-
Prior orders are too old or the customer is new, so there is no history in the 120 to 365 day window.
-
The earlier orders were made with a different card or a reissued card number.
-
One of the earlier orders was itself disputed or reported as fraud.
-
Data was stored in a different format for older orders, so values do not match exactly.
How CE 3.0 qualification works before a dispute
The best outcome is a dispute that never gets filed. Through Verifi Order Insight, an issuer can request your transaction data when a cardholder calls about a charge. If your data for that transaction and the prior transactions satisfies CE 3.0, the issuer is told the transaction qualifies and the dispute is blocked before it is created. That protects you from the chargeback and keeps the case out of your dispute count.
To use this path, your order data has to be available to Order Insight in a structured form, either through your processor or through a provider that connects to Verifi. Our Compelling Evidence 3.0 page explains how NoChargeback prepares that data from your processor records.
How CE 3.0 works after a dispute is filed
If a 10.4 dispute is filed anyway, you can submit CE 3.0 data in your dispute response. Your processor forwards the matching prior transactions and their data elements. When the data qualifies, the liability shifts back to the issuer. If the issuer disagrees with the qualification, the case can continue to pre-arbitration, where the strength of your data again decides the outcome.
Keep the response focused on the matching data. Show the disputed transaction and the two prior transactions in a simple table with the date, the amount, the IP address, the device ID, the account ID and the shipping address, and mark which elements match. A clear chargeback rebuttal letter template helps you present that table in the order reviewers expect.
What data to store from day one
CE 3.0 can only work with data you captured at the time of each order. You cannot reconstruct an IP address a year later. Build these fields into your checkout and order records now, even if you have no disputes today.
-
The public IP address of the buyer for every order, stored with the order.
-
A device ID or fingerprint from your checkout, stored in a consistent format.
-
The customer account or login ID for every order placed while logged in.
-
The full shipping address as entered, for physical goods.
-
The card fingerprint or token your processor provides, so you can find earlier orders on the same card.
-
The dispute and fraud report history per transaction, so you can exclude disputed orders from the prior set.
For subscription and SaaS merchants, every renewal is a transaction on the same card with the same account. If you store the IP and device data for logins near each renewal, long time customers often qualify automatically when they file a fraud claim on a later charge.
How to check qualification step by step
- 1 Confirm the dispute is Visa, card not present, reason code 10.4.
- 2 Find the card fingerprint or token of the disputed transaction in your processor data.
- 3 List every earlier transaction on that card with your business.
- 4 Keep only the ones dated 120 to 365 days before the disputed transaction.
- 5 Remove any that were disputed or reported as fraud.
- 6 For each remaining transaction, compare the IP address, device ID, shipping address and account ID with the disputed one.
- 7 Keep the transactions with at least two matches, at least one of them IP or device.
- 8 If two or more remain, the dispute qualifies. Prepare the package with those transactions and the matching elements.
Doing this by hand takes a long time when a customer has many orders. It is a good candidate for automation, because the rules are exact and the data is already in your systems.
Data quality matters as much as data volume
A match requires the values to be the same. Store IP addresses in one consistent format, trim spaces from account IDs and normalize shipping addresses before you save them, for example by using the same abbreviations for street types. Keep the device ID from the same checkout component over time. If you change the device detection method, earlier orders may stop matching newer ones, so plan the change and keep both values during a transition.
Be careful with IP addresses from mobile networks and corporate networks, which change often or are shared by many users. They still count when they match, but a device ID or an account login is usually the more stable second element.
Who benefits most from CE 3.0
Merchants with repeat customers gain the most: subscriptions, marketplaces, games, digital content and any store with accounts and reorders. One time sellers with no repeat purchases rarely have prior transactions in the window, so they rely more on 3D Secure and alerts. In every case, CE 3.0 addresses first party misuse, not true fraud with a stolen card, because a criminal using a stolen card will rarely share the real cardholder's device and account history.
What about Mastercard and other networks
CE 3.0 is a Visa rule. Mastercard handles similar cases through its own dispute rules and through programs run with Ethoca that focus on first party trust, so the same stored data, such as IP address, device ID and account history, also helps on Mastercard disputes under reason codes such as 4837. For American Express and Discover, the same evidence supports a response but there is no equivalent automatic liability shift. Check the reason codes library for the evidence each network expects.
Putting CE 3.0 into your dispute process
Treat CE 3.0 as part of a wider chargeback prevention setup. Store the data at checkout, share it through Order Insight so qualifying disputes are blocked early, and when a 10.4 dispute arrives, check qualification automatically before you write anything. If the dispute qualifies, submit the CE 3.0 package. If it does not, fall back to 3D Secure results, AVS and CVV matches and account activity.
Check whether a fraud dispute qualifies
Choose Visa 10.4, enter the amount and tick the data you stored. NoChargeback shows what is missing for CE 3.0 and drafts the opening of your response.
Which reason code does Compelling Evidence 3.0 cover?
It covers Visa reason code 10.4, Other Fraud in a card absent environment. Other Visa reason codes and other networks follow their own evidence rules.
How old must the prior transactions be?
The two prior transactions must be between 120 and 365 days before the disputed transaction, and neither can have been disputed or reported as fraud.
Is a matching shipping address enough?
No. You need at least two matching data elements per prior transaction, and one of them must be the IP address or the device ID. A shipping address and an account ID alone do not qualify.
Can CE 3.0 stop a dispute before it is filed?
Yes. Through Verifi Order Insight, the issuer can see that a transaction qualifies and block the dispute before it is created.