What the agentic-commerce protocols mean if you sell

Short answer: the agentic-commerce protocols are all written from the buyer's side, and each one settles a different layer — ACP (OpenAI with Stripe) the shape of a purchase completed inside an assistant, UCP (Google, with commerce platforms) how products and carts are represented across AI surfaces, AP2 (Google, with a broad payments coalition) the cryptographic proof that a human actually authorized a purchase, and x402 (originating at Coinbase) machine-to-machine payment over plain HTTP. If you are a small or mid-sized seller, none of them is an action item this quarter. What is an action item is the thing all four assume: a catalog that is readable as data, prices the server decides rather than the browser, a checkout that completes without a human hand, an address that answers, and order state durable enough to be looked up next week. Get those right and you are reachable by every buyer-side agent that exists, whichever standard wins. That is also, more or less, the design brief behind Agent Storefront — Clize is a CLI and MCP server that gives AI coding agents real-world actions: domains, email, deploys, payments, and media generation.

The four, at a glance

ACP — the purchase moves into the chat

The Agentic Commerce Protocol, published by OpenAI with Stripe, describes how an assistant can complete a purchase without handing the user off to your website. You supply product data and an endpoint the assistant can drive; the payment is authorized through a delegated credential rather than a card number typed into your form. As published, the merchant stays the seller of record and keeps the customer relationship — which is the concession that makes the whole thing acceptable to retailers at all. Practically, this is the one that has actually shipped to consumers, as checkout inside ChatGPT.

The merchant-side reading: it is a distribution channel, not an infrastructure change. Being in it is a listing question — whether your catalog is where the assistant is looking — far more than a protocol-support question.

UCP — the catalog as a first-class object

Google's Universal Commerce Protocol works one layer down from the transaction: a common way to represent products, carts and orders so that any AI surface can read a store consistently instead of scraping it. What it asks of a seller is unglamorous and familiar to anyone who has kept a shopping feed alive — structured product data that is actually current, including price and availability. The AI-era wrinkle is that stale data is now worse than missing data: an agent that quotes a price you no longer honor has made a promise on your behalf.

AP2 — who said this agent could spend?

The Agent Payments Protocol, led by Google with a wide coalition of payment networks, issuers and processors, addresses the question the other two skip: when software presents a payment, how does anyone downstream know a specific human approved this specific purchase? Its answer is signed mandates — verifiable credentials that travel with the transaction and can be checked afterwards, so a legitimate delegated purchase is distinguishable from a compromised agent, and disputes have something to point at.

The merchant-side reading: this is the layer that will eventually decide who eats the chargeback when an agent buys the wrong thing. You will most likely receive it through your processor rather than implement it — but it is worth knowing that the answer to who authorized this is being standardized, because today it is a shrug.

x402 — paying for a request, not for a cart

x402 takes the HTTP 402 Payment Required status code, unused for three decades, and makes it work: a client hits a paid endpoint, gets back a price and a way to pay it, settles in stablecoins and retries the request. It came out of Coinbase and is aimed squarely at machines paying machines — an agent buying an API call, a dataset, a unit of compute. If you sell physical goods to humans, this is not your checkout. If what you sell is something an agent consumes directly, it is the item on this page most likely to matter to you first.

What all four assume about your store

Read together, the specifications agree on a short list, and none of it is exotic. Your catalog must be data, not just a rendered page. The price must be settled by your server — an agent-driven cart is trivially scriptable, and any store where the browser decides the total is a store waiting to be bought out at the wrong number. Checkout must complete without a human hand in the middle. Somebody must answer when the buyer, or the buyer's agent, asks where the order is. And order state must outlive the session, because the thing that placed the order will not remember it.

That list is worth more than a protocol decision right now, because it is the intersection of all four — and because every item on it is also just good practice for human buyers.

What to actually do this quarter

If you are a large retailer, the question is which shopping surfaces to be listed in, and your platform will carry most of the protocol weight. If you are everyone else, adopt none of them yet and do the five things above instead. The agent traffic that already exists for a small store does not arrive over a new protocol — it arrives over a browser, driven by software, and it fails on the same things human buyers fail on: a price the page will not show, a cart that needs a hover, a support address nobody reads, an order nobody can look up.

Then keep watching, and let the standards fight it out. Discovery, authorization and settlement are being standardized separately and on different clocks, which means a store that bets early on one layer can end up rebuilding it. A store that just stays legible does not.

Where Clize fits, briefly

Our entry, so judge accordingly. A Clize storefront is deliberately an ordinary web store: a static site your agent writes, a catalog as JSON at a stable path, prices re-read server-side at checkout, a Stripe checkout, an /orders lookup page, a support inbox on the same domain, and an order record that moves through paid → sourced → shipped → delivered whether or not anyone is watching. None of that is protocol-specific, which is the point while the protocols are moving. The difference is who operates it: the same coding agent that wrote the site can also work the orders. The full loop, with commands, is in sell with an AI agent; the buyer-facing conversation side is Agent Inbox.

How this page is maintained

This is a standing page, not a news post. It is reviewed when something material moves — a specification published, a surface opening to merchants, a payment network committing — and the review date sits at the top so you can tell how fresh it is. Anything version-specific has been left out on purpose: the layers each protocol settles have been stable, the details have not.

$ npm i -g @clize/clize
$ clize login
$ clize claim mystore --email
$ clize shop init