> ## 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.

# About Disputes

> Learn about the dispute resolution process, including the dispute lifecycle and best practices.

Transaction disputes are a necessary part of card issuing. Marqeta enables you to manage the dispute process using the Marqeta Dashboard or with the `/cases` endpoint. You can manage disputes by performing tasks such as submitting a dispute, retrieving information such as dispute status, and uploading supporting documents.

This page provides information on the dispute process and best practices. For information on how to manage disputes in the Marqeta Dashboard, see [Disputes in the Dashboard](/developer-guides/disputes-dashboard/). For specific details on how to integrate with the Mastercard or Visa network, see [Managing Mastercard Disputes](/developer-guides/managing-mastercard-disputes/) or [Managing Visa Disputes](/developer-guides/managing-visa-disputes/). For reference information, see [Disputes (Mastercard)](/core-api/disputes-mastercard/), [Disputes (PULSE)](/core-api/disputes-pulse/), or [Disputes (Visa)](/core-api/disputes-visa/) in the Core API reference.

<Note>
  **Note**\
  The dispute process is the same for both virtual and physical cards.
</Note>

<h2 id="_what_is_a_dispute">
  What is a dispute?
</h2>

A *dispute* is a request or process to have a transaction charged back to the cardholder. A dispute is often initiated if a cardholder:

* Did not receive a product or service.

* Did not recognize the charge or business name on their statement.

* Believes the product to be damaged, defective, or not as described.

* Was the victim of fraud, card theft, or identity theft.

A **chargeback** is a transaction reversal that occurs if a cardholder wins the dispute, providing consumer protection from fraudulent or disputed activity from merchants. **Cases** are Marqeta’s dispute management solution, allowing you to manage dispute progress.

<h2 id="_best_practices">
  Best practices
</h2>

The following are best practices for resolving your disputes and optimizing your win rates:

* When a card is reported lost or stolen, immediately deactivate the card to ensure a tight timeline between a lost card and potential transactions. Submit the dispute case immediately after the dispute has been opened by the cardholder.

* If your team is working directly with cardholders, create a dispute form or use an example from Marqeta for gathering as much information as possible along with the cardholder’s attestation of the dispute.

* Provide the strongest possible level of documentation, such as communication with the merchant, receipts, and timelines. Incomplete dispute information or lack of documentation can decrease the likelihood of winning a dispute.

* If the dispute involves goods and services issues with a merchant, have a representative of your company or the cardholder first contact the merchant directly, which can result in a refund and make a dispute unnecessary.

<Note>
  **Note**\
  No more than 15 fraud-related disputes can be initiated against the same primary account number (PAN, also known as the card number).
</Note>

<h2 id="_before_initiating_a_dispute">
  Before initiating a dispute
</h2>

Before you initiate a dispute, advise the cardholder to contact the merchant directly to resolve the issue. If the issue cannot be resolved, begin the dispute process by initiating a dispute case. You must submit a dispute even if the amount does not meet the program’s dispute threshold.

Have the cardholder complete a dispute form and submit that form with any supporting documentation that might assist in the dispute review process, such as receipts or email communication with the merchant. Incomplete dispute forms or insufficient details increase the likelihood of losing the dispute.

<h2 id="_the_dispute_lifecycle">
  The dispute lifecycle
</h2>

Once the cardholder has contacted you indicating their intention to dispute a transaction, the 30-day SLA timeline for compliance begins.

Disputes are required to follow a series of steps defined by the card networks and participating banks. You start the process when you create a dispute case. As you define the dispute details, the dispute is tracked by dispute case states. After you submit a dispute case to the network, the dispute is tracked by the network using network dispute states.

The following diagram shows the overall lifecycle, including dispute case states and network dispute states.

<Frame>
  <img src="https://mintcdn.com/marqeta-b295cded/TxQgVKoSBbsxuEcD/images/docs/developer-guides/about-disputes/dispute_lifecycle.png?fit=max&auto=format&n=TxQgVKoSBbsxuEcD&q=85&s=7ba9c62acb0a30f4fac30582ad49a57d" alt="Dispute Lifecycle" width="700" height="774" data-path="images/docs/developer-guides/about-disputes/dispute_lifecycle.png" />
</Frame>

