Visa Compelling Evidence 3.0: Prepare Chargeback Evidence Before Peak

October 11, 2026 · 11 min read

Visa Compelling Evidence 3.0 (CE 3.0) lets a merchant answer a card-absent "I did not make this purchase" dispute (Visa reason code 10.4) by showing the same card was used in earlier, undisputed purchases that share identifying data, such as IP address or device ID, with the disputed one. If the data matches, liability moves back to the card issuer. If it does not match, or the data was never recorded, the dispute goes ahead as usual.

Industry summaries of Visa's rules report that from 24 October 2026 the two earlier purchases may come from one or more merchants, not only from the store defending the dispute. That lands four weeks before Black Friday. The thing to do this week has nothing to do with legal wording. Check that your store and your payment provider actually record and pass on the data CE 3.0 needs, so that friendly-fraud disputes from the peak season can be defended in December and January.

At a glance

• CE 3.0 applies to Visa disputes under reason code 10.4 (card-absent fraud). It does not cover "item not received" or "not as described" disputes.
• Qualifying prior purchases must be undisputed, use the same payment credential, and have settled 120 to 365 days before the disputed transaction.
• The matching data is IP address or device ID/fingerprint, plus customer account/login ID, delivery address or item information. Exact field rules depend on your processor.
• From 24 October 2026, industry sources report that prior purchases at other merchants can count. Whether that helps you depends on what your acquirer can see and present.
• Under Visa's monitoring programme (VAMP), early fraud warnings count against you even when no dispute follows. TC40 fraud reports that qualify for CE 3.0 are excluded from the count.
• Your evidence is only as good as your order records. A missing IP address or a guest checkout with no stable identifier usually means nothing can be matched.

Why it matters now

What CE 3.0 is. Visa introduced CE 3.0 in April 2023. According to Verifi, a Visa company, the merchant needs two prior transactions settled 120 to 365 days before the disputed one. The data must match on "IP Address or Device ID/Fingerprint" plus item information, customer account/login ID or delivery address. When it matches, "dispute liability shifts from the seller to the issuer, and the dispute is deflected." Stripe's help centre describes the same 120-to-365-day window and the same-credential rule. It also notes that submitting CE 3.0 evidence "does not guarantee an auto-win."

What changes on 24 October 2026. Several dispute-management providers (Chargeflow, Fraudbeat and others) report that for 10.4 disputes processed on or after 24 October 2026, the two prior transactions may have taken place at one or more merchants. The same card or a token linked to it must still have been used. We could not check this against Visa's own rules text when reviewing this article, so treat it as reported and confirm the details with your acquirer or payment service provider (PSP). In practice, a first-time customer who has an undisputed history with other merchants might become defensible. That only works if the data travels through the acquirer's systems.

Why the monitoring numbers matter. As of October 2026, Stripe's documentation says the Visa Acquirer Monitoring Program (VAMP) counts both disputes (TC15 reports) and early fraud warnings (TC40 reports) against all captured transactions. Outside the CEMEA region, the "Excessive" threshold is a VAMP ratio of 1.5% with at least 1,500 disputes plus fraud reports in a month. In CEMEA it is 2.2% and 150. The "Non-Compliant" level starts at a 0.5% ratio. Stripe also states that Visa excludes "TC40 fraud eligible for Compelling Evidence 3.0" from the VAMP count, along with disputes resolved through pre-dispute products. Refunds do not remove a dispute from the count, and the outcome of a dispute does not change it either. Mastercard's Excessive Chargeback Merchant level starts at 100 chargebacks and a 1.5% ratio, measured against the previous month's transactions.

The season. Peak trading brings more first-time buyers and more gift orders shipped to addresses other than the billing one. Disputes also arrive weeks after the purchase. Data you fail to capture in November cannot be recovered in January.

Step-by-step: get your store CE 3.0-ready this week

1. Find out who submits your evidence. Is it your PSP automatically (Stripe, for example, "automatically queries your past transaction history"), a dispute-management app, or your own team through a portal? Write down the name and the login.
2. Ask your PSP three questions in writing. Do you support CE 3.0 for my account? Will you apply the multi-merchant change from 24 October 2026, and does it apply at the first dispute stage, pre-arbitration, or both? Which order fields must I send you, and in which API fields?
3. Audit what your store records per order. Open five recent card orders in the admin and in the PSP dashboard. Check for customer IP address, a device identifier (if your fraud tool or PSP collects one), customer account ID or email, delivery address, and item descriptions.
4. Check that the IP address is the customer's. Behind a CDN, reverse proxy or load balancer, the stored IP is often the proxy's address. Compare a test order's stored IP with your own public IP.
5. Check that data reaches the PSP. Many integrations collect the IP at checkout but do not send it with the payment. If the PSP never receives it, it cannot match it later.
6. Keep records for at least 13 months. The lookback window reaches 365 days before the disputed transaction, and disputes arrive later still. Data-retention or GDPR-style clean-up jobs that delete IP addresses after 90 days will quietly remove your evidence. Check retention against your privacy notice with whoever owns compliance.
7. Make item descriptions readable. "SKU-88412-B" helps nobody. Use descriptions a cardholder would recognise on a statement.
8. Separate the dispute types. CE 3.0 only helps with 10.4. For "not received" disputes, the evidence that matters is tracking and delivery confirmation. Make sure tracking numbers are saved against the order.
9. Set a weekly dispute and fraud-warning review from now until the end of January (template below).

Who owns what

