Agentic Commerce: AI Agent Payments (AP2, ACP, x402)

Q: What is agentic commerce?

Agentic commerce is buying and selling where an AI agent, rather than a human at a checkout page, performs some or all of the purchase journey: discovering products, comparing options, assembling a cart, and executing payment. It spans a spectrum of autonomy. At the assisted end, a shopping agent researches and fills a cart while the human taps the final approval — the dominant pattern today, visible in buy-in-chat experiences inside AI assistants. At the delegated end, the human grants bounded authority up front — "buy these concert tickets the moment they go on sale, up to $200" — and the agent completes the purchase without a human present at the decisive moment. The reason this required new infrastructure rather than just new apps is that the entire payment stack — fraud models, liability rules, checkout flows, 3-D Secure — was built on the assumption that a human is present to click Confirm. Agents break that assumption, so 2025-26 produced a wave of protocols (Google-led AP2 with 60+ payment-industry partners, the OpenAI/Stripe-originated ACP, Coinbase's x402) whose shared job is making an agent's purchase provably authorized, auditable, and liability-assignable.

Q: What is the AP2 protocol and how do mandates work?

AP2 — the Agent Payments Protocol — is an open protocol announced by Google in late 2025 with more than sixty payment networks and technology partners, designed to answer one question cryptographically: did the user actually authorize what the agent bought? Its core mechanism is the mandate, a tamper-evident verifiable credential signed by the user's side. Two kinds chain together. An intent mandate captures the delegated instruction and its bounds — what to buy, price ceilings, validity window — and is what lets an agent shop while the human is absent. A cart mandate binds the exact final items and price at the moment of approval, either signed by the human in real time (human-present flows) or authorized automatically because it falls within a still-valid intent mandate (delegated flows). The result is a non-repudiable evidence chain from intent to cart to payment execution: merchants can prove they shipped what was authorized, networks can assign liability when something goes wrong, and users can prove what they did and did not approve. AP2 is payment-method-agnostic — cards, bank transfers, local rails, and crypto — because it standardises the authorization proof, not the money movement.

Q: What is x402 and why does it use HTTP status 402?

x402 is Coinbase's open protocol that finally puts HTTP status code 402 — "Payment Required," reserved in the HTTP specification since the 1990s but never standardised — to work for machine-native payments. The flow is elegantly minimal: an agent (or any client) requests a resource from an API; the server responds 402 with payment details — price, accepted asset, destination; the client pays, typically in a stablecoin like USDC on a low-fee chain, and retries the request with proof of payment attached; the server verifies and returns the resource. No accounts, no API-key provisioning, no invoices, no card networks — payment and access collapse into the request/response cycle itself, settling in seconds. Because on-chain stablecoin transfer fees are tiny, per-call prices as small as a tenth of a cent become economically viable, which unlocks genuine pay-per-use API monetization and agent-to-agent service payments that card economics could never support. Its natural habitat is machine-to-machine: agents buying compute, data, inference, or tool calls from other services autonomously. It complements rather than competes with AP2/ACP — those govern human-authorized retail purchases; x402 handles the machine-speed micro-economy underneath.

Q: How is ACP different from AP2?

They solve adjacent but different layers, and a mature stack will likely use both. ACP — the Agentic Commerce Protocol, which emerged from OpenAI and Stripe's work powering instant checkout inside ChatGPT — standardises where and how a transaction happens when the buyer is inside an agent surface: the product feed the merchant exposes, the checkout API the agent calls, and the handoff that keeps the merchant as merchant-of-record with their existing payment service provider processing the payment. Its centre of gravity is conversational commerce: a user chats with an assistant, products appear, and the purchase completes without leaving the conversation. AP2's centre of gravity is authorization proof: the signed mandate chain establishing that a user genuinely delegated or approved a specific purchase, regardless of which surface or checkout pipe executed it — which becomes decisive as flows shift from human-present (the human is right there tapping approve) to fully delegated (the agent acts alone within granted bounds). In practice: ACP-style integration is how a merchant becomes purchasable inside chat assistants today, and AP2-style mandate verification is how everyone gains cryptographic cover as autonomy increases. The protocols are being designed to interoperate rather than as rivals.

Q: What do merchants need to change to accept AI agent purchases?

Four concrete workstreams. First, machine-readable product data: agents do not browse hero banners — they parse structured catalogs, so accurate feeds of products, prices, availability, and policies (returns, shipping) become the storefront; if it only exists in rendered HTML and marketing copy, agents will misread it or skip you. Second, an agent-facing checkout path: an ACP-style API surface alongside the human checkout, with strict idempotency — agents retry at machine speed, and a non-idempotent purchase endpoint will double-sell under perfectly normal agent behaviour. Third, inverted fraud logic: today's stacks are built to detect and block non-human traffic, which now means blocking revenue; the discriminating question becomes "is this agent carrying valid authorization from its human" — verifying AP2-class mandates and agent identity instead of fingerprinting humanity. Fourth, hardened payment plumbing: signed, retried, idempotent webhooks and saga-style orchestration so a mid-purchase failure never strands or double-charges an autonomous buyer that will not notice the way a human would. Merchants who do the first two become visible and purchasable to the agent economy; the second two keep that new channel from becoming an operational and dispute nightmare.

Q: How do you stop an AI agent from overspending or being tricked into bad purchases?

Defense stacks in four layers, none optional. First, scoped credentials: the agent never holds a raw stored card; it holds a purpose-bound payment credential with hard ceilings — per-transaction limit, cumulative budget, category and merchant restrictions, expiry — so even total agent compromise is bounded (the same discipline as any non-human workload identity). Second, mandate-bound authorization: AP2-style intent mandates encode the user's actual instruction and its limits cryptographically, so a purchase outside those bounds fails verification at the rail rather than relying on the agent's good behaviour. Third, escalation thresholds: below a configured amount the agent acts autonomously, above it the human must approve — "spend up to $50 on this task, ask me beyond that" is the shape that works. Fourth, injection-aware design: the classic attack is a prompt-injected agent steered toward an attacker's storefront or manipulated listing — the confused-deputy problem with a payment method attached — countered by allowlisted or reputation-scored merchants, treating all retrieved content as untrusted input, and never letting page content rewrite the agent's purchase policy. Wrap it all in complete audit logging of every decision from instruction to settlement, because when a dispute arrives, that chain is what assigns liability.

Q: Is agentic commerce actually live in 2026 or still hype?

The honest split: human-present agentic commerce is live and scaling; fully delegated purchasing is real but early, arriving category by category. Live today — buy-in-chat experiences inside major AI assistants with merchants integrated through ACP-lineage checkout, agent-assisted shopping across large retail platforms, and the protocol infrastructure itself: AP2 published with its 60+ partner coalition and reference implementations, x402 running with real integrations for machine-to-machine payments. What remains early is unattended autonomy at scale: mandate verification is still rolling out across issuers and networks, liability frameworks for delegated purchases are being worked through, and consumer trust sensibly starts with low-stakes, bounded delegations (subscriptions, restocks, price-triggered buys) before expanding. The strategic signals, though, are not hype: checkout is migrating to wherever the agent conversation happens, product discovery is becoming an answer-engine problem rather than a search-ranking one, and per-call agent payments are creating a machine-speed micro-economy for APIs and services. For merchants the practical read is that Stage-1 readiness — machine-readable catalog, idempotent checkout API, measuring rather than blocking agent traffic — pays off on today's human-present volume while positioning for the delegated wave.

Q: What does agentic commerce mean for payment and platform architects?

It adds a genuinely new set of load-bearing requirements to systems that were already hard. Identity and authorization: every purchase now involves three parties — human principal, agent, merchant — so architectures need agent identity (scoped, rotatable credentials distinct from user credentials), delegation records (mandates or equivalents) as first-class stored objects, and authorization checks that validate the chain rather than just the session. Idempotency and orchestration everywhere: machine buyers retry, parallelise, and never get bored, so purchase APIs need idempotency keys, payment orchestration needs saga-style compensation for partial failures, and webhooks need signatures, retries, and dead-letter queues as table stakes. Auditability as a product feature: the intent-to-settlement evidence chain is what resolves disputes and assigns liability, so event logging moves from ops nicety to compliance asset — append-only, queryable, retained. Fraud rearchitected: signals shift from human-behaviour biometrics to mandate validity, agent reputation, and delegation-scope anomalies. And a new economics layer: if x402-style per-call payments fit your API business, metering, pricing, and settlement become part of the request path itself. Teams with strong payment-resilience foundations — idempotency, sagas, webhook discipline — are most of the way there; the genuinely new work is mandates, agent identity, and the inverted fraud model.