Payment fraud detection

A wrongly-declined real customer is a permanent revenue loss and often a permanent customer loss, and that false-positive cost has risen sharply enough to redefine the job: catching fraud without blocking real customers, rather than catching all fraud at any price. The shift over the last decade has been from rules-based scoring at the payment processor (which still produces 85 to 95% false positive rates) toward layered device-and-behavior evidence that lets you approve more legitimate transactions confidently. The sections below walk through how that layering works in 2026 and where device intelligence fits.

This is the first of three fraud-cluster posts, alongside ecommerce fraud prevention and fraud detection API.

What “payment fraud” actually means

The phrase covers a few distinct attack patterns at checkout, each with different signals and different defenses.

Card testing. An attacker has a list of card numbers (often from breach data, sometimes BIN-enumerated). They run small test transactions (often $0.01 to $5) at your checkout to identify which cards are still valid, which have correct expiry dates, and which have correct CVV values. Successful tests get sold or used elsewhere for larger fraud.

BIN attacks. A specific form of card testing where the attacker enumerates card numbers within a Bank Identification Number (BIN, the first 6 digits) that they know belongs to a specific issuer. They use the issuer’s known card-number generation pattern to guess valid numbers.

Stolen-card fraud. A real attacker has actual stolen card details (number, expiry, CVV, billing address) and uses them to make a real purchase. The card is genuine; the user is not the cardholder.

Friendly fraud (first-party fraud). A real cardholder makes a real purchase, receives the goods, then disputes the charge with their issuer claiming they did not make the transaction. The merchant loses the goods and the funds (and pays a chargeback fee).

Account takeover then purchase. The attacker compromises a customer account (covered in account takeover prevention) and uses stored payment methods or adds a new one to make purchases.

Triangulation fraud. The attacker runs a fake storefront, takes orders from real customers, then uses stolen cards to buy the goods from a real retailer for shipment to the real customer. The real customer never knows. The retailer eats the chargeback when the cardholder reports the stolen-card transaction.

Each pattern has different signals and benefits from different controls.

The payment processor’s view vs the merchant’s view

Payment fraud detection has two parties.

The issuer (the cardholder’s bank). Sees every transaction the cardholder makes anywhere. Has long-term history. Runs risk scoring at authorization time (Visa Advanced Authorization, Mastercard Decision Intelligence, proprietary issuer models). Has the strongest single signal: “is this consistent with this cardholder’s history?”

The merchant. Sees the transactions that happen on their own checkout. Has the device, browser, behavioral and session signals the issuer does not. Has the user-account history if the customer is logged in.

The two views complement each other. The issuer cannot see that the checkout came from a known anti-detect browser; the merchant cannot see that this card was used 30 minutes ago in three different countries.

The merchant contributes the device-and-session layer, the issuer contributes the cross-merchant payment history layer, and high accuracy requires both.

What modern 3D Secure does (and does not do)

3D Secure 2.x is the current standard for card-not-present authentication. The mechanics:

The merchant initiates the transaction and sends a rich set of device, browser, behavioral and session signals to the issuer (the 3DS “device data collection”).
The issuer’s risk engine scores the transaction.
For low-risk transactions, the issuer returns a frictionless authentication (no user-visible step), and the liability for chargeback shifts from the merchant to the issuer.
For higher-risk transactions, the issuer returns a “challenge required” response. The merchant prompts the user for additional authentication: OTP, push notification approval in the banking app, biometric in-app verification.
The challenge response is sent back through the 3DS protocol, the issuer authorizes (or declines), and the merchant gets the liability shift for properly-authenticated transactions.

In 2026, 3DS 2.x is effectively the default authentication path for US card-not-present transactions of meaningful size, with the major issuers running real-time risk scoring in under 100 ms (Evervault: Mastering 3D-Secure).

What 3DS provides:

Liability shift to the issuer for successfully authenticated transactions.
Issuer-side risk scoring with the issuer’s full cardholder history.
A standardized challenge mechanism.

What 3DS does not provide:

Protection against friendly fraud. The cardholder authenticated; the cardholder can still chargeback. Chargeback fraud covers the dispute-side defense.
Useful protection against card testing. Card testing transactions are small enough to fly under most issuer risk thresholds.
Protection against device-level fraud signals that the merchant can see but the issuer cannot.

