Visa Rapid Dispute Resolution

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

Cardholder files a dispute

The dispute hits Visa’s pre-dispute resolution layer.

Visa evaluates against your rules

Your RDR ruleset (configured by PayNext during enrollment) determines whether to auto-refund.

Outcome lands on the payment

If eligible, Visa issues the refund and closes the dispute. If not, the dispute proceeds as a regular chargeback.

payment_v2.updated webhook fires

The visa_rdr sub-object is written with the terminal outcome and the dispute reason.

Set up

Contact PayNext support

Request RDR enrollment for the integrations you want it on.

PayNext enrolls your CAID and rules with Visa

PayNext registers your and coordinates rule configuration with Visa.

Done

No code changes required. RDR outcomes appear on the fraud_prevention.visa_rdr sub-object of every affected payment.

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.

Both actions are attributed automatically as fraud_prevention: the auto-refunded payment’s refund_reason and the cancelled subscription’s cancellation_details.reason 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.

`visa_rdr` payload

{
  "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

Once visa_rdr is written, it is never cleared. Only a later RDR decision can change its status.

Webhook events

Updates to visa_rdr are delivered on the payment_v2.updated event. See Webhook event types and the Payment webhook object for the full schema.

Reference

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

Reason codes — Authorization (11.x)

Code	Name
`11.1`	Card Recovery Bulletin
`11.2`	Declined Authorization
`11.3`	No Authorization

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

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

Introduction

Use Cases

Platform

Payments

Fraud Prevention

Advanced Features

Developers

How RDR works

Set up

Subscription handling

`visa_rdr` payload

Re-decisions

Webhook events

Reference

​How RDR works

​Set up

​Subscription handling

​visa_rdr payload

​Re-decisions

​Webhook events

​Reference

How RDR works

Set up

Subscription handling

`visa_rdr` payload

Re-decisions

Webhook events

Reference