Chargeback Reason Codes: An MSP-Level Guide

Why reason codes carry different weight at portfolio scale

A single merchant looks at a reason code and asks one question. Can I win this case?

That question matters, but it is the smallest question available. A service provider looking at the same code across four thousand merchant accounts is reading something else entirely: a signal about where risk is concentrating, which verticals are generating liability that will eventually land on the acquiring side of the ledger, and which merchants are on a trajectory toward network enforcement.

Chargeback reason codes are structured data. Underused structured data, in most portfolios.

The distinction is worth stressing early because it changes how the rest of this guide should be read. We walk through the full inventory of codes across all four major networks, and each one gets an explanation of what the underlying transaction condition was. But the operational value comes from aggregation, not from case-by-case interpretation. More on that in the closing sections.

One terminology note before the codes. Disputes and chargebacks are sequential stages, not synonyms. A cardholder contacts their issuer and initiates a dispute. If that dispute is not resolved at the inquiry or alert stage, it progresses into a formal chargeback with a reason code attached. Some network documentation blurs the two. We keep them separate throughout, because the interventions available at each stage are completely different, and the window between them is where most portfolio-level savings live.

How the four networks structure their codes

Each network organizes dispute conditions differently, and the structural differences matter for anyone building cross-network reporting.

Visa uses a two-part numeric system introduced with Visa Claims Resolution in April 2018. The first number identifies one of four dispute categories, and the decimal identifies the specific condition. Mastercard uses four-digit message codes that have been consolidated significantly since 2016, with granular subcategories nested inside a handful of parent codes. American Express uses alphanumeric codes grouped into families by first letter. Discover uses two-character and four-character alphabetic identifiers that map loosely to the same families.

Building a unified portfolio view means mapping all four schemes onto a common taxonomy. Most service providers settle on something close to fraud, authorization, processing error, and consumer dispute, which is essentially Visa’s structure applied outward. That mapping is imperfect at the edges, and the edges are worth documenting internally so your analysts know where the joins are approximate.

Visa Category 10 fraud dispute conditions

Category 10 covers transactions the cardholder claims were not authorized by them. These conditions move through Visa’s Allocation workflow, which means liability is assigned by the network based on transaction data before the merchant sees the case, rather than being negotiated through document exchange. Merchants and their service providers respond after allocation, not before.

Visa 10.1 EMV liability shift counterfeit fraud

A counterfeit card was used at a merchant location that could not process a chip transaction, and the cardholder confirms they did not participate. Liability shifts toward the acquiring side because the terminal was not chip-enabled. Defensible outcomes here are limited, and the practical remediation is terminal upgrade rather than representment. For service providers, a cluster of 10.1 activity within a merchant segment usually points to a hardware deployment problem rather than a fraud problem.

Visa 10.2 EMV liability shift non-counterfeit fraud

A lost, stolen, or never-received chip card was used at a terminal that could not support chip and PIN verification. The condition is closely related to 10.1, but the card itself is genuine. Regions where PIN is the standard cardholder verification method see this code more often than markets where signature or no-CVM is common. Again, the fix is generally at the terminal level.

Visa 10.3 other fraud in a card-present environment

The cardholder states they did not authorize a card-present transaction, and the EMV liability shift conditions do not apply. Keyed entry and magnetic stripe fallback transactions surface here regularly. Compelling evidence typically involves cardholder identification, signed receipts, or proof that the cardholder benefited from the transaction. Card-present fraud volume in a portfolio should be low, so any merchant generating meaningful 10.3 counts deserves a manual review of their acceptance environment.

Visa 10.4 other fraud in a card-absent environment

This is the highest-volume fraud condition in most e-commerce portfolios, and it is where first-party fraud hides. The cardholder claims they did not authorize a card-not-present transaction. Some of these cases are genuine third-party compromise. Many are what the industry calls friendly-fraud.

Visa’s Compelling Evidence 3.0 framework applies specifically to this condition, and only to this condition. It does not extend to other fraud codes, authorization disputes, or processing errors. Qualification requires two prior undisputed transactions between the same cardholder and the same merchant, dated at least 120 days but no more than 365 days before the disputed transaction. At least two of four core data elements need to match across all three transactions: user ID, IP address, shipping address, and device ID or fingerprint. One of those two matches must be either the IP address or the device ID. The first six characters of the billing descriptor also need to be identical across all three.

