An AI agent that can finish a purchase on a store’s behalf needs four things the store probably does not expose today: a payment credential that was never typed into a checkout form, an order API that accepts a machine as the buyer, a way to resolve address, tax and shipping with nobody watching, and fraud rules that do not treat every agent session as a bot attack. Agentic checkout for merchants is therefore a payments and risk project first, and a marketing project a distant second. This guide lays out the store-side requirement list in the order most teams end up tackling it.
In short
- Agentic checkout means an AI assistant (ChatGPT, Gemini, Perplexity, a retailer’s own agent) places and pays for an order without the shopper touching the merchant’s checkout page.
- Delegated payment credentials are scoped, network-issued tokens carrying a spending mandate; they are not the same thing as a card on file and they change who is liable for what.
- Order and cart APIs must accept structured, authenticated requests for availability, pricing, cart creation and order placement, and must emit status events the agent can read back.
- Fraud stacks misfire on agent traffic because device fingerprints, behavioral biometrics and velocity rules were built around a human on a browser; the replacement signal is agent identity, not session behavior.
- Refund and dispute handling does not disappear because a machine placed the order; the consumer protections still attach to the human who authorized the mandate, so a staged rollout matters.
What does agentic checkout mean in practice?
In practice, agentic checkout is any flow where software acting for a consumer completes the purchase decision, the payment step and the order confirmation inside the assistant’s interface rather than on the merchant’s site. The shopper says “buy the 32-ounce version and ship it to my office,” the agent resolves product, variant, price, address and payment, and the merchant receives an order it never rendered a page for. The retailer sees a completed transaction and a delegated buyer, not a session.
This is a different animal from the AI-assisted discovery that most retailers have already noticed in their analytics. Being cited by a chatbot or surfaced in an AI Overview is a visibility problem, which is why AIO for retailers sits alongside SEO in most marketing plans. Letting the same assistant press “pay” is a systems problem that lands on the payments, engineering and risk teams. The full landscape, including how the protocols compete, is covered in our guide to preparing your store for AI shopping agents; this article is the narrower engineering checklist.
The three delegation models a store will encounter
Three patterns dominate the current protocol drafts and pilots. Under the assistant-hosted checkout model, exemplified by OpenAI’s Agentic Commerce Protocol work with Stripe as announced in late 2025, the assistant renders the order summary and the merchant’s systems receive a structured order plus a payment token. Under the merchant-hosted handoff model, the agent assembles the cart and the shopper is bounced to a merchant-controlled page for the final confirmation. Under the fully autonomous model, the agent operates under a pre-authorized mandate (a budget, a recurring rule, a “replenish when low” instruction) and no human is present at the moment of purchase.
Each model shifts the requirement list. Assistant-hosted flows demand the most complete API surface because the merchant never gets to show its own form. Merchant-hosted handoffs are the least invasive but throw away most of the conversion advantage. Fully autonomous flows carry the heaviest fraud and dispute exposure because nobody reviewed the order before it shipped.
Where the store sits in each model
In all three, the merchant remains the merchant of record for the sale unless it has explicitly contracted otherwise with a platform. That has consequences: the order lands in the merchant’s order management system, the tax nexus is the merchant’s, the shipping promise is the merchant’s, and the chargeback, if one arrives, is the merchant’s to defend. Retailers who treat the agent as a reseller or affiliate are misreading the arrangement, at least under the protocol designs public as of mid-2026.
How do delegated payment credentials differ from cards on file?
A delegated payment credential is a network token bound to a specific agent, a specific merchant (or merchant class) and a specific set of spending constraints, issued so the agent can pay without ever holding the underlying card number. That last clause is the whole difference. A card on file is a stored copy of the consumer’s primary account number or a merchant-scoped token derived from it; the merchant initiates every charge and carries the liability that comes with storing the credential. A delegated agent credential is issued to the agent, typically by the card network or a wallet provider, with the consumer’s mandate attached as metadata.
The major networks each shipped a version of this idea during 2025. Mastercard’s Agent Pay program introduced what it calls agentic tokens; Visa’s Intelligent Commerce initiative published a Trusted Agent Protocol in the fall of 2025; Google’s Agent Payments Protocol (AP2) proposed signed “mandates” that record the consumer’s intent cryptographically; and Stripe described Shared Payment Tokens for the OpenAI integration. The naming differs but the mechanics converge on tokenization (the general concept is well described on Wikipedia’s tokenization entry) plus a scoped authorization the merchant can inspect.
| Attribute | Card on file (merchant-stored) | Delegated agent credential |
|---|---|---|
| Who holds the credential | Merchant or its payment provider vault | Agent platform or wallet, issued via the card network |
| Who initiates the charge | Merchant (merchant-initiated or customer-initiated transaction flags) | Agent, presenting the token with the order |
| Scope | Any amount at that merchant until revoked | Bounded by mandate: amount cap, category, expiry, single-use or multi-use |
| Consumer consent record | Terms accepted at signup; often not itemized | Signed or logged mandate attached to the token (varies by protocol) |
| PCI scope for merchant | Reduced with network tokens, but the vault is a merchant asset | Merchant typically never sees a PAN; scope shifts toward the agent platform |
| Revocation | Consumer contacts merchant or issuer | Consumer revokes at the wallet or agent level; merchant learns via decline or webhook |
| Dispute posture | Standard card-not-present rules | Emerging; networks have signaled new indicators for agent-initiated transactions |
What the merchant has to accept technically
Store-side, accepting a delegated credential usually means the payment provider must pass through a new transaction indicator or field that marks the transaction as agent-initiated, and the merchant’s authorization request must carry it. Merchants running older gateway integrations that strip unknown fields will find the transaction either declined or, worse, processed as an ordinary card-not-present sale with none of the protective indicators attached. The practical requirement is a payment provider on a current API version that supports network tokens and the agent-initiated flag, plus a reconciliation layer that can tell agent orders apart in settlement reports.
Why the mandate matters for liability
The mandate is the record that the human actually authorized the agent to spend. If a shopper later says “I never told it to buy that,” the mandate is the merchant’s and the network’s first line of evidence. Protocol drafts differ on where the mandate lives and who can read it.
A merchant that cannot retrieve or reference the mandate identifier on an order is accepting agent orders blind. The identity side of this is developing quickly; our analysis of tokenized agent identity as the gate for agentic checkout tracks how the networks are approaching it.
Which order and cart APIs does an agent need to reach?
An agent needs to do five things without a browser: check that a product exists and is in stock, get a firm price including any promotions it qualifies for, create or modify a cart, place the order with a payment credential, and read back status afterward. A store whose only interface for those actions is a rendered web page has no agentic checkout capability, whatever its marketing says. Headless platforms generally expose all five; legacy monoliths often expose the first two and hide the rest behind session cookies and CSRF tokens.
- Availability and pricing lookup. A read endpoint keyed by SKU or GTIN, returning stock state by location, current price, applicable tax class and shipping class. Agents compare this against the feed they discovered the product in; discrepancies between feed and live price are the most common reason an agent abandons a merchant.
- Cart creation and mutation. Create a cart, add or remove line items, apply a promotion code, and receive a totals object that already includes estimated tax and shipping for a given address.
- Checkout session or order placement. Accept a structured request containing the cart reference, the buyer identity (as much as the protocol shares), the shipping and billing addresses, the selected shipping method and the payment credential. Return an order identifier synchronously.
- Order status and events. Webhooks or a polling endpoint for confirmation, fulfillment, shipment tracking, cancellation and refund. Agents that cannot see status will re-ask the shopper, or worse, re-order.
- Cancellation and modification window. An endpoint that allows the agent (or the human) to cancel within a defined window before fulfillment, which becomes a key exposure-limiting control in autonomous flows.
Idempotency and duplicate orders
Every order placement call from an agent must carry an idempotency key and the merchant must honor it. Agents retry on timeouts; without idempotency a single network hiccup produces two orders, two charges and eventually a dispute. This sounds elementary, but it is the failure mode most frequently reported in early pilots, because merchant order endpoints were designed for a human who would notice a duplicate confirmation email.
Feed consistency as a precondition
The order API is only half of the data contract. The agent found the product through a structured feed, and it expects the order API to agree with the feed on identifiers, variants and price. A store that publishes a strong feed but exposes a checkout API keyed by internal IDs the feed does not carry has built two systems that cannot talk. The fields that decide whether an agent even considers a product are covered in our piece on product feeds for AI shopping agents; the same identifiers should be the ones the cart API accepts.
How does a store handle address, tax and shipping selection without a human?
Without a human to correct typos or pick the cheaper option, address, tax and shipping have to resolve deterministically from data the agent supplies plus rules the merchant defines. That means machine-readable address validation, a tax engine that can quote before order placement, and a shipping selection policy that does not depend on a radio button. Merchants that handle these steps with a human “review your order” screen will find that screen has no equivalent inside an assistant.
Address validation and normalization
The agent passes an address it received from the shopper’s profile, which may be stale, informal (“my office”) or in a format the merchant’s carrier will reject. The store needs an address validation service in the checkout path that returns a normalized, deliverable address or a structured rejection the agent can act on (ask the shopper, try the profile’s alternate address). Silent acceptance of a bad address followed by a carrier return is expensive in the human world and worse in agent flows, because the shopper never saw the address the agent used.
Tax calculation before commitment
Tax must be quoted in the cart totals object, not computed after the fact, because the agent presents a final price to the shopper before requesting the credential. US sales tax depends on the destination address and the product’s tax class, and the merchant remains responsible for collecting and remitting it where it has nexus. Real-time tax engines already do this for human checkouts; the requirement is that the same quote is available through the API the agent calls, and that it is recomputed if the address changes.
Shipping method selection by policy
The store should publish shipping options with price and delivery estimate in the cart response and define a default selection policy the agent can rely on (cheapest, fastest under a cost cap, or a shopper preference passed in the request). Protocol drafts generally let the agent choose among options the merchant returns; they do not let the agent invent an option. Merchants offering store pickup or scheduled delivery need to express those as selectable options with structured constraints, or agents will simply route around them.
Which fraud rules misfire on agent traffic?
Most fraud stacks misfire on agent traffic because they infer a human’s honesty from browser behavior, and agents have no browser behavior. Device fingerprinting returns a data-center IP and a headless or server-side client. Behavioral biometrics see no mouse movement and no typing cadence. Velocity rules see one client placing many orders for many different people within minutes.
Each of those, on a legacy rule set, reads as a bot attack. The result is either blanket declines of legitimate agent orders or, if the team relaxes rules to let agents through, a wide-open door.
The replacement signal is agent identity plus mandate verification: is this a known agent platform, presenting a verifiable credential, with a mandate that matches the order? Payment fraud fundamentals do not change (the broader toolkit is laid out in our guide to payment fraud and chargeback prevention for online retailers), but the inputs to the risk model do. The table below summarizes what happens to common signals when the buyer is software.
| Legacy fraud signal | Why it misfires on agents | Replacement or adjustment |
|---|---|---|
| Device fingerprint | Data-center IP, server-side client, identical fingerprint across thousands of shoppers | Whitelist verified agent platforms by signed identity; score the agent, not the device |
| Behavioral biometrics | No mouse, keyboard or scroll data at all | Drop from agent scoring; weight mandate consistency and account history instead |
| Velocity per IP or device | One agent platform legitimately places many orders per minute | Velocity per underlying consumer identity and per mandate, not per client |
| Billing and shipping address mismatch | Agents frequently ship to a profile address that differs from the card’s billing address | Accept mismatch where the mandate includes the shipping address; flag only when the address is new to the consumer’s profile |
| Session duration and page depth | Zero page views; the order arrives fully formed | Remove from model for agent-flagged transactions |
| 3-D Secure challenge | No human present to complete a challenge in autonomous flows | Rely on the network’s agent-initiated indicators and pre-authenticated mandates; reserve challenges for merchant-hosted handoffs |
| Email domain and account age | Agent may present a platform-scoped identifier rather than the shopper’s email | Map platform identifier to consumer account; treat first-time mapping as elevated risk |
Segmenting agent traffic in the risk engine
The first practical requirement is that the risk engine can see the agent-initiated indicator and route those transactions into a separate rule set. Merchants running a single rule set for all card-not-present traffic cannot tune for agents without loosening controls for everyone. The second is logging: every agent order should record the agent platform identifier, the mandate reference and the credential type, so that when a fraud pattern emerges the team can trace it to a platform rather than a device.
What the agent-initiated indicator does and does not do
Network-level indicators flag that a transaction was agent-initiated; they do not by themselves guarantee the agent was authorized. Liability treatment for agent-initiated transactions was still being defined by the card networks as of 2026, and merchants should verify current chargeback and liability rules directly with their acquirer and the network rule documents rather than assume the indicator shifts liability away from them.
Refunds, disputes and who the customer legally is
The consumer who granted the mandate remains the customer, and the consumer protections that attach to a card or bank payment attach to that person regardless of the software that placed the order. This section is general information about how the pieces fit together; it is not legal, tax or customs advice, and a merchant assessing its own exposure should consult a licensed attorney and its acquiring bank for its specific situation. Rules in this area are changing quickly and current terms should be verified at the official source.
In the United States, billing error rights for credit card transactions are set out in Regulation Z and unauthorized electronic fund transfer protections in Regulation E, both administered by the Consumer Financial Protection Bureau (the CFPB publishes the rules and consumer guidance on its official site). Those frameworks predate agents and, as of this writing, have not been amended for them. Separately, the Federal Trade Commission’s Mail, Internet, or Telephone Order Merchandise Rule governs shipping-time promises and refund obligations for orders the merchant cannot ship on time; merchants should check the FTC’s current text for the applicable deadlines. Card network dispute time frames are set by Visa and Mastercard operating rules, which the networks publish and revise on their own schedules.
Refund mechanics through an agent
A refund must flow back to the credential that paid, which in a delegated model means through the agent platform’s token rather than a card the merchant holds. Merchants need their payment provider to support refund-to-token for agent credentials and need an API path for the agent (or the shopper, through the assistant) to request a return. Refund status should surface through the same order-events channel used for confirmation, or the shopper will be asking the assistant a question the assistant cannot answer.
Dispute evidence in an agent world
When a cardholder disputes an agent order, the merchant’s representment package needs the mandate reference, the agent platform identity, the order payload the agent sent, the shipping confirmation and any communication log the platform exposes. Merchants that cannot produce the mandate are defending a card-not-present dispute with less evidence than they would have for a human web order. Whether networks introduce agent-specific dispute reason codes, and how issuers treat “the agent did it” claims, remained unsettled as of 2026, so the conservative posture is to retain everything.
The “who is the customer” question in practice
Operationally, the merchant should treat the consumer behind the mandate as the customer of record for order history, communications, loyalty and data-privacy purposes, and treat the agent platform as a channel. Privacy obligations under state laws such as the California Consumer Privacy Act attach to the consumer’s data regardless of which software submitted it; the merchant’s privacy notice may need to describe agent channels explicitly. Again, this is general orientation, not legal advice, and counsel should review the specific arrangement.
What does a staged rollout that limits exposure look like?
A staged rollout gates each new capability behind a measurable control: order caps, product-category limits, a human confirmation step and a short cancellation window, each relaxed only after dispute and fraud rates at the prior stage are known. The point is not to slow adoption for its own sake but to make sure the first month of agent orders cannot produce a quarter’s worth of chargebacks. The following sequence reflects how several early adopters described their pilots in 2025 and 2026.
- Read-only exposure. Publish the feed and the availability and pricing API. Let agents discover and quote products. No orders. Measure how often agents request prices and how often the quote matches the feed.
- Merchant-hosted handoff. Accept agent-assembled carts, but require the shopper to confirm on a merchant page with the merchant’s own fraud checks. This exposes cart and address handling without exposing autonomous payment.
- Assistant-hosted checkout with caps. Accept delegated credentials for orders under a dollar cap (many pilots started under $100 or its local equivalent), restricted to low-return-rate categories, with a one-hour cancellation window before fulfillment.
- Expanded caps and categories. Raise the cap and open categories once 60–90 days of dispute data exist. Add a separate fraud rule set for agent traffic and compare its false-positive rate with the human rule set.
- Autonomous replenishment. Only after the above, allow recurring or trigger-based mandates for consumables, with per-mandate spending caps and mandatory notification to the shopper on each order.
Metrics that gate each stage
Four numbers decide whether to advance: authorization approval rate on agent transactions versus the human baseline, dispute rate per thousand agent orders, duplicate-order rate (a proxy for idempotency failures), and address-failure rate (returns to sender and carrier corrections). If any of the four is materially worse than the human channel, the stage is not finished. Retailers building the visibility side in parallel should also track how often assistants cite the store at all; our breakdowns of how ChatGPT cites retail content and what Perplexity and Google AI Overviews reward cover that measurement.
Who owns the rollout
In organizations that got this right, the payments or risk lead owned the rollout with engineering, and marketing owned the discovery layer. Where marketing owned checkout enablement, the pilots tended to open too fast on the fraud side and too slow on the API side. The single most useful governance decision is to name one owner for the agent-initiated transaction indicator end to end, from gateway configuration through risk rules to reconciliation.
Common mistakes stores make when enabling agents to buy
The most expensive mistakes cluster around treating agent checkout as a front-end feature. Stores wire an assistant integration to a checkout page rendered for humans, discover that agents cannot complete it, and then strip fraud controls to make it work. A second cluster is data inconsistency: the feed says one price, the API another, and the agent walks. A third is legal complacency, assuming that because a platform “handled” payment the merchant has no dispute exposure.
- No idempotency on order placement. Produces duplicate orders on every agent retry.
- Stripping the agent-initiated indicator at the gateway because the integration predates it, which erases the merchant’s ability to segment risk.
- Applying human velocity rules to a platform that legitimately places hundreds of orders per hour.
- Quoting tax and shipping after order placement, so the agent presents a price the shopper is then charged more than.
- No cancellation window in autonomous flows, so the first correction a shopper can make is a return.
- Failing to store the mandate reference on the order record, leaving the merchant without its best dispute evidence.
- Treating the agent platform as the customer for privacy and communications purposes, which misaligns with how consumer protection frameworks assign rights.
FAQ on agentic checkout
What is agentic checkout, in one sentence?
Agentic checkout is a purchase flow in which an AI agent, acting under a consumer’s authorization, selects the product, resolves address and shipping, presents a payment credential and places the order through the merchant’s APIs without the shopper using the merchant’s checkout page. The merchant remains the seller of record; the agent is a new channel through which orders arrive fully formed.
Is a delegated payment credential the same as a stored card or wallet token?
No. A stored card or merchant-scoped token is held by the merchant and can be charged for any amount until revoked. A delegated agent credential is issued to the agent platform through the card network or wallet, carries a mandate with spending limits and expiry, and typically never exposes the card number to the merchant. The difference affects PCI scope, who initiates the charge and how disputes are evidenced.
Do I need a headless commerce platform to support agentic checkout?
Not strictly, but the store needs API access to availability, pricing, cart, order placement and order status that does not depend on browser sessions. Headless platforms expose this by design. Monolithic platforms can often be extended through their REST or GraphQL layers, but merchants should audit whether order placement is actually reachable without a session cookie before assuming they are ready.
Why are legitimate agent orders being declined by my fraud tools?
Because the tools infer honesty from browser behavior that agents do not have. Data-center IPs, missing device fingerprints, no mouse or typing data, and high velocity from one client all score as bot activity on legacy rules. The fix is to route agent-initiated transactions into a separate rule set that scores the agent’s verified identity and the mandate’s consistency with the order, rather than device and behavioral signals.
Who is liable if an agent buys something the shopper says they never approved?
As of 2026 the card networks were still defining liability treatment for agent-initiated transactions, so no single answer applies everywhere. In general, US consumer protections under Regulation Z and Regulation E attach to the cardholder or account holder, and the merchant remains the party a dispute is filed against. The mandate record is the merchant’s primary evidence. Merchants should verify current rules with their acquirer and consult counsel; this is not legal advice.
How should a store handle returns and refunds on agent orders?
Refunds must return to the delegated credential through the agent platform, so the payment provider needs refund-to-token support for agent credentials. The store should expose return and refund requests through the same API surface the agent used to order, and publish refund status through order events. Return policies themselves do not change, but the shopper’s first contact will often be the assistant, not the merchant’s support desk.
What is a sensible first order cap for a pilot?
Several pilots described in 2025 and 2026 started with caps below $100, restricted to low-return categories such as consumables and replacement parts, with a short cancellation window before fulfillment. There is no official standard; the right cap is the one at which a bad month of disputes is survivable. Caps should rise only after 60–90 days of dispute and duplicate-order data exist for the agent channel.
Does the merchant still owe sales tax on orders placed by an agent?
Yes, where the merchant has nexus. The agent does not become the seller; the merchant does. Tax must therefore be quoted in the cart totals before the agent presents a final price and must be recalculated if the destination address changes. Tax obligations vary by jurisdiction and change frequently, so merchants should confirm treatment with a tax advisor and the relevant state authority rather than rely on general summaries.
Next steps
The order of work that has held up in practice is: audit the API surface for the five agent actions, upgrade the payment integration to pass the agent-initiated indicator and accept network tokens, build a separate fraud rule set, and only then open a capped assistant-hosted pilot. Retailers that want the strategic framing before committing engineering time should read our guide to agentic commerce and preparing your store for AI shopping agents, then return to this checklist with the payments and risk leads in the room.