What Is Compelling Evidence 3.0?

How Compelling Evidence 3.0 Works

CE 3.0 is a structured representment process triggered after a chargeback is filed under Visa reason code 10.4. Unlike standard dispute responses that rely on policy documentation or delivery confirmation, CE 3.0 uses the cardholder's own prior transaction history to demonstrate that the disputed purchase was legitimate. The process follows a defined six-step sequence that merchants and their acquirers must execute within Visa's response window.

Why Compelling Evidence 3.0 Matters

Friendly fraud—where legitimate cardholders falsely claim a transaction was unauthorized—has become the dominant chargeback type in ecommerce, and traditional representment evidence often falls short against a cardholder's sworn denial. CE 3.0 addresses this gap directly by creating an objective, data-driven standard that issuers cannot easily override with a cardholder's word alone. For high-volume card-not-present merchants, the framework can materially shift dispute economics.

• 35–40% of all chargebacks are estimated to stem from friendly fraud rather than genuine criminal activity, according to the Chargebacks911 annual industry report—a figure that climbs above 60% in digital goods and subscription verticals where no physical delivery confirmation exists.
• CE 3.0 win rates for qualifying submissions are reported at 60–75% by major acquirer networks, compared to 20–30% win rates for standard unstructured 10.4 representments that lack the matching-identifier framework.
• Visa's own data indicates that merchants who deploy CE 3.0 correctly reduce their net chargeback loss rate on 10.4 disputes by an average of 45% compared to pre-CE 3.0 dispute strategies against the same reason code.

Compelling Evidence 3.0 vs. Original Compelling Evidence

The original Compelling Evidence framework—sometimes referred to informally as CE 1.0 or CE 2.0—gave merchants flexibility in what they could submit but lacked clear criteria for what would guarantee a liability shift. Visa's reviewers had wide discretion, and outcomes were inconsistent across issuers and regions. CE 3.0 replaced that ambiguity with a structured, pass/fail criteria model that removes issuer discretion when the evidence fully meets the standard. Understanding the differences helps merchants decide which framework applies and how to prepare their data infrastructure.

Types of Compelling Evidence 3.0

CE 3.0 evidence is categorized by the type of customer identifier used to establish continuity across the disputed transaction and the two prior undisputed transactions. Each identifier type has different capture requirements, data persistence characteristics, and suitability by merchant vertical. Merchants should build capture and retention strategies around at least two identifier types to maximize their eligible dispute pool.

Device Fingerprint or Device ID A persistent device identifier—generated by the merchant's fraud tooling, browser fingerprinting library, or mobile SDK—that links a specific device to multiple orders over time. This is generally the strongest CE 3.0 identifier because it is difficult for a cardholder to dispute and does not depend on shipping logistics or address formatting. Device fingerprints must be captured at authorization time and retained for at least 18 months to cover CE 3.0's full lookback window plus the chargeback response period.

IP Address The IP address captured at the time of checkout and authorization. While less persistent than a device fingerprint (dynamic IPs and VPN usage can complicate matching), IP address data is widely supported by existing order management systems and is often the easiest identifier to retrieve retroactively from server logs. Merchants should log both IPv4 and IPv6 addresses, timestamp them at authorization rather than session start, and store them as indexed structured fields—not buried in raw log files.

Physical Shipping or Delivery Address The verified delivery address used for the disputed transaction and matching prior orders. This identifier is most applicable to physical goods merchants where a customer repeatedly ships to the same location. Address normalization is mandatory before comparison—minor formatting discrepancies such as "St" versus "Street" or a missing unit number will invalidate an otherwise valid match. Confirmed carrier delivery scans further strengthen address-based evidence by demonstrating the cardholder received goods at the matched address.

Best Practices

For Merchants

CE 3.0 representment success depends almost entirely on data captured before the dispute is filed. Merchants who treat CE 3.0 as a reactive process—scrambling to find identifier data after a chargeback arrives—consistently lose to merchants who have built proactive data infrastructure around Visa's evidence requirements.

