Agentic Commerce & Agent Payments

Agentic commerce, defined: how value moves on the agentic web

Agentic commerce is the part of the agentic web where an AI agent buys, sells, or pays on a user's behalf — discovering a price, getting authorized to spend, settling over a machine-native payment rail, and returning a receipt — without a human filling in a checkout form. An agent payment is any value transfer an agent completes on-behalf-of a human: a per-request micropayment for an API call, a stablecoin settlement for data, or a card-rail purchase for a physical good.

This pillar explains the concept, the four-step flow, and the rails — and links each rail to its full spec rather than re-defining it. The distinction it draws is simple: e-commerce serves a human at a browser, filling a form; conversational commerce serves a human in a chat, talking to a brand; agentic commerce serves an agent acting for a human, which is why it needs new machine-native rails and a measurable agent-as-buyer success metric instead of a clickthrough funnel. Every agent payment, whichever rail it rides, follows the same four-step flow.

Agent payment flow: discovery, authorization, settlement, receipt

Every agent payment follows four steps: the agent discovers the price and the accepted rail, a mandate authorizes what it may spend, the rail settles the money, and a receipt returns a verifiable record to both the agent and the human. Each step has a concrete mechanism and an owning rail or standard.

Discovery: the agent finds the price and the accepted rail

The merchant advertises the price and the accepted rail in a machine-readable form. An HTTP 402 Payment Required response can carry the x402 payment terms inline; a structured product feed can expose the price to the agent before it ever commits. x402 is the HTTP-402-native option here (verify against the primary x402.org / Coinbase x402 spec at build).

Authorization: a mandate scopes what the agent may spend

A payment mandate cryptographically scopes the spend — amount, merchant, expiry — so the agent cannot exceed the user's intent. This is AP2's contribution, carried over A2A and MCP (verify against the primary AP2 spec at build); the mandate itself is AP2's identity facet that scopes what an agent may spend.

Settlement: the rail moves the money

The rail moves value according to its settlement_type: stablecoin or on-chain for x402, a card rail for ACP and Visa TAP. The pillar carries only the commerce-framed settlement attribute; the full settlement record lives in each rail's Atlas spec.

Receipt: the agent and the human get a verifiable record

A verifiable record — a transaction hash or a signed receipt — closes the loop so the purchase can be audited and disputed. The receipt is what turns an autonomous purchase into an accountable one.

Payment rails move money between agents on the agentic web

