Visa Compelling Evidence 3.0: A Merchant Guide to Friendly-Fraud Evidence

Understand the historical footprint requirement

Visa’s merchant-readiness document states that two prior transactions are used to establish the historical footprint. Those transactions generally must be at least 120 days old and no more than 365 days old when measured from the dispute date, with a stated exception relating to original credit transactions.

The prior transactions must not have an active fraud report or active fraud dispute under the criteria described by Visa.

Retain the core matching fields

Visa lists User ID, IP Address, Shipping Address, and Device ID/Fingerprint as core data elements. At least two core elements must match across the qualifying history and disputed transaction, and one of the matching elements must be either IP Address or Device ID/Fingerprint.

The transactions must also be from the same merchant. That makes stable merchant matching and consistent customer identifiers operationally important.

Run a CE3.0 readiness test on historical data before relying on it. Select recent first-party misuse cases and ask whether the merchant can retrieve two qualifying prior undisputed transactions, stable merchant identifiers, user ID, IP, shipping address where relevant, device ID/fingerprint, and unique transaction references. Missing or overwritten device data discovered during a live dispute is too late to repair retroactively.

Do not treat one signal as identity proof

An IP address can be shared, changed, or routed through a network, and a device identifier can have its own limitations. CE3.0 is valuable precisely because it evaluates a defined historical pattern rather than allowing the merchant to declare “same IP equals same person.”

Outside the formal CE3.0 criteria, describe technical data accurately and avoid overstating what one signal proves.

Prepare the data pipeline before a dispute

Preserve transaction references, card-network identifiers available through the processor, user ID, device information, IP address, shipping details where relevant, order outcome, refund state, and any fraud-report status the merchant can access. Keep retention practices consistent with privacy and security obligations.

If data sits in separate systems, create a retrieval workflow that can produce the relevant transaction history quickly without manual guesswork.

Use CE3.0 as one layer of first-party-misuse control

Historical evidence does not replace descriptor clarity, customer support, refund handling, or pre-dispute transaction clarification. Merchants should still reduce the situations that cause legitimate customers to contact their issuer.

Where the processor supports CE3.0 flows, verify how it collects and submits qualifying data and whether the merchant needs to provide fields or configure integrations.

Coordinate retention with privacy and security requirements. More data is not automatically better. Define which identifiers are necessary for payment-risk and dispute purposes, how long they are retained, who can access them, and how they are protected. The objective is a reliable historical footprint for eligible cases without turning the dispute program into an uncontrolled archive of customer information.

Example: compelling evidence continuity without overclaiming

A disputed card-absent transaction shares account credentials and device characteristics with earlier uncontested transactions, and the purchased service is used afterward. Those facts may be relevant under current Visa compelling-evidence rules if the formal criteria are met.

Do not self-certify eligibility from a blog checklist. Preserve the transaction history and let the processor/acquirer apply current Visa criteria. Internally, separate the raw continuity data from the conclusion about whether it qualifies as Compelling Evidence 3.0.

Build CE3.0 readiness as a historical-data retention project

Compelling Evidence 3.0 is not something a merchant can create after receiving a dispute if the required historical transaction footprint was never retained. The operational work starts much earlier: preserve the customer and transaction fields needed to match the disputed payment with qualifying prior transactions under Visa's current rules. Use stable account or customer identifiers where your systems support them, retain the relevant payment and delivery or service evidence, and make sure older orders remain queryable after normal customer-support data would otherwise be archived.

Data matching should be deterministic and explainable. If the merchant believes two transactions belong to the same customer relationship, document which fields create the match and whether those fields were captured consistently at the time. Avoid building a post-dispute identity theory from loose similarities such as one IP address or a shared last name. Visa's CE3.0 materials define specific criteria; the merchant data pipeline should be designed around those current criteria and validated with the acquirer, processor, or provider that submits the evidence.

Keep first-party misuse prevention distinct from identity claims. Historical undisputed transactions can provide powerful continuity, but the merchant should still describe observed facts accurately. A familiar account, device, address, or service pattern is evidence of continuity in the merchant's data, not a universal proof of who held the card at every moment. This precision is useful even when the network program applies because it prevents internal teams from generalizing CE3.0 logic to unrelated dispute types where the same standard does not apply.

Audit readiness with sample reconstruction. Choose older customer histories and ask whether the team can retrieve the necessary transactions, matching fields, proof of delivery or service, and dates without engineering intervention. Record failure reasons such as expired logs, migrated customer IDs, guest checkouts, missing descriptors, or fragmented payment systems. Fixing those gaps improves more than CE3.0; it creates a durable transaction history for customer support, fraud review, and dispute investigation across the business.

Test historical matching after account merges and guest-to-account conversions

Customer identity changes can break CE3.0 readiness even when the underlying relationship is legitimate. Guest checkouts may later be attached to an account, or two accounts may be merged after support verifies ownership. Preserve stable transaction and customer-link mappings so historical qualifying transactions remain discoverable without inventing a match after the dispute.

Audit older records for these lifecycle changes. If matching depends only on a current email address, a routine email update can fragment history. Design the data model around the fields and criteria used by the current Visa process and validate the export with the submitting provider before relying on it operationally.

Historical transaction matching deserves a conservative internal standard. Account merges, guest checkouts converted to registered profiles, shared household devices, and payment-token changes can create apparent continuity that is weaker than it first looks. Preserve the specific fields that tie prior undisputed activity to the current transaction and note when a match is indirect. Do not collapse multiple customers into one identity merely because they share an address or device. Where the network rule requires particular qualifying evidence, the merchant should verify the current rule and use only records that meet it. This discipline keeps “friendly fraud” analysis from becoming a catch-all label and makes the evidence review reproducible when another analyst reopens the case months later.