Compelling Evidence 3.0
Sign up
Compelling Evidence 3.0
Unleash the power of prevent CE 3.0 to fight fraud and win chargebacks

Chargebackhit and Visa CE 3.0 integration flow with secure gateway, fraud screening, shipment tracking, and ID verification.

Chargebackhit is the world’s first reseller partner to launch Compelling Evidence 3.0. Chargebackhit product, Prevent, is designed to help you reduce fraud and chargeback levels by up to Note
90% chargeback and fraud reduction rate, as well as 100% dispute win rate, are based on historical data from a select group of customers using a combination of Chargebackhit products. Individual results may vary. 90%, with an impressive 100% win rate in preventing fraudulent disputes. By using CE 3.0 with Chargebackhit Prevent, you can:

  • Provide compelling evidence
    Present evidence of previous undisputed transactions to shift liability to issuers, securing your revenue and reputation.
  • Systematically block fraud disputes
    Block any future 10.4 fraud dispute using qualified transaction data, safeguarding your business against fraudulent chargebacks.
  • Avoid financial losses
    By effectively managing fraud and chargebacks, Prevent helps you avoid losses associated with first-party misuse, dispute costs, fees, fines, and operational expenses.
  • Maintain control
    Visa 10.4 fraud dispute with qualifying compelling evidence is not counted against your fraud and dispute ratios, giving you better control over your metrics.

Considerations for CE 3.0
anchor

To take full advantage of CE 3.0 and the Systematic Dispute Deflection it offers, consider the following:

  • Data review
    Ensure your system captures all the required data elements outlined in the CE 3.0 specifications, including Customer Account ID, IP address, Delivery address, Device ID, and Device fingerprint.
  • Data archival and storage policies
    Review your data archival and storage policies to ensure the required data is available in your operational database for up to 365 days.
  • IT and infrastructure capacity
    Evaluate your IT and infrastructure capacity to support the required 2-second response time and implement any necessary optimizations.
  • API integration
    Prepare to integrate with the Chargebackhit API specification to seamlessly leverage the power of CE 3.0. If you are new to Chargebackhit, refer to the integration documentation to get started.
Chargebackhit expert team guides you through the CE 3.0 integration process step-by-step. Prepare to leverage the full power of CE 3.0 effortlessly and revolutionize your approach to fraud and chargeback management.

How CE 3.0 works
anchor

When a cardholder reports fraud, Chargebackhit validates merchant enrollment in Order Insight. It then requests order details for the disputed Visa transaction.

Chargebackhit also sends requests for prior transactions between the merchant and cardholder. These support CE 3.0 pre-dispute rule consideration. Order details are retrieved and returned through the API response.

Visa validates the responses based on CE 3.0 rule criteria. It blocks or deflects the fraud dispute and notifies the issuer of the outcome. Visa also sends a notice to the merchant. This notice indicates whether the CE 3.0 attempt was successful or failed.

CE 3.0 dispute validation flow between issuer, Visa, and merchant
  1. The cardholder contacts the card issuer and reports fraud.
  2. The issuer initiates a Guide
    The cardholder did not authorize or participate in a transaction conducted in a card-absent environment such as internet, mail-order, phone-order, and others.     10.4     fraud dispute process.
  3. Chargebackhit requests order details for the disputed Visa transaction from the merchant.
  4. The merchant retrieves the order details and returns them via API response.
  5. The issuing bank checks if the dispute is eligible.
  6. If the dispute is eligible, additional requests for historical transactions are sent to the merchant. Minimum 2 and maximum 5 additional Chargebackhit requests may be sent requesting the order details for CE 3.0 pre-dispute rule processing.
  7. The merchant retrieves order details for historical transactions and returns them via API response.
  8. The issuing bank validates the responses and blocks the fraud dispute if the Visa rule criteria are met.
  9. The card issuer notifies the cardholder that they cannot dispute a transaction as fraudulent.
Notification
Chargebackhit sends a notification to the merchant, indicating whether the CE 3.0 attempt was successful in deflecting the dispute or if it was unsuccessful.
CE 3.0 rule criteria
Issuers are held liable for a Guide
The cardholder did not authorize or participate in a transaction conducted in a card-absent environment such as internet, mail-order, phone-order, and others. 10.4 (Fraud – Card Absent Transaction dispute when the following information is provided by the merchant via Order Insight and the conditions are met:
  • Minimum of two historical transactions for the same PAN settled more than 120 days and less than 365 days prior to the dispute date.
  • At least two of the following data elements are the same in the disputed and historical transactions:
    • Customer Account ID
    • IP address
    • Delivery address
    • Device ID
    • Device fingerprint
  • One of the two data elements must be either an IP address or Device ID or Device fingerprint.
  • No prior fraud was reported on the historical transactions. Historical transactions may have been disputed but not for any fraud reason code.
  • The merchant provides a product description for each item purchased on the disputed and historical transactions.

Providing detailed product descriptions is crucial for a successful liability shift. A clear and detailed item description helps the cardholder recognize the transaction, which in turn reduces the likelihood of the issuer initiating a review. Examples of effective product descriptions include specifying lodging dates or including comprehensive merchandise specifications.

CE dispute deflection example
anchor

CE 3.0 dispute deflection example with historical transactions
  • The issuer raised dispute on January 21, 2026.
  • The period for valid historical transactions search is therefore between 120 days (September 23, 2025) and 365 days (January 21, 2025).
  • Three valid historical transactions were found by Visa, and their references were sent to the merchant, each transaction had the same PAN, and no fraud was reported on these transactions.
    • Transaction #1 March 8, 2025
    • Transaction #2 May 15, 2025
    • Transaction #3 August 5, 2025
  • The merchant responded to the Order Insight Lookup Requests with data.
  • The following matches were found in the core data elements :
    • Account ID and Delivery Address were the same between Transaction #1 , Transaction #2 and the disputed transaction
    • IP Address and Delivery Address were the same between Transaction #3 and the disputed transaction
    • Delivery address and Device ID were the same between Transaction #1 , Transaction #3 and the disputed transaction
    • Transaction #1 and Transaction #3 were considered as valid responses and the dispute was blocked by Visa
  • The dispute resulted in 10.4 fraud dispute deflection due to pre-dispute Compelling Evidence Rule criteria being met.
Data validation
  • Device ID must have a minimum of 15 characters.
  • IP Address can not be private and must follow IPV4 or IPV6 formats.
  • Device fingerprint should be at least 20 characters long.

Extended qualification criteria
anchor

The qualification criteria are further expanded to encompass transactions where the PAN may differ, but the token remains consistent, provided the historical transactions correspond to the previously mentioned criteria.

If a dispute transaction had 415623 as the PAN and 124583 as the token:

  • Transaction #1 had a different PAN , 423238, but shared the same token, 124583.
  • Transaction #2 had 417569 as the PAN and a different token, 498213.
  • Transaction #3 had 417569 as the PAN and shared the token 124583 with the dispute transaction.
  • Transaction #4 had the same PAN as the dispute transaction, 415623, but a different token, 498213.

In such scenarios, although the PAN may differ, the consistent token between the disputed transaction and the historical transactions (like Transaction #1 and Transaction #3 in the example) can serve as a criterion for validating the transaction legitimacy.

Looking for help? Contact us
Stay informed with Changelog