Authorization fraud is when a payment is approved using stolen or tested card details before any goods or money actually move. The point is to slip past the issuer's checks so the transaction looks clean at the moment of sale; the loss lands later, as a chargeback, not at approval.
What is authorization fraud, in plain English?
Every card payment starts with an authorization: the merchant asks the issuer, in real time, whether the card is valid and has funds, and the issuer answers approve or decline. Authorization fraud is fraud that succeeds at that gate. The fraudster uses stolen or freshly tested card credentials that still pass the issuer's checks, so the transaction is approved and looks legitimate at the exact moment of sale.
The key idea is that approval is not settlement, and it is not proof of a genuine buyer. An authorization only confirms the card number, expiry, and available balance line up well enough to say yes. It does not confirm the person holding the card details is the real cardholder. So a stolen card that has not yet been reported, or a card confirmed live during a card-testing run, sails through.
Because of that, the loss is time-shifted. Nothing appears wrong at approval. The damage shows up days or weeks later when the real cardholder disputes the charge and a chargeback reverses it. Authorization fraud is really about beating the front-door check so the fraud can settle before anyone notices.
Where authorization sits in the flow
- Input — Stolen credentials entered. The fraudster submits a card number, expiry, and security code obtained or confirmed as live.
- Check — Issuer authorizes. The issuer verifies the card is valid and funded and returns an approval, sometimes with AVS or CVV results.
- Capture — Transaction settles. Goods ship or funds move on an approval that appeared clean, so nothing flags at the time.
- Reverse — The chargeback hits. The genuine cardholder disputes the charge and the payment reverses, landing the loss on the merchant.
Who is involved?
Who | Their role |
The fraudster | Supplies stolen or pre-tested card details engineered to pass the authorization check. |
The issuer | Approves or declines in real time based on card validity and funds, with limited fraud context at that instant. |
The merchant | Accepts the approved payment and usually absorbs the chargeback when it disputes later. |
The genuine cardholder | Discovers the unauthorized charge and disputes it, triggering the reversal. |
What it looks like in practice
In practice
A merchant notices its approval rate ticking up over a weekend, which looks like good news. Orders are clearing smoothly, mostly for high-resale-value electronics, shipping to a handful of addresses. The payments authorize without trouble, so the fulfillment team ships them.
Ten days later a wave of disputes arrives. The cards all shared a narrow BIN range and had been confirmed live in a card-testing burst days before the orders. Every one of those approvals was authorization fraud: the credentials passed the issuer's check because the cards had not yet been reported stolen. The rising approval rate was not a win, it was the fraud clearing.
Why a clean approval is not safety
The trap is that an approval feels like validation. Teams that lean only on the issuer's yes or no miss the point: the authorization confirms the card works, not that the buyer is legitimate. Fraud built to pass authorization is invisible in the one metric most operators watch in real time, and it only reveals itself downstream as disputes.
That is why the meaningful signal is the relationship between approvals and disputes. A rising approval rate paired with a rising chargeback rate is the classic tell that stolen credentials are clearing your checks. Address and security-code mismatches on approved transactions, and clustering by BIN, IP, or device after a testing run, are the tools you use to catch what the authorization decision alone cannot.
What to watch in the data
- Approvals up, disputes up. The signature pattern. Rising authorizations alongside rising chargebacks means clean-looking fraud is settling.
- BIN clustering. Approved orders concentrated in a narrow card-number range, often the residue of a card-testing run.
- AVS and CVV mismatches. Approved payments where the address or security-code result did not fully match are higher risk despite the approval.
- Shared device or IP. Many approved transactions traced to the same device fingerprint or IP block.
- High-resale goods to few addresses. Approved orders skewing toward easily resold items shipping to a small set of drops.
Quick questions
If the issuer approved it, is it not the issuer's problem?
Not usually. An approval confirms the card is valid and funded, not that the buyer is genuine. For card-not-present sales the merchant typically absorbs the chargeback unless the payment was authenticated through 3DS.
How does authorization fraud relate to card testing?
Closely. Card testing is how fraudsters confirm which stolen cards are live. Those confirmed cards then produce authorization fraud, clean approvals that dispute later, which is why testing bursts often precede a wave of chargebacks.
Why does the approval rate go up during an attack?
Because the fraudster is using cards specifically selected to pass authorization. Each successful order is an approval, so a burst of fraud can look like a surge in healthy conversions until the disputes arrive.
Can AVS and CVV checks stop it?
They help but are not enough. Fraudsters often have full billing details or security codes from breaches. Treat mismatches as a strong risk signal, but do not treat a match as proof the buyer is real.
What is the best defense?
Layer risk decisioning on top of the authorization: device and behavior signals, velocity limits, BIN and IP clustering, and step-up authentication like 3DS on risky payments. Watch the approval-to-dispute relationship, not the approval rate alone.
Go deeper
- EMVCo ↗ — Maintains the EMV chip and 3-D Secure specifications for card payments.
- PCI Security Standards Council ↗ — Security standards for handling cardholder data, including PCI DSS.