> ## Documentation Index
> Fetch the complete documentation index at: https://docs.decisionly.com/llms.txt
> Use this file to discover all available pages before exploring further.
# What Are Disputes?
> What disputes are, how they work, and what you need to know as an issuer
When a cardholder sees a transaction on their statement that they believe is wrong, they can ask their issuer to reverse it. This reversal process is called a **dispute** — and as an issuer, managing disputes is one of your core responsibilities.
Disputes can also be known as **chargebacks** — a chargeback generally refers to a dispute that has been filed with the network.
This guide explains how disputes work, from the regulations that require them to the card network rules that govern them. If you're new to dispute processing, start here before diving into the API documentation.
**Issuer** — the bank or financial institution that issued the card to the cardholder. If you are a fintech or processor managing disputes, consider yourself the issuer for the purposes of this guide.
**Acquirer** — the bank or payment processor on the merchant's side. The acquirer receives your dispute and works with the merchant to respond.
## Why Cardholders Dispute Charges
Disputes fall into two broad categories based on what the cardholder is claiming:
* **Fraud disputes** — the cardholder says they didn't make or authorize the transaction. Someone else used their card.
* **Merchant disputes** — the cardholder acknowledges the transaction but claims something went wrong. The product never arrived, was defective, or the merchant didn't process a refund.
These two categories follow different rules throughout the dispute process — different liability models, different evidence requirements, and in some networks, different dispute flows entirely.
For a full list of the dispute types supported by Decisionly, see [Dispute Types](/dispute-types).
## Fraud Disputes
In a fraud dispute, the cardholder is asserting that they did not participate in the transaction at all. The card may have been stolen, the number compromised in a data breach, or used by someone with access to the cardholder's account.
Before filing a fraud dispute, you must cancel the compromised card and report the fraud to the card network's fraud database. These are hard requirements — the networks will reject the dispute without them. Decisionly will help with reporting the fraud but it is your responsibility to cancel the card.
### Liability and Authentication
Not every fraud claim results in the merchant bearing the cost. In general, the issuer is liable for card present fraud, while the merchant is liable for card not present fraud.
The card networks use a **liability framework** to determine who is financially responsible for a fraudulent transaction, and that determination depends largely on how the transaction was authenticated.
**Liability shift** — a rule that moves financial responsibility for fraud from one party to another based on how the transaction was processed. If the merchant used a stronger authentication method, liability may shift away from them and back to the issuer.
The core principle is straightforward: the party that failed to use available security measures bears the liability.
**Card-present transactions** (in-store, at a terminal):
* **EMV chip** — if the merchant's terminal read the chip, liability for counterfeit fraud shifts to the issuer. If the merchant didn't support chip and fell back to the magnetic stripe, the merchant bears liability.
* **PIN verification** — a PIN-verified transaction is strong evidence that the cardholder (or someone who knew the PIN) was present. This makes fraud chargebacks difficult to win.
* **Contactless/tap** — generally follows the same liability rules as chip transactions.
* **Digital wallets** (Apple Pay, Google Pay, Samsung Pay) — these use **tokenization**, replacing the actual card number with a device-specific token. A tokenized transaction is strong evidence that the cardholder's enrolled device was present, making fraud chargebacks very difficult to pursue. Digital wallet transactions generally follow the same liability rules as chip transactions.
**Card-not-present transactions** (online, phone, mail order):
* **3-D Secure (3DS)** — an authentication protocol (branded as Visa Secure, Mastercard Identity Check, or Amex SafeKey) where the cardholder verifies their identity during checkout, typically through their banking app or a one-time code. A fully authenticated 3DS transaction shifts fraud liability to the issuer and may block the chargeback entirely.
* **CVV/CVC (Card Verification Value/Card Validation Code)** — the three or four digit security code printed on the card. A CVV match provides some evidence the cardholder had the physical card, but does not trigger a liability shift.
* **AVS (Address Verification Service)** — compares the billing address provided by the buyer against the address on file with the issuer. Like CVV, a match is supporting evidence but does not shift liability.
When you receive a fraud dispute, the transaction data will tell you which authentication methods were used. If the merchant used 3DS or read the chip, the chargeback may be ineligible. Decisionly validates these conditions automatically and will reject cases that cannot be filed — see [Fraud Liability](/fraud-liability) for details.
## Merchant Disputes
Merchant disputes cover situations where the cardholder acknowledges making the purchase but has a legitimate complaint — goods not received, a missing refund, a duplicate charge, and so on. The card networks generally expect the cardholder to attempt to resolve the issue with the merchant before filing.
**Representment** — when the merchant (through the acquirer) responds to a dispute with evidence that the original transaction was valid. The merchant is "re-presenting" the transaction.
When you file a merchant dispute, the merchant can respond with **compelling evidence** to prove the transaction was legitimate. The core question varies by dispute type — did the goods arrive? Was the refund already issued? Were the charges actually distinct transactions? — but the burden is on the merchant to demonstrate that the cardholder's claim doesn't hold up. If a merchant responds with evidence, the dispute is reversed through representment and you must decide whether to accept or escalate.
For the full list of dispute types and evidence requirements, see [Dispute Types](/dispute-types). For filing windows, see [Filing Timelines](/filing-timelines).
## First-Party Fraud
Not all disputes are legitimate. **First-party fraud** (sometimes called friendly fraud) occurs when a cardholder files a dispute for a transaction they actually made and benefited from. Common patterns include:
* Claiming a purchase wasn't received when it was
* Disputing a subscription charge they forgot to cancel
* Regretting a purchase and using a dispute instead of the merchant's return process
* A family member made the purchase but the cardholder doesn't recognize it
* The cardholder doesn't recognize the **billing descriptor** on their statement — the merchant's legal entity name or payment processor name may look nothing like the brand the cardholder purchased from
**Billing descriptor** — the merchant name that appears on the cardholder's statement (also known as the statement descriptor). This can be a source of confusion: a cardholder might buy from "Joe's Coffee Shop" but see "ACME FOOD SERVICES LLC" on their statement. Unrecognized descriptors are a common cause of unnecessary fraud disputes.
First-party fraud is a rapidly accelerating problem for issuers and merchants. From the issuer's perspective, it can be difficult to distinguish first-party fraud from legitimate disputes. Decisionly can help by reviewing dispute and transaction data and flagging potential abuse flags. If a merchant submits compelling evidence, this can also help identify cases of first-party fraud.
## How Card Types Differ
Not all cards follow the same dispute rules. Two distinctions matter most:
* **Consumer vs. commercial** — consumer card disputes (personal credit and debit cards) are governed by federal regulations (Regulation Z for credit, Regulation E for debit) that mandate investigation timelines, provisional credits, and resolution deadlines. .
* **Credit vs. debit** — consumer credit card disputes fall under Regulation Z, with longer resolution windows. Consumer debit card disputes fall under Regulation E, which imposes tighter timelines — you must provisionally credit the account within 10 business days, because the cardholder's own funds (not a credit line) are at stake. Prepaid cards generally follow the same rules as debit.
See [Deadlines](#deadlines) for the specific regulatory requirements.
## The Dispute Lifecycle
A chargeback is a multi-stage process with escalation points. At each stage, one party can accept the outcome or push the dispute further. The process varies slightly across different card networks, but typically follows this standard pattern:
```mermaid theme={null}
flowchart TD
A[Dispute Intake] --> B{File?}
B -->|Reject / Write off| Z1[Case Closed]
B -->|File| C[Chargeback Filed]
C --> D{Merchant response}
D -->|Accepts / No response| Z2[Won]
D -->|Represents| E[Representment]
E --> F{Accept evidence?}
F -->|Yes| Z3[Lost]
F -->|No| G[Pre-Arbitration]
G --> H{Acquirer response}
H -->|Accepts| Z4[Won]
H -->|Declines| I[Arbitration]
I --> J{Network ruling}
J -->|Issuer favored| Z5[Won]
J -->|Acquirer favored| Z6[Lost]
style Z1 fill:#94a3b8,stroke:#64748b
style Z2 fill:#4ade80,stroke:#22c55e
style Z3 fill:#f87171,stroke:#ef4444
style Z4 fill:#4ade80,stroke:#22c55e
style Z5 fill:#4ade80,stroke:#22c55e
style Z6 fill:#f87171,stroke:#ef4444
```
### 1. Intake and Evaluation
At dispute intake, the issuer gathers information from the cardholder about the reason for the dispute and any additional evidence the cardholder may have. Then, the issuer can investigate the transaction and/or issue a provisional credit if needed (for consumer debit cards, Regulation E requires this within 10 business days — see [Deadlines](#deadlines)).
Based on your investigation, you decide whether to **file** the dispute, **reject** the case if you determine the cardholder should be liable, or **accept** the case if you will accept liability as the issuer. Each dispute must meet specific criteria — filing disputes that don't can lead to reversals and network fines.
Decisionly automates the dispute evaluation and decisioning process so that you can programmatically file, reject or accept cases based on network rules and your own criteria.
### 2. Chargeback
If you decide to file, the dispute is submitted to the card network. The disputed funds are debited from the acquirer/merchant and settled back to you, offsetting the provisional credit you already issued to the cardholder. The filing process requires specific documentation to be submitted to the network in accordance with network rules.
Decisionly automatically files disputes into the card network using direct integrations with network dispute infrastructure.
### 3. Representment
The acquirer and merchant review the dispute and decide how to respond. They can:
* **Accept** the dispute — the merchant absorbs the loss and the case is closed
* **Represent** — the merchant submits compelling evidence to contest the dispute.
If the merchant represents, you receive their evidence and must decide whether it resolves the dispute.
### 4. Pre-Arbitration
If you believe the merchant's representment evidence is insufficient, you can escalate to **pre-arbitration**. This is a final attempt to resolve the dispute between the issuer and acquirer before involving the card network.
The acquirer can accept the pre-arbitration (funds return to the cardholder) or decline it, which sets the stage for arbitration.
Pre-arbitration signals intent to escalate. Both parties should weigh the disputed amount and the strength of the case against the cost of proceeding to arbitration.
### 5. Arbitration
If pre-arbitration fails, either party can file for **arbitration**. At this stage, the card network itself reviews the case and makes a binding decision.
Arbitration fees are substantial. Because of the cost and finality, most disputes are resolved before reaching arbitration. It is generally reserved for high-value disputes where neither party is willing to concede.
For how these stages map to the Decisionly API, see [Case Lifecycle](/case-lifecycle). You can track the dispute lifecycle in real time using [webhooks](/webhooks).
## How the Card Networks Differ
While the overall dispute process follows the same pattern across networks, each card network has its own rules, terminology, and systems.
### Mastercard
Mastercard's standard flow uses the terminology **first dispute** and **second presentment** (representment). After second presentment, cases can proceed to pre-arbitration and then arbitration.
Mastercard also supports a **collaboration** flow for certain cardholder disputes. When a dispute is filed, the merchant can offer to resolve the issue by promising to refund the cardholder. If the merchant commits to a refund through collaboration, the dispute is paused — the expectation is that the merchant will issue the credit without the dispute needing to proceed further.
If the merchant promises a refund through collaboration but fails to deliver it, the issuer can file a **follow-up chargeback** to recover the funds. This ensures the cardholder is made whole even when a merchant doesn't honor their commitment.
Decisionly translates these to our [normalized dispute types](/dispute-types) automatically.
* **4808** — Authorization-related
* **4834** — Point-of-interaction errors (duplicate charges, incorrect amounts)
* **4837, 4870, 4871** — Fraud (no cardholder authorization, chip liability shift)
* **4853** — Cardholder disputes (goods not received, not as described, canceled recurring)
### Visa
Visa uses two distinct dispute flows depending on the category:
**Allocation** (fraud and authorization disputes): Visa automatically assigns initial liability based on the transaction data and the specific dispute condition. For example, if a card-not-present fraud dispute is filed and the merchant didn't use 3DS, Visa allocates liability to the acquirer immediately. The acquirer's only recourse is to respond through pre-arbitration — there is no representment step. This makes the allocation flow faster but gives the merchant fewer opportunities to respond.
**Collaboration** (processing errors and consumer disputes): This flow more closely resembles the traditional dispute process. The issuer files a dispute, the acquirer responds with a dispute response (similar to representment), and if the dispute isn't resolved, either party can initiate pre-arbitration. This back-and-forth exchange gives both sides more opportunity to present evidence before escalating.
Decisionly translates these to our [normalized dispute types](/dispute-types) automatically.
* **10 — Fraud** (counterfeit, card-not-present, etc.)
* **11 — Authorization** (no authorization obtained, declined authorization)
* **12 — Processing Errors** (duplicate processing, incorrect amount, incorrect currency)
* **13 — Consumer Disputes** (merchandise not received, not as described, etc.)
Categories 10 and 11 use the allocation flow. Categories 12 and 13 use the collaboration flow.
### American Express
American Express operates through **AEGNS** (American Express Global Network Services). Unlike its proprietary card business where Amex is both issuer and network, AEGNS has separate issuers and acquirers — similar to Visa and Mastercard. The dispute flow follows the same general pattern of dispute, representment, pre-arbitration, and arbitration, with 45-day response windows at each stage.
Decisionly translates these to our [normalized dispute types](/dispute-types) automatically. Amex uses ISO 4500–4999 range codes.
* **4521** — Authorization (invalid authorization)
* **4507, 4512, 4523, 4530, 4536, 4752** — Processing errors (incorrect amount, multiple processing, currency discrepancy, late presentment)
* **4513, 4515, 4544, 4553, 4554** — Cardmember disputes (credit not presented, paid by other means, canceled recurring, not as described, goods not received)
* **4527, 4534, 4540, 4755, 4763, 4798, 4799** — Fraud (missing imprint, card not present, fraud full recourse, liability shift counterfeit/lost/stolen)
## Deadlines
Disputes operate under strict deadlines set by both federal regulations and card network rules. Missing a deadline can mean being out of regulatory compliance or losing the right to dispute a transaction via the network.
### Regulatory Deadlines
In the United States, two federal regulations govern how quickly you must act when a **consumer** cardholder reports a dispute. These regulations do not apply to commercial card programs — for commercial cards, only the card network deadlines below apply.
**Regulation Z** (Truth in Lending Act, implementing the **Fair Credit Billing Act**) — applies to **consumer credit cards**:
* The cardholder has **60 days** from the statement date to report a billing error
* You must acknowledge the dispute within **30 days** of receiving it
* You must resolve the dispute within **two complete billing cycles** (and no more than 90 days)
* You must issue a provisional credit while the investigation is pending
**Regulation E** (Electronic Fund Transfer Act) — applies to **consumer debit and prepaid cards**:
* The cardholder has **60 days** from the statement date to report an error
* You must investigate and resolve the dispute within **10 business days** (or 20 business days for new accounts)
* If you need more time, you can extend to **45 days**, but you must provisionally credit the cardholder's account within 10 business days
* For point-of-sale debit transactions, the extended investigation period is **90 days**
### Card Network Deadlines
On top of regulatory requirements, each card network sets its own filing windows. These deadlines determine how long you have to file a dispute after the transaction date (or after a triggering event like an expected delivery date).
| Stage | Deadline |
| ------------------------------------ | ------------------------------------------------------------------------- |
| Filing (authorization-related) | 90 days from transaction date |
| Filing (cardholder disputes) | 120 days from transaction date or triggering event |
| Filing (fraud) | 120 days from transaction date |
| Filing (point-of-interaction errors) | 90 days from transaction date |
| Second presentment (representment) | 45 days |
| Pre-arbitration response | 45 days |
| Arbitration filing | 45 days from second presentment and 10 days from pre-arbitration rebuttal |
Mastercard also requires a **15-day waiting period** for certain cardholder disputes (such as goods not as described or refund not processed) to give the cardholder time to attempt resolution with the merchant.
| Stage | Deadline |
| -------------------------- | -------------------------------------------------- |
| Filing (fraud) | 120 days from transaction date |
| Filing (authorization) | 120 days from transaction date |
| Filing (processing errors) | 120 days from transaction date |
| Filing (consumer disputes) | 120 days from transaction date or triggering event |
| Pre-arbitration response | 30 days |
| Arbitration filing | 10 days from pre-arbitration response |
Visa also requires a **15-day waiting period** for certain cardholder disputes (such as goods not as described or refund not processed) to give the cardholder time to attempt resolution with the merchant.
| Stage | Deadline |
| ---------------------------------- | ------------------------------------------- |
| Filing (most dispute types) | 120 days from network processing date |
| Filing (fraud full recourse) | 120 days (365 days for high-risk merchants) |
| Second presentment (representment) | 45 days |
| Pre-arbitration / Good faith | No fixed deadline |
| Arbitration filing | 45 days |
Amex also requires a **15-day waiting period** for certain cardholder disputes (such as goods not as described or refund not processed) to give the cardholder time to attempt resolution with the merchant.
For the specific filing windows for each dispute type, see [Filing Timelines](/filing-timelines).
## Dispute Outcomes
Most disputes do not follow the full lifecycle to arbitration. Here's how cases can conclude:
### Merchant Accepted/Didn't Respond
The most common outcome. The merchant (through the acquirer) either explicitly accepts the dispute or simply doesn't respond within the representment deadline. In either case, the cardholder keeps the provisional credit and the case is closed. In the Decisionly API, this results in a `won` status.
### Representment Accepted
The merchant represents with compelling evidence that you find persuasive. You accept the representment, the provisional credit is reversed from the cardholder, and the case is closed with a `lost` status.
Assessing representment evidence is a key part of the dispute process. You need to determine whether the merchant's documentation actually addresses the reason for the dispute — for example, whether a delivery receipt proves the cardholder received the goods, or whether a signed contract proves the cardholder agreed to the charges. Decisionly provides a evidence scoring system to help you evaluate representment evidence.
### Merchant Credited
The merchant issues a refund directly to the cardholder outside the dispute process. Since the cardholder has been made whole, you withdraw the dispute, and reclaim any provisional credit that was offered. This results in a `merchant_credited` status.
### Withdrawn
You can withdraw a dispute before it reaches a final resolution — for example, if the cardholder confirms they now recognize the transaction or resolves the issue directly with the merchant. This results in a `withdrawn` status.
### Rejected
You may determine that the cardholder's claim doesn't warrant a dispute — for example, if you determine the cardholder’s claim is illegitimate or inaccurate. In this case, no provisional credit is issued and no dispute is filed. This results in a `rejected` status.
### Issuer Accepted
Sometimes you may decide not to file a dispute even though the cardholder has a valid complaint. This typically happens when the disputed amount is too small to justify the operational cost of filing, or when the transaction data makes the case unlikely to succeed. You issue the cardholder a credit and absorb the loss yourself rather than pursuing it through the card network. This results in an `accepted` status — you've accepted liability on behalf of the cardholder without involving the merchant.
You may also accept liability after a dispute has been filed — for example, if the merchant represents with compelling evidence and you decide it's not worth escalating to pre-arbitration, but you do not wish to hold the cardholder liable. This also results in an `accepted` status.
## The Decisionly API
Decisionly provides a unified API for managing the entire dispute lifecycle across Visa, Mastercard, and American Express. Rather than integrating directly with each card network's proprietary system, you work with a single set of endpoints and data models.
Here's how the key concepts in this guide map to the API:
* **Creating a dispute** — submit transaction data, cardholder information, and evidence through the [Cases API](/api-reference/v2-cases/create-a-case)
* **Filing** — trigger the dispute with the card network via the [File endpoint](/filing), using workflow rules or direct filing
* **Tracking status** — monitor the dispute as it moves through representment, pre-arbitration, and arbitration via [case status](/case-lifecycle) and [webhooks](/webhooks)
* **Evidence** — attach supporting documentation through the [Files API](/api-reference/v2-files/upload-a-file)
* **Automation** — configure [workflow rules](/workflow-rules) to automatically file, reject, or escalate disputes based on your criteria
Your role as the issuer is to make sure disputes are handled and resolved in line with regulations, network rules and your own business requirements. By configuring your disputes process with Decisionly, you can programmatically determine whether to file a dispute, what reason code to use, whether to accept representment or escalate, and more. Decisionly handles the operational complexity: network-specific message formatting, reason code translation, deadline tracking, routing to the correct network system, and [fraud liability](/fraud-liability). Decisionly also enables you to configure your custom workflows and dispute criteria and automates the evidence review. With Decisionly, you can focus on dispute strategy rather than individual dispute handling or network integration details.
Create and file your first dispute
Evidence requirements for each reason code
Understand case statuses and transitions
Get notified when case status changes