Two developments are worth flagging for anyone advising merchants on CE3.0. In October 2025 Visa expanded the framework to support automated qualification through Visa Secure and Visa Data Only across major regions. And as of April 2026, merchants can submit historical transaction data to prevent certain fraud reports from counting against their dispute ratio. Both changes reward merchants with disciplined data retention, and both are difficult to operationalize without automation.

Worth noting. CE3.0 offers nothing for first-time buyers, because the historical footprint does not exist yet.

Visa 10.5 Visa Fraud Monitoring Program

This condition has an unusual status right now, and service providers should understand why. Visa applies 10.5 to transactions identified through the Visa Fraud Monitoring Program, and representment rights are typically restricted. But VFMP itself was retired in April 2025 and folded into the consolidated Visa Acquirer Monitoring Program.

The dispute condition did not disappear with it. Merchants can remain subject to 10.5 for trailing fraud activity, and the US-only Visa Fraud Monitoring Program for 3D Secure continues to operate as a separate mechanism. Any 10.5 volume in a portfolio should be treated as an escalation trigger regardless of dollar value.

Visa Category 11 authorization dispute conditions

Category 11 covers failures in the authorization process itself. These also move through Allocation. In most cases the underlying cause is a gateway configuration issue, a batch processing defect, or a merchant policy that permits processing without valid approval. That makes Category 11 one of the more fixable code families in the entire inventory.

Visa 11.1 card recovery bulletin

A transaction below the merchant floor limit was completed without authorization, and the account number appeared on the Card Recovery Bulletin or Exception File at the time. Floor limit acceptance has become rare in most markets, so this condition appears infrequently. When it does appear, it usually indicates a legacy terminal configuration still operating on offline rules.

Visa 11.2 declined authorization

The merchant received a decline and processed the transaction anyway. There is very little defensible ground here. Occasionally the cause is a legitimate stand-in scenario or a subsequent approval that was not properly linked, but far more often it reflects a merchant workflow that treats declines as advisory. Recurring billing operations are frequent offenders, particularly where retry logic is aggressive.

Visa 11.3 no authorization

No valid authorization was obtained for the transaction at all. This includes transactions processed after an authorization expired, transactions where the authorization amount and settlement amount diverged beyond permitted tolerance, and transactions submitted with no approval record. Merchants in lodging, car rental, and delivery categories generate this code more than others because of incremental and estimated authorization practices. Documentation of proper incremental authorization handling is the primary defense.

Visa Category 12 processing error conditions

Category 12 conditions move through Visa’s Collaboration workflow, which means the acquiring side receives the case with an opportunity to respond before liability is finalized. These are operational defects rather than fraud or consumer complaints. Portfolio-wide, they are among the most preventable conditions anywhere in the inventory.

Visa 12.1 late presentment

The transaction was not submitted for clearing within the required timeframe, and the cardholder account was closed or otherwise not in a position to be debited when it finally arrived. Batch settlement delays, integration failures, and manual submission processes are typical causes. A merchant producing repeated 12.1 activity has a settlement pipeline problem that will eventually create reconciliation issues well beyond disputes.

Visa 12.2 incorrect transaction code

The transaction was submitted with the wrong transaction code, most commonly a credit processed as a debit or the reverse. The cardholder sees a charge where they expected a refund. Refund processing errors are the usual root cause, and they tend to cluster around staff turnover or point-of-sale software changes.

Visa 12.3 incorrect currency

The transaction currency was handled improperly. This condition covers dynamic currency conversion applied without the cardholder having been offered a clear choice, as well as transactions cleared in a currency different from the one presented at the point of interaction. Merchants operating cross-border with DCC-enabled terminals should have their disclosure flow audited if this code appears.

Visa 12.4 incorrect account number

The transaction was submitted with an account number that does not match the account on the transaction receipt or the account that was authorized. Manual keying and truncation errors account for most of these. Volume here is usually low but concentrated within specific merchants, which makes remediation straightforward once identified.

