> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chargeblast.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Reason Codes

> A guide to all reason codes used when actioning CDRN/Ethoca alerts via the update alerts endpoint.

## Overview

Reason codes are used to communicate the outcome of an alert to the card networks. When you receive a CDRN or Ethoca alert, you action it by updating the alert with one of the reason codes below. Selecting the correct reason code ensures accurate reporting and helps prevent future chargebacks.

<Note>
  Every alert arrives with a status (reason\_code) of `WIP` (Work In Progress). This is the default state on receipt and is **not** a reason code to be used in the update endpoint.
</Note>

## Resolved Codes

These are special reason codes that instruct the issuing bank to **not** move forward with a chargeback. When one of these codes is sent, a standard operating procedure (SOP) is followed at the issuer level, which prevents a dispute from being filed.

| Code | Description |
| - | - |
| `Resolved` | The alert has been resolved, and a refund will be issued to the cardholder. This is the most common resolution and tells the issuer to stop the chargeback process. |
| `AlreadyRefunded` | The transaction was refunded **prior** to the alert being transmitted. This tells the issuer a refund is already in place, so no chargeback should be filed. This code is eligible for credit. |

## Decline Codes

Decline codes indicate the alert is being declined and no refund will be issued. **Declining an alert will result in a chargeback**, so use these codes carefully.

| Code | Description |
| - | - |
| `UnmatchedGeneral` \* | The transaction either can't find a matching transaction, or you're unsure which specific reason code applies. This is the default option to select when in doubt. Credit is subject to review. |
| `UnmatchedCannotFindTransaction` \* | The specific transaction referenced in the alert cannot be found in your system. This code is eligible for credit. |
| `AlreadyChargeback` \* | The transaction has already resulted in a chargeback **prior** to the alert being transmitted. This code is eligible for credit. |
| `Ineligible` | A generic decline code indicating the alert is not eligible for a refund. The main use case is when you simply do not want to refund the cardholder, but the alert is otherwise valid. Not eligible for credit. |
| `MIDLost` | The Merchant ID (processing account) associated with this transaction has been lost or terminated. This code is eligible for credit *only for alerts sent between the unenrollment request and the actual unenrollment date*. |
| `TDS` | The transaction was 3D Secure (3DS) verified. Occasionally, you may want to decline fraud-coded alerts on 3DS-authenticated transactions. Not eligible for credit. |
| `EscalateChargeback` | The merchant is declining the alert and accepting that it will escalate to a chargeback. Use when you have evidence to fight the dispute. Not eligible for credit. |
| `NotMyDescriptor` | The billing descriptor on the alert does not belong to your merchant account. Not eligible for credit. **⚠️ Monitored** — If alerts are actioned with this code, the descriptor may be automatically unenrolled. Use with caution, as this code is not used in most implementations. |
| `Duplicate` \* | The same underlying transaction generates two alerts — typically one from Ethoca and one from CDRN. Credit is subject to review. |
| `ResolvedCancelled` | The transaction failed, canceled, or blocked. Since there is no successful payment to refund, decline the alert using this code. This code is eligible for credit. |

<Info>
  (\*) These are the most commonly implemented decline codes.
</Info>

## Best Practices

<Info>
  For best results, action the alerts as `Resolved` within 48 hours of receiving them. Some banks escalate alerts to chargebacks as quickly as 48 hours after the alert is created.
</Info>

### Notes

1. **Only use decline codes when necessary** — Declining alerts will result in chargebacks, which negatively impact your chargeback ratio.
2. **Be careful with decline codes** — Once you action an alert, you cannot reliably "re-action" it. Make sure the decline code is correct before submitting.
3. **When in doubt, use `Resolved`** — If you're issuing a refund, `Resolved` is almost always the correct choice.
4. **Use `AlreadyRefunded` when applicable** — If the transaction was already refunded before the alert arrived, this code provides better data to card networks and is eligible for credit.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.