Ecommerce fraud cost merchants roughly 2.9% of revenue in 2025, with chargebacks alone projected above $100 billion globally and friendly fraud responsible for 61% of disputes. The number is going up. This article maps the landscape: the categories of fraud worth distinguishing, the vendor ecosystem (liability-shift versus risk-scoring), where AI agents fit, and how device intelligence layers in to improve both the catch rate and the false positive rate at the same time.

This is the parent post in the fraud cluster. The narrower pieces are payment fraud detection for the checkout-and-payment specifics, and fraud detection API for the developer-API integration angle.

The scale and trend

Two numbers worth keeping in mind:

The composition is shifting more than the headline number. As of 2026:

  • Friendly fraud, which is now 61% of disputes, is the single largest category by volume.
  • Promo abuse and return abuse are climbing as a share of merchant losses.
  • Card testing and stolen-card fraud are still active but a smaller share than five years ago.
  • A new category emerged in 2024 and grew sharply in 2025: agentic commerce abuse, where AI agents acting on behalf of users (legitimately or not) interact with the checkout in ways that traditional fraud detection was not built to handle.
Data What chargeback disputes actually break down into
61%
friendly fraud
  • Friendly fraud (legitimate cardholder disputes) 61%
  • True fraud (stolen card, ATO, etc.) 30%
  • Other (processor errors, duplicates) 9.0%
Source: Chargeflow Chargeback Statistics 2025, Signifyd State of Fraud 2025

Friendly fraud is the largest single chargeback category and the hardest to defend against, because the cardholder is who they claim to be at the time of purchase. The defense is evidence at the time of sale, not prevention at checkout.

A working taxonomy

Six categories that warrant different controls.

1. Card-not-present payment fraud

Stolen card details used to make purchases. Covered in payment fraud detection. Specific patterns: stolen-card purchases, card testing, BIN attacks, triangulation fraud.

2. Account takeover then purchase

The attacker compromises a customer account and uses the stored payment methods (or adds new ones). Covered in account takeover prevention. The point of intervention is the login risk score plus the post-login monitoring for value-extracting actions.

3. Friendly fraud (first-party chargebacks)

The customer made the purchase, received the goods, and then disputes the charge with the issuer claiming they did not authorize it. Reasons range from genuine confusion (forgot the subscription, didn’t recognize the merchant name on the statement) to deliberate (they got the goods and wanted to keep them without paying).

The defense is mostly evidence: detailed device-and-session records of the purchase, delivery proof, post-purchase engagement records. When the chargeback is filed, the merchant can submit evidence to the issuer to contest it. Mature device intelligence makes this evidence stronger because the merchant can show “the device that made this purchase is the same device the cardholder has used for 14 other successful purchases over the past year, and the user signed in with their passkey at the time.”

4. Promo and offer abuse

Multi-accounting to redeem one-per-customer offers repeatedly. Covered in promo abuse prevention and fake account prevention.

5. Return abuse and refund fraud

The customer purchases goods, then exploits the return policy: returning empty boxes, returning damaged goods, returning a different item, returning goods after the return window. Or claiming non-delivery for items that were delivered. Or claiming damaged-on-arrival for goods that were undamaged.

Detection is partly behavioral (customers with disproportionately high return rates), partly operational (delivery photos at drop-off, signature requirements), and partly device-level (the device that placed the order matching the device claiming non-delivery, or the address of the return).

6. Agentic commerce abuse

The newest category, in which an AI agent makes a purchase on behalf of a user. There are two failure modes:

  • The agent is not actually authorized by the cardholder. Treat as ATO or stolen-card fraud.
  • The agent is authorized but the cardholder later disputes the charge because they did not realize the agent would buy this. Treat as friendly fraud with an emerging legal complication: who is liable when an AI agent makes a purchase the human did not specifically approve?

