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

# Visa Rapid Dispute Resolution

> Auto-refund eligible disputes before they become chargebacks.

Visa Rapid Dispute Resolution (RDR) evaluates incoming disputes against your configured refund rules and issues refunds automatically when eligible. The dispute closes before it ever becomes a chargeback. When the rules don't match, the dispute proceeds normally and you handle it through your usual chargeback flow.

Outcomes arrive on the payment as `fraud_prevention.visa_rdr` and are always terminal—there is no submitted or pending state.

## How RDR works

<Steps>
  <Step title="Cardholder files a dispute">
    The dispute hits Visa's pre-dispute resolution layer.
  </Step>

  <Step title="Visa evaluates against your rules">
    Your RDR ruleset (configured by PayNext during enrollment) determines whether to auto-refund.
  </Step>

  <Step title="Outcome lands on the payment">
    If eligible, Visa issues the refund and closes the dispute. If not, the dispute proceeds as a regular chargeback.
  </Step>

  <Step title="payment_v2.updated webhook fires">
    The `visa_rdr` sub-object is written with the terminal outcome and the dispute reason.
  </Step>
</Steps>

## Set up

<Steps>
  <Step title="Contact PayNext support">
    Request RDR enrollment for the integrations you want it on.
  </Step>

  <Step title="PayNext enrolls your CAID and rules with Visa">
    PayNext registers your <Tooltip tip="Card Acceptor ID—the merchant identifier registered with the card network.">CAID</Tooltip> and coordinates rule configuration with Visa.
  </Step>

  <Step title="Done">
    No code changes required. RDR outcomes appear on the `fraud_prevention.visa_rdr` sub-object of every affected payment.
  </Step>
</Steps>

## Subscription handling

When an RDR notification lands on a payment that belongs to an active subscription, PayNext cancels the subscription immediately—regardless of whether Visa accepts or declines the case. A dispute filing is a strong signal that the cardholder no longer wants the charge to recur. The subscription `status` becomes `cancelled`.

All of the customer's active subscriptions at your account are acted on. Subscriptions the same customer holds at other merchants are not affected. Track changes via the `subscription_v2.cancelled` webhook.

<Note>
  Both actions are attributed automatically as `fraud_prevention`: the auto-refunded payment's `refund_reason` and the cancelled subscription's [`cancellation_details.reason`](/guides/platform/subscriptions#cancellation-details) are set to `fraud_prevention`, with `trigger_payment_id` pointing at the disputed payment — so you can distinguish RDR-driven activity from `merchant_initiated` actions.
</Note>

## `visa_rdr` payload

```json theme={"system"}
{
  "visa_rdr": {
    "status": "accepted",
    "case_id": "3d2ec10c-8a6c-4ef2-b7e9-0c7b1a9f23ea",
    "reason": {
      "code": "10.4",
      "name": "Other Fraud — Card Absent Environment",
      "category": "fraud"
    },
    "updated_at": "2026-04-23T12:45:51Z"
  }
}
```

| Field             | Type              | Description                                                                                                                    |
| :---------------- | :---------------- | :----------------------------------------------------------------------------------------------------------------------------- |
| `status`          | string            | Terminal RDR outcome. Closed enum: `accepted` (Visa refunded per your rule), `declined` (rule didn't match; dispute proceeds). |
| `case_id`         | string (UUID)     | Stable identifier for the RDR case.                                                                                            |
| `reason.code`     | string            | Visa dispute reason code (e.g. `10.4`). Open enum—new codes pass through with `name: null` and `category: null`.               |
| `reason.name`     | string \| null    | Human-readable reason name, derived from `reason.code` at write time. `null` for codes not yet in the catalog.                 |
| `reason.category` | string \| null    | Reason category. Open enum: `fraud`, `authorization`, `processing`, `consumer`. `null` for codes not yet in the catalog.       |
| `updated_at`      | string (ISO-8601) | Timestamp of the RDR outcome, UTC with `Z` suffix.                                                                             |

## Re-decisions

`visa_rdr` is written only when Visa delivers a new dispute decision. A later decision on the same case overwrites `status`, `reason`, and `updated_at` — last-write-wins.

| Visa event                                           | Effect on `visa_rdr` |
| :--------------------------------------------------- | :------------------- |
| New decision, accepted                               | `status: "accepted"` |
| New decision, declined                               | `status: "declined"` |
| Retraction, timeout, or update without a new outcome | No change            |

<Note>
  Once `visa_rdr` is written, it is never cleared. Only a later RDR decision can change its `status`.
</Note>

## Webhook events

Updates to `visa_rdr` are delivered on the `payment_v2.updated` event. See [Webhook event types](/webhooks/introduction/event-types) and the [Payment webhook object](/webhooks/objects/payment/payment) for the full schema.

## Reference

<AccordionGroup>
  <Accordion title="Reason codes — Fraud (10.x)">
    | Code   | Name                                      |
    | :----- | :---------------------------------------- |
    | `10.1` | EMV Liability Shift Counterfeit Fraud     |
    | `10.2` | EMV Liability Shift Non-Counterfeit Fraud |
    | `10.3` | Other Fraud — Card Present Environment    |
    | `10.4` | Other Fraud — Card Absent Environment     |
    | `10.5` | Visa Fraud Monitoring Program             |
  </Accordion>

  <Accordion title="Reason codes — Authorization (11.x)">
    | Code   | Name                   |
    | :----- | :--------------------- |
    | `11.1` | Card Recovery Bulletin |
    | `11.2` | Declined Authorization |
    | `11.3` | No Authorization       |
  </Accordion>

  <Accordion title="Reason codes — Processing (12.x)">
    | Code     | Name                       |
    | :------- | :------------------------- |
    | `12.1`   | Late Presentment           |
    | `12.2`   | Incorrect Transaction Code |
    | `12.3`   | Incorrect Currency         |
    | `12.4`   | Incorrect Account Number   |
    | `12.5`   | Incorrect Amount           |
    | `12.6.1` | Duplicate Processing       |
    | `12.6.2` | Paid by Other Means        |
    | `12.7`   | Invalid Data               |
  </Accordion>

  <Accordion title="Reason codes — Consumer (13.x)">
    | Code   | Name                                               |
    | :----- | :------------------------------------------------- |
    | `13.1` | Merchandise/Services Not Received                  |
    | `13.2` | Cancelled Recurring                                |
    | `13.3` | Not as Described or Defective Merchandise/Services |
    | `13.4` | Counterfeit Merchandise                            |
    | `13.5` | Misrepresentation                                  |
    | `13.6` | Credit Not Processed                               |
    | `13.7` | Cancelled Merchandise/Services                     |
    | `13.8` | Original Credit Transaction Not Accepted           |
    | `13.9` | Non-Receipt of Cash or Load Transaction Value      |
  </Accordion>
</AccordionGroup>