Agentic Commerce for Merchants: Accept Agent Orders Safely

AI shopping agents now place real orders, and most merchant fraud stacks were built to tell humans from bots, not trusted agents from hostile ones. A merchant that blocks all automated checkout loses legitimate agent-driven sales; a merchant that waves agents through inherits card testing, mispicked orders and disputes it cannot defend. This guide is for e-commerce, payments and fraud teams on the merchant side: how agentic checkout integrations work, how to verify the agent and the user's authorisation before you ship, how to set fraud rules for agent orders, and what evidence you need when a dispute arrives. The identity model behind agentic commerce is covered in the Agentic Commerce Identity Guide and the protocols themselves in the Agent Payments Protocols Guide; this page stays on what a merchant has to build and decide. The specifications are young and change often: statuses below were checked on 8 November 2026.

Key takeaways

You stay the merchant of record. The main protocols keep orders, payment authorisation and compliance on your existing stack and PSP, so your fraud, refund and chargeback exposure does not move to the agent platform.
Verify three things on every agent order: the agent (a signed request you can check against a published key), the user's authorisation (a mandate or scoped token with amount, merchant and expiry limits), and that the order matches that authorisation.
Scoped credentials are your best fraud control. Tokens bound to one checkout session, one merchant, a maximum amount and a short expiry make stolen or replayed credentials far less useful than a raw card number.
Keep the evidence from the start. Signed carts, mandates, request signatures and session logs are what you will need to contest an "I did not authorise this" or "this is not what I asked for" dispute.
Do not trust your own agents' promises. Prices, discounts and refunds must be enforced by the commerce backend, never by a chatbot or merchant agent that a prompt can talk into a bad deal.

How agentic checkout reaches a merchant

Agent orders reach merchants by three broad routes, and most merchants will see all three at once. Knowing which route an order took tells you what proof you can expect with it.

Route	How it works	What the merchant can verify	Main merchant risk
Protocol checkout API	The agent platform calls a checkout API you host. The Agentic Commerce Protocol (ACP) Agentic Checkout RFC defines `POST /checkout_sessions`, update, retrieve, `/complete` and `/cancel`, with your PSP still authorising payment	Bearer token of the platform, optional request `Signature` and `Timestamp`, scoped delegated payment token	Weak platform authentication, missing idempotency, trusting cart data from the agent
Signed browsing agent	The agent uses your normal website or app but signs each HTTP request (Visa Trusted Agent Protocol, Web Bot Auth) so you can identify it	HTTP Message Signature over the request, key published by the agent operator, timestamp and nonce	Unsigned agents and scrapers that look identical to signed ones if you do not check
Unidentified automation	A browser automation tool or headless agent with no signature, often using the user's saved card or account	Only behavioural and device signals	Account takeover, card testing, scalping, orders the user never intended
Mandate-based payment	The agent presents signed mandates (Agent Payments Protocol, AP2) alongside the payment; you sign the cart you offer	Cart Mandate signed by you and the user, or an Intent Mandate with scope and expiry	Fulfilling an order outside the mandate's scope

The ACP checkout RFC states plainly that the merchant remains the system of record for orders, payments, taxes and compliance, and that payment authorisation and settlement continue through the merchant's PSP. It also lists fraud modelling as out of scope. That is the core message for merchants: the protocols carry better signals, but deciding whether to accept an order is still your job.

Verifying the agent before it reaches checkout

Agent verification answers "who is calling", not "should this order be accepted". Treat it as the first gate, at the edge (CDN, WAF or API gateway) where possible.