• Retain full transaction metadata for at least 18 months. CE 3.0's 365-day lookback combined with a typical chargeback response window means data from up to 14 months before a dispute notification date may be required for a qualifying submission.
• Normalize all shipping addresses at the point of capture. Deploy a postal address validation API at checkout so that shipping addresses are stored in canonical form. This eliminates false non-matches at the CE 3.0 review stage caused by formatting inconsistencies.
• Triage every 10.4 dispute before responding. Not every 10.4 chargeback will have two qualifying prior transactions. Run a CE 3.0 eligibility check immediately upon dispute receipt. If no qualifying priors exist, pivot to Rapid Dispute Resolution or accept the chargeback rather than wasting the representment window on an ineligible case.
• Pair CE 3.0 with pre-dispute interception tools. Services like Ethoca Alerts notify merchants of potential disputes before the chargeback is formally filed, giving an opportunity to issue a targeted refund proactively—avoiding the formal chargeback entirely without consuming representment resources.
• Present evidence in tabular format. Visa reviewers handle high volumes. Package prior transaction data as a clear side-by-side table with the matching identifier field highlighted, alongside the disputed transaction row, so the match is unambiguous at first review.

For Developers

CE 3.0 is primarily an engineering problem. The rule demands structured, timestamped, field-level data that most legacy checkout pipelines were not originally built to capture consistently at the transaction level.

• Log device fingerprint at auth_request time, not session start. The authorization event is the legally defensible capture point and aligns with Visa's transaction timestamp definitions for CE 3.0 eligibility.
• Store IP address as a first-class column in your orders table or data warehouse—not relying on web server access logs. Write structured records with order ID, card token hash, IP address, device ID, and Unix timestamp as indexed columns to support fast lookback queries.
• Build a CE 3.0 eligibility API your dispute operations team can call in real time: given a disputed transaction ID, return all undisputed prior transactions on the same card within the 120–365-day window, with identifier overlap scores. Automating this lookup eliminates manual research across disconnected systems and removes a common source of deadline misses.
• Pin your fingerprinting library versions and log the algorithm version alongside each captured fingerprint. Changes to browser fingerprint logic mid-deployment break identifier continuity across the date window, creating gaps that make previously eligible disputes ineligible.

Common Mistakes

CE 3.0 submissions fail for predictable, preventable reasons. Understanding these failure patterns allows merchants to build submission workflows that catch errors before the package reaches Visa review.

1. Anchoring the date window to the dispute filing date instead of the transaction date Prior transactions must fall 120–365 days before the disputed transaction's processing date—not the date the chargeback was filed or received. Using the dispute notification date as the anchor systematically miscalculates eligibility and causes submissions to include out-of-window priors that Visa will reject.

2. Matching identifiers across only two of the three required transactions CE 3.0 requires the same qualifying identifier to appear in all three transactions: the two prior undisputed transactions and the disputed transaction itself. A device ID match between just two of the three does not satisfy the rule. Every CE 3.0 submission checklist must verify three-way identifier continuity before packaging.

3. Skipping address normalization before comparison "123 Main St" and "123 Main Street Apt 4" refer to the same location but will not match as strings. Merchants who compare raw address fields as stored—without normalization—lose valid submissions on a technicality that a simple API call at capture time would have prevented.

4. Applying CE 3.0 to ineligible reason codes CE 3.0 is only available for Visa reason code 10.4. Attempting to invoke the framework for reason codes 13.1 (merchandise not received), 13.3 (not as described), or any Mastercard dispute category wastes the response window and leaves the merchant without a viable rebuttal.

5. Starting data retrieval after dispute notification arrives Acquirers typically allow 30 days to respond to a 10.4 dispute. If CE 3.0 eligibility research is manual—requiring cross-system lookups across an order management platform, a fraud tool, and web server logs—that window disappears faster than expected. Without automated eligibility lookup, merchants routinely miss deadlines or submit incomplete packages under time pressure.

Compelling Evidence 3.0 and Tagada

Tagada's payment orchestration layer captures enriched transaction metadata—device fingerprints, IP addresses, and normalized shipping addresses—at the authorization event across all connected processors and payment methods. Because this data is stored centrally in a single structured schema, CE 3.0 eligibility lookups do not require merchants to reconcile records across multiple processor portals or log sources.