What Most Popular Chargeback Reason Codes Mean and How Merchant Should React
When dealing with fraud and disputes, merchants encounter a wide variety of payment scenarios. Under the framework established by Visa and Mastercard, cardholder cannot simply decide they want their money back because they changed their mind or no longer wish to use a service they purchased. Any request for a reversal must be grounded in specific, well-defined reasons that the payment networks strictly regulate. The system works both ways — it gives cardholders a structured path to protect their rights, and it gives merchants an equally structured path to defend themselves. Understanding the rules and the logic behind them is what makes the difference between a well-managed dispute process and a losing one.
In this article, we break down the most common chargeback reason codes that digital merchants encounter — what they mean, what typically drives them, and how to approach each one when it comes to disputing a claim (and whether doing so makes sense at all).
Merchandise or Services Not Received: Visa 13.1 / Mastercard 4853
One of the most frequently occurring chargeback codes in e-commerce and digital products — the cardholder claims they paid but never received the goods or access to the digital service. The situations that fall under this code vary considerably: a physical item lost in transit, a digital product that was never activated due to a technical failure, or cases where the customer received everything as expected but chose to go to their bank rather than the merchant's support team in an attempt to game the system.
Building a strong defense in these situations starts with having solid, documented proof that the product or service was actually delivered. No one takes anyone's word for it in this process — session logs and customer activity tracking on your platform are essential. You need concrete evidence of how and when the service was provided. For physical goods, that means delivery tracking with a confirmed receipt; for digital products — session history, login IPs, activation timestamps, browser details, customer contact information, and usage history. The more thoroughly you can demonstrate that the customer actively engaged with the product after payment, the stronger your position in a dispute. Sending a delivery or activation confirmation email immediately after the transaction also works as a preventive measure — a good portion of potential disputes get resolved before the cardholder ever reaches their bank.
Not as Described or Defective Merchandise/Services: Visa 13.3 / Mastercard 4853
This code applies when the customer did receive the goods or service but was dissatisfied with what they got: the specifications differed from what was advertised, the quality fell short of expectations, or a physical item arrived damaged or non-functional. In practice, it is also frequently used as a workaround — rather than going through support and waiting for a refund, some customers simply open a dispute because it is faster, even when the product is not actually defective.
The central question here is what exactly was promised at the time of purchase. Product descriptions, images, technical specifications, and service terms all become the baseline for disputing the claim. If the product page was accurate and up to date, and the customer received precisely what was described, that needs to be demonstrated with documentation: dated screenshots, specifications, and the version of the page as it appeared at the time of the transaction. Any communication with the customer in which they did not raise concerns about the product further strengthens the merchant's position.
For physical goods, photos taken during packaging and documents confirming the contents of the shipment are useful supporting evidence. Accurate descriptions and current images also serve a preventive function — they reduce not only the number of disputes but also the number of customers who feel misled in the first place. For digital products the dynamic is somewhat different, since they cannot be physically damaged in transit, which means the merchant's primary line of defense is having a clear, unambiguous description of exactly what the customer will receive.
Other Fraud – Card Absent Environment, No Cardholder Authorization: Visa 10.4 / Mastercard 4837
One of the most difficult codes for a merchant to deal with — and one of the most ambiguous by nature. The cardholder claims they did not make the transaction and did not authorize it. This can reflect a genuine case of unauthorized access to card details, or it can be what the industry calls friendly fraud — where the customer made the purchase themselves, got what they wanted, and then disputed the charge using a conveniently broad code.
Distinguishing between the two in practice is rarely straightforward, and that is precisely what makes this category of chargebacks challenging to manage. Disputing these claims requires building indirect evidence that the payer and the cardholder are the same person: matching billing and shipping addresses, purchase history from the same device and card, a verified email address, an IP address consistent with the card's country of issue, and post-payment usage history on the platform. The more data points that align, the more persuasive the case.
If the transaction was authenticated via 3DS, the dynamic shifts significantly in the merchant's favor. The cardholder's own bank conducted the authentication at the time of payment — meaning it confirmed the identity of the payer itself. Card details can be stolen, but a full compromise covering online banking access, a phone, an address, and an email account simultaneously is considerably less common.
Duplicate Processing: Visa 12.6 / Mastercard 4834
This code is triggered when a customer's card is charged twice for the same purchase. The causes range from technical failures on the merchant or processor side, to double form submission, to errors during retry logic. Sometimes the customer clicks "pay" multiple times without waiting for a response and ends up with two successful charges.
This is one of the few codes when disputing the chargeback only makes sense if there was no actual duplication. Abuse does happen — a cardholder may attempt to recoup money after the fact by disputing one of several identical charges, particularly when buying digital goods repeatedly within a short window or topping up an account balance. If the two transactions are genuinely distinct — different amounts, dates, or items — that needs to be clearly demonstrated: a statement showing both transactions with a description of what was paid for in each case. If the duplicate is real, issuing a refund proactively before the situation escalates is almost always the better call — it is cheaper and keeps chargeback ratios intact. On the preventive side, duplicate detection logic and blocking repeat form submissions address the majority of these cases before they ever become a dispute.
Cancelled Recurring Transaction: Visa 13.2 / Mastercard 4853
One of the most common codes in subscription businesses. The customer cancelled their subscription — or believes they did — and the charge went through anyway. They contact their bank, and the merchant receives a dispute that, at a certain business scale, becomes a recurring operational problem.
Winning the dispute requires demonstrating one of two things: either that no cancellation request was ever received by the merchant's system and there is no documentation to suggest otherwise, or that the charge occurred before the cancellation took effect in accordance with the subscription terms the customer agreed to at sign-up. System logs, account screenshots, and communication history all support the merchant's position. If the customer did cancel correctly, pursuing the dispute is rarely worth it — a refund is cheaper than a lost chargeback and keeps the chargeback rate where it needs to be. The most effective prevention here is operational: billing notifications sent before each charge, a straightforward cancellation flow, and a confirmation email once cancellation is processed eliminate most of these disputes at the dissatisfaction stage, before they become a formal claim.
Credit Not Processed: Visa 13.6 / Mastercard 4860-4853
This code sits at the intersection of customer service and operational process: the customer returned an item or cancelled a service, the merchant agreed to a refund, but the funds never appeared on the card. In some cases, the refund was initiated but the customer did not see it or ran out of patience and opened a dispute before the funds had time to settle.
The foundation of any dispute response here is proof that the refund was initiated — the date, amount, and transaction reference for the return. If the refund is still in processing, that can also be documented with a timeline. Many of these situations get resolved through direct communication rather than a formal dispute process, particularly when the merchant can provide evidence quickly. Preventively, this is the easiest code to keep off the board: clear refund timelines in the return policy and automated status notifications to the customer eliminate most of these cases before the cardholder starts wondering where their money went.
There are other grounds on which a payment can be disputed, but the codes covered above represent the most common ones, as they address the core scenarios cardholders actually encounter. When building out fraud and dispute management processes, it is worth keeping in mind that a chargeback is not inherently a sign of system failure — some are entirely legitimate. That said, a meaningful portion of disputes are filed in bad faith, and the system does get exploited.
The merchant's goal is twofold: reduce the conditions under which legitimate disputes arise by delivering a quality product and responsive support, and build the technical infrastructure and procedural groundwork needed to defend against abuse — within the rules that Visa and Mastercard have established.
