# Dispute States

In this guide, you can learn about the disputes, protested charges, and the chargeback lifecycle.

Whether you're managing disputes through the dashboard or API, the response_state and state of the Dispute details what steps to take to move the Dispute forward.

## Dispute Responses States

| `response_state`  | Description |
|  --- | --- |
| `NEEDS_RESPONSE` | The `Merchant` needs to respond to the `Dispute` by `Dispute#respond_by`. |
| `RESPONDED` | The issuing bank has received the evidence and actively reviewing it. No action needed from the `Merchant`. |
| `ACCEPTED` | The `Merchant` has accepted the `Dispute`. When a `Dispute` is accepted, you concede that the dispute is not worth challenging or representing. For details on how to accept a `Dispute`, see [Accepting a Dispute](/guides/after-the-payment/disputes/accepting-disputes/). |
| `NO_RESPONSE_ALLOWED` | The final `Dispute#response_state` when a `Dispute` is either `WON` or `LOST`. |
| `UNKNOWN` | `Dispute` details couldn't be submitted to the processor. Comes up when testing `Disputes` in sandbox or on the `DUMMY_V1` processor. |


## Dispute States

| `state`  | Description |
|  --- | --- |
| `INQUIRY` | The `Dispute` is being reviewed by the buyer's issuing bank. When `Dispute#state` is `INQUIRY` no changes can be made. |
| `PENDING` | This `Dispute#state` change will happen at a later time, after the `Dispute` accept request is submitted. For a dispute on a sale when accepted the `Dispute#state` changes to `LOST`. For a dispute on a refund when accepted the `Dispute#state` changes to `WON`. We recommend subscribing to our [webhooks](/additional-resources/developers/webhooks), and listening for the [`Dispute` `updated` event](/additional-resources/developers/webhooks/webhook-events#dispute-updated). |
| `LOST` | The `Dispute` is lost and no further changes can be made. |
| `WON` | The `Dispute` is won and no further changes can be made. |


## Dispute Reasons

The `reason` of the `Dispute` provides additional details regarding why the dispute got filed.

| `reason`  | Description |
|  --- | --- |
| `CLERICAL` | An error occurred while processing the sale, or the cardholder has an issue with the transaction and refuses the goods. |
| `FRAUD` | The cardholder claims they didn't approve or authorize the transaction. `FRAUD` is the primary reason disputes get created. |
| `INQUIRY` | The `Merchant` didn't respond by the `respond_by` date, or the transaction got flagged for review due to the network's internal standards. |
| `QUALITY` | The cardholder has issues with the quality of the goods or services received. Reasons can include receiving damaged goods or a service that doesn't match what's promised. |
| `TECHNICAL` | A technical issued caused the transaction to process funds incorrectly. |


`Disputes` get created with a `PENDING` `state`. `Dispute#state` updates with the decision of the issuing bank. The bank's decision is final for all parties. You can’t overturn a lost dispute, and your customer can’t overturn a dispute decided in your favor.

If the `Dispute#state` gets updated to `INQUIRY` or `PENDING` than the issuing bank is requesting additional information, from the seller, showing the transaction was legitimate. For steps on how to upload evidence and respond to the issuing bank, see [Responding to Disputes](/guides/after-the-payment/disputes/responding-to-disputes).