Compelling Evidence 3.0 for Visa Disputes: Which Prior-Transaction Data Wins a Friendly-Fraud Case and How to Collect It

Friendly fraud often occurs when a cardholder disputes a transaction they actually participated in, authorized, or benefited from. For ecommerce merchants, subscription businesses, digital-service providers, and other card-not-present sellers, the difficult part is proving that connection after the cardholder tells an issuer that the transaction was unauthorized.

Visa Compelling Evidence 3.0 gives eligible merchants a structured way to use historical transaction data to establish a stronger relationship between the cardholder and a disputed purchase. 

Rather than relying only on a delivery receipt, customer-service conversation, or screenshot, CE 3.0 looks for specific connections between the disputed transaction and qualifying historical transactions.

Visa’s published merchant guidance identifies CE 3.0 as a remedy associated with Dispute Condition 10.4, Other Fraud—Card-Absent Environment. The framework is designed to address first-party misuse in which an authorized card-not-present transaction is subsequently reported as fraudulent.

That makes CE 3.0 potentially valuable, but its scope is deliberately narrow. It is not a universal chargeback defense, does not automatically classify every disputed purchase as friendly fraud, and does not replace authentication, fraud screening, good fulfillment practices, or responsive customer service.

The most important operational lesson is simple:

A merchant cannot create strong CE 3.0 evidence after the dispute if the qualifying transaction data was never captured and retained in the first place.

A useful way to think about the process is:

Customer Transaction → Capture Identity/Device/Payment Signals → Store Transaction History → Prior Successful Transactions → New Disputed Transaction → CE 3.0 Eligibility Check → Evidence Submission → Visa Dispute Outcome

Merchants therefore need to treat Compelling Evidence 3.0 for Visa disputes as both a dispute-management process and a data-readiness problem.

What Is Visa Compelling Evidence 3.0?

Visa Compelling Evidence 3.0 is a Visa-specific dispute remedy designed to help address certain card-not-present fraud disputes that may involve first-party misuse. 

Visa’s merchant FAQ describes the underlying situation as a cardholder reporting fraud on an authorized transaction and explains that the remedy applies to Visa Dispute Condition 10.4 when qualifying evidence demonstrates participation by the cardholder or an authorized person.

Traditional representment often asks the merchant to assemble evidence after receiving a chargeback. That package could include order records, proof of delivery, customer correspondence, product-use evidence, refund policies, or other information relevant to the particular dispute condition.

CE 3.0 is different because it relies on a structured historical relationship.

The merchant is effectively showing that the disputed transaction shares Visa-defined characteristics with qualifying earlier transactions connected to the same merchant-cardholder relationship. When the specific remedy criteria are satisfied, Visa’s rules can shift responsibility for the qualifying dispute.

Visa’s official merchant resource library continues to identify CE 3.0 as part of its dispute-management resources and describes it as an update to Dispute Condition Code 10.4. Merchants seeking primary documentation should start with the Visa Merchant Resource Library rather than treating third-party summaries as the controlling rules.

CE 3.0 also should not be confused with every other Visa dispute or pre-dispute product. Visa Resolve Online, Order Insight, Rapid Dispute Resolution, Visa Secure, and CE 3.0 can interact with dispute-management processes, but they perform different functions.

What Type of Dispute Does CE 3.0 Address?

Visa’s published guidance ties Compelling Evidence 3.0 to Dispute Condition 10.4 — Other Fraud: Card-Absent Environment. The merchant FAQ states that the remedy was designed for cases in which cardholders report fraud on card-not-present transactions and qualifying evidence supports that the cardholder or an authorized person participated in the transaction.

That distinction matters because merchants frequently use the term “friendly fraud” for many different complaints.

CE 3.0 does not automatically apply simply because the merchant thinks the customer is wrong. A dispute categorized as merchandise not received, merchandise or services not as described, canceled recurring transaction, credit not processed, or another non-10.4 condition must be handled according to the rules governing that actual dispute.

For example, a subscriber may tell the issuer, “I canceled two months ago, but they billed me again.” That case may be fundamentally different from a cardholder saying, “I never made this purchase.”

Visa itself notes that subscription disputes are often categorized as canceled recurring rather than 10.4.

Likewise, proof that a package was delivered does not transform a service, fulfillment, or non-receipt dispute into a CE 3.0 case.

Merchants should therefore begin every chargeback review by answering three questions:

1. What Visa dispute condition was actually submitted?
2. Does the transaction qualify for the CE 3.0 remedy under current Visa rules?
3. Does the merchant have the required qualifying historical transactions and matching data?

The Visa Resolve Online overview identifies VROL as Visa’s end-to-end dispute-processing environment and separately describes CE 3.0 functionality for acquirers.