Device fingerprinting fills those gaps. The 3DS device-data collection ingests merchant-side device data on the issuer’s behalf, but only the merchant’s own device intelligence layer gives the merchant pre-authorization risk scoring.

Card testing has its own pattern

Card testing has a recognizable signature at the checkout endpoint:

A wave of low-dollar transactions (often $0.01 to $5).
High AVS failure rate (the attacker is testing card numbers, not billing addresses).
Repeated CVV failures.
Multiple BINs from a small set of issuers, suggesting the attacker is working through a list.
Source IPs distributed across many residential exits.
No prior history on most of the cards.
Sub-second time between attempts from the same browser session.

Card testing is bot-driven by definition (no human types hundreds of card numbers), so the full bot detection stack applies at the checkout endpoint before any payment-specific logic runs.

Detection at the merchant side:

Per-session card velocity. A single session attempting more than a handful of distinct cards is testing. Hard-block.
Per-device velocity. A single device (by visitor_fingerprint.id) attempting many cards across multiple sessions is testing. Hard-block at the device.
Per-BIN velocity. A single BIN being attempted more than ~10 times in an hour across the platform is a BIN-targeted attack. Throttle or block by BIN until the storm passes.
AVS / CVV failure clustering. Cards that fail AVS or CVV and are followed by retries with slightly different details are being mass-tested.
Low-amount filtering. Many merchants apply higher scrutiny to transactions under a threshold ($10 or so) because card testing concentrates at small amounts.

The 2026 Sentinex card-testing reference is useful for the specific detection patterns and the IP-and-BIN heuristics (Sentinex Risk: Card Testing Attacks).

Device signals at checkout that move the needle

The device-and-session signals that complement the payment processor’s risk score:

Device classification

Is the device a real consumer browser, or a headless framework, or an anti-detect browser, or an emulator?
Has this device been seen on the merchant’s site before? With what outcome?
Does the device’s visitor fingerprint match known fraud history?

Device-billing address consistency

Does the device’s IP-geolocated country match the billing address country?
Does the time zone match?
Has this device been used to bill to this address before?

Device-account consistency (for logged-in checkout)

Is this device on the account’s known device list?
If this is a new device for the account, was the recent login from this device or a different one?
Did the user just add this payment method, or has it been on file?

Behavioral signal

Did the user interact with the checkout form (mouse, scroll, keyboard) or did they submit immediately on page load?
Is the typing pattern consistent with a human entering a real card number for the first time, or with a paste from an autofill (or from a script)?
Did the user spend any time on review-and-confirm screens, or did they click straight through?

Tamper signals

Inconsistencies between TLS, Client Hints, JS environment.
Replayed canvas hash that does not match the claimed device.
Anti-detect browser signatures.

Each of these contributes a probability adjustment to the transaction’s risk score. The combined score drives the merchant’s pre-3DS decision: process normally, request 3DS challenge, decline, or hold for review. Two concrete examples of how this plays out: a never-seen device, a billing country that does not match the IP geolocation, and anti-detect browser signatures together warrant a 3DS challenge rather than the frictionless flow. Conversely, a device on the account’s known list with organic form-fill behavior justifies approving a transaction the processor’s score alone would have flagged.

False positives are the actual cost

The headline statistic in payment fraud detection is the false positive rate. Rule-based systems in 2026 still operate at 85 to 95% false positive rates: for every fraudulent transaction blocked, 5 to 10 legitimate transactions are also blocked. Mature ML-based systems bring this down to 15 to 25% (WorldMetrics: Top 10 Best Payment Fraud Detection Software).

The cost of false positives is high:

The transaction is declined. The merchant loses the sale immediately.
The customer experiences friction. The probability of them coming back to retry is below 100%, often much below.
If the customer does retry and the friction recurs, they often switch to a competitor permanently.
Customer support is engaged, sometimes by a chargeback request that the customer files in frustration.

The right framing is “approve more good transactions” rather than “block more bad transactions.” A merchant that moves from a 90% false positive rate to a 30% rate at the same fraud-catch rate has improved gross approval rates meaningfully and recovered measurable revenue.

Device intelligence is one of the highest-leverage inputs here because it gives genuinely new information. The transaction’s payment-processor signals (BIN, amount, MCC, velocity) are largely known; the device-and-session signals expand what the model has to work with.