Risk	Owner	Check	Frequency
IP address missing or wrong (proxy IP)	Developer / agency	Test order: stored IP equals the tester's public IP	After every checkout or CDN change
Order data not sent to PSP	Developer / agency	Compare a test order in the PSP dashboard with the store admin	Monthly, and after plugin or app updates
Retention job deletes evidence	Operations + compliance	Review clean-up schedules against the 13-month need	Quarterly
CE 3.0 not enabled or not applied	Finance / payments lead	Written confirmation from PSP	Once, then at contract renewal
VAMP or Mastercard ratio rising	Finance / payments lead	Disputes + early fraud warnings / captured transactions	Weekly in peak, monthly otherwise
Card-testing spike	Developer + payments lead	Failed payment attempts per hour vs normal	Continuous alerting
"Not received" disputes	Fulfilment	Tracking number on every shipped order	Daily in peak

Copyable artefact: CE 3.0 readiness test plan

CE 3.0 READINESS TEST - store: ____________   date: __________   owner: ________

A. PROVIDER
[ ] PSP / acquirer name: ______________________
[ ] CE 3.0 supported on our account (written reply attached)
[ ] Multi-merchant change from 24 Oct 2026 applied? Stages: ________
[ ] Required fields and API names listed: _______________________
[ ] Who submits evidence: PSP auto / app / our team

B. TEST ORDER (real card, small amount, then refund)
[ ] Stored customer IP = tester's public IP
[ ] IP visible on the payment in PSP dashboard
[ ] Device ID / fingerprint present (if collected): yes / no / n.a.
[ ] Customer account ID or email stored and sent
[ ] Delivery address stored and sent
[ ] Item description readable on PSP payment record

C. RETENTION
[ ] Order + IP + device data kept >= 13 months
[ ] Clean-up jobs reviewed: ____________________
[ ] Privacy notice covers this purpose (compliance sign-off)

D. MONITORING (weekly until 31 Jan)
Week | Visa captured txns | Disputes | Early fraud warnings | Ratio | 10.4 share | Notes
     |                    |          |                      |       |            |

E. SIGN-OFF
Developer: ________  Payments/finance: ________  Date: ________

Worked scenario (illustrative)

A homeware store on WooCommerce sits behind a CDN and uses a card plugin connected to its PSP. In early October the payments lead runs the test plan above. The test order shows the CDN's IP address in the order record instead of the tester's. The fix is a server setting that reads the real client IP from the CDN's forwarded header. The developer also finds that a privacy clean-up plugin deletes customer IPs from orders after 180 days. That is shorter than the 365-day lookback.

Both issues are fixed in the first week, before the store's code freeze. The illustrative peak month brings 20,000 Visa transactions. If 120 disputes plus early fraud warnings came in, the ratio would be 0.6%: above the 0.5% "Non-Compliant" level and well below "Excessive". The weekly review shows most of them are 10.4. Repeat customers with matching IPs and delivery addresses can now be defended. Before the fixes, the same disputes could not have been, because the data simply was not there. The numbers are invented for illustration. The point is the order of work: check the data first, then rely on the rule.

Common mistakes

• Treating CE 3.0 as automatic. It only works when your PSP supports it and receives the required fields.
• Storing the proxy IP. Very common behind CDNs and hosting load balancers, and invisible until you compare.
• Refunding to "make the dispute go away". Stripe notes that monitoring programmes do not discount disputes because of refunds. Refund before a dispute is raised, not after.
• Capturing first, checking later. Stripe notes that issuers must report fraud on captured payments, even refunded ones, but not on uncaptured authorisations. Authorising, then reviewing suspicious orders before capture, keeps confirmed fraud out of the count.
• Ignoring early fraud warnings. They are not disputes, but VAMP counts them as fraud.
• Mixing up dispute types. CE 3.0 does nothing for "item not received". Tracking does.

Honest limitations. CE 3.0 does not stop disputes. It moves liability for some of them. Guest checkouts, new customers with no history, and shared or changing IP addresses (mobile networks, VPNs) often cannot be matched. The multi-merchant change depends on your acquirer's data and implementation, and acquirers may roll it out differently. None of this is legal advice. Card network rules are published by the networks and applied by your acquirer, so their written answer is the one that counts.

FAQ

Does CE 3.0 apply to Mastercard or other card networks?

No. CE 3.0 is a Visa rule for reason code 10.4. Mastercard and other networks have their own dispute and monitoring rules. Ask your PSP which evidence options apply to each network.

Do I need a device fingerprint, or is the IP address enough?

Published criteria accept IP address or device ID/fingerprint as the core element, plus a second match such as delivery address or account ID. Some processors set narrower field rules, so check yours.

Will CE 3.0 lower my VAMP ratio?

Possibly, in part. Stripe states that TC40 fraud reports eligible for CE 3.0 are excluded from the VAMP count. Ordinary disputes still count whatever their outcome, so prevention still matters most.

Sources

• Verifi (a Visa solution): Visa Compelling Evidence 3.0
• Stripe Support: How does Stripe support Visa Compelling Evidence 3.0?
• Stripe Docs: Dispute and fraud card monitoring programs
• Chargeflow: Visa Compelling Evidence 3.0 Explained (2026 Guide)
• Fraudbeat: Multi-Merchant CE 3.0

Last reviewed: 2026-10-11

For related controls, see fraud controls vs conversion, payment-to-order reconciliation and the ecommerce peak sales readiness checklist. If your store runs on WooCommerce, Pingvera can automate the card-testing row of the table above. It receives order.failed events through its WordPress connector, so a sudden burst of failed orders shows up as an alert on the same timeline as your deploys.

Read next: Ecommerce Peak Sales Readiness Checklist · Website Maintenance Onboarding Checklist · Ecommerce Replatforming Checklist · Promotion and Discount Validation Checklist · Run a free site check.