Payment gateway fraud detection: how the layers work, and what each one misses

Payment gateway fraud detection is not a single check that approves or declines a charge. It is a stack of layers, each watching the transaction from a different angle, and each with a blind spot the next layer is supposed to cover. Address checks, cardholder authentication, transaction scoring, and chargeback management all do real work, but they all read the payment. The layer most stacks are thinnest on reads the actor: the device and connection behind the checkout, the thing that ties a run of "unrelated" transactions back to one source. I ran operations for online businesses where a single quiet attack could pile up processing fees overnight, and the pattern that slipped through was almost never one bad charge, it was one actor the transaction view never connected. This guide walks the layers of payment gateway fraud detection, what each catches, what each misses, and where reading the device fits.

Key takeaways

• Payment gateway fraud is any fraudulent transaction pushed through a checkout, from a stolen card used card-not-present to card testing, friendly-fraud chargebacks, and account takeover at payment.
• Detection works in layers: gateway rules and address checks, cardholder authentication (3DS), automated transaction scoring, device and identity signals, and chargeback management. Each catches a different thing.
• Every layer has a gap. Address checks pass a stolen card with the right details, authentication can approve a session that is still fraudulent, and scoring misses an actor who stays under the thresholds.
• The hardest cases share one trait: a single actor behind many "different" transactions. The card or account changes every attempt while the device and connection do not.
• Reading the device and anonymity behind the checkout adds the actor-level view that the transaction-level layers are not built to see, as a risk input your own rules act on.

What is payment gateway fraud?

Payment gateway fraud is any attempt to push a fraudulent transaction through a payment checkout, usually card-not-present, where the physical card is never seen and only its details are entered. That is where the losses concentrate: the Federal Reserve found that card-not-present fraud made up 54.3 percent of debit card fraud losses in 2023, more than lost, stolen, and counterfeit card fraud combined. The common forms an online business runs into are a handful:

• Stolen-card (card-not-present) fraud. A real card number, obtained through a breach or a phishing kit, used to buy goods the cardholder never authorized.
• Card testing. A burst of small charges that validates which stolen card numbers still work before a bigger purchase, often a card-testing run that cycles a list of stolen numbers through one checkout.
• Friendly fraud and chargebacks. A real customer disputes a legitimate charge to get the goods for free, which lands as a chargeback the merchant pays for.
• Account takeover at payment. An attacker logs into a real customer's account and checks out with the card already on file, so the transaction looks like a returning customer.
• Triangulation and reshipping. A fake storefront or a recruited middleman launders stolen-card purchases through a legitimate-looking order.

What ties most of these together is that the fraudulent transaction is designed to look ordinary at the moment it is submitted. That is exactly why detection cannot rest on any single check.

How payment gateway fraud detection works: the layers

Detection at the gateway is a defense in depth, where each layer covers a different failure of the one before it. Walking the stack from the card outward:

1. Gateway fraud rules and address checks. The first pass. Address Verification (AVS) and the card security code (CVV) confirm that the details entered match what the issuer has on file, and rule sets block obvious mismatches and known-bad inputs, following the card-data security standards the gateway operates under.
2. Cardholder authentication (3DS). 3-D Secure and EMV authentication push verification to the card issuer, which can challenge the shopper with a one-time code or approve silently, and tokenization replaces the card number with a token so the raw data is never exposed.
3. Automated transaction scoring. Velocity rules and risk models look across transactions for patterns and anomalies, a sudden spike in attempts, an odd amount, a mismatch between billing and shipping, and score each transaction in real time.
4. Device and identity signals. A layer that reads the device, connection, and anonymity behind the checkout rather than the card, so it can tell whether many transactions trace back to one source.
5. Chargeback management. The last layer, after the fact, where disputes are fought and represented and the loss is tallied.

Each layer earns its place, and each has a documented gap:

