# Pre-Chargeback Alerts

_Learn about how to enable and use pre-chargeback alerts._

Pre-chargeback alerts notify you when a cardholder raises a dispute with their issuer, giving you a window to resolve it before it escalates to a formal chargeback. This helps keep your chargeback ratio low and avoids potential issues with card networks like Visa and Mastercard.

> **Beta**
>
> Pre-Chargeback Alerts are in beta and are subject to change.

## Alert Types

There are two alert networks, each associated with different card schemes:

- **Verifi RDR (Rapid Dispute Resolution)** — primarily covers Visa transactions. When an alert arrives, Evervault automatically processes a refund on your behalf before a chargeback is filed. No manual action is required from you. You can optionally configure an [amount rule](#verifi-rdr-refund-rules) per merchant to control which Verifi alerts are refunded.
- **Ethoca Alerts** — covers Mastercard, and some American Express and Discover transactions. Unlike Verifi RDR, Ethoca Alerts require you to take an action — such as issuing a refund through your PSP — and then update the alert via the API.

You can enrol a merchant in one or both networks at the same time.

## How it works

Pre-chargeback alerts are configured per merchant through the [Merchants API](/api#createMerchant). You enable them by including a `preChargebackAlerts` object when creating or updating a merchant. When Evervault receives an alert from one of the networks, it creates an alert record that you can retrieve and respond to via the API. You can also subscribe to [webhooks](#webhooks) to receive alert and enrolment status notifications in real time.

## Enable alerts for a merchant

You enable pre-chargeback alerts by including a `preChargebackAlerts` object when creating or updating a merchant. At least one of `ethocaAlert` or `verifiRdr` must be provided.

### For a new merchant

Include `preChargebackAlerts` in the body of `POST /payments/merchants`:

```bash
curl -X POST 'https://api.evervault.com/payments/merchants' \
  -H 'Content-Type: application/json' \
  -u '<app_id>:<api_key>' \
  -d '{
    "name": "Example Store",
    "website": "https://example.com",
    "categoryCode": "5411",
    "business": {
      "legalName": "Example Store Ltd",
      "address": {
        "line1": "123 Main Street",
        "city": "Dublin",
        "postalCode": "D01 AB12",
        "country": "IE"
      }
    },
    "preChargebackAlerts": {
      "ethocaAlert": {
        "descriptors": [
          { "descriptor": "EXAMPLE STORE", "match_type": "STARTS_WITH" }
        ]
      },
      "verifiRdr": {
        "bin": "424242",
        "caid": "1234567890123456"
      }
    }
  }'
```

For Ethoca, each descriptor entry matches the statement descriptor that appears on the cardholder's statement. The `match_type` can be `STARTS_WITH` or `EXACT_MATCH`. Each `descriptor` must be 1–100 printable ASCII characters, and you can supply at most 50 descriptors per enrolment. At least one descriptor is required when enrolling in Ethoca Alerts — an empty `descriptors` array is rejected with a `400` error. Descriptors determine which transactions trigger alerts; omitting `ethocaAlert` entirely enrols the merchant in Verifi RDR only (if configured), not in Ethoca.

For Verifi RDR, to match transactions you must provide either both a `bin` and `caid` (card acceptor ID), or a list of `arns` (acquirer reference numbers). `bin` and `caid` must always be supplied together. `bin` must be 6–11 digits, `caid` must be exactly 16 alphanumeric characters, and each `arn` must be exactly 23 digits. You can supply at most 50 ARNs.

### For an existing merchant

Use `PATCH /payments/merchants/{merchant_id}` and include a `preChargebackAlerts` object with at least one of `ethocaAlert` or `verifiRdr`. The `enabled` field is optional and defaults to `true`.

```bash
curl -X PATCH 'https://api.evervault.com/payments/merchants/{merchant_id}' \
  -H 'Content-Type: application/json' \
  -u '<app_id>:<api_key>' \
  -d '{
    "preChargebackAlerts": {
      "ethocaAlert": {
        "descriptors": [
          { "descriptor": "EXAMPLE STORE", "match_type": "EXACT_MATCH" }
        ]
      }
    }
  }'
```

The merchant's `preChargebackAlerts` field in the response shows the enrolment status:

```json
{
  "id": "{merchant_id}",
  "name": "Example Store",
  ...
  "preChargebackAlerts": {
    "enrolments": [
      {
        "type": "ETHOCA_ALERT",
        "status": "PENDING",
        "ethocaAlert": {
          "descriptors": [
            { "descriptor": "EXAMPLE STORE", "match_type": "EXACT_MATCH", "status": "PENDING" }
          ]
        }
      }
    ]
  }
}
```

> It can take 2–10 days to start receiving alerts after enrolment. This is a
>   limitation of the Verifi RDR and Ethoca Alert networks. You can monitor
>   enrolment status by polling the merchant's `enrolments[].status` field, or by
>   subscribing to the
>   [`payments.pre-chargeback-enrolment-status.updated`](#enrolment-configuration-updated)
>   webhook event. For Ethoca, descriptors are validated asynchronously — if a
>   descriptor is too generic or is already in use across Ethoca's network, the
>   enrolment moves to `ACTION_REQUIRED` and our support team will reach out to
>   agree on an alternative. This typically takes 1–2 business days.

### Enrolment statuses

The `enrolments[].status` field on a merchant can be one of:

| Status | Description |
| --- | --- |
| `PENDING` | Enrolment has been submitted and is awaiting activation from the alert network. This typically takes 2–10 days. |
| `ACTIVE` | Enrolment is active and the merchant can receive alerts. |
| `ACTION_REQUIRED` | Enrolment needs attention — usually an Ethoca descriptor that is too generic or already in use. Our support team will reach out to agree on an alternative. |
| `CANCELLED` | Enrolment has been cancelled and the merchant will no longer receive alerts for this network. |

## Retrieve alerts

### List alerts

`GET /payments/pre-chargeback-alerts/alerts` returns a paginated list of alerts for your app.

Supported query parameters:

- `status` — filter by `ACTION_REQUIRED`, `RESOLVED`, or `INVALID`.
- `merchantId` — filter by Evervault merchant ID.
- `alertReceivedAtGte` — return alerts received on or after this ISO 8601 timestamp (inclusive).
- `alertReceivedAtLte` — return alerts received on or before this ISO 8601 timestamp (inclusive). Must be greater than or equal to `alertReceivedAtGte` when both are provided.
- `sort` — sort order: `-alert_received_at` (newest first, default), `alert_received_at` (oldest first), `-action_required_deadline`, or `action_required_deadline`. Alerts without an `action_required_deadline` sort last when ascending (`action_required_deadline`) and first when descending (`-action_required_deadline`), as if their deadline were infinitely far in the future.
- `limit` — number of results per page, between 1 and 1000.
- `offset` — pagination offset.

Unknown query parameters are rejected with a `400`.

```bash
curl 'https://api.evervault.com/payments/pre-chargeback-alerts/alerts?status=ACTION_REQUIRED&merchantId={merchant_id}' \
  -u '<app_id>:<api_key>'
```

The response is a paginated object with an `items` array and a `count`:

```json
{
  "items": [ ... ],
  "count": 1
}
```

### Get a single alert

```bash
curl 'https://api.evervault.com/payments/pre-chargeback-alerts/alerts/{chargeback_alert_id}' \
  -u '<app_id>:<api_key>'
```

## Respond to an alert

### Verifi RDR

Verifi RDR alerts are resolved automatically. They arrive with a status of `RESOLVED` or `INVALID` and do not require any action from you. The `transaction_refund_outcome` field reflects the outcome.

If the merchant has [refund rules](#verifi-rdr-refund-rules) configured, Evervault evaluates the disputed amount against those rules before processing the refund. Alerts that do not match are not refunded and are not charged. Merchants without any rules continue to have all Verifi alerts refunded by default.

### Ethoca Alerts

> Refunding the customer alone is **not enough** to prevent a chargeback for
>   Ethoca alerts. You must also call the PATCH endpoint so that Ethoca is
>   notified and can stop the chargeback from proceeding. An unactioned alert
>   provides no protection — the chargeback will proceed regardless of whether you
>   issued a refund.

For Ethoca alerts in `ACTION_REQUIRED` status, take action with your PSP first — for example, issuing a refund. The `transaction_statement_descriptor` and `transaction_acquirer_reference_number` fields are useful to share with your PSP to identify the transaction.

Once you have taken action, update the alert via `PATCH /payments/pre-chargeback-alerts/alerts/{alert_id}`. Both fields are optional: `action` notifies Ethoca of the action you took on your PSP and is what prevents the chargeback from proceeding — omitting it means Ethoca is not notified. `note` is purely informational and is stored for your own records only; it is not sent to Ethoca. `note` may be up to 1000 characters and must not contain control characters.

Valid `action` values:

- `REFUND` — you have refunded the customer.
- `CANCEL` — you have cancelled or dismissed the alert.
- `REFUND_AND_CANCEL` — you have both refunded the customer and cancelled the subscription or order.
- `ACCEPT_DISPUTE` — you are accepting the chargeback (equivalent to dismissing the alert without taking action).

```bash
curl -X PATCH 'https://api.evervault.com/payments/pre-chargeback-alerts/alerts/{chargeback_alert_id}' \
  -H 'Content-Type: application/json' \
  -u '<app_id>:<api_key>' \
  -d '{
    "action": "REFUND",
    "note": "Refund issued via PSP before deadline"
  }'
```

Once actioned, the alert moves to `RESOLVED` status. Alerts that are already `RESOLVED` cannot be actioned again. Pay close attention to `action_required_deadline` — if you do not act before this ISO 8601 timestamp, the chargeback proceeds regardless.

## Verifi RDR refund rules

Refund rules let you control which **Verifi RDR** alerts Evervault automatically refunds. Rules only affect Verifi RDR alert processing — they don't change how Ethoca alerts are resolved, even if the merchant is enrolled in both networks.

By default, when a merchant has no rules configured, **all** incoming Verifi alerts are refunded. Once you create one or more rules, Evervault evaluates the disputed transaction amount against those rules. If the amount matches, the alert is refunded as usual. If it does not match, the alert is **not** refunded — and because Verifi alerts are only charged when a refund is processed, non-matching alerts aren't billed either.

### The rule object

```json
{
  "id": "{rule_id}",
  "type": "AMOUNT",
  "outcome": "REFUND",
  "parameters": {
    "operator": "LESS_THAN_OR_EQUAL",
    "currency_code": "USD",
    "amount_in_cents": 5000
  },
  "created_at": "2025-02-11T10:30:00Z"
}
```

- `type` — currently `AMOUNT` (the only supported rule type).
- `outcome` — the action taken when the rule matches. Currently always `REFUND`.
- `parameters.operator` — one of `GREATER_THAN`, `GREATER_THAN_OR_EQUAL`, `LESS_THAN`, `LESS_THAN_OR_EQUAL`, `EQUAL`, or `NOT_EQUAL`.
- `parameters.currency_code` — must be `USD`. Only USD transaction amounts are supported for rule evaluation. If you want to set a threshold in another currency, convert it to USD yourself and pass the equivalent amount in cents with `currency_code` set to `USD`.
- `parameters.amount_in_cents` — the threshold amount in cents against which the disputed amount is compared. Must be a positive integer.
- `created_at` — ISO 8601 timestamp (UTC), consistent with the alert object's `created_at`.

### Create a rule

`POST /payments/pre-chargeback-alerts/merchants/{merchant_id}/rules`

The merchant must already be enrolled in Verifi RDR — rules only govern Verifi auto-refunds, so creating a rule for a merchant enrolled only in Ethoca is rejected with a `400`. Both `type` and all `parameters` fields are required. Returns `201` with the created rule.

```bash
curl -X POST 'https://api.evervault.com/payments/pre-chargeback-alerts/merchants/{merchant_id}/rules' \
  -H 'Content-Type: application/json' \
  -u '<app_id>:<api_key>' \
  -d '{
    "type": "AMOUNT",
    "parameters": {
      "operator": "LESS_THAN_OR_EQUAL",
      "currency_code": "USD",
      "amount_in_cents": 5000
    }
  }'
```

This example refunds Verifi alerts where the disputed amount is $50.00 USD or less. Alerts above that threshold are not refunded.

### Update a rule

`PATCH /payments/pre-chargeback-alerts/merchants/{merchant_id}/rules/{rule_id}`

A rule's `type` cannot be changed — only its `parameters`. `parameters` is replaced, not merged, so send the complete object (`operator`, `currency_code`, `amount_in_cents`); a partial or empty object is rejected with `400`. Omitting `parameters` entirely is a no-op — the rule is returned unchanged. Returns `200` with the updated rule, or `404` if the rule does not exist or does not belong to that merchant.

```bash
curl -X PATCH 'https://api.evervault.com/payments/pre-chargeback-alerts/merchants/{merchant_id}/rules/{rule_id}' \
  -H 'Content-Type: application/json' \
  -u '<app_id>:<api_key>' \
  -d '{
    "parameters": {
      "operator": "LESS_THAN_OR_EQUAL",
      "currency_code": "USD",
      "amount_in_cents": 10000
    }
  }'
```

### List rules

`GET /payments/pre-chargeback-alerts/merchants/{merchant_id}/rules`

Returns a JSON array of rules for the merchant.

A merchant has [at most one rule](#verifi-rdr-refund-rules), so this array contains zero or one item.

Unlike the [alerts list](#list-alerts), the response is a bare array, not wrapped in an `{ items, count }` object.

```bash
curl 'https://api.evervault.com/payments/pre-chargeback-alerts/merchants/{merchant_id}/rules' \
  -u '<app_id>:<api_key>'
```

### Get a rule

`GET /payments/pre-chargeback-alerts/merchants/{merchant_id}/rules/{rule_id}`

Returns `404` if the rule does not exist or does not belong to that merchant.

```bash
curl 'https://api.evervault.com/payments/pre-chargeback-alerts/merchants/{merchant_id}/rules/{rule_id}' \
  -u '<app_id>:<api_key>'
```

### Delete a rule

`DELETE /payments/pre-chargeback-alerts/merchants/{merchant_id}/rules/{rule_id}`

Deleting a rule restores the default behaviour: all Verifi alerts for that merchant are refunded. Returns `204 No Content` on success. Returns `404` if the rule does not exist or has already been deleted — delete is not idempotent, so retrying a successful delete won't return `204`.

```bash
curl -X DELETE 'https://api.evervault.com/payments/pre-chargeback-alerts/merchants/{merchant_id}/rules/{rule_id}' \
  -u '<app_id>:<api_key>'
```

## Webhooks

Rather than polling the API, you can subscribe to webhook events to be notified in real time. Pre-chargeback alerts supports two event types:

- [`payments.pre-chargeback-alert.received`](#alert-received) — fired when Evervault receives a new alert for your app.
- [`payments.pre-chargeback-enrolment-status.updated`](#enrolment-configuration-updated) — fired when an enrolment's status changes (for example, `PENDING` → `ACTIVE`).

See the [Webhooks](/developers/webhooks) documentation for full setup instructions, including how to secure and register your endpoint. Register your endpoint in the [Dashboard](https://app.evervault.com) under **Settings > Webhooks** and subscribe to the events you need.

> Webhook events may be delivered more than once in rare cases. Use the `id`
>   field on the event object to deduplicate. Duplicate alert webhook events are
>   only charged once.

### Alert received

Event type: `payments.pre-chargeback-alert.received`

Fired whenever Evervault receives a new alert for your app. Each delivery is a POST request with a JSON body shaped as a standard [webhook event object](/developers/webhooks#webhook-event-object):

```json
{
  "id": "{event_id}",
  "type": "payments.pre-chargeback-alert.received",
  "data": {
    ...alert object...
  },
  "createdAt": "2025-02-11T10:30:00Z"
}
```

The `data` field contains the full [alert object](#the-alert-object). Here is an example handler that processes both pre-chargeback alert webhook events:

```javascript
app.post("/evervault", (req, res) => {
  const event = req.body;

  switch (event.type) {
    case "payments.pre-chargeback-alert.received": {
      const alert = event.data;

      if (
        alert.alert_type === "ETHOCA_ALERT" &&
        alert.status === "ACTION_REQUIRED"
      ) {
        // Resolve with your PSP, then PATCH the alert via the Evervault API
      }
      break;
    }
    case "payments.pre-chargeback-enrolment-status.updated": {
      const configuration = event.data;

      if (configuration.status === "ACTIVE") {
        // Enrolment is live — the merchant can now receive alerts
      } else if (configuration.status === "ACTION_REQUIRED") {
        // Enrolment needs attention (usually an Ethoca descriptor issue)
      }
      break;
    }
  }

  res.status(200).send({ success: true });
});
```

### Enrolment configuration updated

Event type: `payments.pre-chargeback-enrolment-status.updated`

Fired when an enrolment's status changes after the initial create or update call — for example when a network activates the enrolment or flags a descriptor for review. This is the recommended way to track [enrolment status](#enrolment-statuses) transitions without polling the Merchants API.

Each delivery uses the same [webhook event object](/developers/webhooks#webhook-event-object) shape:

```json
{
  "id": "{event_id}",
  "type": "payments.pre-chargeback-enrolment-status.updated",
  "data": {
    ...configuration object...
  },
  "createdAt": "2025-02-11T10:30:00Z"
}
```

The `data` field contains a [configuration object](#the-configuration-object) describing the status transition.

## The alert object

When Evervault receives an alert from one of the networks, it creates an alert record. Here is a full example:

```json
{
  "id": "{chargeback_alert_id}",
  "merchant_id": "{merchant_id}",
  "alert_type": "ETHOCA_ALERT",
  "alert_network_id": "1234567890",
  "status": "ACTION_REQUIRED",
  "chargeback_reason_code": "10.4",
  "transaction_amount_in_cents": 4999,
  "transaction_currency_code": "USD",
  "transaction_authorized_at": "2025-02-10T10:30:00Z",
  "action_required_deadline": "2025-02-17T10:30:00Z",
  "transaction_authorization_code": "ABC123",
  "transaction_acquirer_reference_number": "74027012345678901234567",
  "transaction_statement_descriptor": "EXAMPLE STORE",
  "transaction_card_bin": "424242",
  "card": {
    "bin": "424242",
    "last_four": "4242",
    "brand": "VISA",
    "issuer": "Example Bank"
  },
  "transaction_refund_outcome": null,
  "transaction_network_id": null,
  "subscription_cancel_outcome": null,
  "note": "Customer requested immediate review",
  "integration_id": null,
  "integration_transaction_id": null,
  "created_at": "2025-02-11T10:30:00Z"
}
```

- `alert_type` — either `ETHOCA_ALERT` or `VERIFI_RDR`.
- `status` — `ACTION_REQUIRED` (Ethoca only), `RESOLVED`, or `INVALID`.
- `transaction_authorized_at`, `action_required_deadline`, and `created_at` — ISO 8601 timestamps in UTC (for example, `"2025-02-11T10:30:00Z"`). For Ethoca alerts, you must act before `action_required_deadline` or the chargeback proceeds regardless of whether you refunded the customer.
- `transaction_acquirer_reference_number` — the ARN, which is useful when communicating with your PSP to identify the transaction.
- `transaction_statement_descriptor` — the descriptor that appeared on the cardholder's statement.
- `transaction_card_bin` — first 6–11 digits of the card number. Also included in `card.bin`.
- `card` — card details for the disputed transaction, when available. Contains `bin` (BIN/IIN), `last_four` (last four digits), `brand` (card scheme, for example `VISA` or `MASTERCARD`), and `issuer` (issuing bank name).
- `transaction_refund_outcome` — populated when a refund outcome is known. For Verifi RDR, this is set automatically.

## The configuration object

When an enrolment's status changes, the `payments.pre-chargeback-enrolment-status.updated` event includes a configuration object in `data`. Here is a full example:

```json
{
  "id": "{chargeback_alerts_enrolment_id}",
  "merchant_id": "{merchant_id}",
  "type": "ETHOCA_ALERT",
  "old_status": "PENDING",
  "status": "ACTIVE",
  "updated_at": "2025-02-11T10:30:00Z"
}
```

- `id` — Evervault enrolment UUID (for example, `chargeback_alerts_enrolment_...`).
- `merchant_id` — Evervault merchant ID the enrolment belongs to.
- `type` — enrolment network: `ETHOCA_ALERT` or `VERIFI_RDR`.
- `old_status` — status before this update. `null` on the first event for a new enrolment.
- `status` — current enrolment status after the update. See [enrolment statuses](#enrolment-statuses) for possible values.
- `updated_at` — ISO 8601 timestamp (UTC) when the enrolment was last updated.

Provider-specific configuration (Ethoca descriptors, Verifi BIN/CAID, and so on) is not included in the webhook payload — retrieve the merchant via the [Merchants API](/api#getMerchant) if you need the full enrolment details.

## Testing (sandbox)

In sandbox, you can simulate an incoming alert without waiting for a real dispute. This is useful for testing your webhook handler and alert-processing logic.

```bash
curl -X POST 'https://api.evervault.com/payments/pre-chargeback-alerts/simulate-alert' \
  -H 'Content-Type: application/json' \
  -u '<app_id>:<api_key>' \
  -d '{
    "merchantId": "{merchant_id}",
    "status": "ACTION_REQUIRED",
    "cardScheme": "MASTERCARD",
    "amountInCents": 4999,
    "currencyCode": "USD"
  }'
```

All fields other than `merchantId` are optional. The `merchantId` must belong to a merchant that has already been enrolled in pre-chargeback alerts. When supplied:

- `amountInCents` must be a positive integer.
- `currencyCode` must be a valid ISO 4217 code.
- `status` must be one of `ACTION_REQUIRED`, `RESOLVED`, or `INVALID`.
- `cardScheme` must be one of `VISA`, `MASTERCARD`, `MAESTRO`, `AMEX`, `DISCOVER`, `JCB`, `DINERS_CLUB`, `UNIONPAY`, `RUPAY`, `INTERAC`, `MIR`, or `OTHER`.
- `transactionRefundOutcome` must be `REFUNDED` or `NOT_REFUNDED`, and may only be supplied when `status` is `RESOLVED`.
- `transactionAcquirerReferenceNumber` must be exactly 23 characters.
- `transactionAuthorizationCode` must be exactly 6 characters.

The endpoint returns a simulated alert object with a `201` status.

> Simulate is only available for sandbox apps.

## Disable alerts

To disable pre-chargeback alerts for a merchant, call `PATCH /payments/merchants/{merchant_id}` with `preChargebackAlerts.enabled` set to `false`:

```bash
curl -X PATCH 'https://api.evervault.com/payments/merchants/{merchant_id}' \
  -H 'Content-Type: application/json' \
  -u '<app_id>:<api_key>' \
  -d '{
    "preChargebackAlerts": {
      "enabled": false
    }
  }'
```

> If the merchant is already actively receiving alerts, the unenrolment process
>   is manual and takes a few working days to complete. The merchant will continue
>   to receive alerts during this window.

## Errors

Pre-chargeback alerts endpoints return standard Evervault API error responses. Common cases:

| HTTP status | When |
| --- | --- |
| `400` | The request is invalid — for example, an invalid field in an update or simulate request (such as an unrecognised `action`, `status`, `cardScheme`, or `transactionRefundOutcome`); invalid, empty, or partial rule `parameters`; creating a rule for a merchant that has no Verifi RDR enrolment; a rule already exists for the merchant; or malformed query parameters on the alerts list. |
| `404` | The requested resource was not found — for example, an alert or rule ID that does not exist, a rule that does not belong to the merchant, a merchant that does not exist or is not yours, or pre-chargeback alerts that have not been configured for the app. |
| `422` | The alert network rejected the request — for example, attempting to action an alert that is already resolved. |

## Reason codes

Each alert includes a `chargeback_reason_code` field that identifies why the dispute was raised. The codes differ by card network.

| Code | Description |
| --- | --- |
| **Visa** | |
| 10.1 — EMV Liability Shift Counterfeit Fraud | A counterfeit copy of the cardholder's chip card was used to make fraudulent purchases. |
| 10.2 — EMV Liability Shift Non-Counterfeit Fraud | The cardholder's chip card required PIN verification, but the merchant processed it at a terminal without a chip reader. |
| 10.3 — Other Fraud: Card-Present Environment | The cardholder disputed a transaction that was key-entered by staff, or processed at an unattended terminal without the cardholder's involvement. |
| 10.4 — Other Fraud: Card-Absent Environment | The cardholder claimed that a card-not-present transaction was unauthorized. |
| 10.5 — Visa Fraud Monitoring Program | The merchant is enrolled in Visa's fraud monitoring program, which permits the issuer to raise disputes. |
| 11.1 — Card Recovery Bulletin | The transaction exceeded the merchant's floor limit, and no authorization was requested from the card network before completing the sale. |
| 11.2 — Declined Authorization | The terminal received a decline or card-pickup response from the authorizing network, but the sale was completed regardless. |
| 11.3 — No Authorization | The payment was processed without attempting to obtain an authorization approval. |
| 12.1 — Late Presentment | The merchant submitted the transaction after the presentment window expired, by which point the account was no longer in good standing. |
| 12.2 — Incorrect Transaction Code | A debit was submitted when a credit was required, or a credit was submitted in place of a reversal. |
| 12.3 — Incorrect Currency | The currency at the terminal didn't match the currency transmitted to Visa during processing. |
| 12.4 — Incorrect Account Number | The transaction was applied to the wrong card account number. |
| 12.5 — Incorrect Amount | The amount debited from the cardholder differed from the amount they agreed to pay. |
| 12.6 — Duplicate Processing / Paid By Other Means | The same transaction was submitted more than once in a batch settlement, or the customer paid using a separate payment method and was charged again. |
| 12.7 — Invalid Data | The authorization request contained an error in a required field such as the transaction date, merchant category code, or country code. |
| 13.1 — Merchandise/Services Not Received | The cardholder didn't receive the goods or services within the timeframe that was defined at the point of sale. |
| 13.2 — Cancelled Recurring Transaction | A recurring charge was billed after the cardholder already requested cancellation of the subscription or agreement. |
| 13.3 — Not As Described or Defective Merchandise/Services | The item or service delivered was materially different from what was advertised at purchase, or arrived damaged or non-functional. |
| 13.4 — Counterfeit Merchandise | The goods received were not genuine, or the cardholder falsely asserted that authentic items were counterfeit. |
| 13.5 — Misrepresentation | The merchant's product or service descriptions were misleading, inaccurate, or materially incomplete. |
| 13.6 — Credit Not Processed | The merchant failed to apply an agreed credit, or the credit was issued too late to appear on the relevant billing statement. |
| 13.7 — Cancelled Merchandise/Services | Goods were returned or a service was cancelled, but the cardholder's account wasn't credited. |
| 13.8 — Original Credit Transaction Not Accepted | The cardholder declined to accept the original credit, or local regulations prevented the issuing bank from processing it. |
| 13.9 — Non-Receipt of Cash or Load Transaction Value | The cardholder didn't receive the full cash amount from an ATM withdrawal, or received only a partial disbursement. |
| **Mastercard** | |
| 4807 — Warning Bulletin File | The card appeared on a warning bulletin at the time of the transaction, indicating it shouldn't have been accepted. |
| 4808 — Authorization-Related Chargeback | The required authorization wasn't obtained before processing, or the transaction was completed after receiving a decline response. |
| 4812 — Account Number Not on File | The card account number submitted didn't match any record held by the issuer. |
| 4831 — Transaction Amount Differs | The amount charged to the cardholder didn't match what appeared on the transaction receipt. |
| 4834 — Duplicate Processing | The same transaction was submitted and settled multiple times. |
| 4837 — No Cardholder Authorization | The cardholder stated they didn't authorize the transaction and received no benefit from it. |
| 4840 — Fraudulent Processing of Transactions | A transaction was processed multiple times under a single authorization, or a series of fraudulent charges were made with a single approval. |
| 4842 — Late Presentment | The transaction wasn't submitted to the network within the required timeframe. |
| 4846 — Correct Transaction Currency Code Not Provided | The cardholder was billed in a different currency than the one used at the time of purchase. |
| 4850 — Installment Billing Dispute | A dispute was made over the terms or execution of an installment billing arrangement. |
| 4853 — Cardholder Dispute: Defective/Not as Described | The goods or services received were defective, damaged, or materially different from how they were described. |
| 4854 — Cardholder Dispute: Not Elsewhere Classified | The dispute doesn't fit any other defined category and wasn't resolved through direct negotiation. |
| 4855 — Goods or Services Not Provided | The merchant didn't deliver the goods or services the cardholder purchased. |
| 4859 — Services Not Rendered | The cardholder paid for a service that wasn't performed. |
| 4860 — Credit Not Processed | The merchant agreed to issue a credit but didn't process it within the expected timeframe. |
| 4863 — Cardholder Does Not Recognize: Potential Fraud | The cardholder can't identify the charge on their statement and suspects it may be fraudulent. |
| 4870 — Chip Liability Shift | A genuine chip card was used at a non-chip-capable terminal and a fraudulent transaction resulted. |
| 4871 — Chip/PIN Liability Shift | A chip-and-PIN card was processed at a terminal that didn't support chip-and-PIN authentication and fraud occurred. |
| 4999 — Domestic Chargeback Dispute | A domestic transaction was disputed under local card network operating regulations. |
| **American Express** | |
| A01 — Charge Exceeds Authorization Amount | The final amount billed exceeded the amount that was originally authorised. |
| A02 — No Valid Authorization | The transaction was processed without obtaining a valid authorization code. |
| A08 — Authorization Approval Expired | The authorization obtained prior to settlement had already lapsed when the charge was submitted. |
| C02 — Credit Not Processed | A credit was either not applied or was only partially posted to the cardholder's account. |
| C04 — Goods/Services Returned or Refused | The cardholder returned or refused the goods or services, but no refund was issued. |
| C05 — Goods/Services Cancelled | An order was cancelled in line with the merchant's stated policy but no refund was provided. |
| C08 — Goods/Services Not Received | The cardholder didn't receive the ordered goods or services within the expected timeframe. |
| C14 — Paid By Other Means | The cardholder paid for the transaction using a different payment method and was charged twice. |
| C18 — No-Show or CARDeposit Cancelled | A reservation was cancelled within the policy period but a no-show or deposit fee was still charged. |
| C28 — Cancelled Recurring Billing | A recurring charge was processed after the cardholder already cancelled the subscription or agreement. |
| C31 — Goods/Services Not As Described | The item received didn't match what was shown or described at the time of purchase. |
| C32 — Goods/Services Damaged or Defective | The goods arrived in a damaged condition or were defective upon delivery. |
| F10 — Missing Imprint | No card imprint was captured at the point of sale despite being required for the transaction type. |
| F14 — Missing Signature | The sales receipt lacks the cardholder's signature, which was required for the transaction. |
| F24 — No Cardmember Authorization | The cardholder denied authorizing or benefiting from the transaction. |
| F29 — Card Not Present | The cardholder disputed the transaction because the card wasn't physically present at the time of purchase. |
| F30 — EMV Counterfeit | A counterfeit chip card was used to complete a fraudulent transaction. |
| F31 — EMV Lost/Stolen/Non-Received | The card used in the transaction was reported lost, stolen, or was never received by the cardholder. |
| M01 — Chargeback Authorization | The cardholder authorized the merchant to raise a chargeback on their behalf. |
| M10 — Vehicle Rental: Capital Damages | The cardholder disputed capital damage charges applied by a vehicle rental company. |
| M49 — Vehicle Rental: Theft or Loss of Use | The cardholder disputed fees for theft or loss-of-use levied by a vehicle rental company. |
| P01 — Unassigned Card Number | The card number used didn't correspond to any account the issuer holds on record. |
| P03 — Credit Processed as Charge | A credit or refund was submitted in error as a charge to the cardholder. |
| P04 — Charge Processed as Credit | A purchase transaction was incorrectly posted to the account as a credit. |
| P05 — Incorrect Charge Amount | The amount charged differed from the amount at the time of the transaction. |
| P07 — Late Submission | The charge was submitted for settlement after the permitted submission window had closed. |
| P08 — Duplicate Charge | The same transaction was submitted and posted more than once. |
| P22 — Non-Matching Account Number | The account number used during authorization differed from the one recorded on the settled charge. |
| P23 — Currency Discrepancy | The currency of the settled transaction didn't match what was specified during authorization. |
| R03 — Insufficient Reply | The merchant's response to a previous dispute inquiry didn't contain enough information to resolve the issue. |
| R13 — No Reply | The merchant didn't respond to a dispute inquiry within the required timeframe. |
| **Discover** | |
| AA — Does Not Recognize | The cardholder can't identify the transaction on their statement. |
| AP — Recurring Payments | A recurring billing charge was processed after the cardholder cancelled the underlying subscription or agreement. |
| AW — Altered Amount | The transaction amount was changed after the cardholder's initial approval. |
| PM — Paid By Other Means | The purchase was settled using a different payment method, resulting in a duplicate charge on the Discover card. |
| RG — Non-Receipt of Goods or Services | The cardholder didn't receive the goods or services they purchased. |
| UA01 — Fraud: Card Present Transaction | The cardholder denied making a purchase that was processed as a card-present transaction. |
| UA02 — Fraud: Card Not Present Transaction | The cardholder stated they didn't authorize an online or telephone transaction. |
| UA05 — Fraud: Chip Counterfeit Transaction | A counterfeit chip card was used fraudulently at a chip-enabled terminal. |
| UA06 — Fraud: Chip and PIN Transaction | A chip-and-PIN transaction was disputed as fraudulent by the cardholder. |
| UA38 — Fraud: Fictitious Account | The account number used doesn't correspond to a genuine, active Discover card account. |