Create disputes on behalf of cardholders using the POST /cases endpoint, with step-by-step examples for Visa, Mastercard, and PULSE.
When a cardholder reports a problem with a transaction such as unauthorized use, merchandise that never arrived, or a billing error, you can open a dispute on their behalf using the POST /cases endpoint.
Marqeta routes the dispute to the appropriate card network and initiates the chargeback process.
The POST /cases endpoint supports two types of submissions: chargeback requests, which initiate the formal dispute and recovery process, and fraud reports, which record fraud for card network reporting purposes but do not initiate chargeback recovery.
The structure of your request payload depends on the following:
Card network — Visa, Mastercard, and PULSE each have different payload requirements.
Dispute category — Such as Fraud, Consumer, Authorization, or Processing Error.
Reason code — The specific reason for the dispute within that category.
Marqeta provides a response that indicates that the dispute has been created successfully or provides an error message if unsuccessful.
Before creating a dispute, make sure you have the following:
Authentication — A valid API key or access token to authenticate your request.
original_transaction_token — The token of the transaction being disputed. You can retrieve this using the Transactions API.
Card network — The network associated with the original transaction (Visa, Mastercard, or PULSE).
Dispute reason — The dispute reason that applies to the cardholder’s situation. See the payload reference below for the full list of supported reason codes by network.
This section provides payload examples to create disputes.
These examples are based on scenarios with various combinations of card networks, disputes categories, and reason codes.
Scenario: A cardholder purchased a jacket online but never received it.
They contacted the merchant with no resolution.Step 1: Identify your parameters
{ "type": "DISPUTE", "memo": "Cardholder reports merchandise never received after contacting merchant", "dispute_details": { "dispute_reason": "SERVICE_NOT_PROVIDED_MERCHANDISE_NOT_RECEIVED", "dispute_amount": 89.99, "cardholder_contact_date": "2026-03-10T09:00:00Z", "original_transaction_token": "a2d7d73a-02c6-4865-9fa6-6c998a179b2a", "consumer_dispute_type_dispute_details": { "service_not_provided_merchandise_not_received_details": { "detailed_description_of_what_was_purchased_and_explanation_of_the_dispute": "Cardholder ordered a blue denim jacket (size M) on February 20, 2025\. Expected delivery was March 5, 2025\. Item was never received and merchant has not responded to two contact attempts.", "expected_receipt_date": "2026-03-05T00:00:00Z", "merchandise_or_services": "MERCHANDISE", "did_cardholder_attempt_to_resolve_dispute_with_merchant": true, "is_attempt_to_resolve_prohibited_by_local_law_or_regulations": false, "did_cardholder_return_merchandise": false, "did_cardholder_attempt_to_return_merchandise": false, "is_merchant_in_bankruptcy_liquidation": false, "third_party_gift_card_indicator": false, "merchandise_delivered_late": false, "was_merchandise_delivered_to_wrong_location": false, "did_merchant_cancel_merchandise": false } } }}
Step 3: Send the request
In the following example, replace the <payload above> text in the last line with the JSON payload from Step 2.
Example 2: Mastercard — Cancelled recurring transaction
Scenario: A cardholder was billed for a recurring subscription they cancelled two months ago.Step 1: Identify your parameters
Network: Mastercard
Reason code: CANCELLED_RECURRING_TRANSACTION
Mastercard payloads generally require the core dispute fields and a network_comment explaining the dispute context.
For fraud reports, additional fields are required — see the Fraud Report tab under the Mastercard section for details.
Step 2: Construct the payload
{ "type": "DISPUTE", "memo": "Cardholder cancelled subscription in January; merchant continued billing in February and March.", "network_comment": "Cardholder cancelled their monthly streaming subscription on January 15, 2025 via the merchant's online portal and received a confirmation email. Despite cancellation, the merchant charged the cardholder $14.99 on February 1 and March 1, 2025.", "dispute_details": { "original_transaction_token": "75a1d6d5-01f8-4c9a-b89d-ecf80658e801", "dispute_amount": 14.99, "dispute_reason": "CANCELLED_RECURRING_TRANSACTION", "cardholder_contact_date": "2026-03-05T14:00:00Z" }}
Step 3: Send the request
In the following example, replace the <payload above> text in the last line with the JSON payload from Step 2.
Scenario: A cardholder reports that a fraudulent application for credit was submitted in the account holder’s name.Step 1: Identify your parameters
Network: Visa
Category: Fraud Report
Reason code: FRAUD_REPORT
Fraud type: FRAUDULENT_APPLICATION
Fraud reports record fraud for card network reporting but do not initiate chargeback recovery.
If you want to recover funds, use a fraud-category dispute reason code instead.
Step 2: Construct the payloadThe following is an example of a fraud report request to the Visa card network for a fraudulent application.
In the following example, replace the text of the memo with details relevant to the fraud report.
{ "dispute_details": { "dispute_reason": "FRAUD_REPORT", "dispute_amount": 50, "fraud_category_type_dispute_details": { "fraud_type": "FRAUDULENT_APPLICATION" }, "original_transaction_token": "1c0a45c3-8212-4524-b679-610cf4d231a8", "cardholder_contact_date": "2026-03-12T11:30:00Z" }, "memo": "This is a QE test", "type": "DISPUTE"}
Step 3: Send the request
In the following example, replace the <payload above> text in the last line with the JSON payload from Step 2.
Scenario: A cardholder paid for a home cleaning service that was never performed.
They contacted the merchant with no resolution.Step 1: Identify your parameters
The response schema is the same regardless of card network or reason code, but not all fields will be populated in every response.
The fields most relevant to your workflow are:
Field
Description
token
Unique identifier for this case. Use it to retrieve or update the case later.
state
The internal case state within Marqeta’s system.
dispute_state
The state of the dispute within the card network’s workflow. Possible values vary by card network.
provisional_credit_granted
Whether Marqeta has granted the cardholder a provisional credit while the dispute is in progress.
network_case_number
The case number assigned by the card network. Available once the case has been submitted to the card network.
network_failure_response
Populated if the card network rejected the submission. Use this to diagnose and correct the request.
If your request is rejected by the card network, the response includes a network_failure_response field describing the reason for the rejection.
Review the value of this field, correct the relevant parameters in your payload, and resubmit the request.
Use the tabs below to find the correct payload for your card network and dispute reason code.
For Visa and PULSE payloads with conditional fields, a dependency diagram is provided alongside the flat payload example.
For Visa and PULSE payloads with conditional fields, a dependency diagram is provided alongside the flat payload example.
These diagrams show which fields are conditionally required based on the values of other fields.Here is how to read them:
Branches — A [BRANCH: VALUE] label means the fields below it are only applicable when the parent field is set to that value.
IF conditions — An IF: True or IF: False label means the fields below it are only required when the parent boolean resolves to that value.
Optional fields — Fields marked [Optional] are not required to submit the dispute but may be relevant to your case.
Use the flat payload as your starting point, then use the dependency diagram to remove fields that don’t apply to your specific scenario.
VISA
MASTERCARD
PULSE
Visa dispute payloads include conditional fields that vary by dispute category and reason code.
All detail fields must be sent flattened in the request body, regardless of their interdependencies. Flattened means that all fields are included at the same level within their parent object — no conditional nesting based on the values of sibling fields.
This section covers five dispute categories — Fraud, Processing Errors, Consumer, Fraud Report, and Authorization — each with flat payload examples and dependency diagrams where applicable.
Fraud
Processing Errors
Consumer
Fraud Report
Authorization
Fraud disputes cover unauthorized transactions and Europay, Mastercard, and Visa (EMV) liability shift scenarios.
Use the reason codes in this category when a cardholder reports a transaction they did not authorize.
Errors in the processing category will have the dispute_details \-> processing_error_type_dispute_details object defined.
Below are examples of specific payloads for dispute reasons in the Processing category.
{ "type": "DISPUTE", "memo": "Transaction was processed despite invalid data in the authorization request.", "dispute_details": { "dispute_reason": "INVALID_DATA", "dispute_amount": 110.01, "cardholder_contact_date": "2026-01-24T23:00:00Z", "processing_error_type_dispute_details": { "invalid_data_details": { "authorization_request_declined_valid_data": true, "explain_why_valid_data_inclusion_reason": "The authorization request included an expired card number that should have been declined." } }, "original_transaction_token": "c14fed48-b3f5-435e-99f2-743cbff97a0f" }}
Errors in the Consumer category will have the dispute_details \-> consumer_dispute_type_dispute_details object defined.
Below are examples of specific payloads for dispute reasons in the Consumer category.
{ "type": "DISPUTE", "memo": "Cardholder ordered merchandise that was never delivered.", "dispute_details": { "dispute_reason": "SERVICE_NOT_PROVIDED_MERCHANDISE_NOT_RECEIVED", "dispute_amount": 110.01, "cardholder_contact_date": "2026-01-24T23:00:00Z", "consumer_dispute_type_dispute_details": { "service_not_provided_merchandise_not_received_details": { "detailed_description_of_what_was_purchased_and_explanation_of_the_dispute": "Cardholder ordered a blue denim jacket (size M) on January 1, 2024\. Expected delivery was January 15, 2024\. Item was never received and merchant has not responded to two contact attempts.", "expected_receipt_date": "2026-01-15T00:00:00Z", "expected_receipt_time": "2026-01-15T17:00:00Z", "did_cardholder_cancel_prior_to_the_expected_date": false, "did_cardholder_attempt_to_resolve_dispute_with_merchant": true, "is_attempt_to_resolve_prohibited_by_local_law_or_regulations": false, "merchandise_or_services": "MERCHANDISE", "was_merchandise_delivered_to_wrong_location": false, "did_cardholder_return_merchandise": false, "did_cardholder_attempt_to_return_merchandise": false, "third_party_gift_card_indicator": false, "did_merchant_cancel_merchandise": false, "is_merchant_in_bankruptcy_liquidation": false, "merchandise_delivered_late": false } }, "original_transaction_token": "c14fed48-b3f5-435e-99f2-743cbff97a0f" }}
The payload for the CANCELLED_MERCHANDISE_OR_SERVICES reason code will be different if the cancellation applies to merchandise or a service.
{ "type": "DISPUTE", "memo": "Cardholder cancelled order within the merchant's stated policy window but was not refunded.", "dispute_details": { "dispute_reason": "CANCELLED_MERCHANDISE_OR_SERVICES", "dispute_amount": 110.01, "cardholder_contact_date": "2026-01-24T23:00:00Z", "original_transaction_token": "c14fed48-b3f5-435e-99f2-743cbff97a0f", "consumer_dispute_type_dispute_details": { "cancelled_merchandise_or_services_details": { "merchandise_or_services": "MERCHANDISE", "describe_what_was_purchased": "Blue denim jacket, size M", "date_cardholder_received_or_expected_to_receive_merchandise": "2026-01-10T00:00:00Z", "did_the_cardholder_attempt_to_resolve_the_dispute_with_the_merchant": true, "is_attempt_to_resolve_prohibited_by_local_law_or_regulations": false, "did_the_cardholder_return_the_merchandise": true, "date_of_return": "2026-01-15T00:00:00Z", "date_merchant_received_returned_merchandise": "2026-01-18T00:00:00Z", "return_method": "UPS", "tracking_number": "1Z999AA10123456784", "explain_how_the_merchandise_was_returned": "Cardholder dropped off the package at a UPS store and received a receipt.", "did_the_cardholder_attempt_to_return_the_merchandise": true, "date_of_attempted_return": "2026-01-14T00:00:00Z", "detailed_description_of_how_the_cardholder_attempted_to_return_and_the_disposition_of_the_merchandise": "Cardholder contacted merchant via email on January 14 to initiate return; merchant provided a prepaid UPS label.", "what_is_the_disposition_of_the_merchandise": "Returned to merchant via UPS on January 15.", "did_cardholder_cancel": true, "cancellation_date": "2026-01-13T00:00:00Z", "cancellation_reason": "Item did not match description on website.", "was_cancellation_policy_provided": true, "merchant_refuse_advise": "MERCHANT_REFUSED_RETURN_AUTHORIZATION", "type_of_service": "OTHER", "date_of_service_or_expected_service": "2026-01-10T00:00:00Z", "cancelled_guaranteed_reservation_certification_selection": "CARDHOLDER_PROPERLY_CANCELLED" } } }}
{ "type": "DISPUTE", "memo": "Cardholder received merchandise identified as counterfeit by the IP owner.", "dispute_details": { "dispute_reason": "COUNTERFEIT_MERCH", "dispute_amount": 110.01, "cardholder_contact_date": "2026-01-24T23:00:00Z", "consumer_dispute_type_dispute_details": { "counterfeit_merch_details": { "what_was_ordered": "Limited edition designer handbag", "date_the_cardholder_received_the_merchandise_or_notification": "2026-01-10T00:00:00Z", "describe_the_counterfeit_merchandise": "The bag lacks official authentication tags and stitching quality is inconsistent with genuine products.", "describe_the_disposition_of_counterfeit_merchandise": "Cardholder retained the item pending dispute resolution.", "provide_information_about_the_entity_that_indicated_the_merchandise_to_be_counterfeit": "Brand's authorized representative confirmed counterfeit via email on January 20, 2024.", "certification_the_merchandise_was_identified_as_counterfeit_by_one_of_the_following": "THE_OWNER_OF_THE_INTELLECTUAL_PROPERTY_OR_ITS_AUTHORIZED_REPRESENTATIVE" } }, "original_transaction_token": "c14fed48-b3f5-435e-99f2-743cbff97a0f" }}
{ "type": "DISPUTE", "memo": "Cardholder received a product that was materially misrepresented in the merchant's listing.", "dispute_details": { "dispute_reason": "MISREPRESENTATION", "dispute_amount": 110.01, "cardholder_contact_date": "2026-01-24T23:00:00Z", "original_transaction_token": "c14fed48-b3f5-435e-99f2-743cbff97a0f", "consumer_dispute_type_dispute_details": { "misrepresentation_details": { "merchandise_or_services": "MERCHANDISE", "merchandise_received_date": "2026-01-10T00:00:00Z", "describe_what_was_purchased": "Wireless noise-cancelling headphones, model XZ-500", "how_merchandise_service_misrepresented": "Merchant advertised 40-hour battery life; actual battery life is under 8 hours.", "cardholder_attempt_to_resolve": true, "attempt_to_resolve_proh_local_law": false, "cardholder_return_merchandise_ind": true, "cardholder_returned_merchandise_date": "2026-01-18T00:00:00Z", "merchant_received_returned_merchandise_date": "2026-01-21T00:00:00Z", "return_method": "UPS", "shipping_tracking_number": "1Z999AA10123456784" } } }}
Fraud reports record fraudulent activity for card network reporting purposes but do not initiate chargeback recovery.
Use this reason code to report fraud types such as lost or stolen cards, account takeover, or counterfeit card fraud.
Authorization disputes cover transactions that were processed without valid authorization.
Use the reason codes in this category when a transaction was declined, processed against a closed account, or lacked a valid authorization.
Mastercard dispute payloads generally require the core dispute fields and the network_comment field explaining the dispute context, with additional fields required for fraud reports.
This section covers all standard dispute reason codes as well as a separate Fraud Report payload that requires additional fraud classification fields.
All Reason Codes
Fraud Report
This tab covers all non-fraud Mastercard dispute reason codes, which share a common payload structure.
Use the network_comment field to provide dispute context for the card network.
{ "type": "DISPUTE", "memo": "Internal case notes go here.", "network_comment": "Cardholder cancelled subscription on January 15 via merchant portal and received confirmation. Merchant continued to bill $14.99 on February 1 and March 1.", "dispute_details": { "original_transaction_token": "75a1d6d5-01f8-4c9a-b89d-ecf80658e801", "dispute_amount": 14.99, "dispute_reason": "CANCELLED_RECURRING_TRANSACTION", "cardholder_contact_date": "2026-03-05T14:00:00Z" }}
PULSE dispute payloads require the core dispute fields, with additional detail objects available for select reason codes.
This section covers the Consumer, Processing Error, and Non-Cardholder Reasons dispute categories, spanning a total of 17 reason codes.
{ "type": "DISPUTE", "memo": "Cardholder cancelled order but merchant did not issue a refund.", "dispute_details": { "original_transaction_token": "c14fed48-b3f5-435e-99f2-743cbff97a0f", "dispute_amount": 50.00, "dispute_reason": "CANCELLED_MERCHANDISE_OR_SERVICES", "cardholder_contact_date": "2026-01-24T23:00:00Z" }}
PULSE supports two distinct reason codes for duplicate charge disputes.
They differ in network scope, when to use them, and how the dispute amount is handled when the case is submitted to the PULSE network.
PULSE code: 4534 | Networks: PULSE onlyUse this when the cardholder was charged twice for the exact same transaction and no alternate payment was involved.
This is a PULSE-exclusive reason code — it has no Visa or Mastercard equivalent.
{ "type": "DISPUTE", "memo": "Cardholder was charged twice for the same transaction.", "dispute_details": { "original_transaction_token": "c14fed48-b3f5-435e-99f2-743cbff97a0f", "dispute_amount": 50.00, "dispute_reason": "DUPLICATE_PROCESSING", "cardholder_contact_date": "2025-01-15T10:30:00Z" }}
PULSE code: 4865 | Networks: Visa (12.6), Mastercard (73), PULSE (4865)Use this when the transaction was processed twice, or the cardholder already paid for the goods or services by another method such as cash, check, or gift card.This reason code works across all three networks.
For PULSE, use this reason code when payment is made by other means.
The dispute_amount is forwarded to the PULSE network when the case is submitted.
{ "type": "DISPUTE", "memo": "Cardholder was charged twice for the same transaction.", "dispute_details": { "original_transaction_token": "c14fed48-b3f5-435e-99f2-743cbff97a0f", "dispute_amount": 50.00, "dispute_reason": "DUPLICATE_PROCESSING_OR_PAID_BY_OTHER_MEANS", "cardholder_contact_date": "2025-01-15T10:30:00Z" }}