Visa 12.5 incorrect amount

The amount cleared differs from the amount the cardholder authorized or the amount on the receipt. Tip adjustment errors, decimal placement mistakes, and currency rounding are common triggers. Hospitality and personal services merchants see this more than most.

Visa 12.6.1 duplicate processing

The same transaction was submitted to clearing more than once. Terminal retry behavior, duplicate batch submission, and integration race conditions are the usual causes. Because duplicates often arrive in clusters, a single processing defect can generate a burst of chargebacks that materially moves a merchant’s monthly ratio.

Visa 12.6.2 paid by other means

The cardholder paid for the same goods or services through a different payment method and was charged twice. Split-tender transactions and situations where a customer switches payment methods mid-transaction produce this condition. Evidence of two separate purchases, or documentation that the alternative payment was refunded, forms the basis of any response.

Visa 12.7 invalid data

The transaction was submitted with invalid or incorrect data in the authorization request. This is a technical compliance condition tied to field-level accuracy. It appears more often in portfolios with custom integrations or older gateway connections that have not been updated to current message specifications.

Visa Category 13 consumer dispute conditions

Category 13 is where the cardholder acknowledges making the purchase but disputes what happened afterward. These conditions run through Collaboration, and they are the most evidence-responsive family in the Visa inventory. They are also the family where merchant policy and customer service quality show up most directly in the data.

Visa 13.1 merchandise or services not received

The cardholder paid but never received what they bought, or received it substantially later than agreed. Proof of delivery, service completion records, and documented fulfillment timelines are the core evidence. Travel and event merchants encounter a variant of this condition when services are cancelled by the merchant rather than simply undelivered.

Visa 13.2 cancelled recurring transaction

The cardholder cancelled a recurring arrangement and was billed anyway, or was billed after notifying the merchant they wished to stop. Subscription businesses generate the bulk of this volume. Cancellation confirmations, records showing the cancellation request arrived after the billing date, and evidence of a functioning cancellation mechanism are what matter. A merchant with elevated 13.2 volume often has a cancellation flow that is technically present but practically difficult to complete.

Visa 13.3 not as described or defective merchandise or services

The item or service delivered did not match its description, or arrived damaged or non-functional. Evidence needs to address the specific mismatch the cardholder alleges. Product listings, specifications, communications with the customer, and return policy documentation all contribute. Marketplaces, platforms, and dropship models see disproportionate volume because the merchant of record often has limited control over the actual goods.

Visa 13.4 counterfeit merchandise

The cardholder claims the goods received were counterfeit, typically supported by a determination from a rights holder or a customs authority. Successful defense generally requires supply chain documentation and authorized reseller status. This code is rare in most portfolios but carries reputational risk beyond the dispute itself, and repeated activity should trigger an underwriting review.

Visa 13.5 misrepresentation

The cardholder alleges the terms of sale were misrepresented at the time of purchase. Terms and conditions disclosures, checkout screenshots, and acknowledgment records form the response. Free trial conversions and negative option billing arrangements attract this code, and merchants operating those models should expect scrutiny of their disclosure timing and placement.

Visa 13.6 credit not processed

The merchant agreed to a refund or credit that was never issued, or the cardholder returned merchandise under a policy entitling them to a refund. Processing the credit before the dispute escalates is nearly always cheaper than defending it. Refund backlogs are the most common underlying cause, and they are visible in operational data long before they surface as chargebacks.

Visa 13.7 cancelled merchandise or services

The cardholder cancelled an order or a service and was still charged, distinct from the recurring billing scenario in 13.2. Hotel cancellations, event ticket cancellations, and cancelled special orders fall here. Cancellation policy disclosure at the point of purchase is the pivotal evidence.

Visa 13.8 original credit transaction not accepted

An original credit transaction, meaning a push payment to a cardholder account, was refused or could not be accepted. This condition appears in payout-oriented business models such as gaming, remittance, and gig platforms rather than in traditional retail.

Visa 13.9 non-receipt of cash or load transaction value