Friendly Fraud vs. True Fraud

“Friendly fraud” is an industry expression, not proof of customer misconduct. Some cardholders genuinely forget a purchase or do not recognize a descriptor; others may have had their accounts compromised, and still others may knowingly dispute transactions they made.

A responsible dispute process evaluates evidence rather than assuming intent.

Scenario	Possible Classification	CE 3.0 Relevance
Stolen card used by a criminal	True third-party fraud	Historical matches should not be treated as proof that the cardholder made the new purchase
Cardholder forgets a purchase	Possible first-party misuse or transaction confusion	Potentially relevant if the dispute is eligible and CE 3.0 criteria are satisfied
Family member uses a shared account or authorized device	Depends on authorization and facts	Potentially relevant, but merchants should not assume who personally performed the transaction
Customer disputes after receiving goods	Could be first-party misuse, service disagreement, or another dispute type	Relevant only if the actual dispute condition and CE 3.0 requirements qualify
Subscription renewal not recognized	Could be confusion, first-party misuse, account takeover, or cancellation issue	Potentially relevant under 10.4; not automatically applicable to canceled-recurring disputes

Merchants should also distinguish first-party misuse from account takeover. A criminal who gains access to a legitimate shopper’s account may create transaction data that resembles earlier activity. A matching account ID or IP address does not, by itself, establish that the cardholder personally authorized the purchase.

Fraud prevention therefore remains necessary even when CE 3.0 data is available. Resources on ecommerce authentication, EMV 3DS, and network tokenization provide useful additional context on reducing card-not-present risk before a transaction becomes a dispute.

How CE 3.0 Uses Prior Transactions

CE 3.0 works by using qualifying historical transactions to establish a merchant-cardholder history. Visa’s merchant guidance states that two qualifying historical transactions are needed under the standard CE 3.0 criteria and that they generally must fall between 120 and 365 days before the dispute processing date.

The age requirement is significant.

A transaction from two weeks before the dispute cannot simply replace a transaction inside Visa’s prescribed historical window. Likewise, a transaction older than the applicable window does not become qualifying merely because it looks highly similar.

Visa’s guidance includes a specialized exception involving disputed Account Funding Transactions and associated Original Credit Transactions, so merchants operating in that area should obtain current implementation details directly from their acquirer rather than generalizing the normal ecommerce rule.

Which Prior Transactions Qualify?

The prior transactions used for CE 3.0 must meet Visa’s remedy criteria and establish the required historical relationship.

Visa’s merchant FAQ states that historical transactions cannot have fraud activity. Importantly, the same FAQ says that a prior non-fraud dispute does not necessarily disqualify a transaction; it specifically explains that only prior transactions with fraud activity are excluded under the described criteria.

This is more precise than saying every historical transaction must simply be “never disputed.”

For operational purposes, merchants should maintain at least these statuses for historical transactions:

• authorization outcome;
• settlement/transaction reference;
• refund or reversal status;
• fraud-notification status;
• dispute status;
• dispute category where known;
• account/payment relationship;
• transaction date;
• CE 3.0 matching identifiers.

If a historical transaction was refunded, reversed, canceled, or otherwise altered, do not assume its CE 3.0 treatment. Have the acquirer or dispute provider evaluate the actual transaction record against current Visa rules.

How Far Back Can Prior Transactions Be?

Visa’s published standard merchant criteria identify two transactions occurring 120–365 days before the dispute processing date.

This creates a practical data-retention requirement. A merchant that deletes relevant device, account, IP, and transaction-linkage information after 90 days may eliminate evidence that would otherwise have become useful for CE 3.0.

At the same time, CE 3.0 does not justify indefinite retention of every customer signal.

The better approach is to map Visa’s required historical period against legal requirements, privacy obligations, security risk, operational needs, tax or accounting retention, and the merchant’s legitimate dispute-management purposes.

CE 3.0 Data Elements: What Visa Actually Looks For

Visa’s merchant FAQ identifies a mandatory item description plus four principal comparison fields:

• customer account/login ID;
• delivery address;
• device ID/device fingerprint;
• IP address.

Visa states that at least two of those listed data elements must be the same across the disputed and historical transactions, and at least one of the two matching elements must be the device ID/device fingerprint or IP address.

That last requirement is easy to overlook.

Matching a customer account/login ID and delivery address, without a qualifying device or IP match, does not satisfy the published combination described in Visa’s CE 3.0 merchant guidance.

The item description is separately listed as a mandatory field.

Which Fields Must Match?

The table below illustrates how a merchant might evaluate a hypothetical case. It is not a substitute for the acquirer’s actual CE 3.0 validation process.

