Unauthorized Transaction Disputes
Quick answer
When a buyer says 'I didn't make this purchase,' here's the genuine evidence to gather — AVS/CVV results, IP and device, account history, and prior orders.
An unauthorized-transaction dispute is the bank's way of saying the cardholder claims they didn't make or approve the purchase. It's filed under a fraud reason code, and it asks a very different question from a delivery dispute. A "not received" case is about whether the item arrived; an unauthorized case is about who placed the order — so the evidence that matters is almost entirely different.
This guide covers what to gather for these claims. Organizing it well never guarantees a result — the cardholder's bank decides — but presenting the genuine signals you have, clearly and in order, is how you give a complete response instead of a thin one.
What the bank is actually asking
For an unauthorized claim, the issuer wants to see whether the transaction lines up with the real cardholder: did it use their verified details, come from a plausible place and device, and connect to an account or history that's theirs? Your job is to surface whatever genuine signals tie the order to the cardholder — not to accuse anyone, just to show what your records contain.
The evidence that's relevant
Pull together whichever of these you actually have:
- AVS result — whether the billing address the buyer entered matched the card's address on file.
- CVV result — whether the card security code was entered and matched.
- IP address & geolocation — where the order was placed from, and whether it's consistent with the cardholder.
- Device and browser data — any fingerprint your platform captured.
- Account history — login records, account age, and whether the order used an established account.
- Prior order history — earlier purchases from the same customer, especially ones never disputed.
- Delivery to the cardholder — if the item shipped to the cardholder's own verified address, that matters here too.
- Communication — any genuine messages with the buyer about the order.
These are the signals most fraud reason codes are concerned with. To confirm exactly which apply, check the reason code on your notice and where it appears in your provider — the Stripe Dashboard, PayPal Resolution Center, or your own admin.
"Unauthorized" vs friendly fraud
Sometimes a charge really was made by the cardholder (or someone in their household) who then disputes it anyway — often called friendly fraud. The evidence above is what helps a reviewer see the full picture either way, but it's worth understanding the distinction so you respond to what was actually claimed. We cover it in friendly fraud vs a genuine chargeback.
When it really was fraud
If the transaction genuinely was fraudulent and your records don't connect it to the cardholder, you may simply not have grounds to contest it — and that's okay. Don't invent IP logs, fabricate an account history, or alter verification results to manufacture a case. A response has to be built on records you actually hold; anything else is both wrong and easy to unravel.
Organize and submit
As with any dispute: note the deadline, gather only the relevant records, add a short neutral cover summary and a numbered index, and submit the package yourself through your provider before the date. The free Dispute Evidence Builder will give you a tailored checklist for an unauthorized claim if you'd rather not assemble it from scratch.
Merchant Casefile provides organizational tools and educational resources. It does not provide legal, financial, banking, or payment-processor advice, and does not guarantee dispute outcomes.
Turn this into a real case file
Use the free Dispute Evidence Builder to see exactly what to gather, grab a template kit, or have us organize a dispute-ready package for you.
Honest-by-design
Merchant Casefile provides organizational tools and educational resources. It does not provide legal, financial, banking, or payment-processor advice, and does not guarantee dispute outcomes.