The cardholder did not receive cash or the expected value load from a transaction. It applies to ATM activity, prepaid load transactions, and similar value-transfer scenarios. Most acquiring portfolios will see none of this unless they support ATM or prepaid program merchants.

Mastercard codes and their nested subcategories

Mastercard consolidated its inventory substantially beginning in 2016, folding many previously standalone codes into a smaller set of parent codes with detailed subcategories underneath. That structure means the four-digit code alone often tells you less than the equivalent Visa condition does. The subcategory is where the actual diagnostic information sits, and any reporting layer that captures only the parent code is discarding most of the signal.

All Mastercard dispute activity flows through Mastercom, the network’s dispute management platform. Mastercom Collaboration supports earlier-stage resolution before a chargeback is filed, and the Mastercard Dispute Resolution Initiative, correctly abbreviated MDRI rather than DRI, governs the broader modernization of these processes.

Mastercard 4808 authorization-related chargeback

This parent code covers authorization failure scenarios. Its subcategories include required authorization not obtained, where no valid approval existed; expired chargeback protection period, where the authorization aged beyond its protected window before clearing; multiple authorization requests, where repeated attempts created duplicate holds or charges; and cardholder-activated terminal level 3 device, which addresses unattended terminal transactions that failed authorization requirements. Functionally, 4808 is the Mastercard analogue to Visa’s Category 11. Remediation is almost always technical.

Mastercard 4834 point-of-interaction error

The former duplicate processing code expanded into a broad operational error category. Subcategories cover cardholders debited more than once for the same goods or services, transaction amounts differing from what was agreed, ATM disputes, charges applied for loss or theft or damages beyond the original agreement, late presentment, point-of-interaction currency conversion where DCC was applied improperly, paid by other means, and merchant credit correcting a currency exchange loss. Vehicle rental and lodging merchants generate the damages-related subcategory with some regularity.

Mastercard 4837 no cardholder authorization

The cardholder states they did not authorize or participate in the transaction. This is the primary card-absent fraud code in the Mastercard inventory and the closest counterpart to Visa 10.4.

Mastercard’s First-Party Trust program provides the recovery pathway here, and it works differently from CE3.0 in one important respect. Qualification generally calls for at least one data point from each of three categories: device identity such as an IP address or device fingerprint, delivery information, and an additional identity factor such as an account login or phone number. Unlike Visa’s framework, First-Party Trust does not require a history of prior undisputed transactions with the same cardholder. First-time customers can qualify. For merchants with high new-customer acquisition rates, that difference is significant, and it is one of the more useful things a service provider can explain to a merchant weighing where to invest in data capture.

Mastercard 4849 questionable merchant activity

Mastercard applies this code when a merchant has been identified through one of its merchant audit programs, specifically the Global Merchant Audit Program and the Questionable Merchant Audit Program. It is not a cardholder-initiated dispute in the normal sense, and representment rights are generally restricted. Mastercard publishes bulletins naming the merchants and the applicable timeframes, and acquirers that continue processing for a listed merchant can face liability of their own. For a service provider, a 4849 in the portfolio is a compliance event requiring immediate attention at the account management level, not a case for the disputes team.

Mastercard 4850 installment billing dispute

This code applies in participating markets where domestic installment billing arrangements are supported, addressing disputes over installment terms, amounts, or schedules. Most North American portfolios will not encounter it. Providers supporting Latin American acquiring, particularly in Brazil, will.

Mastercard 4853 cardholder dispute

This is the largest parent code in the Mastercard inventory and the one where subcategory capture matters most. Its subcategories include goods or services not as described or defective; goods or services not provided; digital goods purchases of $25 or less; credit not processed; counterfeit goods; cardholder dispute of a recurring transaction; issuer dispute of a recurring transaction; addendum disputes covering charges added after the original transaction; no-show hotel charges; transactions that did not complete; timeshare disputes; credits posted as purchases; and purchase price disputes where the amount charged exceeded what was agreed.

Reporting 4853 as a single bucket tells you almost nothing. Reporting it by subcategory tells you whether a merchant has a fulfillment problem, a cancellation problem, or a pricing disclosure problem. Those three require entirely different remediation.

Mastercard 4854 cardholder dispute not elsewhere classified

