Disputes
Reason code
Scheme-defined code identifying the grounds for a chargeback (e.g. Visa 10.4 for cardholder-not-authorised, 13.1 for goods not received) that dictates the evidence required to defend it.
Reason code means: Scheme-defined code identifying the grounds for a Chargeback (e. g. Visa 10. 4 for cardholder-not-authorised, 13. 1 for goods not received) that dictates the evidence required to defend it.
In payment operations it is not just a label; it controls how a transaction, credential, risk event, or funding movement is interpreted by counterparties. The mechanic is part of the post-transaction Dispute path between the cardholder, Issuer, scheme, Acquirer, and merchant.
It determines who can raise a claim, what evidence is admissible, and which party carries the loss if the case is not reversed. It is commonly analysed alongside Chargeback, Dispute, Representment, because those neighbouring concepts determine the commercial and operational outcome.
The practical detail is usually found in gateway logs, Acquirer reports, scheme files, customer-service records, and Settlement statements rather than in a single dashboard. Teams should record the value, timestamp, counterparty, currency, response code, and any exemption or liability indicator attached to the event.
A common mistake is to treat Reason code as a static definition. In practice the meaning can change by scheme, country, MCC, card product, Issuer, transaction channel, and whether the payment is customer-initiated or merchant-initiated.
That is why high-volume merchants normally document rules, monitor exceptions weekly, and review thresholds before a small operational issue becomes a Chargeback, funding, or compliance problem.
Worked example
A merchant reviews a £480 transaction where Reason code is the deciding factor. The Issuer raises the case, the Acquirer debits the merchant, and the merchant must submit evidence before the Representment deadline expires.
The operational cost is modelled at a £20 Chargeback fee plus the full sale amount at risk, and the relevant action must complete 30 days. Step 1 is to Capture the original request data, including amount, currency, Issuer country, MID, and response or status code.
Step 2 is to apply the merchant's rule set, for example whether to retry, challenge, Refund, release goods, or hold for review. Step 3 is to reconcile the result against Acquirer reporting so finance can see the cash impact.
If the rule improves the outcome by even 50 basis points on 2,000 similar monthly transactions, the merchant protects roughly 10 extra orders from avoidable failure or loss.
Scheme notes
Visa and Mastercard use different Dispute labels, reason-code groupings, and monitoring programmes, even when the commercial event is similar. Visa Dispute and fraud monitoring has moved under VAMP, while Mastercard still distinguishes Excessive Chargeback Merchant and High Excessive Chargeback Merchant tiers in the ECP framework.
Retrieval, Representment, Pre-Arbitration, and Arbitration windows are scheme-specific, with many merchant response windows falling around 20 to 45 days once Acquirer notification and evidence preparation time are considered.
American Express and Discover run their own Dispute rails, so merchants should not assume that evidence accepted by one scheme will automatically satisfy another.
Why it matters for merchants
Commercially, this affects direct loss, Chargeback fees, evidence workload, and the risk of entering scheme monitoring programmes. For a merchant processing £500,000 per month, a 25 basis point movement is worth £1,250 before secondary effects such as disputes, reserves, support tickets, or failed delivery costs.
The impact is larger in high-risk, subscription, travel, digital-goods, and cross-border models because Issuer decisions and scheme monitoring can compound quickly.
Cardflo can help by combining acquiring access, MID routing, orchestration rules, KYB review, and Chargeback tooling where relevant, so the merchant is not dependent on one processor interpretation or one fixed transaction path.
Frequently asked
Which data should a merchant store for Reason code?
Store the transaction ID, MID, Acquirer, amount, currency, Issuer country, Card scheme, response or status code, timestamp, and any 3DS, exemption, Refund, or Dispute reference. For card transactions, keep Authorisation and Clearing identifiers because Settlement or Chargeback questions may arrive 30 to 120 days later.
For regulated flows, keep customer consent and evidence records for at least the period required by local law or scheme rules. Good records reduce investigation time from hours to minutes when Acquirer reporting does not match the order system.
How often should Reason code be reviewed?
High-volume merchants should review exception rates weekly and trend the main metric monthly by scheme, Acquirer, Issuer country, MCC, and payment method. A movement of 20 to 50 basis points can be material if the merchant processes thousands of orders.
Finance should reconcile the cash impact at Settlement level, while risk or payment operations should analyse the root cause. Reviewing only blended totals hides problems that appear on a single BIN range, region, or MID.
What threshold usually triggers action on Reason code?
The threshold depends on the category, but merchants should investigate any sudden change above 10% relative movement or 25 basis points absolute movement.
For disputes and fraud, scheme thresholds such as 0. 9% under Visa monitoring or 1. 5% under Mastercard ECM can create immediate escalation risk. For Settlement or pricing items, even 5 to 15 basis points can justify routing or contract review.
The key is to set thresholds before month-end, not after a processor invoice or scheme notice arrives.
Can Reason code differ between acquirers?
Yes. Acquirers can map response codes differently, apply different risk rules, support different data fields, and settle on different cycles.
One Acquirer may return a generic decline while another exposes Issuer advice that allows a safe retry. Fee treatment can also vary by contract, especially for cross-border, FX, premium cards, and alternative payment methods.
This is why merchants using orchestration should compare performance by Acquirer and scheme rather than relying on a single blended approval or cost figure.
What is the first remediation step when Reason code creates losses?
Start with a 30-day sample and split it by scheme, Issuer country, card product, payment method, MID, and response or Dispute code. Quantify the value at risk in cash terms, not just percentage points.
Then decide whether the fix is operational, such as better evidence or customer communication, technical, such as richer data or 3DS indicators, or commercial, such as a different Acquirer route.
Recheck the same metric after one full Settlement or Dispute cycle to confirm the change worked.
See how Reason code plays out in practice
Industries and regions where this term drives real acquiring, routing, or dispute decisions.
Related terms
A forced reversal of a card payment initiated by the cardholder's issuing bank.
Any cardholder-initiated challenge to a transaction, covers retrieval requests, chargebacks, pre-arbitration, and arbitration.
The merchant's response to a chargeback, with evidence that the original transaction was valid.
Related guides.
Ready to improve your payments setup?
Tell us about your business. We'll match you with the right acquiring partners and the right route, typically inside a week.