Layer	What it checks	What it can miss
Gateway rules + AVS/CVV	Address and card-code matches, known-bad inputs	A stolen card entered with the correct details
Cardholder authentication (3DS)	The cardholder's identity at the issuer	A taken-over account that passes auth; added checkout friction
Automated transaction scoring	Patterns and anomalies across transactions	One actor spread thin to stay under the thresholds
Device and identity signals	The device, connection, and anonymity behind the session	(the layer many stacks are thinnest on)
Chargeback management	Disputes after the sale	Everything, until the money is already gone

What the transaction layer cannot see: the actor

Read down that "what it can miss" column and a single theme runs through it. The card-facing layers are very good at judging a transaction and much weaker at judging the person submitting it. A stolen card with the right address verifies; an authenticated session can still be a hijacked account; a scoring model tuned to catch volume is exactly what a patient attacker stays beneath. In each case the transaction looks acceptable on its own, and the fraud only becomes visible when you connect it to the others.

That connection is an actor-level question, not a transaction-level one. The cards, the accounts, and the order details are made to change on every attempt, which is what defeats anything reasoning about them in isolation. What changes far more slowly is the machine and the connection driving the attempts. One device, often behind one masked connection, sits behind a run of transactions that the card view sees as unrelated strangers. The clearest example is card testing, where dozens of cards flow through one checkout from one device, but the same shape appears under account takeover and multi-accounting at payment. Tie the run back to its source and the pattern that was invisible per transaction becomes obvious.

Which businesses payment gateway fraud hits hardest

Gateway fraud follows the checkout, so any business taking card payments online is exposed, but some feel it more:

• E-commerce and retail. High order volume and physical goods make card testing and stolen-card checkout a constant, and a rejected shipment is a real loss.
• Digital goods and subscriptions. Instant fulfillment hands a fraudster the product before a chargeback lands, so software, gaming, and media checkouts are prime testing grounds.
• Marketplaces. Payments flow through to third-party sellers, so buyer-side card fraud and seller-side collusion both converge on the gateway.
• Donations and ticketing. Low-friction, high-frequency payment forms are favorite targets for card testing, where a fraudster validates stolen cards a few cents at a time.

Across all of them the transaction looks different but the device behind the checkout does not, which is what the device layer reads regardless of vertical.

Preventing payment gateway fraud with ShieldLabs

ShieldLabs is the device-and-identity layer of that stack, working alongside the checks your gateway and issuer already run. Your payment stack authorizes and settles the charge, 3DS verifies the cardholder, and your chargeback tools fight disputes; ShieldLabs reads the device and the anonymity signals behind the checkout session, then links sessions that arrive as separate transactions back to the one device driving them. A run of cards or accounts that the transaction view sees as unrelated collapses to a single source, and a session routed through a VPN, an anonymous proxy, a datacenter, or an anti-detect browser is flagged for what it is built to hide.

We measured this the way an operations team would, replaying a run of different cards and accounts through one checkout and watching what stayed constant. The cards, emails, and IPs changed on every attempt, yet the device behind them kept tying back to a single identifier, the returning-device recognition the layer is built for, accurate up to 99 percent. That constant became more valuable in 2020, when Safari began blocking third-party cookies by default and cookie-based tracking stopped being something a fraud team could lean on.

Every checkout gets a risk score from 0 to 100 with the signals that fired named alongside it, so the read is explainable rather than a black-box verdict. You take the score and the named signals through the API and webhooks and decide, by your own rules, what a high-risk checkout is worth, whether that is a step-up, a manual review, or a hold. The transaction decision stays in your payment stack where it belongs; the device read adds the actor-level context that stack is not built to produce. It is a supporting signal weighed into your own decision, and the same approach runs on the payment fraud prevention page.

Sources

1. Visa: Guide to detecting and preventing payment fraud
2. Federal Reserve: 2023 interchange fee revenue, covered issuer costs, and fraud losses (card-not-present fraud share)
3. PCI Security Standards Council: PCI DSS (Payment Card Industry Data Security Standard)
4. OWASP: Credit Card Fraud (Automated Threats to Web Applications, OAT-001 Carding)
5. Stripe: How automated fraud detection works in payments
6. Wikipedia: 3-D Secure