Available in the United States region only, this code covers disputes arising under applicable law that do not fit any other condition. Its use requires the cardholder to have attempted resolution with the merchant first. Volume is low, but the cases can be complex because they often turn on statutory rather than network rules.

Mastercard 4863 cardholder does not recognize potential fraud

The cardholder does not recognize the transaction on their statement. The distinction from 4837 is meaningful. A 4863 is frequently a recognition failure rather than an actual fraud claim, which makes it one of the most preventable conditions in the entire cross-network inventory. Clear billing descriptors and enriched transaction data delivered at the point of inquiry address the root cause directly. Portfolios with elevated 4863 volume usually have a descriptor hygiene problem that can be corrected merchant by merchant.

Mastercard 4870 and 4871 chip liability shift

4870 applies when a counterfeit chip card was used at a terminal not capable of processing chip transactions, the Mastercard counterpart to Visa 10.1. 4871 applies when a lost, stolen, or never-received chip card was used at a terminal that could not support PIN verification, the counterpart to Visa 10.2. Terminal capability is the determining factor in both cases, and relevance varies substantially by market depending on local cardholder verification standards.

Legacy Mastercard codes in transition

Service providers running multi-year trend analysis will encounter codes at various stages of consolidation. 4807 warning bulletin, 4812 account number not on file, 4831 transaction amount differs, 4840 fraudulent processing of transactions, 4841 cancelled recurring or digital goods transactions, 4842 late presentment, 4846 incorrect transaction currency code, 4855 goods or services not provided, 4859 addendum and no-show and ATM disputes, and 4860 credit not processed have been progressively absorbed into 4808, 4834, and 4853. Industry references disagree on which of these remain functional, and some processors still surface them in reporting feeds.

The region-limited 4999 condition, applicable in Europe, sits in a similar category.

The practical implication is straightforward. Any historical reporting spanning a consolidation event needs an explicit mapping table, or trend lines will show phantom drops and spikes that reflect nothing but a taxonomy change. Verify the active set against current Mastercard rules documentation rather than a secondhand list, including this one.

American Express chargeback reason codes

American Express operates a closed-loop network, so dispute handling follows a different operational path than the four-party model. For service providers supporting merchants on OptBlue or direct arrangements, the inventory is organized into families by leading letter, with a flat response window of roughly 20 days from notification regardless of which code applies.

Authorization codes

A01 indicates the charge amount exceeded the authorization amount, typically arising from tip adjustments or incremental charges outside permitted tolerance. A02 indicates no valid authorization existed for the transaction. A08 indicates the authorization approval had expired before the charge was submitted, which appears most often in delayed delivery and lodging scenarios where the gap between authorization and settlement stretches beyond the permitted window.

Cardmember dispute codes

C02 covers credits that were promised but never processed. C04 addresses goods or services returned or refused. C05 covers goods or services that were cancelled. C08 applies where goods or services were not received at all or were only partially received. C14 addresses transactions paid by another method, creating a duplicate charge. C18 covers no-show charges and cancelled CARDeposit transactions, the lodging deposit scenario. C28 addresses recurring billing that continued after cancellation. C31 covers goods or services that did not match their description. C32 addresses goods or services that arrived damaged or defective.

Fraud codes

F10 indicates a missing imprint on a transaction that required one. F14 indicates a missing signature. F24 covers transactions the cardmember states they did not authorize. F29 addresses card-not-present fraud claims and is the highest-volume fraud code for e-commerce merchants on this network. F30 covers EMV counterfeit transactions and F31 covers EMV transactions involving lost, stolen, or never-received cards, both operating on liability shift principles comparable to the other networks.

Processing error codes

P01 indicates an unassigned card number was used. P03 covers a credit processed as a charge and P04 covers the reverse. P05 addresses an incorrect charge amount. P07 covers late submission beyond the required timeframe. P08 addresses duplicate charges. P22 indicates the card number on the submission did not match the card number on record. P23 covers currency discrepancies between the transaction and the submission.

Inquiry and compliance codes

