Agentic commerce protocols compared: AP2, ACP, x402 and UCP

Four protocols are routinely listed together as "agentic commerce standards", which makes them sound like competing versions of one thing. They are not. They occupy different layers of a transaction and are backed by different coalitions. Sorting them by layer is most of what you need to decide whether one concerns you.

AP2: authorisation, not settlement

AP2 names five roles and assigns each verification duties. The merchant verifies a checkout mandate against the checkout it built; the provider and processor verify a payment mandate bound to it by hash; a Trusted Surface, which must be non-agentic, obtains the user's signature. In the human-present mode the user signs the finalised checkout. In the human-not-present mode the user signs an open mandate carrying constraints and the agent signs the closed mandate under it — the sequence that makes autonomous purchase defensible rather than merely convenient.

AP2's specification calls AP2 "a security feature within a Commerce Protocol" and puts commerce APIs out of scope, so the implementer's work is verification: signatures, hashes, constraint evaluation, signed receipts. If you want cryptographic evidence that an agent was authorised to spend a specific amount on a specific cart, that is the problem AP2 solves. It is not a way to start taking payments.

State and governance. AP2 was announced by Google in September 2025 — the date is stated on AP2's own documentation, which links the announcement — and the specification is published at v0.2. Its documentation states that standardisation continues in the FIDO Alliance's Agentic Authentication and Payments technical working groups. A version number exists; a ratified standard does not.

ACP: a checkout protocol

ACP is a Stripe and OpenAI specification published under Apache 2.0, and it is the narrowest of the four in scope and the most concrete. An agent calls a seller's endpoints to create a checkout session, apply buyer selections and complete the purchase. The agent renders the checkout UI, and the seller keeps its existing back end and payment processing. ACP's documentation states the goal as "a common set of interfaces (think MCP) for how agents can conduct a checkout and how they can securely relay credentials", claiming two benefits: a deterministic purchase instead of an agent traversing a site, and secure credential relay between seller and PSP.

Capability negotiation and extensions are part of the specification, a sign of a protocol still finding its edges. Discovery is unresolved on the agent side: ACP's own FAQ says work on discovery mechanisms is ongoing, and that a business wanting to participate in ChatGPT applies to OpenAI. The protocol is open; the route to agent traffic is not. Stripe is the first compatible PSP, via its Shared Payment Token, documented in Stripe's agentic commerce documentation, and OpenAI is the first platform implementation.

x402: payments inside HTTP

x402 revives HTTP's 402 Payment Required status, reserved and unused since the protocol was written. A server that wants payment answers with 402 and the terms; the client pays and retries with proof of payment. x402's documentation describes the seller integration as middleware requiring payment per request, and the buyer flow as receiving the 402, paying and retrying. Settlement is on-chain, with stablecoins as the primary use case and Base and Solana named among supported networks.

It fits one job: charging per request for an API call, a data fetch or a piece of content, where card rails are uneconomic and account creation is friction. It is the least about commerce in the retail sense — no cart, no order, no merchant of record. If your product is a dataset, x402 is plausible this quarter; if it is a physical good, x402 solves the smallest part of the problem. x402 is a Linux Foundation project with its own foundation and member list. Its FAQ states the protocol is production-ready and audited, a self-reported claim this article cannot independently verify.

UCP: a commerce protocol with a manifest

UCP is the broadest of the four and is not primarily a payment mechanism. It carries the commerce lifecycle — catalog search, cart, identity linking, checkout, order management — across REST, MCP and A2A transports, with capability negotiation and namespaced extensions. Its specification overview describes namespace governance, versioning rules, a negotiation algorithm and a payment architecture, which is the shape of a standard rather than an API. A merchant publishes a discovery document declaring what it supports, the platform intersects that with its own, and both proceed on the intersection.

