# How Should Merchants Prevent Fraud in Agentic Commerce in 2026?

l0t.me · September 23, 2026

> The Direct Answer Merchants prevent fraud in agentic commerce by treating an AI shopping agent as a new type of customer, not as a trusted extension of...

## The Direct Answer

Merchants prevent fraud in agentic commerce by treating an AI shopping agent as a new type of customer, not as a trusted extension of the customer’s browser. The payment flow should verify who authorized the purchase, what the agent may buy, which merchant it may use, and whether the transaction matches the shopper’s intent before money moves. Controls should combine identity verification, spending limits, merchant allowlists, real-time risk scoring, and payment-network authentication. They should also record enough information to investigate disputes after settlement. This matters because an agent can assemble a plausible order from a conversation, but plausibility is not the same as authorization. As of September 24, 2026, the practical question is therefore not whether agentic payments are convenient, but where human consent ends and automated purchasing authority begins. The strongest programs make that boundary explicit.

**Also worth reading:** [What are the most effective checkout conversion optimization tactics for modern e-commerce merchants in 2026?](https://l0t.me/knowledge/what_are_the_most_effective_checkout_conversion_optimization_tactics_for_modern_e-commerce_merchants_in_2026.php) · [How do agentic payment checkout flows work and what should merchants know before implementing them?](https://l0t.me/knowledge/how_do_agentic_payment_checkout_flows_work_and_what_should_merchants_know_before_implementing_them.php) · [What Are the Technical Integration Steps for Implementing Agentic Commerce Protocols in 2026?](https://l0t.me/knowledge/what_are_the_technical_integration_steps_for_implementing_agentic_commerce_protocols_in_2026.php)

Agentic commerce generally describes systems in which software agents search for products, compare options, negotiate terms, and initiate purchases on behalf of a person or business. Payment providers such as Mastercard are developing infrastructure for this model, while Antom publicly introduced an agentic payment solution in September 2025. Banks and payment companies have also been discussing fraud risks and operating principles as automated purchasing expands. Those developments do not establish a single global security standard. They do, however, make one point clear: existing card controls were built mainly for a customer clicking “pay,” and an agent adds several additional decisions before that click—or its automated equivalent.

## Why Ordinary Checkout Fraud Controls Are Not Enough

Traditional fraud controls evaluate the cardholder, device, account history, transaction pattern, merchant, and sometimes the browser or phone used to make a purchase. An agent changes the transaction context rather than simply introducing a new technical channel. It may use a different interface, act across several merchants, spend more time comparing products, and make rapid repeat purchases after one instruction. Fraud can occur when a malicious prompt manipulates the agent, a legitimate account is compromised, a merchant falsely describes an item, or an agent exceeds the buyer’s intended budget. A familiar card number can therefore be attached to an unfamiliar decision path.

A useful threat model separates unauthorized intent from misleading presentation. With unauthorized intent, the shopper never intended the purchase, or intended a different amount, merchant, or product. With misleading presentation, the shopper gave limited authority, but hidden fees, false scarcity, or substituted products caused the agent to cross the intended boundary. Prompt injection is a separate concern: hostile text or content encountered while researching can attempt to redirect an agent. Banks have publicly raised concerns about agentic-commerce scams, and FICO has argued that fraud defenses must evolve as these transactions become more autonomous. Neither observation means every agent transaction is fraudulent; both warn against assuming that the underlying customer account automatically proves customer intent.

The relevant evidence should connect three records: the user’s instruction, the agent’s proposed action, and the final payment request. Examples include the stated product category, maximum price, preferred merchant list, delivery deadline, and whether the agent may make substitutions. If those instructions were never captured, a later dispute may become a dispute over interpretation rather than over identity. Merchants should also distinguish an agent-mediated purchase from a normal card-not-present transaction in their systems. Combining both into one generic category can make risk models look healthy while hiding losses caused specifically by delegated purchasing.

## Controls to Combine Rather Than Choose Between

There is no single control that proves intent in every agentic purchase. Identity verification confirms who is associated with an account, while transaction authentication confirms that the payment instrument is being used legitimately. Spending and merchant limits constrain the authority granted to an agent. Real-time decisioning examines whether the requested action is consistent with that authority and with the account’s behavior. Step-up confirmation asks the human to approve a sensitive or unusual action. Post-transaction monitoring detects repeated attempts, coordinated abuse, or patterns that were not visible at authorization.

The table below compares several control types. The figures are operating examples rather than universal industry rules, because merchants and networks may set different thresholds according to risk appetite, regulation, and product type.

| Control | What it proves or limits | Example operating policy | Main weakness |
| --- | --- | --- | --- |
| Identity verification | The person or business behind a request is known | Recheck identity when a new agent or account is enrolled | A legitimate account can still be compromised |
| Spending limits | The agent cannot exceed a specified amount | Approve up to $200 per order and $1,000 per 30 days | A scammer may stay below the limit |
| Merchant allowlist | The agent can buy only from approved sellers | Permit three merchants selected by the shopper | A permitted merchant can still receive a misleading order |
| Product and condition rules | The order matches what was authorized | Prohibit used, refurbished, or subscription items unless approved | Rules may not detect every false product claim |
| Step-up confirmation | A human approves a sensitive decision | Prompt above $500 or for a first-time merchant | Excess prompts can push users toward unsafe bypasses |
| Tokenized payment | The payment credential is scoped and more difficult to reuse | Issue a token valid only for this intended order | Tokens do not prove the shopping purpose was truthful |
| Behavioral monitoring | The request fits or departs from known behavior | Review agents making more than five orders in 10 minutes | Novel legitimate behavior can trigger false declines |
| Audit trail | Decisions can be reconstructed later | Store instruction, approvals, substitutions, and outcomes for 90 days | Poorly designed logs may be incomplete or privacy-invasive |

These controls work best as a chain because each one fails in a different way. A $200 limit does little against a compromised account authorized for a $150 purchase, and identity verification does little against a deceptive but correctly identified shopper. Merchants should therefore avoid treating any one number—such as a particular transaction amount or approval rate—as a universal sign of fraud. Instead, the selected limits and thresholds should reflect ticket size, expected purchase frequency, delivery model, customer support burden, and the losses associated with different error types. False declines and fraudulent approvals impose different costs, so a single optimization target can conceal a poor overall result.

## A Practical Implementation Workflow

Begin by defining the agent’s authority in plain language. Record the allowed categories, budget, merchants, substitutions, purchase timing, and actions requiring human approval. An instruction such as “buy running shoes under $150” is incomplete without deciding whether taxes, shipping, marketplace sellers, or multiple pairs are acceptable. For a first rollout, many merchants can exclude high-risk categories such as gift cards, financial services, adult content, luxury goods, and products with unclear refund terms. The point is not that these categories are always fraudulent; it is that they can make authorization mistakes more expensive or harder to reverse.

Next, connect the shopping session to the payment session through a durable transaction identifier. The record should show the original request, products considered, final choice, amount, merchant, authorization decision, and any human approval. Merchants can apply tighter controls at the cart level rather than relying only on the card network’s final authorization message. For example, a request containing 12 pairs of identical shoes from a newly created seller profile deserves different treatment from a shopper buying one replacement pair from an established merchant. Reason codes passed between platforms should be specific enough to support action, but they should not expose unnecessary personal data.

A staged rollout is usually more informative than an immediate blanket ban. Run the new system in observation mode, where it scores transactions without automatically declining them, and compare the results with ordinary card-not-present traffic. A practical review window might be 30 days for a low-volume pilot and 90 days for a seasonal category. Merchants should record approval rate, fraud loss in basis points of sales, manual-review cost, dispute rate, checkout abandonment, and confirmed customer complaints. An increase in approvals is not progress if the fraudulent share also rises, while aggressive blocking can hide losses by discouraging legitimate customers from trying again.

The final step is to make escalation proportional. Low-risk deviations, such as a color substitution below a 10% price difference, can follow an automated rule. Larger substitutions, a new merchant combined with a high-value order, or a request to change delivery details immediately before payment may need explicit approval. Merchants should also define a customer-facing route for reporting an agent that ignored instructions. Otherwise, users may assume the merchant approved a misleading product description simply because the payment succeeded.

## Cost, Pricing, and the Business Case

The direct cost of agentic fraud prevention depends heavily on the existing payment stack. A merchant with a trusted fraud team and a mature gateway may begin with configuration work, data integration, and additional review staff. A smaller team may encounter larger fixed costs for identity, device intelligence, token management, and case investigation. Public list prices are not consistently available for an entire agentic-commerce risk stack, so merchants should request an itemized proposal covering per-transaction scoring, identity checks, network fees, chargeback handling, data retention, and integration work.

A useful business case starts from expected loss, not from the number of agent transactions. Fraud loss is commonly expressed as a share of payment volume: a 0.5% loss rate on $1 million in transactions is $5,000, while a 0.1% rate is $1,000. These are arithmetic examples, not claims about a particular merchant. Prevention spending should be compared with avoidable losses, manual-review expense, and the revenue lost when legitimate shoppers abandon. Merchants should also account for fraud that occurs after settlement, since a real-time decline can protect against one category of loss while unauthorized orders that ship later create chargebacks, redelivery costs, and customer-service contacts.

Pricing negotiations deserve the same scrutiny as technical performance. Ask whether identity checks are charged per request or only on success, whether device signals are included, and whether investigation tools require a minimum annual commitment. A vendor that advertises a 99% fraud-detection rate may not disclose how many legitimate payments were rejected. Request precision, recall, calibration, latency, and performance by merchant category over time. Detection quality can change as fraud patterns adapt, and a result measured on last year’s data may not predict performance against a new manipulation technique.

## How Agentic Fraud Differs from Other Payment Fraud

The phrase is broad, and comparing it with ordinary e-commerce fraud is necessary. Card testing, account takeover, stolen-card activity, friendly fraud, and merchant deception can all occur in agentic transactions. The distinctive problem is that a legitimate human may delegate a decision to software whose behavior is difficult to observe. This creates gaps between identity, consent, and execution. An agent may follow a corrupted instruction, invent a condition, or select an item that a hurried human would not have approved. Yet the card account and checkout process can still appear technically valid.

It also differs from authorized push-payment fraud because network and user authentication can remain intact, and it differs from many subscription disputes because the shopper may expect only one purchase. A useful comparison is shown below. The categories can overlap, so the table should guide investigation rather than force every case into one label.

| Fraud type | Typical evidence | Correct initial response | Likely recovery path |
| --- | --- | --- | --- |
| Conventional card-not-present fraud | Stolen credential, impossible device, mismatched location | Step up authentication or decline | Card-network dispute or account remediation |
| Friendly fraud | Customer recognizes the charge but denies authorizing it | Review order details and prior consent | Merchant evidence, issuer dispute, or goodwill refund |
| Agent prompt manipulation | Hostile content or instructions altered the shopping objective | Preserve session evidence and contain the account | Investigation may require platform cooperation |
| Excessive delegation | Agent bought valid goods beyond the customer’s scope | Apply scope rules and prevent repeat attempts | Refund, credit, or customer-service settlement |
| Merchant or seller deception | Description, condition, fees, or delivery terms were misleading | Preserve listing, agent inputs, and final receipt | Refund, chargeback, marketplace claim, or legal remedy |
| Compromised authorized agent | Valid enrollment and token were stolen or misused | Revoke tokens, recheck identity, and review orders | Account recovery plus payment dispute process |

A key operational mistake is to call every excessive purchase “fraud.” Some transactions may reflect poor prompting, an ambiguous instruction, a legitimate urgency, or a product-selection error. A fair process should first establish what the customer authorized and what the merchant represented. It should then determine whether technology failure, deception, or ordinary human error caused the mismatch. That distinction affects remediation, platform reporting, and the design of future controls.

## Common Mistakes and Weak Security Patterns

The most obvious mistake is trusting the user’s identity as proof of a specific purchase. A verified customer can still have an account taken over, share credentials, or authorize an agent with broad permissions. Another common error is giving the agent unrestricted browser and payment access before observing its behavior. A safer design grants the shortest practical permission set and removes it when the shopping task ends. Long-lived tokens are particularly unsuitable for a one-time assignment unless the user has deliberately established a reusable purchasing relationship.

Second, merchants often block all automation because bot-detection systems were not designed for it. This can transfer risk elsewhere and prevent customers from seeing the reason for a failure. Third, teams may set strict limits but fail to limit merchant, product, or substitution permissions. An attacker can divide purchases across small transactions or use low-cost items as a route to a more valuable target. Fourth, companies may collect extensive session data without explaining retention or access. Auditability and surveillance are not identical; the record should be proportionate to fraud prevention, dispute handling, and legal obligations.

Fifth, many programs measure only chargebacks. Chargebacks are delayed, and some customers never file, while merchants absorb losses after a dispute window. Attempt rates, confirmed unauthorized orders, refunds, support contacts, and repeat abuse are also relevant. Finally, static rules become brittle when fraudsters test their boundaries. Controls need periodic tuning, but tuning should use labeled outcomes rather than automatically changing thresholds whenever an analyst sees a spike. Seasonality, bot campaigns, and legitimate product releases can otherwise create contradictory signals.

## When Merchants Should Act and What Changes in 2026

Merchants should act early if agents already create carts, hold payment credentials, initiate checkout, or negotiate on behalf of customers. The first objective need not be a fully autonomous payment network. A separate agent order identifier, a constrained authorization record, and a review queue can produce useful evidence before integration becomes complex. Merchants should also act when agent-mediated sales exceed an agreed risk threshold, when refunds repeatedly cite unexpected products, or when support teams cannot tell which purchases were delegated.

A sensible 90-day program begins with a written authorization policy, followed by data mapping and a limited pilot. During the first 30 days, the organization defines prohibited actions and measures baseline performance. In days 31–60, it tests limits, allowlists, step-up prompts, and audit records under simulated and real low-volume conditions. During days 61–90, it reviews measured losses and customer friction, then expands only the categories that meet predefined criteria. This schedule is a management framework, not a regulatory deadline or a guarantee of safety.

The 2026 environment offers more experimentation, including payment-network initiatives and products from companies such as Antom, but it does not remove the need for merchant judgment. Reports from banks, payments publications, and fraud specialists consistently frame agentic commerce as both a payment opportunity and a control challenge. Merchants should demand interoperability, reason codes, evidence access, and clear allocation of responsibility from vendors. They should also keep a non-agent fallback and a human escalation path. The right goal is not to eliminate all errors, which could exclude legitimate shoppers, but to reduce preventable loss while preserving a defensible record of what the customer and merchant actually agreed to do.

## The Defensible Operating Standard

The definitive answer is to make agentic payments bounded, attributable, and reviewable. A merchant should know who enrolled the agent, what the agent was allowed to do, which version of the instruction it followed, why it selected the final item, and who approved any exception. Payment authentication, identity verification, and behavioral scoring should support that record rather than replace it. Limits should be tested against both large-ticket abuse and low-value repetition, while high-risk actions should be denied or escalated. Effectiveness should be reported in dollars prevented, basis points of fraud loss, false declines, abandonment, and support burden—not as a single claim that a system “prevents agentic fraud.”

This standard is demanding because it applies a new form of automation to transactions that already involve imperfect evidence and imperfect customers. Some suspicious agent behavior will be caused by legitimate experimentation, and some fraud will resemble ordinary e-commerce abuse. Programs that recognize those ambiguities will usually be more durable than those promising perfect detection. By September 24, 2026, the most credible merchant strategy is a controlled rollout with explicit permissions, credible measurements, and rapid revocation. The agent may act on the customer’s behalf; it should never act beyond the authority the merchant can prove it received.

## Quick answers

### Is agentic commerce fraud the same as card-not-present fraud?

Not always. Card-not-present fraud is a broad transaction category, while agentic fraud adds delegated purchasing, manipulated instructions, or permission errors to the threat model. Conventional tools can help, but merchants may also need to preserve the shopping instructions and agent decision record.

### What spending limit should a merchant set for an AI shopping agent?

There is no universal amount because a $50 threshold may be restrictive for one category and ineffective for another. Start with a conservative pilot, then measure fraud, false declines, and substitution frequency; an order limit of $200 with a 30-day cap is only an illustrative starting point.

### Can identity verification alone stop agentic payment fraud?

No. Identity verification can show that a known account initiated a request, but it cannot prove that the account holder intended the exact product, price, or merchant. Spending rules, merchant controls, transaction authentication, and intent records add the missing context.

### Should merchants block all AI shopping agents?

A blanket ban may remove a growing checkout channel without addressing the underlying weaknesses. Merchants that choose to allow agents should restrict permissions, log decisions, and monitor outcomes; merchants that block them should still distinguish automated abuse from legitimate automated shopping.

### What evidence is useful in an agentic-commerce dispute?

Useful evidence can include the original instruction, permitted budget and merchants, item-selection history, substitutions, final receipt, authentication events, and any human approval. A card statement alone may establish the charge but not what the shopper authorized.

Canonical: https://l0t.me/knowledge/how_should_merchants_prevent_fraud_in_agentic_commerce_in_2026.php
Markdown: https://l0t.me/knowledge/how_should_merchants_prevent_fraud_in_agentic_commerce_in_2026.php/index.md