Visa Dispute Resolution: A Merchant's Guide to Win in 2026
A merchant can refund a Visa alert and still carry the fraud signal that threatens its monitoring position. That's the uncomfortable reality of Visa dispute resolution in 2026. Visa says it processed 106 million disputes globally in 2025, 35% above 2019 levels, while its newer dispute framework and AI tools changed how merchants must think about pre-dispute automation. Visa's 2026 dispute announcement makes the direction clear: automation is expanding, but a fast refund is no longer a complete risk strategy.
If your first dispute wave has arrived, don't start by refunding everything. Separate fraud signals from chargeback counts, map each case to its reason code, and build an evidence workflow before the next deadline hits.
The New Reality of Visa Disputes in 2026
A mid-market direct-to-consumer brand can run clean operations for years, then see its Visa monitoring position deteriorate after its payment data is classified differently under the current program. The team may not have changed its checkout, fraud tools, or customer service. What changed is the way issuers, networks, and acquirers classify and transmit dispute activity.
That distinction matters. Visa dispute resolution is no longer a back-office exercise that begins after a chargeback reaches the merchant. Visa says its systems handled about 1.1 billion disputes annually in 2024, with a reported 90% recovery rate compared with a 79% industry average. The same reporting says Visa's pre-dispute tools resolved $695 million in pre-disputes, covered 97% of global Visa issuer activity through RDR, and resolved 13.3 million card-network-agnostic pre-disputes. Visa's dispute-management overview shows how automated these workflows now sit inside the payments network.
Three forces are reshaping merchant exposure:
- Evidence standards are stricter. Issuers expect structured proof tied to the reason code, not a general statement that the customer received the order.
- Pre-dispute pipelines move quickly. An alert is useful only if your processor can retrieve the transaction and issue an appropriate action inside the available window.
- Acquirers push operational liability downstream. Merchants increasingly absorb the cost of late responses, weak documentation, poor descriptors, and fragmented fulfillment records.
Operational rule: A refund decision and a fraud-reporting decision are no longer automatically the same decision.
The old reflex was simple: refund quickly, avoid the chargeback, and move on. In 2026, that approach can leak revenue while leaving the underlying fraud signal intact. Your actual job this week is to decide which cases deserve a refund, which deserve evidence, and which data your acquirer is using to evaluate the account.
What Visa Dispute Resolution Actually Means
“Dispute” is often used as a catch-all term. That creates bad routing decisions. An inquiry is an issuer or cardholder question about a transaction. A pre-dispute alert is an early warning that gives the merchant an opportunity to resolve the issue before a formal chargeback. A chargeback is the formal reversal of all or part of a transaction value from the issuer to the acquirer, usually onward to the merchant bank, as Visa describes in its public business guidance on dispute resolution.
RDR, or Visa Rapid Dispute Resolution, is the network's automated pre-dispute path. Think of it as the issuer tapping the merchant on the shoulder before filing. The merchant's configured rules determine whether the transaction receives a refund. RDR is Visa-specific.
CDRN, the Chargeback Dispute Resolution Network, is a Verifi alert path that gives the merchant transaction context and an opportunity to resolve a cardholder concern before it becomes a chargeback. It generally requires an operational decision rather than relying only on a preconfigured Visa RDR decision.
Ethoca Alerts provide another early warning channel, commonly used across Mastercard-related and broader issuer workflows. The important distinction isn't the brand name. It's whether the alert reaches your payment system with enough transaction detail and time for your team or automation to act.
Representment is the merchant's formal response after a chargeback. The merchant submits evidence through the acquirer, attempting to reverse the issuer's decision. If the issuer rejects that response, the case can move to pre-arbitration and potentially arbitration, where network rules determine the next liability decision.
| Term | Who triggers it | What the merchant does |
|---|---|---|
| Inquiry | Cardholder or issuer | Clarifies the transaction and supplies available details |
| Pre-dispute alert | Issuer or alert network | Reviews the case and chooses refund, decline, or evidence routing |
| RDR | Visa issuer through Visa's resolution network | Applies configured rules and resolves eligible cases automatically |
| Chargeback | Issuer | Accepts the reversal, checks the reason code, and prepares a response |
| Representment | Merchant through its acquirer | Submits reason-code-specific evidence |
| Pre-arbitration or arbitration | Issuer, acquirer, or network process | Escalates only when the earlier response didn't resolve liability |
The distinction that causes the most expensive mistake is this: removing a chargeback isn't the same as removing a fraud signal. Recent analysis of the 2026 VAMP environment notes that RDR and CDRN can eliminate TC15 dispute counts while no longer suppressing TC40 fraud signals. A refund may protect one metric while leaving another exposed. Build your workflow around both.
How the Dispute Lifecycle Works Step by Step
The lifecycle starts with the cardholder, not the merchant. The cardholder contacts the issuer, the issuer reviews the complaint, and the issuer opens a case under an applicable reason code. Visa then transmits the case through its dispute infrastructure to the acquirer, which notifies the merchant or the merchant's processor.
Visa describes the dispute as a reversal of transaction value. That means the merchant must respond to the actual allegation, not merely prove that an order exists. A delivery record may help with a non-receipt claim, but it won't necessarily answer a fraud or authorization allegation.
The practical sequence looks like this:
- Cardholder contacts the issuer. The cardholder reports fraud, a missing product, a recurring billing problem, or another transaction issue.
- Issuer opens the case. The issuer assigns a reason code and sends the case through Visa's dispute process.
- Acquirer notifies the merchant. The processor or acquirer supplies the case details and response deadline.
- Merchant chooses the path. The merchant may accept the claim, resolve it through a pre-dispute channel, or submit representment evidence.
- Issuer reviews the response. The issuer either accepts the merchant's evidence or rejects it.
- The case escalates. A rejected response can move into pre-arbitration or arbitration.
Some processors impose merchant response windows of 9 days for U.S. and Canada local disputes and 18 days in many other regions, according to Adyen's Visa chargeback guidance. Treat those as operational deadlines, not suggestions. Your processor agreement can impose its own timing rules, and the shortest applicable window governs your workflow.
Reason codes determine the evidence
Reason code 10.4, other fraud, requires identity and transaction linkage. Visa's published rules identify evidence such as device ID, device fingerprint, IP address, account or login ID, and delivery address across at least two prior undisputed transactions more than 120 days old. Visa's public rules also describe restrictions on acceptable photographic or email evidence in certain circumstances.
Reason code 13.1, merchandise or services not received, calls for fulfillment and delivery proof. Reason code 11.3, no authorization, requires authorization records and a coherent explanation of how the transaction was approved.
Every stage can add cost, including the reversed transaction amount, processor or chargeback fees, representment handling charges, and arbitration filing costs. Don't assume a case is worth fighting until you compare the transaction value with the evidence quality and the likely operational burden.
Comparing RDR, Verifi CDRN, and Ethoca Alerts
These tools overlap, but they aren't interchangeable. RDR belongs to Visa, Verifi's CDRN supplies a separate pre-dispute alert path, and Ethoca provides a broader alert ecosystem commonly used for Mastercard and cross-network issuer activity.
The core business question is not which logo appears in the dashboard. It's whether the alert arrives with enough data for your system to make a defensible decision before the issuer advances the case.
| Feature | Visa RDR | Verifi CDRN | Ethoca Alerts |
|---|---|---|---|
| Network ownership | Visa | Verifi, a Visa-owned service provider | Ethoca, commonly associated with Mastercard workflows |
| Primary stage | Pre-dispute | Pre-dispute | Pre-dispute |
| Merchant action | Automated rule-based refund or configured resolution | Merchant or platform reviews and resolves the alert | Merchant or platform reviews and resolves the alert |
| Automation profile | Strong when rules and processor integration are configured | Depends on the merchant's integration and rules | Depends on the merchant's integration and rules |
| Coverage | Visa transactions and participating issuers | Order and dispute context through participating issuers | Broad issuer and network participation |
| Main operational risk | Refunding cases that could have been defended, while missing fraud-signal implications | Alerts become noise without fast transaction matching | Alerts become noise without reliable refund and order workflows |
RDR works well when a merchant has clear rules for transaction amount, issuer, currency, category, and reason code. CDRN is useful when the business needs richer order-source context or wants to handle cases outside a simple Visa-only rule set. Ethoca becomes more important for merchants with meaningful Mastercard volume or an omnichannel footprint.
The trade-off is control versus coverage. A narrow RDR strategy can be precise but incomplete. A multi-network alert stack can capture more events but create operational noise if your processor doesn't expose real-time webhooks, refund status, and order-level data.
An alert without a connected refund path is just a faster notification.
For a Visa-heavy ecommerce portfolio, prioritize RDR and CDRN. For a merchant operating across Visa and Mastercard, layer Ethoca on top, then filter aggressively by reason code, product line, order value, and evidence strength.
Why 2026 VAMP Changes the Math for Merchants
The 2026 VAMP rules break a common assumption: a successful pre-dispute refund does not necessarily protect every monitoring metric. Visa now treats fraud reporting and dispute reporting as related but separate signals. RDR and CDRN may still remove TC15 dispute counts while leaving TC40 fraud signals in place. Review your acquirer's interpretation before changing automation rules.
The decision rule must therefore cover more than chargeback prevention. For every alert, ask:
- What reason code is involved?
- Will the action affect the TC15 count, the TC40 signal, or both?
- Could strong evidence defeat the case?
- How does the acquirer calculate monitoring exposure for this account?
Some industry analyses cite thresholds around 0.9% fraud and 1.8% dispute-to-sales, but the verified Visa materials here do not establish those figures as a universal current VAMP table. Treat them as example thresholds, not compliance facts. Ask your acquirer for the applicable table, effective date, merchant-category treatment, and calculation method.
Replace blanket refunds with triage
Refund every alert when fraud is clear, the merchant made an error, or usable evidence is missing. Route the case for review when the transaction has a credible defense. A blanket refund policy can reduce immediate disputes while preserving the underlying TC40 signal and giving up revenue unnecessarily.
Map each reason code to the evidence required. For 10.4, connect the cardholder, device, account, and fulfillment history. For 13.1, retain delivery, tracking, service-use, and customer communication records. For 11.3, preserve authorization results, authentication data, and recurring billing consent.
Visa's rules require issuers to certify that they contacted the cardholder and reviewed compelling evidence. Your pre-dispute workflow should mirror that structure. Build reason-code-specific evidence mapping this week, then measure refunds, TC15 outcomes, TC40 signals, and representment wins separately. Pre-dispute automation is triage, not surrender.
Merchant Playbook for Preventing Disputes
Start Monday with the workflow, not the dashboard. Your team needs a decision tree that tells customer service, fraud operations, and payments operations what to do with the same alert.
1. Resolve customer friction before issuer contact
Make your billing descriptor recognizable. Publish refund and cancellation policies where customers can find them. Give support agents a direct path to cancel an unwanted renewal, correct a duplicate order, or explain a fulfillment delay before the cardholder contacts the issuer.
A merchant-controlled refund is usually easier to document than an issuer-originated dispute. It also gives customer service a chance to preserve the relationship instead of forcing the customer into a formal bank process.
2. Filter alerts by defensibility
Don't configure automatic refunds solely by transaction value. Combine value with reason code, product type, delivery status, customer history, issuer information, and available evidence.
Refund automatically when the merchant error is clear or the transaction has no credible defense. Route likely friendly-fraud cases into evidence collection. Review the rules whenever refund volume rises without a corresponding reduction in formal cases.
3. Build the evidence library before the deadline
Create reusable evidence templates for each major code:
- 10.4 fraud: 3DS results, device and IP linkage, account history, prior undisputed transactions, and delivery details where permitted.
- 13.1 non-receipt: carrier tracking, delivery confirmation, service access logs, and customer messages.
- 11.3 authorization: authorization response, recurring agreement, authentication record, and transaction timeline.
Your OMS, PSP, fraud platform, subscription engine, and support system should feed one case record. If an analyst has to search five systems manually, the case is already at risk.
4. Connect alerts to real-time actions
Choose a processor integration that exposes webhook-based alerts, refund status, and transaction identifiers. Batch files create avoidable latency. Your team needs to know when the alert arrived, when the refund was attempted, whether it succeeded, and whether the case moved forward.
5. Review the right dashboard every week
Break the data down by BIN, product line, fulfillment route, customer segment, reason code, and alert source. Look for concentration, not just the blended ratio. A single subscription product or issuer group can create the problem while the overall account still appears stable.
The chargeback-fighting workflow should connect prevention, evidence, and escalation rather than treating them as separate queues.
How Disputely Fits Into a Modern Dispute Stack
A modern dispute stack needs a control plane between issuer alerts and merchant systems. That layer should receive the alert, identify the order, classify the reason code, apply a refund rule where appropriate, and route defensible cases into evidence assembly.
Disputely is one option for that layer. Its stated workflow connects Visa RDR, Mastercard CDRN, and Ethoca alerts with payment processors, allowing merchants to configure automatic resolution rules and monitor incoming alerts in real time. The relevant use case isn't “refund everything.” It's refund the cases that should be refunded, then preserve the evidence path for the rest.
That distinction is central under VAMP. A platform that merely reduces filed chargebacks may still leave the merchant exposed to fraud reporting. A better workflow records both outcomes: what happened to the dispute count and what happened to the fraud signal. Merchants should confirm the exact treatment with their acquirer instead of assuming the platform's outcome applies identically to every monitoring calculation.
Compare the operating models
| Metric | Manual workflow | Issuer-funded refund only | Disputely managed |
|---|---|---|---|
| Alert handling | Analyst checks portals and inboxes | Merchant receives an alert and acts manually | Rules route alerts to refund or evidence workflows |
| Transaction matching | Manual lookup across systems | Depends on processor detail | Connected transaction and order records |
| Evidence preparation | Built after the chargeback arrives | Often skipped after refund | Can be organized before the response deadline |
| Main advantage | Maximum human judgment | Simple operational setup | Consistent routing across alert sources |
| Main risk | Missed deadlines and inconsistent decisions | Over-refunding and incomplete monitoring visibility | Poor rules can automate the wrong decision |
The economic comparison should use your own ledger. Record refund cost, processor fees, analyst time, lost merchandise, representment recovery, and any reserve or account restrictions. Don't use generic savings claims to justify a tool. Calculate what one avoided filing costs your business and how many alerts your team can process without automation.
If your team is spending its week matching alerts to orders, connect the systems and define the rules. A merchant can review a dispute-resolution workflow that places alert intake, automated decisions, and representment preparation in one operating path. The platform won't replace reason-code judgment. It can make that judgment repeatable.
Your 30-Day Action Plan and What to Watch Next
Use the next month to replace improvisation with measured routing. Don't wait for the next acquirer warning before asking how TC40 and TC15 activity are calculated.
Week 1
Pull the last 90 days of TC40 and dispute data, and group every event by reason code, issuer, product, fulfillment status, and alert source. The plan notes identify the two codes responsible for 70% of the damage, but your own data must verify that concentration before you act. Start evidence work where volume and defensibility intersect.
Week 2
Ask your PSP and acquirer for the current VAMP dashboard, the applicable threshold table, the distinction between RDR-eligible and non-eligible flows, and the treatment of TC40 after pre-dispute refunds. Request written clarification on merchant-category classification and any fee or reserve consequences.
Week 3
Connect a chargeback alert platform, configure refund rules by reason code, and feed 3DS authentication results, order records, delivery data, and customer communications into the case workflow. Don't activate blanket automation. Run the rules against historical alerts first, then approve only the paths your evidence and economics support.
Week 4
Create a weekly dashboard covering dispute rate, refund-to-alert ratio, reason-code mix, evidence submission speed, recovery outcomes, and VAMP position. Hold a short payments, fraud, fulfillment, and support review every week. Assign one owner to each recurring root cause.
Watch Visa's new dispute tools, acquirer guidance, and future rule or fee updates, but don't run the business on predictions. Your immediate priority is evidence quality, response speed, and a clear record of how refunds affect both dispute counts and fraud signals. Merchants using Shopify or similar ecommerce systems can also review Shopify chargeback protection options while designing the broader workflow.
Disputely connects Visa RDR, CDRN, and Ethoca alerts to automated refund rules and evidence workflows, so your team can separate legitimate refunds from cases worth defending. Review your alert volume and reason-code mix this week, then visit Disputely to see whether a connected dispute-resolution workflow fits your processor stack.
