AI Shopping Bots vs Fraud Bots: How to Tell Them Apart

Merchants can tell AI shopping bots from fraud bots by checking what an agent is allowed to do and what its actions cause. A fast checkout, a real browser, or a recognizable agent name cannot establish that a purchase is authorized. Evaluate agent identity, shopper permission, transaction validity, and abuse patterns separately.

That distinction matters because useful shopping automation and harmful automation often touch the same product, cart, and payment endpoints. Your policy needs to preserve product discovery while protecting the actions that spend money, reserve stock, or redeem value.

What OpenAI’s ACP model changes for merchants

OpenAI’s September 2025 Instant Checkout and Agentic Commerce Protocol announcement described ChatGPT passing purchase details to merchant systems. The merchant accepts or declines the order, processes payment through its provider, and handles fulfillment and customer support. The launch design also described shopper confirmation and payment tokens restricted to a specific merchant and amount.

The current OpenAI ACP documentation emphasizes structured catalog ingestion, inventory understanding, and product discovery. Treat the launch checkout model as a documented architecture, rather than assuming every discovery integration has purchase permissions or the same checkout capabilities.

The security implication for merchants is practical: catalog access and purchase authority need separate decisions. An agent permitted to recommend a jacket should not gain permission to reserve every size, change a delivery address, or redeem a customer’s loyalty balance. An authorized purchase still needs the store’s inventory, promotion, and payment checks.

Seven kinds of shopping automation

This table is a starting policy for merchant teams. Adapt it to the access you offer and the behavior your store actually observes.

Authorized product-discovery agents

A discovery agent might compare product dimensions, shipping options, or whether a size is available. Public catalog access can be useful without requiring the agent to disclose a shopper’s identity. Define which information you expose and how frequently clients may retrieve it.

Separate public descriptions from customer-specific prices, account history, and private inventory data. A product feed or documented read API can make approved access easier to operate. Measure useful referrals and catalog load; a discovery visit is not itself a purchase authorization.

Checkout agents acting with delegated authority

Delegation means a shopper has permitted an action within a defined scope. A request saying “the user approved this” is only a claim until the merchant can validate it through the integration’s authorization mechanism.

For a purchase, establish the authorized merchant, items, quantity, amount and currency, delivery details, and validity period as appropriate to the workflow. If a material detail changes, confirm that the existing permission covers the change or return the shopper to confirmation. Keep the checkout session bound to the intended customer and order.

These are merchant policy recommendations, not a list of fields guaranteed by every ACP implementation. Your supported checkout and payment specifications determine how the evidence is exchanged.

Inventory scrapers

Inventory scraping is data collection. It does not necessarily involve stolen payments or account access. A comparison service may have permission to collect prices; another client may exceed your access policy or repeatedly query expensive availability endpoints.

Review the breadth of collection, refresh frequency, cache use, and server cost. Product-discovery traffic and bulk scraping can overlap technically, so intent should not be inferred from a single request. Define permitted collection, offer an appropriate feed where useful, and enforce limits on the costly operations.

Keep collection policy separate from payment-fraud labels. That gives support teams a useful explanation when a permitted partner needs a higher catalog allowance.

Sneaker bots and inventory-hoarding bots

These are two different stock problems. OWASP’s scalping category describes unfair acquisition of scarce goods, including sneaker bots. Denial of inventory describes holding stock without completing a purchase, preventing other customers from obtaining it.

For a limited release, our recommended policy is to enforce purchase allowances across the relevant customer and order records, expire unused reservations, and limit concurrent holds. A valid payment does not establish compliance with a one-pair-per-customer rule. Likewise, an unpaid cart should consume scarce inventory only according to an explicit reservation policy.

Investigate related reservations before treating several households on a shared network as one purchaser. IP addresses alone are a poor substitute for the business rule you need to enforce.

Carding automation

Carding tests payment credentials. It can target saved-card flows as well as purchases, so protecting only the visible checkout button leaves other paths exposed. Stripe’s card-testing guidance identifies repeated failed authorizations, unusual payment activity, and attacks on card setup and payment endpoints; it also explains why a single IP heuristic is insufficient.

Apply processor-supported fraud controls and limits to every route that can validate or charge a payment method. Correlate failures with account, session, and permitted processor identifiers. Avoid recording raw card numbers or security codes in bot logs.

A single decline is not proof of fraud. Review bursts and repeated attempts in context, and prevent uncontrolled retries from amplifying the problem.

Coupon and loyalty abuse