The defense is mostly:

  • Identify the agent (AI agent detection).
  • Tie the agent to an authorized user with a known authorization event.
  • Surface the purchase to the user via a confirmation mechanism the agent cannot complete on the user’s behalf (push notification to the user’s phone, email link, biometric confirmation).
  • Log the entire purchase trace for chargeback evidence.

The vendor ecosystem

The ecommerce fraud vendor market splits along two axes that matter when evaluating options.

Liability-shift vs risk-scoring

Liability-shift vendors. Signifyd, Riskified, Forter, Chargeflow. The vendor scores the transaction; if they approve it and it turns out to be fraud, they reimburse the merchant for the chargeback (subject to terms). The merchant trades a per-transaction fee (typically 0.5% to 1.5% of order value) for guaranteed losses.

Risk-scoring vendors. Sift, Kount, ThreatMetrix, SEON, Foil, dozens of others. The vendor scores the transaction and provides a risk verdict; the merchant decides what to do. The merchant retains the chargeback liability but gets full control over the decision logic.

The right choice depends on the merchant’s risk profile and operational maturity. A high-volume merchant with internal fraud expertise generally does better with risk-scoring (more control, lower fees, better integration with proprietary signals). A merchant with low fraud literacy or thin margins on individual transactions does better with liability-shift (one fee, predictable outcomes).

Stack position

Edge vendors. Sit at the CDN or WAF layer. Block obvious automation before it reaches the application. Good at scraping and bot defense; weak on transactional fraud signals because they do not see the cart contents, the customer history, or the post-checkout flow.

Application-layer vendors. Sit inside the merchant’s checkout flow. See the full transaction context. Can use customer history. Better for fraud-on-real-customers cases like friendly fraud.

Issuer-side scoring. Visa Advanced Authorization, Mastercard Decision Intelligence. Built into 3D Secure. Sees cross-merchant patterns the merchant cannot. Strong on stolen-card and card-testing detection.

Most well-defended merchants run all three layers in combination.

What device intelligence adds

Device intelligence sits inside the application-layer category and provides specific evidence that the other layers cannot reach:

  • Device identity. A device that has made successful purchases before is much lower risk when it makes another; a device that has never been seen is higher risk by default.
  • Device classification. Real consumer browser vs framework vs anti-detect vs agent.
  • Cross-checks. TLS-vs-UA, time-zone-vs-IP, GPU-vs-platform inconsistencies that catch spoofing.
  • Behavioral signal. Did the user actually interact with the checkout, or did they submit immediately?
  • Device continuity. Does this transaction come from a visitor fingerprint already linked to recent abuse?
  • Per-merchant account linking. Across the merchant’s user base, which other accounts has this device interacted with?

Each contributes to the overall risk score. The leverage is in two directions: catching fraud that other layers miss (especially device-level fraud like anti-detect browser sessions and credential-stuffed checkouts), and approving transactions that other layers would have flagged but shouldn’t have (a returning customer on a known device with a small change in billing address, for example).

The second direction matters more than the first in many production deployments. False positive reduction is the higher-leverage outcome, because false positives are immediate measurable revenue loss while fraud catches are loss avoidance.

Building the risk model

A practical merchant-side risk model combines signals from three sources:

Issuer signals. The 3DS device-data exchange returns issuer risk metadata. The authorization response includes AVS, CVV, and issuer score where exposed. Velocity flags from the processor.

Device signals. From the device intelligence layer: classification, identity, cross-checks, behavioral.

Merchant signals. Customer history (orders, returns, chargebacks). Cart contents (categories, amount, item type). Session context (referrer, time on site, browsing behavior).

The model is typically structured as:

  1. Hard-block rules. A small number of rules that trigger immediate decline regardless of score. Examples: device is a known framework, transaction matches an active card-testing pattern, billing address is on a known abuse list.
  2. Score-based decision. Combined risk score from the three signal sources. Thresholds for “approve,” “request 3DS,” “send to manual review,” “decline.”
  3. Post-decision logging. Every transaction, every signal, every decision logged for both audit and feedback into the model.