Data Element	Disputed Transaction	Prior Transaction 1	Prior Transaction 2	Qualifying Match?
Underlying payment relationship	Same qualifying merchant-cardholder pairing	Same	Same	Required for historical pairing
IP address	198.51.100.20	198.51.100.20	198.51.100.20	Yes
Device identifier	DEV-8421	DEV-8421	DEV-8421	Yes
Delivery address	125 Example Ave.	125 Example Ave.	125 Example Ave.	Yes if normalized and submitted correctly
Customer account/login ID	CUST-59320	CUST-59320	CUST-59320	Yes
Item description	Provided	Provided as required	Provided as required	Mandatory information

A merchant does not need to invent extra identifiers to make a case look stronger. The objective is to preserve the Visa-defined fields accurately.

Other evidence may still be useful during ordinary dispute handling, but merchants should label it correctly.

Delivery confirmations, email receipts, customer-support tickets, subscription-use logs, signed terms, download records, and fulfillment records can be valuable merchant dispute evidence without necessarily being one of the CE 3.0 matching fields.

Customer Account, Device, IP, and Address Evidence

The four comparison categories appear simple on paper, but their usefulness depends heavily on data quality. A merchant may technically collect all four and still have weak historical matching if account identities constantly change, device IDs reset on every visit, IP addresses are missing, or shipping addresses are stored inconsistently.

Customer Account or Login ID

A stable customer account/login identifier can connect multiple purchases without relying on the person’s display name or email formatting.

The merchant should use an internal immutable account identifier where its systems support one. Email addresses may change, customers may use aliases, and two accounts can sometimes share the same contact information.

Do not automatically treat an email address as interchangeable with Visa’s customer account/login ID terminology. Confirm with the gateway, acquirer, or CE 3.0 provider exactly what value is transmitted in the relevant field.

A good ecommerce architecture might connect:

Customer Account ID → Order ID → Payment Attempt → Provider Transaction ID → Fulfillment → Refund → Dispute

That lets a dispute analyst locate the history quickly without searching independent systems manually.

Duplicate customer accounts create another problem. If a shopper has CUST-1002, CUST-1488, and CUST-2015, otherwise useful transaction history can become fragmented.

Merchants should therefore have controlled account-merging processes without rewriting historical transaction records.

Device ID and Device Fingerprint

Visa lists device ID/device fingerprint among the CE 3.0 comparison fields and allows it to satisfy the required device-or-IP portion of the match.

The value must be useful consistently over time. A random session identifier generated on every page load will not provide the same type of historical continuity as a properly implemented persistent device identifier.

Merchants also need to consider privacy law, consent requirements, transparency, and data minimization when implementing fingerprinting technologies. The fact that a technical signal may be useful in fraud or dispute management does not create unlimited permission to monitor visitors.

First-party identifiers managed for legitimate fraud-prevention and payment-security purposes may provide a cleaner operational model than collecting unnecessary behavioral attributes.

Device evidence also has limitations. Shared tablets, household computers, factory resets, browser privacy controls, app reinstallations, and hardware upgrades can change identifiers.

A device match is evidence of consistency—not an infallible statement about who was physically holding the device.

IP Address Evidence

Visa includes IP address among the CE 3.0 qualifying comparison elements, and it can satisfy the rule requiring one matching device-or-IP signal.

Merchants should capture the actual shopper-facing network address at the appropriate transaction point and avoid accidentally storing only an internal load balancer, proxy, CDN, or server address.

Infrastructure teams should document which header is trusted and how the application determines the original client IP. Otherwise thousands of customers may appear to share the same network identifier.

Even correctly collected IP addresses have natural limitations:

• mobile carriers can reassign them;
• office networks may serve hundreds of users;
• household Wi-Fi is shared;
• VPNs can change apparent location;
• IPv6 addresses can be represented in different forms;
• network address translation can obscure individual devices.

For that reason, an IP match should be treated according to Visa’s criteria rather than described as independent proof that a particular person made the purchase.

Shipping or Delivery Address Evidence

Visa’s CE 3.0 material uses delivery address as one of the eligible comparison fields.

Physical-goods merchants can benefit from keeping a normalized fulfillment address in a form that remains connected to the payment record.

For example:

• “125 West Main Street Apt 4”
• “125 W Main St #4”
• “125 W. Main Street, Apartment 4”

may describe the same location but appear different to poorly designed comparison logic.

Address normalization should happen systematically and predictably rather than through manual edits performed after a chargeback arrives.

The original customer-entered value may still need to be retained where appropriate for audit purposes. A merchant can store a normalized comparison field separately while preserving the source record.

Payment Credentials, Tokens, Wallets, and Transaction Matching

Payment matching deserves special attention because modern ecommerce transactions frequently involve tokens rather than a merchant directly handling a reusable PAN.

