> ## Documentation Index
> Fetch the complete documentation index at: https://www.marqeta.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Managing Visa Disputes
> Manage Visa disputes by integrating your dispute cases with the Visa network.
This page provides information on how to integrate your dispute cases with the Visa card network using the `/cases` endpoint. With the `/cases` endpoint you can manage disputes, including tasks such as initiating a dispute, uploading supporting documents, and receiving status updates. You can also use the `/cases` endpoint to track dispute progress by retrieving information such as:
* A list of dispute cases and their current state
* Information on a specific dispute case
* A specific dispute case transition
* An array of all dispute transitions related to a particular dispute case
* Dispute case documents
For general information on disputes, chargebacks, and best practices, see [About Disputes](/developer-guides/about-disputes/). For detailed reference information, see [Disputes (Visa)](/core-api/disputes-visa/) in the Core API Reference.
Dispute cases
Each `case` object corresponds to a dispute case. The `case` object requires a `CLEARING` transaction token. The amount disputed by the cardholder, indicated in `dispute_amount`, must be less than or equal to the clearing amount. Multiple partial disputes are accepted on the same clearing transaction, as long as the total amount is not greater than the dispute amount.
Dispute categories
The dispute type indicates the category of a dispute, which can be `FRAUD`, `AUTH`, `PROCESSING`, or `CONSUMER`.
Fraud
A cardholder submits a fraud dispute when they see a transaction on their statement that they do not recognize, which can result from a lost or stolen card or a stolen PAN.
Auth
An authorization dispute occurs when the partner program attempts to reclaim money that the cardholder has spent that has resulted in a negative balance. This typically happens when there is a clearing transaction without an authorization transaction. In this case, the cardholder has found a way to spend money without permission from the program, such as spending more money than they have in their account balance.
Processing
A processing dispute occurs when the transaction was expected, but the data or metadata is incorrect, such as the transaction amount or account number.
Consumer
A consumer dispute occurs when the cardholder has a dispute with the merchant, such as a claim that incorrect or defective merchandise was received, or that they did not receive the goods or services they paid for. In this case, the cardholder is demanding their money back and the merchant has refused.
Dispute questionnaires
When a cardholder opens a Processing or Consumer dispute, they are presented with a corresponding set of questions. These are exposed as either `PROCESSING` or `CONSUMER` in the `dispute_reason` field. Visa provides decision trees that require answers to certain questions if other questions are answered by the cardholder or have a certain value.
Processing errors
For processing errors, the questionnaire asks the cardholder for details about what is incorrect about the transaction. As the cardholder moves through the questionnaire, the specific questions presented depend on the answers provided. The decision tree for processing errors is shown below:
```json JSON expandable lines wrap theme={null}
*What is incorrect about this transaction - IAN/IA/IC/IT/ID/LP/DP
IAN (Incorrect Account Number) {
*Is the account number on the issuer's master file - Y/N {
Y {
*Does the account number on the receipt match the cardholder's account
number or token? (Y/N)
}
N {}
}
}
ITA (Incorrect Transaction Amount) {
*What is the amount on the cardholder's receipt
*What is the currency on the cardholder's receipt
*Is the dispute due to the difference between quoted price and actual charges made by the merchant - Y/N
}
IC (Incorrect Currency) {
*Incorrect Currency Reason - Currency Difference/DCC Dispute {
Currency Difference {
*Processed through VisaNet as CAD; what was the correct currency
}
DCC Dispute {
*Certification that the cardholder did not agree to Dynamic Currency
Conversion and did not make an active choice - Y/N {
Y {}
N {}
}
}
}
}
IT (Incorrect Transaction Code) {
*How is Transaction Code incorrect - CRI/CRD/DCR {
CRI (Credit instead of reversal or adjustment) {
*Explain why the credit refund was processed in error
}
CRD (Credit posted instead of debit) {}
DCR (Debit posted instead of credit) {}
}
}
LP (Late Presentment) {
*What is the status of the account - AC/CP/F/NF {
AC (Account Closed) {}
CP (Credit Problem) {}
F (Fraud) {}
NF (Non-sufficient Funds) {}
}
}
DP (Duplicate) {
*Are both transactions for the same merchant and same card - Y/N {
Y {
*Clearing Token of the Duplicate Original Transaction
}
N {
*Is the other transaction for the same merchant and on a different
Visa card owned by the same issuer/cardholder? - Y/N {
Y {
*Clearing Token of the Duplicate Transaction
}
N {
*Is the other transaction paid by other means Y/N {
Y {
*Provide proof of payment by other means {
*ARN from other transactions if paid with
Visa card {
*Acquirer reference Number
}
}
*Transaction information from other
transaction, if paid with Visa card {
*Transaction identifier
}
*Cash receipt (CASH_RECEIPT)
*Copy of the front and back of a canceled
cheque
*Voucher from the third party {
*Does the issuer have evidence that the
first merchant passed on the funds to
the second merchant - Y/N {
Y {
*Docs should be attached
}
N {}
}
}
*Statement from other card
*Other (OTHER)
}
N {}
}
*Did the cardholder attempt to resolve the dispute
with the merchant - Y/N {
Y {}
N {
*Is attempt to resolve prohibited by local law
or regulations - Y/N {
Y {
*Provide details of local law or
regulations
}
N {
Error "The cardholder must attempt to
resolve the dispute with the merchant
unless prohibited by local law or
regulations"
}
}
}
}
}
}
}
}
}
DP (Paid by other means) {
*Are both transactions for the same merchant and same card - Y/N {
Y {
*Clearing Token of the Duplicate Original Transaction
}
N {
*Is the other transaction for the same merchant and on a different
Visa card owned by the same issuer/cardholder? - Y/N {
Y {
*Clearing Token of the Duplicate Transaction
}
N {
*Is the other transaction paid by other means Y/N {
Y {
*Provide proof of payment by other means {
*ARN from other transactions if paid with
Visa card {
*Acquirer reference Number
}
}
*Transaction information from other
transaction, if paid with Visa card {
*Transaction identifier
}
*Cash receipt (CASH_RECEIPT)
*Copy of the front and back of a canceled
cheque
*Voucher from the third party {
*Does the issuer have evidence that the
first merchant passed on the funds to
the second merchant - Y/N {
Y {
*Docs should be attached
}
N {}
}
}
*Statement from other card
*Other (OTHER)
}
N {}
}
*Did the cardholder attempt to resolve the dispute
with the merchant - Y/N {
Y {}
N {
*Is attempt to resolve prohibited by local law
or regulations - Y/N {
Y {
*Provide details of local law or
regulations
}
N {
Error "The cardholder must attempt to
resolve the dispute with the merchant
unless prohibited by local law or
regulations"
}
}
}
}
}
}
}
}
}
```
For detailed information on processing errors, see [The processing\_error\_type\_dispute\_details object](/core-api/disputes-visa/#_the_processing_error_type_dispute_details_object) on the Disputes (Visa) page in the Core API Reference.
Consumer disputes
For consumer disputes, the questionnaire asks the cardholder for details about the dispute. As the cardholder moves through the questionnaire, the specific questions presented depend on the answers provided. The decision tree for consumer disputes is shown below:
```json JSON expandable lines wrap theme={null}
*Dispute Due To - CR/CS/CN/DM/NR/ND/CL
CR (Cancelled Recurring Transaction) (All Jurisdictions Except Europe) {
*Enter one of the following: {
*Date cardholder withdrew permission to charge the Payment Credential
*Date issuer informed merchant of account closure
}
*Contact method with merchant
*Select at least one:
Email {
Email Address
}
Call Center Name {
Phone Number
}
Mail {
Physical Address
}
SMSTextMessage {
Phone Number
}
In-Person {
Physical Address
}
Webform/Application Name {
Application Name
}
*Other form of payment (Optional) {
Y {
*Describe form of payment
}
}
*Cancellation Reason
}
CS (Cancelled Merchandise or Services) {
*What was purchased - Merchandise/Services {
Merchandise {
*Describe what was purchased (Free text, Required)
*Did cardholder receive the merchandise? (Y/N, Required) {
Y {
*Did the cardholder return the merchandise (Y/N, Required) {
Y {
*Date cardholder returned the merchandise: (Date,
Required)
*Date merchant received returned merchandise:(Date,
Required)
*Return Method (Dropdown, Required)
(Face to face, FedEx, DHL, UPS, Postal Service, Other)
}
N {
*Did the cardholder attempt to return the merchandise?
(Y/N, Required) {
Y {
*Date of attempted return (Date, Required)
*Provide a detailed description of how the
cardholder attempted to return and the
disposition of the merchandise: (Free Text, Required)
}
N {}
}
}
}
}
N {
*Did the cardholder cancel? (Y/N, Required) {
Y {
*Cancellation date (Date, Required)
*Cancellation reason (Free text, Required)
}
N {
*Was a cancellation policy provided? (Y/N, Required)
}
}
}
*Date the cardholder received or expected to receive the
merchandise (Date, Required)
*Did the cardholder attempt to resolve the dispute
with the merchant? (Y/N, Required) {
Y {}
N {
*Is attempt to resolve prohibited by local law or
regulations? (Y/N, Required) {
Y {}
N {
Invalid
}
}
}
}
Services {
*Type of Service (Radio button, Required) {
Timeshare {
*Date of the timeshare, or the date the contract or
related documents were received (Date, Required)
*Date of service or expected service (Date, Required)
*Did the cardholder attempt to resolve the dispute
with the merchant? (Y/N, Required) {
Y {}
N {
*Is attempt to resolve prohibited by local law or
regulations? (Y/N, Required) {
Y {}
N {
Invalid
}
}
}
}
*Cancellation Date (Date, Required)
*Cancellation Reason (Free text, Required)
}
Guaranteed Reservation {
*Date of service or expected service (Date, Required)
*Did the cardholder attempt to resolve the dispute
with the merchant? (Y/N, Required) {
Y {}
N {
*Is attempt to resolve prohibited by local law or
regulations? (Y/N, Required) {
Y {}
N {
Invalid
}
}
}
}
*Certification of one of the following
(radio button, required) {
*The cardholder properly cancelled the guaranteed
reservation
*The cardholder attempted to cancel within 24 hours
of delivery of the reservation confirmation
*The merchant billed a no-show transaction for more than
one day's accommodation or rental
}
*Cancellation Date (Date, Required)
}
Other {
*Describe what was purchased? (Free text, Required)
*Did the cardholder cancel? (Y/N, Required)
*Date of service or expected service (Date, Required)
*Did the cardholder attempt to resolve the dispute
with the merchant? (Y/N, Required) {
Y {}
N {
*Is attempt to resolve prohibited by local law or
regulations? (Y/N, Required) {
Y {}
N {
Invalid
}
}
}
}
*Cancellation Date (Date, Required)
*Cancellation Reason (Free text, Required)
}
*Was a cancellation policy provided? (Y/N, Required)
}
}
}
}
CN (Credit not processed) {
*Was a credit voucher, voided transaction receipt or refund acknowledgement
given - (Y/N, Required) {
Y {
Is the credit voucher, transaction receipt, or refund acknowledgement
dated? (Y/N, Required) {
Y {
*Date of credit voucher, transaction receipt or refund
acknowledgement: (Date, Required)
}
N {
*Date the cardholder cancelled the service or returned the
merchandise: (Date, Required)
}
}
}
N {
Invalid
}
}
}
DM (Damaged or Defective Merchandise) {
*What was purchased - Merchandise / Services {
Merchandise {
Provide certification of one of the following {
Merchant refused to provide return authorization
Merchant refused to accept returned merchandise
Merchant informed cardholder not to return the merchandise
}
}
Services {}
}
*What was ordered and how it was damaged or defective
*Date merchandise was received
*Date the cardholder first notified the issuer of the dispute
*Did the cardholder attempt to resolve the dispute with
the merchant - Y/N {
Y {}
N {
*Is attempt to resolve prohibited by local law or regulations - Y/N {
Y {
*Provide details of local law or regulations
}
N {
Invalid
}
}
}
}
*Did the cardholder return the merchandise - Y/N {
Y {
*Date Cardholder returned the merchandise
*Date merchant received the returned merchandise
*Return Method - Face to Face/FedEx/DHL/UPS/Postal Service/Other {
Face to Face {}
FedEx {
Tracking Number
}
DHL {
Tracking Number
}
UPS {
Tracking Number
}
Postal Service {
Tracking Number
}
Other {
Explain how the merchandise was returned
}
}
}
N {
Did cardholder attempt to return the merchandise - Y/N {
Y {
*Date of attempted return
*Explain how the merchandise was returned
*Provide a detailed description of how the cardholder
attempted to return and the disposition of the
merchandise
}
N {}
}
}
}
}
NR (Merchandise or Services not received) {
*Provide detailed description of what was purchased and an explanation
of the dispute
*What was the expected receipt date AND time
*Did the cardholder cancel prior to the expected date - Y/N {
Y {
*Cancellation Date
*Cancellation Reason
}
N {}
}
*Did the cardholder attempt to resolve the dispute with the merchant - Y/N {
Y {}
N {
*Is attempt to resolve prohibited by local law or regulations - Y/N {
Y {
*Provide details of local law or regulations
}
N {
Invalid
}
}
}
}
*What was not received - Merchandise/Services {
Merchandise {
*Provide detailed description of what was purchased and an explanation
of the dispute: (Free text, Required)
*What was the last expected receipt date? (Date, Required)
*What was the last expected receipt time? (Free text, optional)
*Did the cardholder cancel prior to the expected date? (Y/N, Required) {
Y {
Cancellation Date: (Date, Required)
Cancellation Reason (Free text, Optional)
}
N {}
}
*Did the cardholder attempt to resolve the dispute with the
merchant? (Y/N, Required) {
Y {}
N {
*Is attempt to resolve prohibited by local law or regulations?
(Y/N, Required) {
Y {}
N (
Invalid
}
}
}
}
*Was the merchandise delivered late or to the wrong location?
(Y/N, Required) {
Y {
*Provide address of the agreed location or details of late
delivery: (Free text, Required)
*Did the cardholder return the merchandise? (Y/N, Required) {
Y {
*Date cardholder returned the merchandise (Date,
Required)
*Date merchant received returned merchandise (Date,
Required)
}
N {
*Did the cardholder attempt to return the
merchandise? (Y/N, Required)
}
Y {
*Date of attempted returned (Date, Required)
}
N {}
}
}
}
*Did merchant cancel the merchandise?
(Y/N, Required) {
Y {
*Date merchant cancelled merchandise (Date, Required)
}
N {}
}
}
Service {
*Provide detailed description of what was purchased and an explanation
of the dispute: (Free text, Required)
*What was the last expected receipt date? (Date, Required)
*What was the last expected receipt time? (Free text, optional)
*Did the cardholder cancel prior to the expected date? (Y/N, Required) {
Y {
Cancellation Date: (Date, Required)
Cancellation Reason (Free text, Optional)
}
N {}
}
*Did the cardholder attempt to resolve the dispute with the merchant?
Y/N, Required) {
Y {}
N {}
}
*Is attempt to resolve prohibited by local law or regulations?
(Y/N, Required) {
Y {}
N {
Invalid
}
}
*Is the purchase a third-party gift card without an expiration date,
where the merchandise or services were not provided by the third
party due to insolvency or bankruptcy? (Y/N, Required)
*Did merchant cancel services?
(Y/N, Required) {
Y {
*Date merchant cancelled services (Date, Required)
}
N {}
}
}
}
}
ND (Not as Described) {
*Date merchandise or service was received
*Date the cardholder first notified the issuer of the dispute
*Does the dispute involve merchandise or services provided that do not match
the merchant's verbal description - Y/N {
Y {
*Did the cardholder attempt to resolve the dispute with the
merchant - Y/N {
Y {}
N {
*Is attempt to resolve prohibited by local law or regulations {
Y {
*Provide details of local law or regulations
}
N {
Invalid
}
}
}
}
}
N {}
}
Did the merchandise or services differ from what was described
on the receipt - Y/N {
Y {
Provide details of what was ordered and not as described
}
N {
*Provide details of what was ordered and not as described
}
}
*Is attempt to resolve prohibited by local law or regulations - Y/N {
Y {
*Provide details of local law or regulations
}
N {
Invalid
}
}
*What was purchased - Merchandise / Services {
Merchandise {
*Did the cardholder return the merchandise - Y/N {
Y {
*Date cardholder returned the merchandise
*Date merchant received the returned merchandise
*Return Method - Face to Face/FedEx/DHL/UPS/Postal Service/
Other {
Face to Face {}
FedEx {
Tracking Number
}
DHL {
Tracking Number
}
UPS {
Tracking Number
}
Postal Service {
Tracking Number
}
Other {
Explain how the merchandise was returned
}
}
}
N {
*Did the cardholder attempt to return the
merchandise - Y/N {
Y {
*Date of attempted return
*Provide a detailed description of how the cardholder
attempted to return and the disposition of the
merchandise
}
N {}
}
}
}
Provide certification of one of the following {
Merchant refused to provide return authorization
Merchant refused to accept returned merchandise
Merchant informed cardholder not to return the merchandise
}
}
Services {
*Did the cardholder cancel the services - Y / N {
Y {
*Cancellation Date
*Cancellation Reason
}
}
}
}
}
CL (Non Receipt of Cash or Load) {
}
```
For detailed information on consumer disputes, see [The consumer\_dispute\_type\_dispute\_details object](/core-api/disputes-visa/#_the_consumer_dispute_type_dispute_details_object) on the Disputes (Visa) page in the Core API Reference.
Dispute reasons
Reason codes indicate the reason for a dispute. For a list, see [The dispute\_details.dispute\_reason field](/core-api/disputes-visa/#_the_dispute_details_dispute_reason_field) in the Visa Cases API Reference.
Uploading documents
Cardholders must attach necessary documents to support their claim. Visa requires that supporting documents be uploaded only for Consumer disputes. The `OPEN`, `OPEN_WITH_ACTION_REQUIRED`, and `READY` states where documents can be uploaded.
About associated transactions
When an additional transaction or credit is attached to a transaction dispute, the dispute can become invalid at the card network, requiring additional steps to transition the dispute case. As part of the dispute process, Marqeta proactively identifies transactions such as a credit, reversal, or adjustment that may be associated with the disputed transaction and could render the dispute invalid.
Some transactions may appear to be but are not associated with a transaction. These transactions must be identified before submitting them to the card network. If a transaction dispute that has an associated transaction is submitted to the card network, it will be invalidated, requiring the dispute to be resubmitted.
Submitting a dispute
To submit a dispute and check for and resolve associated transactions, follow these steps:
* Create the dispute case.
* If there are possible associated transactions, get the list.
* Submit the batch of associated transactions.
* Transition the dispute case to `READY`.
* Transition the dispute case to `CHARGEBACK_INITIATED`.
* Update the associated transactions, if necessary.
* Close or withdraw a dispute.
* Recreate the dispute case, if necessary.
Each of these steps are described in detail in the following sections.
Creating the dispute case
Create a dispute case by sending a `POST` request to the `/cases` endpoint. The `associated_transaction_selection_required` field of the `dispute_details` object indicates whether there are any transactions that may be associated with the current dispute. If so, a list of those transactions is downloaded, the `associatedTransactionSelectionRequired` field is set `true`, and the case is put into the `OPEN_WITH_ACTION_REQUIRED` state.
Transitioning the dispute case to READY
After the required information has been provided, transition the dispute case to `READY` by sending a `POST` request to the `/cases/{token}/transitions` endpoint with the `action` field set to `REVIEW`, Marqeta determines if there are any associated transactions for the dispute case. If there are associated transactions, the transition to `READY` will fail because the associated transactions must be resolved and the dispute case will be moved to the `OPEN_WITH_ACTION_REQUIRED` state.
Getting a list of potentially associated transactions
Send a `GET` to the `/cases/{case_token}/associated_transactions` endpoint to get a list of transactions that are potentially associated with the given dispute case. For details, see [List Associated Transactions](/core-api/disputes-visa/#_list_associated_transactions) in the Disputes API (Visa) reference.
Submitting a batch of associated transactions
To submit a list to the card network indicating which transactions are associated with a dispute case, send a `POST` to the `/cases/{case_token}/associated_transactions/selection` endpoint with the details of each transaction. For details, see [Submit a batch of associated transactions](/core-api/disputes-visa/#_submit_a_batch_of_possibly_associated_transactions) in the Cases API (Visa) reference.
Sending a dispute case to the card network
A dispute case is sent to the card network when the dispute case is transitioned to the `CHARGEBACK_INITIATED` state. Once the dispute case is submitted to the card network, it moves through the card network dispute transitions until the dispute is resolved by the card network, and can then be closed.
Resubmitting associated transactions
When you transition a dispute case to `READY` or `CHARGEBACK_INITIATED` by calling the `/cases/{token}/transitions` endpoint with the state set to `READY`, Marqeta determines if there are any new associated transactions for the dispute case. If there are any new associated transactions, the transition to `READY` will fail because the associated transaction must be resolved and the dispute case will be moved to the `OPEN_WITH_ACTION_REQUIRED` state.
To resubmit the associated transactions after they have been submitted to the card network, send a `PUT` request to the `/cases/{token}/associated_transactions/selection` endpoint. If the associated transaction does not equal the total amount, resubmit the dispute for the partial amount. For details, see [Update submitted associated transactions](/core-api/disputes-visa/#_update_submitted_associated_transactions) in the Disputes API (Visa) reference.
Managing provisional credits
[Regulation E](https://www.federalreserve.gov/supervisionreg/regecg.htm), the United States regulation implementing the Electronic Fund Transfer Act, provides a framework for protecting customers who use electronic methods to transfer money, as well as guidelines for electronic debit card issuers throughout the dispute investigation process.
Regulation E allows for up to 45 days to resolve these disputes but, during that time, you must typically issue a provisional credit for the disputed amount. The provisional credit must be provided within 10 days after the customer made first contact. If a dispute is not resolved within the required 45-day time frame, the provisional credit is automatically granted to the cardholder.
You can manage provisional credit in Marqeta Dashboard for your Regulation E compliant programs. For more details, see [Disputes in the Dashboard](/developer-guides/disputes-dashboard/). For details on managing provisional credits using the `/cases` endpoint, see [Managing Provisional Credits](/developer-guides/disputes-regulation-e/).
Closing or withdrawing a dispute
When a `POST` request to the `/cases/{token}/transitions` endpoint is called with `stateTo` set to `CLOSE` and action `WITHDRAW_AND_CLOSE` with a `reason_code` of `40`, Marqeta determines if the dispute case is in a state that allows the transition. If so, an entry is created in the dispute case transitions history with the new transition and the dispute case state is set to `CLOSED`.
For any disputes that are returned as an associated transaction, close those disputes using the `/cases/{token}/transitions` endpoint. If there are no associated transactions, no action is necessary.
A dispute case can only be withdrawn if the dispute case is in the following the `OPEN`, `READY`, or `OPEN_WITH_ACTION_REQUIRED` state. The dispute case can only move to `CLOSED` with a `WITHDRAW_AND_CLOSE` action. If the transition is to `CLOSED` with `WITHDRAW_AND_CLOSE` and the dispute case state is not in the previously stated valid states, the transition will fail.
Monitoring states using the Webhooks endpoint
Marqeta receives state changes for each dispute from the card network and makes them available to you through webhooks. To monitor these, use the `/webhooks` endpoint to subscribe to the chargeback transition events described in [Webhooks](/core-api/webhooks/).
You can also subscribe to the following additional events in order to track chargeback progress:
* `authorization.clearing.chargeback`
* `authorization.clearing.chargeback.completed`
* `authorization.clearing.chargeback.provisional.credit`
* `authorization.clearing.chargeback.provisional.debit`
* `authorization.clearing.chargeback.reversal`
* `authorization.clearing.representment`
* `pindebit.chargeback`
* `pindebit.chargeback.completed`
* `pindebit.chargeback.provisional.credit`
* `pindebit.chargeback.provisional.debit`
* `pindebit.chargeback.reversal`
* `pindebit.representment`
For a detailed description of these events, see [Transaction Events](/core-api/event-types/#_transaction_events).
Resolution timeframes
Visa dispute responses are required within a specific timeline. The Visa lifecycle proceeds differently for Allocation or Collaboration disputes as shown in following diagram.
The following describes the expected timelines from the Visa SLA for responses to an allocation or collaboration dispute.
Fraud and authorization (allocation):
* **Prearbitration:** 30 days
* **Prearbitration response:** 30 days
* **Arbitration response:** 10 days
Processing errors and consumer disputes (collaboration):
* **Dispute response:** 30 days
* **Prearbitration:** 30 days
* **Prearbitration response:** 30 days
* **Arbitration response:** 10 days
Reporting fraud
The Visa network requires issuers and programs to report fraud to the card network regardless of the amount. Whenever a cardholder reports fraud, a subsequent fraud report must be created with the card network. Noncompliance with card network rules results in fines and suspension of the ability to process chargebacks. Fraud reports can be submitted from the Disputes dashboard or using the `/cases` endpoint.
To submit a fraud report using the `/cases` endpoint, send a `POST /cases` request with `FRAUD_REPORT` as the `dispute_reason` in the [dispute\_details\_dispute\_reason](/core-api/disputes-visa/#_the_dispute_details_dispute_reason_field) field and the required information in the \[fraud\_category\_type\_dispute\_details]\(/disputes-visa/#\_The fraud\_category\_type\_dispute\_details\_object) object. For an example, see [Sample request body](/core-api/disputes-visa/#_sample_request_body_fraud).
Rejection from the Visa network for Compelling Evidence 3.0-enabled merchants
In response to the growth of digital commerce, Visa Compelling Evidence 3.0 expands the list of compelling evidence you can use to help invalidate certain customer disputes.
**Compelling evidence** is proof the cardholder participated in the transaction, received the goods or services, or benefitted from the transaction. This determines how much and the types of evidence you must submit to resolve customer disputes before submitting a dispute. If the merchant is enabled for Compelling Evidence 3.0, and there are at least two historic transactions that meet the Remedy Prior Undisputed transaction criteria, rejection from the card network can happen at two points in the dispute workflow:
* Pre-dispute
* Post-dispute
Pre-dispute rejects
If a rejection happens in this case, one of the following errors are generated when you attempt to initiate the dispute with the card network. These disputes move to `OPEN_WITH_ACTION_REQUIRED`. For the `/cases` endpoint, the following error messages are captured in the card network reject webhooks:
| Error Code | Message | Meaning and Expected User Action |
| ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| E-900003544 | Dispute is invalid as prior transactions were detected for this merchant with the same data elements (IP Address, Device ID, etc.). Neither of these transactions were reported as fraud activity to Visa. This transaction will not be counted as a fraud activity. | Remedy Prior Undisputed Transactions conditions have been met—that is, the merchant has signed up for Remedy Prior Undisputed transactions and there are at least two historical transactions (120-365 days old), which establishes the undisputed transaction history between the merchant and the cardholder.
There are no dispute rights on this transaction. You can mark these disputes as Program Write-off or Case Lost. If you have enough evidence that the dispute was rejected incorrectly, you can request an exception review, with an additional fee. |
| E-900003545 | This dispute is still processing and please resubmit. | Indicates that the merchant has signed up for Compelling Evidence 3.0 and Visa is attempting to retrieve the Compelling Evidence 3.0 data from the merchant.
You can attempt to resubmit these disputes after a brief waiting period. |
| E-900003543 | Dispute is invalid as it was qualified under the Visa Remedy criteria. This transaction will not be counted as a fraud activity. | Appears if you attempt to raise a 10.4 dispute against a transaction that already had a fraud dispute reject due to Compelling Evidence 3.0 (E-900003544). The chargeback cannot be initiated with the card network. |
Post-dispute rejects
Merchants can provide Compelling Evidence 3.0 data during prearbitration of a 10.4 dispute. In this case, the dashboard displays the prearbitration reason as RE (Remedy Prior Undisputed transaction), along with historic data that establishes undisputed transaction history between the merchant and the cardholder. You can either accept liability or respond to the prearbitration after reviewing the Compelling Evidence 3.0 data. If you decline prearbitration, sufficient evidence should be provided to dispute the Compelling Evidence 3.0 data.
Criteria for Compelling Evidence 3.0
Compelling Evidence 3.0 rules require that merchants share data that helps establish a historical footprint of previous purchase history by sharing two previous transactions that meet certain criteria, including:
* The transactions must be at least 120 days old (calculated from the dispute date).
* The transaction must have no active fraud report.
* The transaction must have no active fraud dispute.
* At least two of the core data elements (user ID, IP address, shipping address, device ID/fingerprint) match between prior transactions and the disputed transaction, and one of the two must be either the IP address or device ID/fingerprint.
* Transactions must be from the same merchant.
* An item description must be provided for the transactions.
For details and exceptions to these guidelines, see the [Visa FAQ](https://usa.visa.com/content/dam/VCOM/regional/na/us/support-legal/documents/evolution-of-compelling-evidence-external-faqs.pdf).
Smart rejects
When a user submits a dispute that would eventually be rejected by the card network, smart reject rules allow those disputes to be rejected earlier in the dispute lifecycle, minimizing the operational cost. Smart rejects are implemented through webhooks. For details on smart rejects, see [Smart rejects](/core-api/event-types/#_smart_rejects) in Event Types.