HTTP Message Signatures: The common building block is RFC 9421 HTTP Message Signatures. The IETF Web Bot Auth working group's draft-ietf-webbotauth-httpsig-protocol (version -01, 29 October 2026, an Internet-Draft, not yet an RFC) defines a Signature-Agent header that points to the signer's key directory, a JWKS-based directory format and a well-known URI where it is published. Because it is a draft, build verification so that header names and key discovery can be updated without a code release. See the Web Bot Auth and HTTP Message Signatures for Agents.
Trusted Agent Protocol: Visa's TAP repository describes signatures that carry a timestamp, a unique session identifier, a key identifier and an algorithm identifier, bound to the merchant's domain and to the operation (browsing or payment). Its sample implementation verifies RFC 9421 signatures in a CDN proxy and looks up keys in an agent registry. Check freshness and reject replays: a valid signature from yesterday is not a valid request today.
Platform authentication for checkout APIs: The ACP checkout RFC makes Authorization: Bearer required and recommends a Signature over canonical JSON plus an RFC 3339 Timestamp, verified within a bounded clock-skew window, over TLS 1.3. Treat the platform's bearer token as a privileged machine credential: store it in a secrets manager, rotate it and scope it to the checkout endpoints only.
Bot management classification: Edge providers increasingly label traffic. Cloudflare's documentation, for example, distinguishes verified bots from signed agents and lets site owners set allow or block expectations for AI crawlers and agents. Use this to route traffic into different policies, not as the only decision. See the Bot vs AI Agent Traffic Management Guide.

A verified agent is a known operator, not a trustworthy order. A signed agent can still be acting for a fraudster with a stolen account, and a legitimate user can still be using an unsigned tool. Verification lowers uncertainty about the caller; the fraud and authorisation checks below decide the order. The Know Your Agent (KYA) Guide covers how to onboard and rate agent operators.

Verifying the user's authorisation and the order

The harder question is whether the human behind the agent agreed to this purchase, on these terms. Each protocol answers it differently, and the merchant's job is to check the answer against the actual order.

Artefact	Defined in	What it proves	Merchant check before fulfilment
Cart Mandate	AP2 specification (v0.1 proposal)	The merchant signed the cart it offered and the user approved those exact goods, price and payment method with a hardware-backed device key (human present)	Signature valid, cart hash matches the order you are about to ship, no line items added after signing
Intent Mandate	AP2 specification	The user pre-authorised a scope (products or categories, criteria, a "prompt playback" of their request) with an expiry, for human-not-present purchases	Order sits inside the scope, mandate not expired; if in doubt, force the user back into session to approve a cart
Payment Mandate	AP2 specification	Tells the network and issuer that an agent was involved and whether the user was present	Passed through with authorisation by your processor; confirm your PSP supports it
Delegated payment token with Allowance	ACP Delegate Payment RFC (draft)	A vault token usable only within `max_amount`, `currency`, `checkout_session_id`, `merchant_id` and `expires_at`, with `reason` set to `one_time`	Order total at or below `max_amount`, same session and merchant, before expiry; read the required `risk_signals`
Shared payment token	Stripe documentation (one ACP implementation)	A scoped grant to the seller with `usage_limits` (`currency`, `max_amount`, `expires_at`, optional `recurring_interval`)	Charge within limits; listen for `shared_payment.granted_token.deactivated` (consumed, resolved, expired or revoked)
Agentic network token	Card network programmes such as Visa Intelligent Commerce	A token provisioned for an AI agent token requestor, with consumer approval of purchase instructions through passkey-based step-up	Processed through your acquirer as a tokenised transaction; confirm what agent indicators your acquirer passes to you

The AP2 specification gives merchants an explicit lever: for a human-not-present purchase, the merchant can require the user to return to the session to choose between options, which produces a Cart Mandate, or to answer questions that update the intent. AP2 also notes that any party can trigger a challenge such as 3-D Secure, completed by the user on a trusted surface. The ACP checkout RFC has a matching mechanism: the server sets session.status to authentication_required, and a /complete call without an authentication_result is rejected with code requires_3ds. Use these to step up on high-risk orders instead of declining them outright. The AI Agent Action Approvals and Spending Limits Guide covers how limits are set on the agent side.

Fraud rules for agent orders

Agent orders break several assumptions in existing fraud models: there is no mouse movement, sessions are short, the shipping address may be new, and velocity can be high and still legitimate. Rather than loosening rules for all automation, create a separate policy path for verified agent traffic.