Visa’s merchant FAQ states that Visa uses the underlying PAN to confirm the merchant-cardholder pairing. It further explains that PAN and tokenized historical transactions can be used when the underlying PAN of the historical transaction matches the transaction being disputed.

That does not mean merchants should start storing full PANs merely to build CE 3.0 evidence.

A gateway token, merchant vault token, network token, and wallet token are not automatically the same thing:

• A PAN is the underlying payment account number.
• A network token can replace the PAN within network tokenization.
• A wallet/device token may be provisioned for a particular wallet environment.
• A gateway token may be a processor-specific reference.
• A merchant vault token may be an internal or provider-issued alias for stored payment credentials.

The merchant often needs the processor, network, or acquirer to perform the underlying credential correlation.

Wallet Transactions

Apple Pay, Google Pay, and other tokenized wallet transactions can complicate historical matching if a merchant assumes the visible token reference will remain identical forever.

The appropriate question for the processor is not, “Do these token strings look the same?” It is:

Can your CE 3.0 implementation correctly associate these Visa transactions through the underlying credential relationship required by Visa?

Visa’s guidance confirms that tokenized and PAN-based historical transactions can participate in the historical footprint when the underlying PAN relationship meets the rule.

Merchants should therefore retain provider transaction references and network information rather than attempting to reverse-engineer token mappings themselves.

Guest Checkout

CE 3.0 does not mean merchants must force every customer to create an account.

Guest-checkout merchants may still capture other relevant signals such as delivery address, device ID, IP address, provider transaction references, and transaction history.

However, they should not fabricate an account/login ID simply to fill a CE 3.0 field.

If no genuine persistent customer ID exists, leave the data model truthful and determine whether another qualifying field combination can satisfy the remedy.

Subscriptions, Digital Goods, and Physical Goods

CE 3.0 can matter across different ecommerce business models, but the evidence architecture varies substantially.

Subscription Merchants

Visa’s published merchant FAQ confirms that CE 3.0 can be available for recurring Merchant Initiated Transactions. It also states that, for subscription merchants, the IP address from the first Customer Initiated Transaction may be populated for a subsequent recurring MIT used as historical evidence.

That makes the initial subscription signup especially important.

A subscription platform should connect:

• original customer-initiated transaction;
• subsequent recurring transactions;
• customer account ID;
• subscription ID;
• payment credential references;
• initial device/IP data;
• renewal dates;
• cancellations;
• refunds;
• service access and usage;
• dispute history.

Visa also notes that an annual subscription may not satisfy the standard historical requirement if the merchant lacks enough qualifying transactions inside the applicable window.

CE 3.0 does not excuse unclear renewal disclosures or failure to honor cancellation requests. A canceled-recurring dispute is not automatically a 10.4 fraud dispute simply because historical transactions exist.

Digital Goods

Digital-goods merchants often have extensive account evidence that may help ordinary representment:

• login history;
• entitlement activation;
• software license usage;
• downloads;
• content streaming activity;
• game-account usage;
• IP history;
• device history.

Of these, only Visa-defined qualifying fields should be presented as CE 3.0 matching elements.

A download log may demonstrate that an account accessed the product, but it does not become a Visa CE 3.0 field simply because the merchant considers it compelling.

Maintaining this distinction improves both dispute accuracy and internal training.

Physical Goods

Physical-goods sellers generally have richer fulfillment evidence, including shipping address, carrier tracking, delivery confirmation, warehouse scans, serial numbers, and return records.

Delivery address may participate in CE 3.0 matching under Visa’s criteria. Carrier delivery confirmation is useful operational evidence but should not automatically be labeled a CE 3.0 matching field.

For broader chargeback handling, merchants may benefit from keeping structured order and fulfillment evidence as described in this guide to preparing chargeback rebuttal documentation. CE 3.0 should be treated as a specific Visa remedy layered on top of disciplined dispute documentation—not as a replacement for it.

CE 3.0 vs. Traditional Representment

CE 3.0 and ordinary representment overlap in their goal—showing why a merchant should not bear responsibility for a disputed transaction—but their evidence structures are different.

Area	Traditional Representment	CE 3.0
Primary evidence	Evidence relevant to the applicable dispute reason, such as fulfillment, terms, communication, or authorization records	Visa-defined historical transaction relationship and qualifying matching fields
Historical transactions required	Not universally	Yes, under CE 3.0 criteria
Applicable dispute types	Depends on network dispute condition	Specifically tied to qualifying Visa 10.4 CNP fraud disputes
Data matching	Case-specific	Structured Visa-defined matching requirements
Network-specific criteria	Yes, varies by dispute program	Visa-specific
Outcome	Depends on dispute rules and evidence	Qualifying CE 3.0 remedy can shift applicable liability under Visa rules