The agentic web settles agent payments over a handful of rails: x402 (HTTP-native, stablecoin settlement), AP2 (payment mandates over A2A and MCP), ACP (OpenAI and Stripe's Agentic Commerce Protocol, reported live in ChatGPT Instant Checkout), plus UCP, MPP, Kite and Visa TAP — and every rail here is specified in the Payments & Settlement layer of the Protocol Atlas. Each rail below gives its commerce role in one sentence and links to its spec for the full settlement record.

x402 settles HTTP-native payments at the 402 status code

x402 settles HTTP-native agent payments (full spec) at the 402 Payment Required status code, with a settlement type of stablecoin / on-chain. It is also defined in the Lexicon: x402 is the HTTP-native agent payment protocol (DefinedTerm). Adoption figures sometimes quoted for x402 (such as a large transaction count) are not asserted here as bare fact — any number must cite its primary source at build.

AP2 adds payment mandates over A2A and MCP

AP2 extends x402 with payment mandates (spec): it adds cryptographic mandates over A2A and MCP so an agent's spend is scoped and verifiable. AP2 extends x402 rather than replacing it — it proves the authorization, x402 moves the value.

ACP powers checkout inside ChatGPT (OpenAI + Stripe)

ACP (the Agentic Commerce Protocol, from OpenAI and Stripe) is reported live in ChatGPT Instant Checkout, letting a merchant accept an agent-driven purchase over a card rail (verify the "live in ChatGPT Instant Checkout" claim and any date against the primary OpenAI / Stripe announcement at build). It is the rail that completes a retail purchase from inside a chat.

UCP, MPP, Kite and Visa TAP: the rest of the rail landscape

The rest of the landscape is emerging and must be verified against its primary spec at build: UCP (a broader commerce/checkout interoperability layer — name expansion and owner verify against primary), MPP (machine/merchant payment plumbing, associated with Stripe + Tempo in research — verify), Kite (an agent-payment network), and Visa TAP (Visa's Trusted Agent Protocol, a card-network agent rail). None of these maturity values are settled from an internal file.

Rail comparison: which agent payment rail to accept when

Choose an agent payment rail by settlement type and use case: accept x402 for HTTP-native, per-request or stablecoin micropayments; accept ACP (via ChatGPT Instant Checkout) to sell physical/retail goods to agents on a card rail today; layer AP2 mandates when an agent must prove scoped authorization; and treat UCP, MPP, Kite and Visa TAP as emerging options to watch. Every Rail and Spec cell links to the rail's spec in the Atlas.

Maturity values for rails not in the internal research file are marked "verify against primary at build". last_verified: 2026-06-15.

Agent checkout flows complete the purchase on the agentic web

An agent checkout flow lets an AI agent complete a purchase end-to-end — ChatGPT Instant Checkout, built on the ACP rail, lets a user buy from a participating merchant without leaving the chat — and the metric that grades such a flow is the Agent Success Rate (ASR): the share of agent-attempted checkouts that complete.

ChatGPT Instant Checkout: an agent buys without leaving the chat

Inside ChatGPT, an agent discovers a product, authorizes the spend, and settles via ACP — without the user visiting the merchant's site. The buyers in this flow are the same AI agents catalogued among the AI crawlers and agents that traverse the web (for example ChatGPT-User). Verify the "live in ChatGPT Instant Checkout" claim and merchant scope against the primary OpenAI source at build.

Agent Success Rate (ASR): the metric that measures an agent-ready checkout

ASR is the conversion metric for agentic commerce: the fraction of agent-initiated checkouts that complete successfully. A low ASR signals a store that is visible to agents but not transactable by them — a missing structured price, a blocked checkout, no accepted rail. No benchmark number is attached here; any figure must cite a primary source at build. ASR is the commerce analogue of the agent-readiness score: to raise it, make your store accept agent payments (commerce readiness).

Agentic commerce maturity signals which rails are production-ready

Production-ready agentic-commerce rails today are reported to include x402 (settling HTTP-native payments) and ACP (live in ChatGPT Instant Checkout); AP2 is rolling out as the mandate layer, while UCP, MPP, Kite and Visa TAP are emerging and must be verified against their primary specs. The sourcing rule for this section is strict: every maturity claim, launch date, "live in" claim, and any adoption figure must be filled in at build from its primary spec or source URL — never from an internal research doc — and each row carries its last_verified date (here 2026-06-15). Adoption of each rail is measured over time in the State of the Agentic Web report.

Agent payment demo: a SIMULATED x402 checkout on this site

This site ships a SIMULATED x402 checkout so an agent can walk the full discovery → authorization → settlement → receipt flow against a real 402 Payment Required response — but it is clearly a DEMO and moves no real money. The demo returns a 402 with x402-style payment terms, accepts a simulated payment header, and returns a simulated receipt: no funds are transferred, no wallet is charged, and the settlement is mocked. This is the self-demonstration that distinguishes the Almanac — it implements what it documents — while staying truthful: a reference site is not a live payment processor.

Agent payments start with a rail and end with a commerce-ready store

You now understand what agentic commerce is, how an agent pays, and which rail to accept — but does your own store actually let an agent discover a price, authorize, and check out, and can you prove it? Each rail above maps to one concrete change in your store — a structured price, an accepted rail, an unblocked agent checkout — and the commerce dimension of the Agent-Readiness Audit checks whether you made it. That question cannot be answered with more commerce facts; it is answered by crossing into the engineer → audit → monetize context.

To accept these rails, follow the commerce dimension of Agent-Readiness Engineering and make your store accept agent payments (commerce readiness); then audit whether your store is transactable by agents, certify, and get listed. Agent payments are one layer of the wider Protocol Atlas of agentic-web standards; an agent's buying decisions run on the tool-calling frontier models that drive purchases; the agent-as-buyer concept and related agent payment terms are defined in the Lexicon. A machine-readable price is an agent-readiness signal your content should expose, and answer-first product data gets you cited and chosen by buying agents (GEO). This commerce pillar is one of the datasets the agentic web home indexes — verify the live SIMULATED demo there.