Compelling Evidence 3.0
Get started
Sign In
Compelling Evidence 3.0
Unleash the power of prevent CE3.0 to fight fraud and win chargebacks

CE3-0-via-Order-Insight.png

Chargebackhit is the world’s first reseller partner to launch Compelling Evidence 3.0. Our enhanced product, Prevent, is designed to help you reduce fraud and chargeback levels by up to Note
Our 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 leveraging CE3.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 will not be counted against your fraud and dispute ratios, giving you better control over your metrics.

Considerations for CE3.0

To take the full advantage of CE3.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 CE3.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 CE3.0. If you are new to Chargebackhit, refer to the integration documentation to get started.
Our expert team will guide you through the CE3.0 integration process step-by-step. Prepare to leverage the full power of CE3.0 effortlessly and revolutionize your approach to fraud and chargeback management.

How prevent CE3.0 works

When a cardholder reports fraud, Chargebackhit validates merchant enrollment in Order Insight, requests order details for the disputed Visa transaction, and sends further requests for prior transactions between the merchant and cardholder for CE3.0 pre-dispute rule consideration, with order details retrieved and returned via API response.

VISA validates the responses based on CE3.0 rule criteria to block or deflect the fraud dispute, notifying the issuer of the outcome, and sending a notice to the merchant to indicate whether the CE3.0 attempt was successful or failed.

  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 (i.e., internet, mail-order, phone-order, etc.)
    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 CE3.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 will send a notification to the merchant, indicating whether the CE3.0 attempt was successful in deflecting the dispute or if it was unsuccessful.
CE3.0 rule criteria
Issuers will be held liable for a Guide
Visa’s Reason Codes follow a format of two digits, a period, and a third digit. The first two digits indicate which category the reason code falls under: 10 for Fraud, 11 for Authorization, 12 for Processing Errors, and 13 for Customer Disputes. The third digit indicates the specific reason within this category.
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 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.
  • Product description for each item purchased is provided by the merchant on the disputed and historical transactions.

Providing detailed product descriptions is crucial for a successful liability shift. 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

  • The issuer raised a dispute on Sept 18, 2022.
  • For this dispute, the valid historical transaction window was between 120 days (May 21, 2022) and 365 days (Sept 18, 2021).
  • Visa found three valid historical transactions made by the same cardholder during that timeframe. Each transaction had the same PAN and no fraud reported:
    • Transaction #1 April 2, 2022
    • Transaction #2 Jan 12, 2022
    • Transaction #3 Nov 5, 2021
  • 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’t be private and must follow IPV4 or IPV6 formats.
  • Device fingerprint should be at least 20 characters long.

Extended qualification criteria

The qualification criteria are further expanded to encompass transactions where the PAN may differ, but the token remains consistent, provided the historical transactions adhere 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.