Threat	How it shows up in agent traffic	Merchant control
Card testing through agent APIs	Many small checkout sessions, many cards, one platform or one key	Rate limit per platform key and per agent key; honour the ACP `card_testing` risk signal and its `blocked` or `manual_review` action; see the Card Testing and Carding Attacks Defence Guide
Account takeover driving an agent	A legitimate signed agent placing orders from a compromised customer account, new address, high-resale goods	Address and device change rules still apply; step up with 3-D Secure or return-to-session for new shipping addresses
Replayed or relayed requests	Same signature or session identifier seen twice, timestamp outside window	Nonce store, tight clock skew, reject reuse; TAP and Web Bot Auth both rely on freshness
Order outside the user's intent	Wrong size, wrong quantity, substitute product, price above the mandate	Compare order to mandate scope or token `max_amount` before capture; never upsell or substitute without a fresh user approval
Retries creating duplicate orders	Agent retries after a timeout and creates a second order	ACP requires an `Idempotency-Key` on every POST, scoped to the authenticated identity and endpoint, retained at least 24 hours, with `idempotency_conflict` (422) for a reused key with a different body
Scalping and inventory hoarding	Agents holding carts or buying limited stock at machine speed	Per-agent and per-account purchase limits on limited items, cart hold timeouts, queue fairness that does not favour automation
Prompt injection against your own agent	A buyer's agent or a human talks your merchant chatbot into a price or promise	Price, discount and refund rules enforced server side; see OWASP LLM01 Prompt Injection and LLM06 Excessive Agency

Decision guidance: a small merchant on a hosted platform should rely on its PSP's agentic integration and token scoping, keep its existing fraud tool switched on for agent orders, and focus on evidence retention. A large merchant with its own fraud models should label agent orders as a separate channel (signed, unsigned, mandate-backed), train or tune rules on that channel separately, and decide explicitly which product categories it will sell to human-not-present agents at all. Gift cards, high-resale electronics and age-restricted goods are the obvious candidates for "human present only".

Disputes, chargebacks and liability

Dispute rules were written for human purchases. The protocols try to give merchants better evidence, but they do not rewrite card scheme rules on their own.

Liability still follows network rules: The AP2 specification sets out principles: stay close to existing regulation, rely on verifiable cryptographic evidence, and assign liability to a real-world party (user, merchant or issuer) in most cases. Its scenario table covers first-party misuse, mispicks, non-fulfilment, account takeover and man-in-the-middle attacks, but the document says it is a guide only and that each network sets its own liability terms. As a general rule of card payments, card-not-present fraud losses fall on the merchant unless authentication such as 3-D Secure shifts liability; check your acquirer agreement and network rules for how agent transactions are treated.
Signed carts are dispute evidence: AP2 describes the merchant using the Cart Mandate as evidence in a dispute, with the network adjudicator comparing the cart, its hash and the mandates to decide whether the user approved the cart and the merchant delivered it. Store the signed cart, the mandate and the verification result with the order.
"Not what I asked for" disputes: These are the new category. A mispick by the agent against a valid Intent Mandate is different from a merchant shipping something outside it. You can only argue the first if you kept the mandate scope and can show the order matched it.
Refunds and cancellations: Agents will request them too. Route agent-initiated refunds through the same authorisation checks as orders, and pay refunds only to the original payment method.
Webhook integrity: The ACP checkout RFC requires order lifecycle webhooks (order_create, order_update) to the platform, and calls for HMAC verification (Merchant-Signature). A forged "order delivered" webhook can mislead the platform and the user, so sign and verify both directions.

The Ecommerce Fraud and Chargeback Protection buyer's guide covers how to evaluate tools that will need to handle this channel.

Integration rollout

Inventory current agent traffic. Use edge logs to measure signed, verified and unidentified automated traffic reaching product, cart and checkout pages. Decide which flows you will open to agents and which stay human only.
Choose integrations through your PSP first. Most merchants should start with their payment provider's agentic offering, which handles token provisioning and network programmes, rather than implementing raw protocols.
Build the checkout API defensively. Recalculate price, tax, shipping and stock server side on every update; never accept totals from the agent. Enforce idempotency, bounded clock skew and request signature verification, and never log full card numbers or CVC (a requirement the ACP RFC also states).
Set the order policy. Define per-category rules: human-present only, mandate required, maximum basket value for human-not-present orders, step-up triggers.
Pilot in a ring. Open one agent platform or one product range, compare fraud, refund and dispute rates against your human channel for at least one full chargeback cycle before expanding.
Keep a kill switch. Be able to disable agent checkout per platform, per agent key or for all agents without touching the human checkout. Revoke the platform's bearer token and stop accepting new sessions; existing tokens expire by design if you kept expiries short.

