> ## Documentation Index > Fetch the complete documentation index at: https://waffo.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Chargeback Reason Codes & Reported Fraud > The complete Visa and Mastercard dispute reason codes Waffo recognises, grouped by category, with what each one is claiming; plus what Reported Fraud is, how it differs from a chargeback, and how to query it. Chargeback Analytics shows the most frequent reason codes plus an **Others** bucket, and a case's own detail shows its single code. This page is the full list behind both, so you can look up any code you receive. What to *send* for a given code is in the [Chargeback Evidence Guide](/docs/en/support/chargeback-evidence-guide); the case's own fields are in the [Chargeback field reference](/docs/en/support/chargeback-field-reference). ## How are reason codes organised? Every recognised code belongs to one card scheme and one of five categories. The category is the useful thing: it tells you which of the three defence dimensions the case turns on before you read the code text at all. | Category | What the issuer is claiming, in one line | | - | - | | **Fraud-related** | The cardholder says they did not authorise this | | **Authorization Errors** | The transaction should not have been authorised the way it was | | **Processing Errors** | The transaction was submitted incorrectly — wrong amount, currency, date or account | | **Customer Disputes** | The cardholder authorised it but is unhappy with what they got | | **Miscellaneous Chargebacks** | Region-specific and residual cases | A code you receive that is not in the tables below comes through as `0000/00` / *Not available* — see the last question on this page. ## Visa reason codes ### Fraud-related | Code | Reason | | - | - | | `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 | `10.4` is the one most online merchants see: the cardholder denies a card-not-present transaction. ### Authorization Errors | Code | Reason | | - | - | | `11.1` | Card Recovery Bulletin | | `11.2` | Declined Authorization | | `11.3` | No Authorization | ### Processing Errors | Code | Reason | | - | - | | `12.1` | Late Presentment | | `12.2` | Incorrect Transaction Code | | `12.3` | Incorrect Currency | | `12.4` | Incorrect Account Number | | `12.5` | Incorrect Amount | | `12.6` | Duplicate Processing / Paid by Other Means | | `12.7` | Invalid Data | `12.6` is the code to check first when a cardholder says they were charged twice — it is often answerable with the two authorisation records alone. ### Customer Disputes | Code | Reason | | - | - | | `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 | `13.2` and `13.7` are the subscription and cancellation codes: what decides them is your cancellation record and the policy the buyer accepted, not proof of delivery. ## Mastercard reason codes ### Fraud-related | Code | Reason | | - | - | | `4837` | No Cardholder Authorization | | `4849` | Questionable Merchant Activity | | `4870` | Chip Liability Shift | | `4871` | Chip Liability Shift – Lost / Stolen / Never Received Issue (NRI) Fraud | `4837` is the code that drives the Mastercard fraud-rate card in Chargeback Analytics — see [Portal analytics](/docs/en/support/portal-analytics-faq) — so it is the one with a compliance consequence attached, not just a financial one. ### Authorization Errors | Code | Reason | | - | - | | `4808` | Authorization-Related Chargeback | ### Processing Errors | Code | Reason | | - | - | | `4831` | Point-of-Interaction (POI) Error | ### Customer Disputes | Code | Reason | | - | - | | `4841` | Canceled Recurring or Digital Goods Transactions | | `4850` | Installment Billing Dispute – Participating Countries | | `4853` | Cardholder Dispute | | `4854` | Cardholder Dispute – Not Elsewhere Classified | | `4855` | Goods or Services Not Provided | | `4859` | No Show / Addendum / ATM Dispute | | `4860` | Credit Not Processed | ### Miscellaneous | Code | Reason | | - | - | | `4999` | Domestic Chargeback Dispute (European region) | ## Two schemes use similar-looking codes. How do I read mine correctly? Always read the code **together with the card scheme** on the case. The codes are only unique within a scheme, and Waffo resolves a code by scheme precisely to avoid the ambiguity — so a code looked up against the wrong scheme can land you on the wrong claim and the wrong evidence. The case record carries both; use both. ## My case shows an unknown or unhelpful reason. What do I do? A code Waffo does not recognise, or a case that arrives without one, is represented as `0000/00` with the reason *Not available*. It is a real state, not a data error — some raising sides do not pass a code through. It changes nothing about the deadline and nothing about your ability to defend. What it changes is how you build the submission: with no code to aim at, send the fallback combination in the [Chargeback Evidence Guide](/docs/en/support/chargeback-evidence-guide) and, where you can, find out what the actual claim is before you submit. ## What is Reported Fraud, and is it the same as a chargeback? No — they are separate records and one does not imply the other. | | Reported Fraud | Chargeback | | - | - | - | | What it is | The card scheme reporting that a transaction was flagged as fraudulent | A formal dispute claiming the money back | | Does money move? | **No** | Yes — the amount and fee are booked against you | | Can you contest it? | There is nothing to contest | Yes, within the deadline | | Where it shows | The Reported Fraud API; its count feeds the Visa fraud-rate card in Chargeback Analytics | The Chargebacks list, the chargeback API and the daily dispute report | A transaction can be reported as fraud and never charged back, or be charged back and never reported. Both matter for compliance ratios, and one of the ratio cards deliberately combines them — see [Portal analytics](/docs/en/support/portal-analytics-faq) for exactly which card counts what. The practical point: Reported Fraud is a **signal**, not a liability. It costs you nothing directly and there is no action to take on an individual record, but a rising volume is the early warning that chargebacks and a monitoring-programme problem are coming. Read it as a trend. ## How do I query Reported Fraud? Through `/api/v1/fraud-report/list` — a paged POST. There is no Reported Fraud list page in the Portal, so the API is the only place to get the individual records. | Parameter | Required | Notes | | - | - | - | | `merchantId` | Yes | Your Waffo merchant id | | `startDate`, `endDate` | Yes | `yyyy-MM-dd`, both inclusive, spanning at most three months — this is the fraud **report** date, not the transaction date | | `pageNum` | Yes | Starts at 1 | | `pageSize` | Yes | 1–100 | | `paymentMethod` | No | An array of card schemes (`VISA`, `MASTERCARD`); multiple values are OR'd, empty means all | | `acquiringOrderId` | No | Look up a single transaction | The date range filters on when the fraud was reported, which is **later** — often much later — than when the transaction happened. A window that looks empty for a period you know had fraud is usually a window aimed at transaction dates. ## What does each Reported Fraud record contain? | Field | What it gives you | | - | - | | `acquiringOrderId` | The Waffo order, so you can find the transaction | | `paymentRequestId` | Your own request id — populated for one-off payments, empty for subscriptions | | `subscriptionId` / `merchantSubscriptionId` | Populated for subscription payments, empty for one-off | | `merchantUserId` | Your own user identifier for the payer | | `transactionDateTime` | When the original transaction happened (UTC) | | `fraudReportDate` | When the report arrived | | `fraudAmount` / `fraudCurrency` | The amount reported as fraudulent | | `orderAmount` / `orderCurrency` | The original order amount | | `fraudReason` | The raising side's own wording, e.g. *Account takeover* | | `fraudReasonCode` | The card scheme's own fraud code, e.g. `VI:6`, `MC:5` | | `paymentMethod` | The card scheme | | `cardType` | Credit / Debit / Prepaid / Unknown | | `cardMaskedNo` | The masked card number as supplied by the raising side | Two things to note when you build against it. `fraudReasonCode` is the **scheme's fraud taxonomy**, which is a different code space from the chargeback reason codes on this page — do not look one up in the other's table. And the identifier that is populated tells you which flow the transaction came from: a record with `subscriptionId` set and `paymentRequestId` empty is a subscription charge, which usually means the useful evidence is the subscription's consent and billing history rather than a single order. ## Why does one of my cases have no Defend button? The action on a dispute row reads **Defend** only when both of these hold, and reads **View** otherwise: 1. **The case is in a status that accepts a response** — one of `EVIDENCE_REQUIRED`, `ACTION_REQUIRED`, or `SECOND_CYCLE_RESPONSE_REQUIRED`. A case in a final status, an expired case, and a case still in `UNDER_REVIEW` all show View. 2. **Your Portal user has the dispute-update permission.** Without it every case shows View, no matter what state it is in. This is the cause people miss — if a colleague can defend a case you cannot, it is permissions, not the case. Ask your account administrator. A third case has a status of its own: a chargeback that arrived without enough information to open properly sits in `INCOMPLETE` until Waffo completes it. `INCOMPLETE` is not a respondable status, so it shows View — the case will move to `ACTION_REQUIRED` and become defensible, or be closed out, without you doing anything. Its deadline clock does not start while it is incomplete. ## What decides whether I can close a customer dispute myself? Two conditions, both on the case: * The status is one that still accepts action — `UNDER_REVIEW`, or one of the response-required statuses. * **Compulsory Channel Review is false.** Where the raising side requires the case to go through its own review, you cannot close it out yourself; the Close action is not offered. What Compulsory Channel Review means is in the [Chargeback field reference](/docs/en/support/chargeback-field-reference). Replying is separate and more permissive: a customer dispute can be replied to in `UNDER_REVIEW`, in a response-required status, and even in `CLOSED`, where the case itself allows replies. That is why a closed customer dispute can still show an unread count. *** Code you cannot find, or a Reported Fraud record you cannot tie to an order? [Contact support](mailto:support@waffo.com) with the `acquiringOrderId`. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.