An agent applying an eligible coupon for its shopper is doing useful work. Abuse starts when the action violates the offer: repeated introductory discounts, disallowed stacking, manufactured referrals, or redemption from an account the shopper does not control.

OWASP’s sensitive business flows guidance includes automated referral-program abuse and recommends identifying the business actions that become harmful when repeated.

Our recommended controls are server-side eligibility checks, atomic redemption, explicit stacking rules, and limits on repeated attempts. Require appropriate account authorization before spending loyalty balances. An authenticated agent still needs an eligible customer and a valid offer; authentication does not create entitlement.

Fake agent impersonation

A User-Agent header is self-declared text. Verify claimed operators through the mechanism they actually support, such as published network information or a supported request-signing scheme. Keep “unverified” distinct from “verification failed”: missing evidence or an unavailable verification service does not establish a deliberate impersonation attempt.

For signed requests, use trusted key discovery and the required signature profile. Check that the signature covers the intended request components and satisfies freshness and replay requirements. RFC 9421 defines HTTP Message Signatures and discusses insufficient coverage and replay risks; a signature’s presence alone is not verification.

Even successful operator verification says nothing by itself about whether a particular shopper approved this order. Keep that authorization check independent.

A merchant decision flow that preserves legitimate shopping

The following is a proposed policy design, not a measured detection benchmark or a claim about every agent platform.

1. Classify the requested action. Reading a public product page, reserving an item, adding a payment method, and redeeming points should have separate permissions and limits.
2. Establish the available identity evidence. Record the claimed operator and verification result. Give public discovery traffic an appropriate read policy; require stronger evidence where a trusted integration is necessary.
3. Validate authority before changing state. Bind customer access and transaction permission to the requested action. Reject expired or out-of-scope authority and provide a confirmation path where the shopper can resolve it.
4. Recompute the transaction on the server. Check current prices, taxes, shipping, stock, quantity limits, and promotion eligibility. Do not accept client-supplied totals as the source of truth.
5. Apply abuse controls within the authorized workflow. Track repeated holds, redemption attempts, and payment failures. Use idempotency for retried order creation so a network retry does not become a second purchase.
6. Record the decision and outcome. Keep a reason code and references to the relevant session, order, and authorization evidence. Use those records for support and false-positive review.

For example, consider an agent helping a shopper buy one pair of shoes. Public product reads can pass the discovery policy. A reservation uses a short, bounded hold. Checkout requires the shopper’s confirmed order and the normal payment checks. A retry with the same order operation should return the existing result. Attempts to exceed the purchase allowance should receive the store’s limit response, even when the agent is recognized.

An unfamiliar browser or missing mouse movement should not, by itself, force that shopper out of the flow. When stronger evidence is needed, offer a supported confirmation or handoff rather than requiring an agent to imitate human interaction.

What merchants should measure

Keep useful shopping activity and abuse outcomes in separate reports. Track completed orders from authorized integrations, checkout abandonment after a confirmation request, and decisions reversed by support. Compare those with reservation expiry, purchase-limit violations, ineligible redemptions, and repeated payment failures.

Measure requests and verified operators separately from shoppers and orders. One operator can serve many shoppers, and one shopper can use several devices. Neither a shared fingerprint nor a shared network address proves those purchases belong to the same person.

Use reason codes such as authorization_expired, reservation_limit, or promotion_ineligible to explain decisions. A single “bot blocked” total cannot tell you whether you stopped abuse or lost an authorized customer.

Where WebDecoy fits

WebDecoy’s Agent Identity tooling provides evidence about claimed crawler identities, while bot scanners and response rules support investigation and configured responses to automation. Treat that evidence as an input to your merchant policy. Purchase authorization, payment decisions, inventory allocation, and promotion eligibility remain responsibilities of the systems that perform those actions.

For Shopify merchants, the WebDecoy Shopify integration surfaces actor activity and order-risk evidence for merchant review. It does not automatically cancel orders or stop checkout. Use the evidence alongside your platform and payment-provider controls, with an explicit decision about which actions each integration may take.

Start by documenting the permissions for product reads, reservations, payments, and rewards. Then test an approved shopper journey and an abuse scenario for each. That gives your team a concrete way to welcome useful agents while enforcing the rules of your store.

Sources checked September 12, 2026. The Instant Checkout discussion refers to OpenAI’s September 2025 announcement. Merchant policy examples are WebDecoy’s analysis; they are not claims of ACP certification, universal platform support, or measured fraud-prevention rates.