Where identity fits

Two sets of non-human identities sit inside this flow. The first is inbound: agent operators' signing keys and the platforms' bearer tokens. Maintain an allow list of the operators and key directories you accept, record which key signed each order, and remove keys when a platform relationship ends. The second is yours: the API keys and webhook secrets your checkout service uses with PSPs, platforms and network token services. These are payment-capable credentials and belong in a secrets manager with rotation, scoping and alerting. See the Retail and E-Commerce Identity Security Guide.

Detection and measurement

Log per order: channel (signed agent, protocol API, unidentified automation, human), agent operator and key ID, signature verification result, mandate or token ID and its limits, step-up outcome, idempotency key.
Alert on: signature failures or replays from a known operator, sudden volume from one key, orders rejected for exceeding token limits, spikes in requires_3ds failures, webhook signature failures.

Metrics that show the controls work:

Share of agent orders carrying a verifiable signature and a scoped credential or mandate.
Fraud-coded chargeback rate for agent orders versus the human channel.
"Not as described" or "not authorised" dispute win rate for agent orders where mandate evidence was submitted.
Duplicate order rate from agent retries (target near zero once idempotency is enforced).
Step-up completion rate for agent orders that were challenged.

Framework mapping

Control area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	Other
Authenticate agent operators and platforms	IA-9 Service Identification and Authentication	PR.AA-03	RFC 9421; Web Bot Auth draft
Keep signed carts and mandates as evidence	AU-10 Non-repudiation	DE.AE-02 (analysis of events)	AP2 mandates
Freshness and replay protection	SC-23 Session Authenticity	PR.AA-03	TAP timestamps and nonces
Server-side validation of price and cart	SI-10 Information Input Validation	DE.CM-09	OWASP LLM01, LLM06
Enforce token limits and category rules	AC-3 Access Enforcement	PR.AA-03	ACP Allowance; SPT usage_limits
Contracts with agent platforms and PSPs	SA-9 External System Services	GV.SC-05	Acquirer and network rules

Common failure patterns

Accepting the agent's cart total. If the checkout API trusts price or discount fields sent by the agent, a manipulated agent sets its own price. Recalculate everything server side.
Letting a merchant chatbot make binding offers. The Chevrolet dealer chatbot incident in December 2023 showed a customer-service bot being talked into "agreeing" to sell a car for $1. As merchants deploy their own selling agents to talk to buyers' agents, the same weakness becomes an automated one: offers and discounts must come from the pricing engine, not the model.
Checking the signature but not the freshness. A valid signature replayed later passes a naive check. Enforce timestamps, expiry and nonce reuse.
One fraud policy for all automation. Blocking every agent loses sales; trusting every signed agent ignores account takeover. Separate channels, separate rules.
Not storing the mandate. Teams verify the mandate at checkout and discard it, then have nothing to submit when the dispute arrives months later. Retain it with the order for the full dispute window.
Long-lived platform tokens. A static bearer token for an agent platform, shared across environments and never rotated, is a payment-capable credential waiting to leak.

Practitioner checklist

Classify automated traffic into signed agents, protocol API calls and unidentified automation, and route each to its own policy.
Verify RFC 9421 signatures with timestamp, expiry and nonce checks at the edge, with key discovery that can follow draft changes.
Recalculate price, tax, discounts and stock server side on every checkout update.
Enforce idempotency keys on every POST and keep the mapping for at least 24 hours.
Charge only within token limits (amount, currency, merchant, session, expiry) and check the order against mandate scope before capture.
Define which product categories require a human-present approval or step-up.
Store signed carts, mandates, verification results and session logs with each order for the dispute window.
Keep platform bearer tokens and webhook secrets in a secrets manager, scoped and rotated.
Pilot one platform for a full chargeback cycle and compare against the human channel before expanding.
Maintain a per-platform and global kill switch for agent checkout.

Agentic Commerce for Merchants: Accepting AI Agent Orders Safely