Get started on dispute preventionPublic preview
Learn about the benefits and requirements of Stripe's dispute prevention offering powered powered by Verifi and Ethoca.
Stripe has built integrations with dispute prevention products offered by Verifi (a Visa solution) and Ethoca (a Mastercard solution).
##Verifi and Ethoca offerings
The Verifi offering includes Order Insights (OI) and Rapid Dispute Resolution (RDR), while the Ethoca offering includes Ethoca Alerts. Our integrations allow you to use these products without manual setup to help reduce your dispute rate and increase revenue retention. Learn more about pricing on the product overview page.
Rapid Dispute Resolution (RDR) 
RDR lets you construct a ruleset to resolve incoming disputes on Visa transactions for a fee per dispute (for example, resolve all potential fraud disputes under 10 USD). The main benefits of RDR are:
- Resolved non-fraudulent disputes don’t count towards your overall dispute rates, helping you stay out of monitoring programs.
- You don’t pay a separate dispute received fee on these resolved non-fraudulent disputes.
If you enter the Visa Acquirer Monitoring Program (VAMP), this helps because it reduces your dispute rates for non-fraudulent disputes and lowers dispute feeds. It also lets you avoid network fines and Stripe payment volume reserves.
Ethoca Alerts (Available May 1, 2025)
Ethoca Alerts allows users to construct rulesets to prevent what would be chargebacks by specifying conditions to trigger automatic resolutions. Ethoca Alerts is available for Mastercard transactions and resolved disputes don’t count towards dispute rates, helping merchants exit Mastercard’s chargeback monitoring programs such as ECM, HECM and EFM by reducing dispute rates, and lowering fines.
RDR and Ethoca Alerts requirements
No separate integration is required to use these resolution solutions. However, the onboarding process requires you to set up resolution rules through Radar to access dispute resolution and define which transactions to refund. Learn more about setting rules through Radar.
Order Insight (OI)
If a consumer checks their digital banking app or calls their issuer to say they don’t recognize a Visa charge and you’re enrolled in OI, the issuer’s customer support agent can send a real-time lookup (API request to Stripe) to provide detailed descriptions of the item the consumer purchased (such as product descriptions, quantity, shipping address, or IP address). The additional data helps the consumer recognize the charge and prevent follow-through on disputes. OI also uses new Visa rules such as Compelling Evidence 3.0 (CE 3.0), where if you can send issuers data about prior successful transactions with the same cardholder as a response to a lookup, the issuer is required to block the cardholder from filing the dispute at all. See Compelling Evidence 3.0 with OI for more information.
Cardholders are less likely to follow through on filing a dispute if they can recognize the charge. The chances of successfully deflecting a dispute when a lookup is made depend on the quality of the data that Stripe can provide. Stripe automatically pulls any available data on a charge on your behalf and sends it to the issuer. Stripe uses the data that you provide during charge time and doesn’t require you to build any integrations or maintain a real-time service. See the list of fields below that are eligible as part of the lookup response. By using the OI service, you direct Stripe to share this data with issuers and ultimately with cardholders. Verifi might occasionally update these fields, and your continued use of the OI service depends on your adapting to any new operational requirements.
Note
For a dispute to be eligible for a block using CE 3.0 rules, Stripe must have prior transaction data available. See Compelling Evidence 3.0 with OI for which data is required for CE 3.0 blocks. If prior transaction data isn’t available, Stripe still sends any other available data.
When you use dispute prevention, you agree to comply with Stripe’s reasonable requests and to provide additional data as needed.
| Object | Field | Description |
|---|---|---|
| Receipt | orderDate | Order date |
| orderNumber | Unique identifier for the order defined by the business | |
| invoiceNumber | Invoice number (alternate to order number) | |
| subTotalAmount | Subtotal amount of the purchase before tax and shipping fees are included | |
| shippingAndHandlingAmount | Shipping and Handling amount related to the purchase | |
| orderTotalAmount | Total amount of the order | |
| Payment information | paymentMethod | Masked representation of the card and card number of the original purchase as displayed on the physical or digital receipt. Limited to the last 4 digits of the card PAN. |
| billingName | First and last name from the card | |
| paymentTotalAmount | Payment amount of the purchase | |
| cvvChecked | Card security code validation at time of purchase | |
| Product purchased | productDescription | Detailed description of the product (merchandise or service) purchased |
| unitPriceAmount | Amount of the individual item | |
| quantity | Quantity of the product purchased | |
| Customer information | firstName | Customer’s first name |
| lastName | Customer’s last name | |
| lengthOfRelationship | Length of customer relationship with the business in number of months | |
| accountId | Cardholder registered identifier to uniquely identify their account with the business. This should be recognizable to the Cardholder (not an internal system identifier) and something they provided the business during account creation. Examples are a unique username, email, phone number, or other similar value. | |
| emailAddress | Email address that customer provided | |
| Billing address | address1 | Street address plus additional address lines such as suite number and apartment |
| address2 | Street address plus additional address lines such as suite number and apartment | |
| city | Name of city | |
| region | Region or state | |
| postalCode | Zip or postal code | |
| country | Country code | |
| Merchant information | merchantName | Corporate or parent company name of the business, This might or might not be recognizable to the consumer. |
| merchantUrl | Business’s corporate URL. Might be different than the websiteUrl where the customer made the purchase from. | |
| merchantContactPhone | Business’s customer service phone number. This should be the number that you would want a consumer to contact you to discuss any questions they have about the purchase. | |
| merchantAddress | Business’s corporate address | |
| termsAndConditions | Overview of cancellation policies for businesses | |
| storeDetails | A business might have multiple stores or locations that purchases are made from. The store details should indicate where the purchase was processed or the online webstore details. | |
| Store details | storeName | Store or webstore name where the purchase was made |
| storeContactPhone | Business’s customer service phone number | |
| Delivery address | address1 | Street address plus additional address lines such as suite number and apartment |
| address2 | Street address plus additional address lines such as suite number and apartment | |
| city | Name of city | |
| region | Region or state | |
| postalCode | Zip or postal code | |
| country | Country ISO 3166-1 code alpha-3 | |
| Delivery details | shippingCarrier | Shipping carrier |
| trackingNumber | Tracking number of the shipment or delivery | |
| Device | ipAddress | IP Address associated with the device |
Compelling Evidence 3.0 with OI
Compelling Evidence 3.0 (CE 3.0) is a program that benefits businesses by providing more aggressive tools to deflect and remedy first-party misuse (friendly fraud) disputes on Visa transactions categorized as 10.4 Other Fraud—Card Absent Environment. CE 3.0 rules dictate which evidence can be provided post-dispute to improve your chances of winning a dispute. To learn more, see our support article.
If you’re enrolled in OI, you can also use CE 3.0 pre-dispute to completely block the dispute from being filed. This works by providing the required prior transaction data to issuers during a lookup. If prior transactions between you and the cardholder exist, Visa automatically selects the 2-5 most recent non-fraud prior transactions and requests data on all of them. Stripe then automatically provides all available information.
If at least two prior transactions exist with complete product descriptions that have matching IP addresses and at least one matching email address or customer delivery address, the issuer must block the dispute. As a result, the dispute is never filed and you don’t incur any dispute fees or increases to your dispute rate.
OI Requirements
The onboarding flow in the Stripe Dashboard collects all the data elements that Stripe needs to begin servicing OI lookups on your behalf. These include Business name, Business URL, Business Phone Number, and Email. To achieve the best possibility for deflected disputes, make sure your Stripe integration is set up to provide as many of the above fields as possible at transaction time. To ensure that Stripe can effectively block disputes on your behalf with CE 3.0, make sure that all your transactions include IP Address, Customer Email Address, Product Descriptions, and if possible, Shipping or Customer Address.