R03 and R13 relate to retrieval requests, indicating an insufficient reply or no reply respectively. Both convert into chargebacks when merchant response obligations go unmet, which makes them the most avoidable losses in the entire American Express inventory. Reply on time and with sufficient detail, and a case you would otherwise win never becomes a chargeback at all. M01 covers chargeback authorization where the merchant has agreed to the chargeback. M10 and M49 address vehicle rental scenarios involving capital damages and theft or loss of use.

Discover chargeback reason codes

Discover also operates a closed-loop structure in most markets. Its identifiers are two-character alphabetic for most conditions and four-character for fraud, and the inventory has been consolidated over time in a manner similar to Mastercard’s.

Fraud codes

UA01 covers fraud in a card-present transaction. UA02 covers fraud in a card-not-present transaction and carries the highest volume in e-commerce portfolios. UA05 addresses counterfeit chip transactions and UA06 addresses chip and PIN transactions, both tied to liability shift conditions. UA10 relates to requests for transaction receipts on swiped transactions and UA11 addresses cardholder fraud claims on swiped transactions where no imprint was obtained.

Authorization codes

AT indicates authorization noncompliance, meaning the transaction did not follow authorization requirements. DA indicates the transaction was processed after a decline. NA indicates no authorization was obtained. EX indicates an expired card was used. IN indicates an invalid card number was submitted.

Processing error codes

AW indicates the transaction amount was altered after authorization. CD indicates a credit or debit was posted incorrectly. DP addresses duplicate processing of the same transaction. IC indicates illegible sales data on the submitted transaction record. LP addresses late presentation beyond the required clearing window. PM covers transactions where the cardholder paid by other means.

Cardholder dispute codes

AA indicates the cardholder does not recognize the transaction, the Discover counterpart to Mastercard 4863 and a similarly strong signal of descriptor problems. AP addresses cancelled recurring transactions. RG covers non-receipt of goods, services, or cash. RM addresses cardholder disputes over the quality of goods or services received. RN2 covers credits that were not processed. SV addresses services not rendered. NF covers non-receipt of cash from an ATM. DC covers dispute compliance matters and NC covers conditions not otherwise classified.

Turning code distribution into portfolio risk intelligence

Now the part that separates a reference document from an operating capability.

A service provider with reason code data across an entire portfolio has something no individual merchant possesses: a comparative baseline. You can see what normal looks like for a given MCC, a given ticket size, a given fulfillment model. And you can see which merchants deviate from it.

The following patterns are worth building alerting around:

• Fraud-family concentration in a card-present merchant, which usually indicates an acceptance environment problem rather than genuine fraud exposure
• Recognition-driven codes such as Mastercard 4863 and Discover AA above segment baseline, which typically points to descriptor configuration
• Authorization-family volume of any meaningful size, which is nearly always a fixable technical defect
• Recurring billing conditions trending upward month over month, which frequently precedes a broader cancellation flow failure
• Credit not processed conditions appearing at all, which signals a refund operations backlog
• Any enforcement-linked condition, including Visa 10.5 and Mastercard 4849, which requires immediate account-level escalation

None of these signals require case-level review to detect. They emerge from aggregation. A merchant whose chargebacks are ninety percent processing errors needs an integration audit, not a representment strategy. A merchant whose chargebacks are ninety percent consumer disputes needs a fulfillment or disclosure review. Sending both merchants the same remediation letter wastes the diagnostic information you already hold.

Reason codes and network monitoring exposure

Card networks evaluate acquiring portfolios as well as individual merchants, which means code distribution eventually becomes an acquirer-level concern.

Visa’s Acquirer Monitoring Program, VAMP, replaced the Visa Dispute Monitoring Program and the Visa Fraud Monitoring Program in April 2025, combining fraud reports and disputes into a single ratio measured against settled card-not-present transactions. The merchant excessive threshold tightened to 1.5% on April 1, 2026, down from 2.2%, across the US, Canada, the EU, APAC, and LATAM, with CEMEA remaining at 2.2%. Acquirer-level thresholds sit at 0.5% for above standard and 0.7% for excessive. Volume floors apply before the ratio is calculated, generally 1,500 combined fraud and dispute events per month, with a separate enumeration ratio applying above 300,000 enumerated transactions. Merchants above threshold face fees reported at roughly $8 per flagged transaction.