<Steps>
  <Step>
    **Presentment**: The transaction clears. This is a typical transaction clearing event. In order for there to be a dispute, the transaction must first clear.
  </Step>

  <Step>
    **Create case:** The user creates a dispute case to dispute the transaction on behalf of the cardholder, beginning in the `OPEN` or `OPEN_WITH_ACTION_REQUIRED` state.
  </Step>

  <Step>
    **Prepare case:** The user assembles the necessary information to prepare the dispute at the network. When all the information and supporting documents are assembled, the dispute case progresses to the `READY` state.
  </Step>

  <Step>
    **Submit case:** The user submits the dispute to the network. The dispute case state transitions to `CHARGEBACK_INITIATED`. If the dispute case is rejected, it enters the `network.rejected` state and exits the dispute lifecycle. Review the dispute case to determine if it can be resubmitted.
  </Step>

  <Step>
    **Network dispute initiated**: The dispute enters the network dispute lifecycle in the `initiated` state. The acquiring bank can respond to the dispute directly or forward it to the merchant. If forwarded to the merchant, the merchant can accept the loss or provide documentation to refute the dispute claim.
  </Step>

  <Step>
    **Representment (Second Presentment)**: The acquiring bank attempts to refute the claim, likely because they believe it is invalid or incomplete. Merchants have recourse to defend against the claim by submitting a representment. For example, if a cardholder claims fraud in a card present transaction, the merchant may provide the card network with a representment that includes a signed copy of the receipt. In this case, the merchant has complied with their requirements and is not liable. The dispute enters the `representment` state.
  </Step>

  <Step>
    **Prearbitration**: Upon receipt of the representment, Marqeta may choose to reach out to the acquiring bank once again. Visa refers to this additional step as **prearbitration**. This optional step allows the merchant an additional opportunity to provide supporting documentation. The dispute enters the `prearbitration` state.
  </Step>

  <Step>
    **Arbitration**: All information and supporting data has been provided to the network and the network makes a decision. The network’s decision is final and must be accepted by both Marqeta and the acquiring bank.
  </Step>

  <Step>
    **Resolution**: After arbitration, the dispute is resolved and enters into either the `case.won` or `case.lost` state.
  </Step>

  <Step>
    **Close case:** The user closes the case, which enters the `CLOSED` state.
  </Step>
</Steps>

