Skip to main content
Once the dispute enters the READY state, you can submit it to the card network for processing. Submitting the dispute formally initiates the chargeback with the card network.
Caution
In production, Marqeta handles all network-side state transitions once a chargeback is submitted. To simulate the card transitions once the dispute is submitted, you will call the /disputetransitions endpoints. This endpoint is not used in the production environment. This guide includes the following steps only to illustrate the transitions that occur automatically.

Submitting a dispute to the card network

After reviewing the dispute case in a READY state, Marqeta submits it to the card network and the case transitions to the CHARGEBACK_INITIATED network state. You can simulate submitting a dispute using a POST /cases/<case_token>/transitions request. The chargeback can be initiated for a provisional credit or no credit flow. The example below demonstrates a no-credit chargeback flow by sending CHARGEBACK_NO_CREDIT in the action field.

Sample request body

Sample request

Sample response body

Sample response

Upon submission, the dispute case transitions to the CHARGEBACK_INITIATED Marqeta state and the initiated network state.
Note
If the network rejects the submission, the dispute enters the network.rejected network state and the Marqeta state transitions to CLOSED. You can review the case and resubmit it with corrected details.
When a dispute is submitted and enters a chargeback state, the Marqeta platform triggers specific webhooks. The exact webhooks depend on whether the the action involves a provisional credit or no credit flow. The reason_code used must match the action being performed. Test your webhook handlers based on the selection you make from the following options. If you select the CHARGEBACK_CREDIT action for provisional credit, the following webhook events are sent:
  • transactions.authorization.clearing.chargeback
  • chargebacktransitions.initiated
  • transactions.authorization.clearing.chargeback.provisional.credit.
If you select the CHARGEBACK_NO_CREDIT action for no credit, the following webhook events are sent:
  • transactions.authorization.clearing.chargeback
  • chargebacktransitions.initiated.
Note
There can be a delay between the time an action is taken and when the webhook is sent. This is true for all webhooks.

Dispute identifiers

Marqeta and the card network identify a dispute using different tokens, as described below:
  • Case creation: When a case is created, you have the reason code, and your primary identifier is the transaction token. This is the identifier Marqeta uses to identify the dispute.
  • Chargeback initiation: When a chargeback is initiated on the network, you receive both the transaction token and the chargeback token. The card network uses the chargeback token to identify the dispute.
To effectively track and manage chargebacks, Marqeta recommends that you:
  • Maintain a mapping: Store the relationship between the reason code and the transaction token within your system.
  • Link the identifiers: Once a chargeback is initiated, use the chargeback token to tie the network event back to the original transaction token.
  • Associate the reason code: Ensure the reason code is associated with the chargeback token for future tracking.
Note
  • The chargeback token will be the identifier that is sent throughout the lifecycle of disputes in all subsequent webhooks.
  • There can be multiple disputes associated with a transaction. Hence, the chargeback token is the right identifier to map to a reason code.

Providing provisional credit

Granting provisional credit is required if your program is subject to specific regulations. You are responsible for providing this credit if your program manages the ledger via Just-in-Time (JIT) funding. For this example, which uses the CHARGEBACK_NO_CREDIT action, the system does not require provisional credit. However, this section provides an example of requesting provisional credit below for reference.

Sample request body

Simulating merchant representment

In some cases, the acquiring bank might forward the dispute claim to the merchant. A merchant can choose to accept the dispute or challenge it. Marqeta might request additional documentation from the cardholder to resubmit the dispute. After the representment is received from the merchant, card network reviews the information to determine if the cardholder or merchant wins the dispute. In the sandbox, you can simulate merchant representment (the merchant’s response to the dispute) using the POST /cases/<case_token>/disputetransitions endpoint. Define the amount field within the network_details.representment_details object in the request body to simulate the representment.

Sample request body

Sample request

Sample response body

Sample response

This request transitions the network state to representment and Marqeta state remains as CHARGEBACK_INITIATED. If the merchant challenges the chargeback, you receive an authorization.clearing.representment event.

Representment in Visa

When a dispute goes through the Visa network, the representment state does not always apply. Visa uses the following dispute flows depending on the reason code provided:
  • Collaboration: For reason codes related to fraud and authorization. This flow can simplify the case management process and move it along faster.
    • Collaboration flow: Initiated → Representment → Prearbitration (decline or responded) → Arbitration.
  • Allocation: For all other reason codes. The allocation flow skips the representment portion and moves directly into pre-arbitration. State transitions for each flow is as described:
    • Allocation flow: Initiated → Prearbitration (decline or responded) → Arbitration.

Simulating prearbitration

If Marqeta chooses to challenge the merchant’s representment, it moves the dispute to the prearbitration network state, which allows the involved parties to provide further evidence. You can simulate this transition into prearbitration. You can simulate the pre-arbitration action by the acquirer by passing RESPOND_WITH_PREARB in the action field.

Sample request body

Sample request

Sample response body

Sample response

This request transitions the network state to prearbitration and Marqeta state remains as CHARGEBACK_INITIATED. Marqeta sends you the chargebacktransitions.prearbitration webhook.

Responding to prearbitration

At this point, the merchant can submit further evidence for the case. The specific requirements for the prearbitration_response_details object differ across the various card networks. You can simulate the reponse to pre-arbitration action to the acquirer by passing RESPOND_WITH_PREARB_RESPONSE in the action field. This example follows the Mastercard object, which requires only a list of associated document UUIDs in the attached_contents field in the network_details.prearbitration_response_details object.
Caution
For testing purposes, pass an empty list in attached_contents. You can upload new documents and pass those UUIDs in the list.

Sample request body

Sample request

Sample response body

Sample response

The network state remains as prearbitration and Marqeta state remains as CHARGEBACK_INITIATED. The chargebacktransitions.prearbitration.responded webhook event sent.

Moving to arbitration

Assume that the acquirer (merchant) does not agree with the pre-arbitration process. You can simulate an arbitration request to proceed by passing RESPOND_WITH_ARB in the action field.At this point, Marqeta transitions the dispute to the card network, who will provide the final and indisputable decision on the case.

Sample request body

Sample request

Sample response body

Sample response

The network state remains as arbitration and the Marqeta state remains as CHARGEBACK_INITIATED. Marqeta sends you the chargebacktransitions.arbitration webhook.