A merchant may have an excellent traditional evidence package yet still lack CE 3.0 eligibility.

The reverse is also possible: historical fields may satisfy the CE 3.0 structure, while operational evidence such as customer emails or delivery details adds useful context elsewhere in the dispute workflow.

The safest practice is therefore to maintain two internal concepts:

CE 3.0 qualifying evidence and general dispute evidence.

Confusing them causes teams to believe they are “CE-ready” merely because they retain receipts and tracking numbers.

For a broader view of how chargebacks affect merchant operations, see the discussion of chargeback costs and representment.

CE 3.0 and Visa’s Dispute Workflow

Visa’s merchant material describes more than one route through which the CE 3.0 criteria can be used.

Its published FAQ explains that merchants can use Order Insight during pre-dispute processing to provide required criteria before the dispute is created and processed through Visa Resolve Online. It also describes submission of the required criteria in the post-dispute, pre-arbitration response process through the merchant’s acquirer.

At a high level:

Issuer/Cardholder Inquiry → Eligibility and Transaction Matching → Merchant/Provider Data → CE 3.0 Evaluation → Dispute or Liability Outcome

Merchants should not assume that every processor implements these steps identically.

Some providers may automate data gathering. Others may require a dispute analyst to select historical transactions. Enterprise platforms may integrate directly with Visa-related services, while smaller merchants may access CE 3.0 entirely through their acquirer or processor.

Visa describes VROL as its end-to-end dispute platform and separately identifies a pre-arbitration CE 3.0 capability for acquirers.

Order Insight and CE 3.0

Order Insight is designed to provide richer transaction information at the inquiry or pre-dispute stage. Visa’s post-purchase resources describe Order Insight as a tool that lets merchants share order details so issuers and cardholders can identify transactions more easily and potentially prevent unnecessary disputes.

CE 3.0 is not synonymous with Order Insight.

Order Insight is a data-sharing/pre-dispute capability; CE 3.0 is a particular dispute remedy based on qualifying criteria.

Visa has continued evolving their relationship. Visa announced that an April 2026 update allows merchants to use CE 3.0 within Order Insight to share evidence with banks regarding suspicious transactions.

Visa also announced automatic CE 3.0 qualification through Visa Secure in the U.S. beginning October 17, 2025, including Visa Data Only, with a fee for successful qualifications introduced effective April 17, 2026.

These developments reinforce why merchants should verify their provider’s current implementation rather than relying solely on a CE 3.0 integration description written several years ago.

Collecting CE 3.0 Data Before a Dispute

CE 3.0 readiness begins at checkout, not when a dispute notification appears.

A practical collection workflow is:

1. Assign stable identifiers: Maintain persistent order, transaction, customer, and payment-provider references.
2. Capture approved qualifying fields: Record relevant IP, device, delivery-address, and account/login data where appropriate and lawful.
3. Preserve the transaction relationship: Connect authorization, settlement, refund, fraud status, fulfillment, and dispute records.
4. Normalize comparison data: Standardize addresses, device formats, date handling, and account identifiers.
5. Retain historical status: Record whether earlier transactions later received fraud reports or disputes.
6. Map tokens through providers: Keep references needed for your processor or acquirer to establish the underlying Visa credential relationship.
7. Protect sensitive data: Store only what the business is permitted and justified in retaining.
8. Test retrieval: Make sure an analyst can find eligible history within a dispute deadline.
9. Test provider submission: Confirm the acquirer can actually transmit CE 3.0 data.
10. Review retention periodically: Align stored evidence with Visa requirements, privacy obligations, and security policies.

CE 3.0 Data Collection Table

Data	Capture Point	Where Stored	Retention/Privacy Review	CE 3.0 Use
Transaction ID	Gateway/payment response	Payment ledger	Operational retention	Links historical payment records
Device ID	Web/app checkout	Fraud or customer-event store	Privacy and minimization review	Visa-listed comparison field
IP address	Checkout/payment event	Secure event or transaction store	Privacy and retention review	Visa-listed comparison field
Delivery address	Checkout/order	Order/fulfillment database	Customer-data retention review	Visa-listed comparison field
Customer account ID	Login/account service	Customer database	Account lifecycle review	Visa-listed comparison field
Fraud/dispute status	Processor/acquirer events	Dispute repository	Network/business retention	Determines historical eligibility
Item description	Order/cart system	Order database	Normal business retention	Mandatory CE 3.0 information in Visa guidance

Data Normalization, Duplicate Accounts, and Evidence Repositories

Good CE 3.0 evidence depends as much on data engineering as dispute expertise.

A transaction record spread across ten disconnected systems may technically exist but still be operationally unusable when the response deadline arrives.