Mastercard’s Excessive Chargeback Program uses two tiers. Excessive Chargeback Merchant status requires 100 or more chargebacks and a ratio of 150 basis points or higher in the same month. High Excessive Chargeback Merchant status requires 300 or more chargebacks and a ratio of 300 basis points or higher, again in the same month. Both conditions have to be met together. A high count with a low ratio does not trigger the tier, and neither does a high ratio with a low count. Fines escalate with duration, and an issuer recovery assessment of $5 per chargeback can apply above the 300 mark. Mastercard separately runs audit-based programs, GMAP among them, that operate independently of these ratio calculations.

The connection to reason codes is direct. Fraud-family conditions feed fraud reporting through TC40 and equivalent flows. Non-fraud conditions feed dispute counts through TC15 and equivalent flows. A portfolio that reduces one while ignoring the other can find its aggregate position barely improved. Understanding which codes contribute to which calculation is a prerequisite for building a remediation plan that moves the number you are trying to move.

For service providers, the practical consequence is that portfolio-level intervention has to be prioritized by monitoring impact, not just by dollar value. A cluster of low-ticket disputes can matter more to your VAMP position than a single high-value chargeback. Thresholds and calculation methods have been revised repeatedly during rollout, so current network bulletins remain the authoritative source.

Matching intervention to code family

Reason codes tell you what already happened. The operational question is which intervention would have prevented it, and that answer differs by family.

Recognition and confusion conditions, including Mastercard 4863, Discover AA, and a meaningful share of Visa 10.4 volume, respond to enriched transaction data delivered at the point of inquiry. DEFLECT integrates Verifi Order Insight and Ethoca Consumer Clarity, sending transaction and fulfillment detail into banking applications and issuer call centers so the cardholder’s question is answered before a dispute is ever filed. Applied across a portfolio, this reaches the code families driven by uncertainty rather than intent.

Conditions where the cardholder has already contacted their issuer respond to alert-based resolution. RESOLVE consolidates Verifi CDRN, Ethoca Alerts, and Visa RDR into a single workflow, giving merchants a window to refund before a dispute progresses to a chargeback with a code attached. Conditions that never get assigned never enter a ratio calculation, which is why alert coverage across a merchant base tends to show up in monitoring metrics faster than almost any other intervention. Consolidating chargeback alerts at the portfolio level also gives you a single view of where resolution activity is concentrated.

Conditions that warrant a defense respond to structured representment. RECOVER automates evidence assembly from transaction and fulfillment data, building rebuttals matched to the specific code. Because evidence requirements differ sharply between, say, Visa 13.1 and Visa 10.4, automation that maps evidence to code is more effective than a generic document package, and it helps merchants recover revenue they would otherwise write off. This matters at portfolio scale, where manual case handling stops being viable well before volume peaks.

Build your reason code intelligence layer

If your portfolio reporting currently captures chargeback reason codes as a flat field rather than a structured taxonomy with subcategory detail, that is the first thing worth changing. From there, the work is comparative baselining by merchant segment, alerting on deviation, and routing each deviation to the intervention that addresses its root cause rather than its symptom.

We work with service providers to build exactly that layer, connecting portfolio-wide code data to chargeback prevention, alert resolution, and automated representment across every merchant account under management. If you would like help structuring reason code reporting for your portfolio, identifying which merchants are trending toward monitoring exposure, or deploying DEFLECT, RESOLVE, and RECOVER across your merchant base, we encourage you to reach out to our team.

Why ChargebackHelp?

ChargebackHelp gives merchant service providers a single card-agnostic platform that handles the integrations, maintenance, and compliance work that portfolio-wide code management demands. We connect directly to Visa, Mastercard, Verifi, and Ethoca, so your merchants gain access to prevention and recovery capabilities without your organization absorbing the engineering cost of building and maintaining those connections. That translates into a competitive advantage on two fronts. Your portfolio risk profile improves through measurable reductions in dispute and chargeback volume, and your sales organization gains a differentiated offering that merchants increasingly expect from their provider rather than sourcing separately. Contact us to discuss what that looks like across your merchant base.