Its relationship with AP2 is explicit. UCP's AP2 documentation calls AP2 the trust layer for agent-led transactions: the business declares AP2 support in its discovery document, the checkout session activates the extension, the business returns a signed checkout state, the platform produces checkout and payment mandates, and the business and processor verify them at completion. UCP carries the commerce, AP2 carries the authorisation, and neither is a rail.

UCP's site lists Google, Shopify, Etsy, Wayfair, Target, Walmart, Amazon, Microsoft, Meta, Salesforce and Stripe among co-developers, with lodging and food verticals in draft. That breadth is the strongest signal here and the thing to be careful about: co-developers publishing a specification is not a ratified standard, and the roadmap and announcements pages are where the current state lives. This article will not assert a version number.

The honest state of the market

Agent-initiated transactions are a small fraction of commerce, and you would not know it from the announcements. The arithmetic is instructive. x402's site reported, on a rolling thirty-day basis at the time of writing, roughly 75 million transactions against roughly $24 million in volume — about a third of a dollar per transaction. Those figures move continuously and come from a project dashboard; quote them as a shape, not a measurement.

The shape is the point. A high transaction count with a low average value is what you would expect from a protocol used mainly to meter machine-to-machine data access, and it is the pattern that lets a headline number imply a boom the settlement value does not support. When you read a transaction count here, ask three questions: who is counting, what counts as one transaction, and what was the total settled value. A count without the third number is not evidence of a market. The same holds for retail: agentic checkout through a major platform's agent exists, but "agents can buy" and "agents are buying, at volume" are different claims, and the second is not one this article can support with a verifiable source.

Why the data layer decides, not the checkout layer

An agent that cannot read your price, your availability and your returns terms cannot transact, whichever protocol you support. Checkout is the last step; data is the first, and data is where sites fail.

Price. A number rendered for a human to read, with no machine-readable declaration, is not a price an agent can quote. Variants, currency and tax treatment must resolve to something determinate: product and catalog schema. Availability. "In stock" that was true when a page was cached is worse than no signal, because an agent will act on it: inventory freshness. Shipping. A cost that appears only after a postcode is entered, or a table rendered as an image, cannot be evaluated by an agent comparing two merchants: shipping cost declaration. Returns. A thirty-day return window is a machine-readable fact or it is nothing, and it belongs inside structured product and offer data rather than on a policy page: return and shipping terms is a schema question. And whether you accept agent purchases at all is a policy decision with liability attached, upstream of every protocol: agent purchase policy.

A site that publishes clean product data, fresh availability and explicit return terms is legible to an agent today, with no protocol implementation, because agents already read structured data. A site that supports a checkout protocol but publishes ambiguous price data has built a rail to a station nobody can find. For the transaction layer measured directly, agent payment standard support is the check, and the UCP manifest looks for the discovery document that declares it.

What to implement, and when to implement nothing

The order of operations is not the order of the announcements. Fix reachability, then data, then the protocol layer. An agent that cannot fetch your pages, or that cannot determine price, availability or returns from them, is unaffected by which protocol you support. Confirm first that legitimate agents are not blocked, since a network-layer block refuses the exact traffic these protocols exist to carry, and the failure is silent. Then ask which protocol, if any, maps onto something you already do.

The difference between these is not the quality of the specification. x402 maps onto a unit of work you already price. ACP is concrete but buys you an endpoint and no traffic without a platform arrangement. UCP is the broadest and least settled. AP2 is a verification workload, and a verification path you have not tested against a hostile input is a liability rather than a feature.

The honest "none yet" applies more often than the vendor material suggests. If your catalogue is not machine-readable, if you have not decided whether you accept agent purchases at all, if nobody has asked you for an agent checkout, or if your only agent traffic is price comparison you neither want nor have blocked, then a protocol is not your next step. Publishing product data, stating a purchase policy, and making your robots.txt and Content Signals choices explicit is. Those are cheap, reversible, and the preconditions every protocol above assumes. It is also the position the methodology takes: a capability you cannot demonstrate is a claim, and claims are not evidence.