The model improves over time only if the merchant closes the outcomes loop. Chargeback and dispute labels arrive weeks or months after the transaction, and they are the ground truth the model trains on. A scoring pipeline that never joins those late labels back to the original decision records is flying blind. Pipe back every outcome: which transactions resulted in chargebacks, which manual-review approvals were correct, which declines were appealed by legitimate customers. And measure the result as approval-rate lift at constant fraud loss, not just fraud catch rate; a model that catches slightly more fraud while declining more good customers is a regression.

Friendly fraud is the hardest

Friendly fraud is the largest single category and the hardest to defend against because the cardholder is who they claim to be at the time of purchase. The chargeback comes weeks later. We cover the dispute lifecycle, prevention, and evidence strategy in depth in chargeback fraud.

The defenses are:

  • Strong evidence of authorization. 3DS authentication, biometric or passkey verification, device-level identity continuity with the account history.
  • Subscription disclosure. Clear pre-purchase disclosure of recurring charges, confirmation emails on each charge, easy cancellation.
  • Delivery and signature evidence. Photo on delivery, signature requirement for high-value goods.
  • Post-purchase engagement. Records of the user logging in, using the goods or service, opening confirmation emails. A user who used the product for two weeks and then claims they did not authorize the purchase has a weaker dispute.
  • Chargeback representment. When the chargeback is filed, submit the evidence to the issuer. Win rates vary by category, but well-documented disputes win at rates around 30 to 50%.

Device intelligence helps at the evidence stage. The detailed device-and-session record from the purchase, plus the matching device record from subsequent legitimate logins, makes the representment case stronger.

Return abuse and the friction trade-off

Return abuse has the same structural problem as promo abuse: legitimate returns and abusive returns look similar at submission. The defenses:

  • Per-customer return rate. Customers with disproportionate return rates relative to category norms get scrutinised more.
  • Return inspection. For high-risk customers or high-value items, returned goods are inspected and approved before refund. Slower for the customer; catches obvious abuse.
  • Cross-merchant return reputation. Some vendors share return-abuse data across merchants (this is sensitive privacy-wise and is done within explicit data-sharing agreements).
  • Device-level abuse linking. The customer’s account history is one input; the customer’s device history (including other accounts on the same device) is another.

How Foil supports it

Foil’s role in ecommerce fraud is the device intelligence layer that improves both catch and approval rates. The SDK collects across the customer’s session; the verdict returns the decision, the durable visitor fingerprint, attribution labels, and the contributing signals. The merchant uses these to drive the checkout risk model and the post-purchase evidence trail.

A typical fraud-relevant integration sketch:

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

async function evaluateOrder(req, order) {
  const result = safeVerifyFoilToken(req.body.foilToken, process.env.FOIL_SECRET_KEY);
  if (!result.ok) return computeRisk(order, null);

  const { decision, visitor_fingerprint, signals } = result.data;
  const account = req.session?.userId ? await accounts.get(req.session.userId) : null;

  const visitorId = visitor_fingerprint?.id;
  const deviceHistory = visitorId ? await orders.findByVisitor(visitorId) : [];
  const accountDeviceHistory = account ? await orders.findByAccount(account.id) : [];

  const evidence = {
    visitorFingerprintId: visitorId,
    verdict: decision.verdict,
    riskScore: decision.risk_score,
    signals,
    deviceKnown: deviceHistory.length > 0,
    accountKnown: accountDeviceHistory.length > 0,
    deviceAccountMatch: accountDeviceHistory.some(o => o.visitorFingerprintId === visitorId),
  };

  await orders.attachEvidence(order.id, evidence);

  return computeRisk(order, evidence);
}

The evidence record persists with the order. It is used at decision time, in fulfilment, and (months later) in chargeback representment.

For the checkout-payment-specific detail, payment fraud detection. For the developer-API perspective, fraud detection API.

Further reading