<Note>
  **Note**\
  The vast majority of disputes are resolved during the Initiated state. Disputes typically take 30-120 days to resolve. A dispute is won if the acquirer does not respond to the dispute within the expected timeline. Expected timelines vary according to the card network, which are defined in their respective 30-day service level agreement (SLA) timelines. For the Visa SLA, see [Managing Visa Disputes](/developer-guides/managing-visa-disputes/#_resolution_timeframes).
</Note>

<h3 id="_disputes_under_threshold">
  Disputes under threshold
</h3>

To ensure that all disputes are visible and meet the regulatory compliance, you must submit a dispute even if it does not meet the program’s dispute threshold. It is mandatory for Managed by Marqeta (MxM) programs that are on Marqeta’s regulatory platform to submit all disputes, even if they are under threshold. When you submit such a dispute, it is processed as follows:

<Steps>
  <Step>
    Marqeta automatically issues a provisional credit.
  </Step>

  <Step>
    Dispute system applies a program write-off.
  </Step>

  <Step>
    Case is moved to a `CLOSED` state and a `case.won` resolution, without submission to the network.
    <br />Marqeta informs cardholders of the status of the case based on the communication process.
    <br /> If you manage cardholder communications, you are responsible for informing cardholders.
  </Step>

  <Step>
    Fraud is automatically reported when applicable.
  </Step>
</Steps>

<Note>
  **Note**\
  For customers whose cardholder notifications are not managed by Marqeta, you must implement additional logic to handle the provisional credit webhooks based on the dispute amount. For more information about webhook updates, reach out to your Marqeta representative.
</Note>

<h2 id="_states_and_transitions">
  States and transitions
</h2>

**Case states** indicate the status of a dispute case as you prepare it before submitting to the network. **Network disputes states** represent the current state at the network. **Case transitions** move the dispute through the dispute case states on the Marqeta platform. Once a dispute case has been submitted to the network, the dispute progresses through the network dispute lifecycle and is tracked using **network dispute states**. **Transitions** move a dispute through the resolution process by moving the dispute to the next state. **Case transitions** move the dispute through the dispute states; **network dispute transitions** move the dispute through the network dispute states.

<h2 id="_dispute_case_states">
  Dispute case states
</h2>

Dispute case states include the following. The `OPEN`, `OPEN_WITH_ACTION_REQUIRED`, and `READY` states are staging states where information can be gathered and other concerns addressed. The `CHARGEBACK_INITIATED` state formally starts the dispute process at the network.

| State                       | Description                                                |
| --------------------------- | ---------------------------------------------------------- |
| `OPEN`                      | The dispute case was created.                              |
| `OPEN_WITH_ACTION_REQUIRED` | The dispute case has been created with an action required. |
| `READY`                     | The dispute case is ready for review.                      |
| `CHARGEBACK_INITIATED`      | A dispute was initiated at the network.                    |
| `CLOSED`                    | The dispute case was closed.                               |

<h2 id="_network_dispute_states">
  Network dispute states
</h2>

Once a dispute has been initiated, it flows through a series of states, or **transitions**. The following are the states involved in a dispute case resolution:

* Initiated

* Representment

* Prearbitration

* Arbitration

* Case won

* Case lost

* Network rejected

The following sections describe the details and responsibilities for the key states involved in resolving a dispute.

<h3 id="_initiated">
  Initiated
</h3>

After presentment, the dispute enters the `initiated` state. The request is reviewed and the dispute initiated with the card network as follows:

* Depending on the reason for the dispute, Marqeta applies a provisional credit to the cardholder’s account.

* If additional information or documentation is required, Marqeta requests this information from you.

* You are notified when the dispute is initiated.

If the acquiring bank forwards the dispute claim to the merchant, the merchant may accept the loss or provide the additional information to refute the claim.

<h3 id="_representment">
  Representment
</h3>

If the acquiring bank attempts to refute the claim, the merchant can defend the claim by submitting a representment, also known as the dispute response. The dispute then enters the `representment` state. For example, if a cardholder claims fraud in a card present transaction, the merchant could provide proof that the card was swiped and show that they have a copy of the receipt signed by the cardholder. The merchant has then complied with the card network requirements and is not liable.

Marqeta reviews the representment:

* Marqeta may request additional documentation from the cardholder in order to resubmit the dispute case to the card network.

* Marqeta resubmits the dispute case, if appropriate.

After the above actions, the information is reviewed by the card network to determine whether the cardholder or the merchant wins the dispute and returns the decision to Marqeta.

<h3 id="_prearbitration">
  Prearbitration
</h3>

The dispute case enters the `prearbitration` state if Marqeta chooses to reach out to the acquiring bank once again after the dispute has entered representment. Marqeta may submit updated information to support the dispute.

Prearbitration allows the cardholder and the merchant to provide further information about the dispute. It also allows the cardholder to submit a second dispute if the initial dispute was rejected. Prearbitration and the Prearbitration Response can take up to 30 days for each part of the process. For the Visa lifecycle, prearbitration proceeds differently, with different timelines, for Allocation or Collaboration disputes.

For detailed information about the timelines for prearbitration, see [Mastercard resolution timeframes](/developer-guides/managing-mastercard-disputes/#_resolution_time_frames) or [Visa resolution timeframes](/developer-guides/managing-visa-disputes/#_resolution_timeframes).

<Note>
  **Note**\
  Only relevant dispute cases assume this status.
</Note>

<h3 id="_arbitration">
  Arbitration
</h3>

The dispute case enters the `arbitration` state when the acquirer disputes a claim, and the issuer submits the case to the card network for arbitration. In arbitration, the card network decides who wins the dispute case.

<h3 id="_case_won">
  Case won
</h3>

If the dispute is won by the cardholder, it enters the `case.won` state. Marqeta completes the following actions:

* If a provisional credit was not issued at the time when the dispute was initiated, the customer’s account is credited for the amount of the dispute.

* If a provisional credit was issued at the time when the dispute was initiated, no further action is required.

<h3 id="_case_lost">
  Case lost
</h3>

If the dispute is lost by the cardholder, it enters the `case.lost` state. Marqeta completes the following actions:

* If a provisional credit was issued when the dispute was initiated, the provisional credit is reversed by debiting the customer’s account in the amount of the dispute.

* If a provisional credit was not issued when the dispute was initiated, no further action is required.

<h3 id="_network_rejected">
  Network rejected
</h3>

If the card network rejects the dispute submission, the dispute enters the `network.rejected` state in which case the dispute amount may be written off by either the issuer or the program or resubmitted with updated details. For guidelines for reducing network rejections, see [Best practices](/developer-guides/about-disputes/#_best_practices).

<h2 id="_resolving_disputes">
  Resolving disputes
</h2>

Additional considerations for resolving disputes include notifying the cardholder of the dispute outcome and managing provisional credits, reconciliation, mitigation, and true-up transactions.

<h3 id="_notifying_the_cardholder">
  Notifying the cardholder
</h3>

Once a dispute is resolved, notify the cardholder of the outcome. Example email templates are provided below for both the case won and case lost scenarios.

<Note>
  **Note**\
  These templates are provided for your reference and convenience. Communication of outcomes to cardholders is your responsibility.
</Note>

<h4 id="_case_won_email_template">
  Case won email template
</h4>

The review of the transaction you disputed on `[DATE]` has been completed. We are pleased to report that the dispute has been resolved in your favor and your account has been credited for the disputed amount.

* Dispute details: XXXXX

* Amount of the credit to your account: XXXXX

* Date of the credit to your account: XXXXX

<h4 id="_case_lost_email_template">
  Case lost email template
</h4>

The review of the transaction you disputed on `[DATE]` has been completed. We regret to inform you that the dispute has been resolved in favor of the merchant. The provisional credit to your account, if any, has been reversed.

* Dispute details: XXXXX

* Original transaction amount: XXXXX

* Amount of the provisional credit reversal adjustment to your account: XXXXX

* Date of the reversal: XXXXX

<h3 id="_managing_partial_chargebacks">
  Managing partial chargebacks
</h3>

If a merchant promises a product but delivers only a portion of their transaction obligation, a cardholder may request a chargeback for the undelivered portion of the total transaction amount. If a partial chargeback is indicated, Marqeta initiates the dispute for the partial amount.

<h3 id="_managing_provisional_credits">
  Managing provisional credits
</h3>

Some dispute scenarios require that a cardholder be issued a provisional credit. However, provisional credit can be issued in any dispute scenario.

<h4 id="_issuing_provisional_credits">
  Issuing provisional credits
</h4>

Deciding when to issue a provisional credit is a joint responsibility shared between you and Marqeta. It is your responsibility to conform to regulations that govern provisional credits. However, since provisional credits can be issued in any dispute scenario at your discretion, it is your responsibility to request that Marqeta issue a provisional credit.

<h4 id="_reversing_provisional_credits">
  Reversing provisional credits
</h4>

If a provisional credit must be reversed, it is your responsibility to request the reversal and Marqeta’s responsibility to implement the reversal.

<h4 id="_reconciling_provisional_credits">
  Reconciling provisional credits
</h4>

It is your responsibility to reconcile disputes for lost cases against any funds issued to the cardholder. To do this, subscribe to the webhooks described in [Event Types](/core-api/event-types/). Maintain a ledger for tracking when cardholders have been compensated, when they should be compensated, and when their provisional credit should be reversed. For information on monitoring states, see [About Webhooks](/developer-guides/about-webhooks/).

<h3 id="_reconciling_disputes">
  Reconciling disputes
</h3>

You are responsible for reconciling all disputes, regardless of provisional credit issuance. To reconcile a dispute, use the Chargebacks report in the [Marqeta Dashboard](/developer-guides/reports-dashboard/). To view reports on current dispute cases, see the Settlements report.

<h3 id="_mitigation">
  Mitigation
</h3>

Dispute mitigation is a joint responsibility shared between you and Marqeta. Vet your cardholders and take proactive steps to prevent transactions from entering the dispute stream.

<h3 id="_true_up_transactions">
  True-up transactions
</h3>

A monthly "true-up" transaction adjusts the funds between cardholder bank account balances and enterprise reserve bank accounts. The "true-up" corrects for any discrepancies based on provisional or other credits issued to the customer, as well as whether or not the dispute case was won by the cardholder.

<h2 id="_resolution_timeframes">
  Resolution timeframes
</h2>

Disputes must conform to specific resolution timeframes, which vary among card networks. Expected timelines are defined in their respective 30-day service level agreement (SLA) timelines. For the Mastercard SLA, see [Resolution timeframes](/developer-guides/managing-mastercard-disputes/#_resolution_time_frames) in Managing Mastercard Disputes. For the Visa SLA, see [Resolution timeframes](/developer-guides/managing-visa-disputes/#_resolution_timeframes) in Managing Visa Disputes.


## Related topics

- [Disputes Overview](/docs/developer-guides/disputes-landing-page.md)
- [Disputes (PULSE)](/docs/core-api/disputes-pulse.md)
- [Disputes (Mastercard)](/docs/core-api/disputes-mastercard.md)
- [Disputes in the Marqeta Dashboard](/docs/developer-guides/disputes-dashboard.md)
- [Managing Visa Disputes](/docs/developer-guides/managing-visa-disputes.md)