Data Normalization

Address normalization is a clear example.

Convert formatting consistently while preserving necessary original source data:

• Street → St
• Apartment → Apt
• consistent ZIP/postal formatting;
• consistent country codes;
• standardized Unicode and capitalization handling.

Device identifiers should follow one generation and storage policy across web, mobile, and checkout environments.

Customer IDs should not be silently recreated after CRM migrations.

IP addresses should be captured in a documented format. If IPv6 compression or proxy handling changes between systems, normalize representation before comparison.

Normalization should happen during routine ingestion, not manually during a chargeback investigation.

Duplicate Customer Accounts

Multiple accounts can fragment a strong history.

Suppose a shopper creates one account using a work email and another using a personal email. Their device, shipping address, and underlying payment relationship may remain consistent, but the merchant’s account identifier no longer does.

That does not automatically defeat CE 3.0, because other qualifying combinations may still exist, but it reduces useful evidence.

Account-merging workflows should maintain an audit trail. Do not rewrite old transactions as if they originally belonged to a different account ID.

Build a Dispute Evidence Repository

A useful model is:

Order ID ↔ Customer Account ↔ Payment ID ↔ Provider Reference ↔ Device/IP ↔ Delivery Address ↔ Fulfillment ↔ Prior Transactions ↔ Refunds ↔ Fraud Reports ↔ Disputes

The repository does not need to be a single physical database.

A well-designed data warehouse or case-management layer can join authoritative systems while keeping sensitive data compartmentalized.

The goal is repeatable retrieval.

When a 10.4 dispute arrives, an analyst should be able to identify potential historical transactions, validate their age and fraud status, compare qualifying fields, and package the required provider data without ad hoc detective work.

Privacy, Data Retention, and PCI DSS

Evidence collection must not become an excuse for indiscriminate surveillance or unsafe card-data storage.

Merchants should collect only data they have a legitimate reason to process, maintain appropriate privacy disclosures where required, restrict internal access, and delete information when the applicable retention purpose ends.

Data Minimization and Privacy

Device identifiers and IP addresses can be sensitive or regulated information in some jurisdictions.

Businesses should document:

• why the data is collected;
• who may access it;
• how long it is retained;
• whether it is shared with processors or fraud providers;
• what security protections apply;
• how privacy requests interact with legal and operational retention needs.

CE 3.0 readiness should be designed jointly by payments, security, privacy, legal, and engineering teams rather than treated solely as a chargeback project.

PCI DSS Considerations

Merchants must not retain prohibited sensitive authentication data after authorization simply because they believe it could help a future dispute.

PCI guidance prohibits post-authorization storage of sensitive authentication data such as:

• CVV2/CVC2/CID;
• full magnetic-stripe or equivalent track data;
• PIN or PIN block data.

PCI SSC guidance also emphasizes that retained cardholder data should be limited to what is needed and appropriately protected.

Use tokenized references and provider identifiers when possible rather than unnecessarily storing payment credentials.

The PCI Security Standards Council should be the starting point for current PCI DSS requirements rather than informal chargeback advice.

Secure Evidence Storage

A dispute repository should use controls such as:

• role-based access;
• least-privilege permissions;
• encryption at rest and in transit;
• audit logs;
• secrets management for dispute APIs;
• restricted bulk exports;
• documented retention and deletion;
• monitoring of employee access;
• secure backups.

Payment Processor and Gateway Support

A merchant can collect excellent historical data and still be unable to use CE 3.0 effectively if its payment provider cannot identify, transmit, or validate the necessary information.

Visa’s own guidance repeatedly tells merchants to work with their acquirers. Its merchant FAQ specifically advises collaboration with the acquirer when selecting qualifying historical transactions and checking for fraud activity.

Ask your provider:

• Do you currently support Visa CE 3.0?
• Which Visa dispute conditions can your platform process through the CE 3.0 workflow?
• Which qualifying fields do you receive and transmit?
• How do you identify the two qualifying historical transactions?
• How do you verify the 120–365-day window?
• How is prior fraud activity checked?
• How are PAN and tokenized transactions correlated?
• How do you handle wallet or network-token transactions?
• Can we export historical device, IP, address, and account data?
• Do you use Order Insight for CE 3.0?
• Is CE 3.0 applied automatically, manually, or both?
• Can we see whether a case successfully qualified?
• What dispute-management or CE 3.0 fees apply?
• Who is responsible for data retention—the merchant, gateway, processor, or another party?
• What happens if the gateway retains an eligible field for less time than Visa’s historical window?

Do not accept “we support chargebacks” as an answer.

CE 3.0 requires a specific capability.

Visa’s service-provider materials describe a separate Pre-arbitration Compelling Evidence 3.0 function and encourage providers to work with Visa’s post-purchase ecosystem.