How the layers fit together at checkout

A working checkout fraud flow:

Session starts. The user arrives at checkout. The device intelligence SDK collects fingerprint and behavioral signals during the form-fill.
Pre-submit risk check. Before the user clicks submit, the merchant has the device classification, the device-account history, the device-billing consistency check.
Form submit. The merchant decides: process normally, request 3DS challenge regardless, or decline before the payment is sent to the processor.
3DS exchange (if requested). The issuer’s risk engine scores the transaction with the merchant’s collected device data plus the issuer’s history. Frictionless or challenge.
Authorization. The processor authorizes the transaction at the network level. Approve, decline, or referral.
Post-authorization review (for medium-risk transactions). The merchant may hold the transaction for review, send a confirmation email with a link the user has to click, or apply a small additional friction step.
Fulfilment. Goods are shipped (or services delivered). For physical goods, the merchant has another opportunity to delay shipment if post-auth signals raise the risk score.

Each step has its own decision logic and draws on different signals. The point of the device intelligence layer is to provide useful evidence at steps 2, 3, and 6 in particular.

What changes for digital goods and subscriptions

Digital goods (software licenses, gaming currency, gift cards, mobile top-ups) are the highest-risk merchant category because:

Fulfilment is instant. There is no shipping window in which to detect post-auth fraud.
The goods are easily monetised by the attacker (resold for crypto, used to buy other things).
Friendly fraud is common because there is nothing physical to dispute.

The defense for digital goods is heavier pre-authorization device-and-session checking, more aggressive 3DS challenge requests, and tighter merchant-side decline logic. The trade-off against false positives is more painful here because the alternative (post-auth review) does not work for instant fulfilment.

Subscription products are similar but with the addition of recurring payments. Card-on-file fraud is detected when the recurring charge fails and the customer claims they did not authorize it; the fix is rigorous device-attached card-on-file verification at the initial setup.

How Foil supports it

Foil’s contribution to checkout fraud is the device intelligence and session classification layer. The SDK collects during the cart, browse, and checkout interactions; the verdict returns the decision (decision.verdict and decision.risk_score), the durable device identity (visitor_fingerprint.id), and per-signal evidence (attribution labels, network anonymity, behavioral and fingerprint cross-checks).

A typical checkout integration:

import { Foil, safeVerifyFoilToken } from "@abxy/foil-server";

const client = new Foil({ secretKey: process.env.FOIL_SECRET_KEY });

app.post('/api/checkout', async (req, res) => {
  const { cart, account, paymentMethod, billingAddress, foilToken } = req.body;

  const result = safeVerifyFoilToken(foilToken, process.env.FOIL_SECRET_KEY);
  if (!result.ok) {
    return res.status(400).json({ error: 'invalid_payment_method' });
  }

  const { decision, visitor_fingerprint, session_id } = result.data;

  if (decision.verdict === 'bot') {
    return res.status(400).json({ error: 'invalid_payment_method' });
  }

  const visitorId = visitor_fingerprint?.id;

  if (await cardTestingDetected(visitorId, cart.amount)) {
    return res.status(400).json({ error: 'invalid_payment_method' });
  }

  // Pull the enriched session for network and device-history context.
  const session = await client.sessions.get(session_id);
  const seenCount = session.visitor_fingerprint?.lifecycle.seen_count ?? 0;
  const billingMatchesIp = ipMatchesBilling(session.network.location, billingAddress);

  const riskFactors = {
    deviceNew: seenCount <= 1,
    billingMismatch: !billingMatchesIp,
    antiDetect: session.attribution.labels.some(l => l.value === 'anti-detect-browser'),
    proxyDatacenter: session.network.anonymity.hosting,
    elevatedRisk: decision.risk_score >= 0.5,
  };

  if (countTrue(riskFactors) >= 2) {
    return requestThreeDSChallenge(req, res);
  }

  // Link the device to the account for future device-account consistency checks.
  if (account) {
    await client.sessions.attachClientUser(session_id, account.id);
  }

  return processPayment(req, res);
});

The decision provides the evidence, while the policy choices stay in the application’s hands.

For the broader ecommerce-fraud framing, ecommerce fraud prevention. For the developer-API layer that returns these signals, fraud detection API.