Building a CE 3.0 Readiness Audit

A CE 3.0 readiness audit should test the entire evidence chain rather than merely checking whether columns exist in a database.

Start with several real historical Visa transactions and simulate a future 10.4 dispute.

Can the team identify two potentially qualifying transactions in the correct historical window? Can it determine whether those transactions have fraud activity? Can it retrieve the required item descriptions? Are account, address, device, and IP values available in consistent formats?

Next, test the provider side.

Does the processor recognize the same transactions? Can it associate tokenized activity correctly? Can it explain exactly how a CE 3.0 case reaches Visa?

CE 3.0 Readiness Checklist

Control	Ready?
Historical transaction IDs retained	☐
Provider/acquirer references retained	☐
Prior fraud and dispute status known	☐
Device data retained where appropriate	☐
IP data available	☐
Delivery address normalized	☐
Customer account IDs consistent	☐
Processor supports CE 3.0	☐
Token mapping process understood	☐
Historical lookback retention reviewed	☐
Privacy policy/process reviewed	☐
Evidence export tested	☐
Staff know CE 3.0 vs ordinary evidence	☐

The audit should also look for false confidence.

A merchant may store “device_id” but discover that the value changes with every session. An “IP” column may contain the CDN address. A “customer_id” may have been regenerated during a platform migration.

Friendly-Fraud Prevention Beyond CE 3.0

CE 3.0 acts after transaction history exists. The better business outcome is often preventing unnecessary disputes before they happen.

Visa’s current friendly-fraud guidance emphasizes transaction transparency, recognizable descriptors, customer communications, account management, and post-purchase tools as parts of a broader strategy.

Merchants should improve:

• recognizable billing descriptors;
• purchase confirmation emails;
• renewal reminders;
• clear cancellation procedures;
• refund confirmations;
• delivery notifications;
• customer-service access;
• account authentication;
• purchase-history screens;
• fraud screening;
• account-takeover detection.

Billing Descriptors

An unfamiliar statement descriptor can convert customer confusion into an avoidable fraud claim.

Use descriptors that are reasonably recognizable and keep descriptor practices consistent. Visa’s CE 3.0 merchant FAQ also advises descriptor consistency to support transaction matching, including maintaining consistent leftmost characters and avoiding data-quality issues.

Descriptor management therefore supports both dispute prevention and historical transaction correlation.

Customer Communications

Retain appropriate copies or records of:

• order confirmations;
• shipment notifications;
• renewal notices;
• customer-service conversations;
• refund confirmations;
• cancellation confirmations.

These records may not constitute CE 3.0 matching fields, but they can be useful for transaction recognition, customer support, and ordinary representment.

Account Takeover vs. Friendly Fraud

Account takeover must remain part of fraud analysis.

A transaction matching an old account or device should not automatically be assumed legitimate. Criminals can reuse compromised accounts, session cookies, credentials, devices, or household networks.

CE 3.0 and fraud screening solve different problems:

Fraud screening: before authorization or fulfillment.

CE 3.0: structured handling of an eligible later Visa dispute.

Merchants need both.

CE 3.0 Reporting and Performance Metrics

A good reporting program measures readiness and outcomes without inventing universal win rates.

Track at least:

• Visa fraud disputes received;
• 10.4 cases potentially eligible for CE 3.0;
• cases with two qualifying historical transactions;
• CE 3.0 submissions;
• successful CE 3.0 outcomes;
• missing-data cases;
• cases rejected because historical transactions had fraud activity;
• transactions outside the qualifying time window;
• processor/provider failures;
• average analyst preparation time;
• operational dispute cost;
• fraud loss.

Visa has incorporated CE 3.0 into broader fraud and dispute monitoring considerations. Its current VAMP materials state that certain fraud qualified for CE 3.0 is excluded from the VAMP ratio, subject to the timing of the relevant data extract.

That makes accurate qualification and reporting operationally important, but merchants should not promise a particular chargeback-ratio reduction.

CE 3.0 Dashboard

Metric	Why It Matters
Eligible disputes	Shows the true CE 3.0 opportunity
Qualifying prior-history cases	Measures whether historical data is usable
Evidence completeness	Identifies missing IP/device/account/address information
Successful outcomes	Measures real dispute results
Data-gap cases	Directs engineering and retention improvements
Average preparation time	Measures operational efficiency
Provider qualification failures	Identifies processor or integration problems

A strong dashboard distinguishes eligible cases, submitted cases, and successful cases.

Combining all three into one “win rate” hides operational problems.

Common CE 3.0 Mistakes

The most expensive CE 3.0 mistakes generally happen before a dispute reaches the chargeback team.

Common examples include:

• assuming every friendly-fraud complaint qualifies;
• applying CE 3.0 to the wrong Visa dispute condition;
• relying on outdated third-party criteria;
• deleting historical data too early;
• failing to retain fraud/dispute status of earlier transactions;
• treating every previous charge as automatically qualifying;
• using unstable device identifiers;
• storing the proxy or CDN IP instead of the shopper IP;
• failing to normalize delivery addresses;
• duplicating customer accounts;
• confusing delivery proof with a CE 3.0 matching field;
• assuming gateway tokens and network tokens are interchangeable;
• attempting to map tokenized transactions without processor support;
• storing prohibited card authentication data;
• assuming CE 3.0 replaces account-takeover detection;
• failing to confirm provider support;
• describing CE 3.0 as guaranteed protection.

Another mistake is using hostile language toward cardholders.

The evidence should demonstrate the transaction relationship. A merchant does not need to call a customer dishonest or accuse them of fraud to present a strong case.

Good dispute teams state verifiable facts and let the applicable Visa process determine the outcome.

Practical CE 3.0 Example

Consider a hypothetical ecommerce merchant selling specialty home products.

A cardholder disputes a $184 purchase as unauthorized, and the issuer submits the matter under Visa 10.4. The names, amounts, identifiers, dates, and other details below are hypothetical.

The merchant’s system finds two prior Visa purchases associated with the same merchant-cardholder relationship:

• Prior Transaction A occurred 174 days before the dispute processing date.
• Prior Transaction B occurred 291 days before the dispute processing date.
• Neither historical transaction shows fraud activity.
• Visa/provider matching confirms the necessary underlying cardholder-merchant relationship.

The disputed transaction and both historical transactions contain:

• customer account ID CUST-44718;
• device ID DEV-72904;
• the same normalized delivery address;
• the same IP address;
• appropriate item descriptions.

The merchant therefore has more than two matching fields, including the required device/IP-type element.

The analyst does not simply declare the chargeback “friendly fraud.”

Instead, the workflow is:

1. Confirm that the issuer submitted the dispute under the eligible 10.4 condition.
2. Confirm that both historical transactions fall within the applicable 120–365-day standard window.
3. Check historical records for fraud activity.
4. Confirm the provider can establish the required underlying Visa credential relationship.
5. Compare Visa-defined matching elements.
6. Submit the required CE 3.0 data through the supported acquirer/provider workflow.
7. Record whether the case qualified and its final outcome.

If one of the historical transactions had fraud activity, if both transactions were too recent, or if the provider could not establish the proper transaction relationship, the merchant should not simply substitute unrelated delivery evidence and label the case CE 3.0.

That evidence might still be useful elsewhere, but the CE 3.0 eligibility decision must follow Visa’s current rules.

Frequently Asked Questions

Conclusion

Visa Compelling Evidence 3.0 changes the way eligible merchants can address some card-not-present fraud disputes because it places unusual importance on what happened before the disputed transaction.

The strongest CE 3.0 chargeback defense is not a persuasive letter written after the customer files a dispute. It is an accurate, secure historical record showing the transaction relationships and qualifying data Visa requires.

Visa’s published criteria describe two qualifying historical transactions in the standard 120–365-day window, required transaction relationships, historical fraud-status considerations, an item description, and matching combinations drawn from customer account/login ID, delivery address, device ID/device fingerprint, and IP address—with at least one qualifying device-or-IP match.

Merchants should preserve those signals without confusing them with general representment evidence.

A shipment tracking number may be useful. A customer-service transcript may be useful. An account-usage log may be useful. But CE 3.0 qualification depends on Visa-defined data and the applicable Visa process, not simply on how convincing a document appears to the merchant.

The operational priority is therefore to build reliable transaction history:

Order → Customer → Payment → Device/IP → Delivery → Fulfillment → Historical Transactions → Fraud/Dispute Status

Then verify that the processor or acquirer can use that history through its current CE 3.0 workflow.

CE 3.0 should also remain one layer of a larger strategy. Recognizable descriptors, strong authentication, fraud screening, account-takeover detection, timely customer communication, transparent subscriptions, fair refund processes, and accessible support can prevent many disputes before historical evidence is needed.

Visa continues to develop its post-purchase and dispute services, so merchants should periodically recheck the official Visa merchant dispute resources and their acquirer’s implementation rather than relying permanently on an old workflow document.

Informational disclaimer: This guide is provided for general payment, dispute-management, fraud-prevention, and security information. Visa rules, provider implementations, fees, regional availability, and dispute procedures can change. 

Merchants should confirm current requirements with Visa documentation, their acquirer, processor, gateway, PCI-qualified advisers where appropriate, and legal/privacy counsel for requirements applicable to their business.