The Agentic Commerce Stack in 2026: UCP, ACP, AP2 and x402, Measured on 30 Storefronts

Five protocol names now compete for the same sentence in every agentic commerce explainer: UCP, ACP, AP2, x402 and MPP. Almost every explainer treats them as rivals. They are not. Four of the five are layers of one stack, and on 8 September 2026 we probed 30 live storefronts and queried 494 scanned sites to find out which of those layers a real shop is actually running.

The short answer: one of the five is already deployed at scale and nobody told the merchants, one is a checkout integration you apply for, one is a trust layer neither side ships yet, and one is moving real money on a surface that has nothing to do with shopping.

Quick summary

The measurement that reframes the argument: across 181 commerce sites in our own scan corpus, the x402 check (M3) has now passed on zero for a fourth consecutive week, while the UCP check (M1) passes on 27 of 181. x402 is not unadopted. It is being measured on the wrong surface.

Five names, one stack, and only two of them overlap

The fastest way to stop confusing these is to ask what question each one answers.

UCP states the relationship in its own words. It is "built on industry standards", and the standards it names are REST and JSON-RPC transports plus built-in support for AP2, Agent2Agent and the Model Context Protocol, "so different systems can work together without custom integration." AP2's specification returns the compliment: "AP2 is designed explicitly to be compatible with the Universal Commerce Protocol (UCP)."

So UCP and AP2 are not competitors. AP2 describes itself as operating "as a security feature within a Commerce Protocol," and says the details of that commerce protocol are outside its own scope. The only genuine rivalry in the group is UCP versus ACP, and even that is softer than the coverage suggests, because they are aimed at different buyers: UCP at any platform that wants to discover a business, ACP at merchants who want to sell inside ChatGPT.

What we probed, and what counts as adoption

Two independent measurements, both dated 8 September 2026, both reproducible with curl.

The storefront probe. 30 well-known consumer stores, four requests each: GET /.well-known/ucp, GET /.well-known/x402, GET /.well-known/mpp, and POST /api/mcp with a JSON-RPC tools/list body. Every request went out with an ordinary desktop Chrome user agent from a datacentre address.

The refusal rate matters and it is published here rather than buried. Of the 30 hosts, 3 refused the connection outright, 2 returned 403, 1 returned 429, 1 returned 404 at the origin and 1 returned a 301 we did not follow. That leaves 22 hosts that answered every probe with a real body. A datacentre address gets refused by retail hosts at a measurable rate, and any sweep that does not say so is overstating its own denominator.

Adoption means a parsing body, not a status code. A response counted only if it returned HTTP 200 and the body parsed as JSON and the JSON carried the protocol's own required keys. That rule matters more than it sounds, and the next section shows why.

The corpus query. Separately, 494 sites from our own production scan database, filtered to rubric version 2026.08.2 and site scope, deduplicated to one latest scan per host, with aiscan.site excluded. 181 of those carry the commerce checks. This is the same population definition published in our 2026 readiness study, reused verbatim so the numbers stay comparable.

UCP is already on your storefront and nobody sent you an email

21 of 30 probed stores serve a valid UCP profile at /.well-known/ucp. Every one of them declares protocol version 2026-08-25. Every one declares the identical set of eight capabilities and three payment handlers.

The specification is unambiguous about where that file lives. According to UCP's core concepts page, capabilities "are declared in the Business's UCP profile at /.well-known/ucp, negotiated by exact version, and confirmed in every response so that the Platform always knows the active feature set for a given interaction."

Here is what a real profile contains, fetched from a live storefront on 8 September 2026:

Two details in that table are worth a merchant's attention. The payment_handlers block carries a Google Pay merchant ID and gateway merchant ID in plain JSON, which is the same information a Google Pay button already exposes in the page, but it is now sitting in a machine-readable file that any agent can read without rendering anything. And the profile advertises checkout, not just search, so the declared surface includes buying rather than browsing.

The live MCP endpoint tells the same story from the other direction. Of the 30 stores, 19 returned a parseable tools/list response. 10 of those 19 returned a five-tool set covering search_catalog, get_product_details, get_cart, update_cart and search_shop_policies_and_faqs. The other 9 returned exactly one tool, the shop-policies lookup.

And 10 of 19 carry UCP identifiers inside the tool schema itself. The search_catalog description ends with a sentence that names the capability by its reverse-domain identifier, verified on ten separate storefronts: "Response conforms to the UCP catalog search capability (dev.ucp.shopping.catalog.search)."

The input schema goes further. It defines a signals object described as "Environment data provided by the platform for authorization and abuse prevention," containing dev.ucp.buyer_ip ("Buyer IP address (IPv4 or IPv6)") and dev.ucp.user_agent ("HTTP User-Agent header value"). A separate meta block is labelled "MCP transport metadata for UCP agent discovery" and asks the agent for a profile URI.

Read that plainly: the protocol expects the shopping agent to forward the human buyer's IP address and user agent to the merchant. That is a reasonable anti-fraud design and it is also a privacy decision nobody consulted the store owner about.

One caution that has now been observed three times. The tool set is not stable per store. One store returned five tools on 2 September, one tool on 4 September, and one tool again on 8 September. Any claim of the form "N% of stores expose write tools" needs at least two probes hours apart and should be reported as a range. The store-level denominator is a separate study; this one measures the protocol layer.

The governance is moving faster than the storefront numbers suggest. UCP publishes dated releases rather than semantic versions, and its announcements page records three in quick succession: protocol release v2026-08-25 on 25 August 2026, adding structural refactoring for multi-vertical expansion, 3DS2 payment security, structured request constraints and independent capability versioning; a Lodging Technical Council formed on 11 August 2026 with Amadeus, Booking.com, Expedia, Google, Hilton, Marriott and Trip.com; and a Food Technical Council formed on 16 July 2026 with Block (Square), DoorDash, Google, Toast and Uber Eats. The named co-developers on the protocol's front page include Google, Shopify, Etsy, Wayfair, Target, Walmart, Amazon, Microsoft, Meta, Salesforce and Stripe. That is a wide enough coalition that a merchant deciding whether to care should assume the vocabulary is durable even if today's storefront defaults change.

ACP is a partnership, not a file you can probe

The Agentic Commerce Protocol describes itself as "an open standard for programmatic commerce flows between buyers, AI agents, and businesses," released under Apache 2.0. According to OpenAI's own key-concepts guide, supporting Instant Checkout requires a merchant to implement three flows: sharing a product feed, handling orders and checkout through the Agentic Checkout Spec, and handling payments through the Delegated Payment Spec.

The split is clean and worth stating precisely, because most coverage gets it backwards. In OpenAI's words, "the checkout session is rendered in the OpenAI UI, but the actual checkout state and payment processing occurs on the merchant's systems." The merchant validates, calculates tax, runs risk, charges through their existing processor, and accepts or declines. ChatGPT renders the result.

Payment moves by a one-time delegated token with a maximum chargeable amount and an expiry. OpenAI names Stripe's Shared Payment Token as "the first Delegated Payment Spec-compatible implementation, with more PSPs coming soon."

Why ACP does not appear in our storefront numbers: there is nothing to probe. ACP adoption starts with sending a sample feed for validation and daily snapshots, which is a business relationship rather than a discovery document. Cloudflare's free scanner probes /.well-known/acp.json for it, and that path returned nothing on any site we scanned, including a payments company. Absence of that file is not evidence of anything, and any scanner reporting an ACP failure on it, ours included in spirit, is reporting on a convention the specification does not require.

AP2 is the layer both stacks point at, and neither ships yet

AP2 is at v0.2 and describes five roles: Shopping Agent, Credential Provider, Merchant, Merchant Payment Processor and Trusted Surface. Its central objects are a Checkout Mandate and a linked Payment Mandate, which exist so that a dispute months later can be settled against cryptographic evidence rather than a chat transcript.

The protocol's own framing of the problem is the clearest paragraph anyone has written on this subject. Today's payment systems "assume a human is directly clicking 'buy' on a trusted website," and an autonomous agent breaks that assumption, leaving three questions unanswered: authorisation, authenticity and accountability.

UCP's integration guide sets out the seven-step flow: the business declares AP2 support in its discovery document, the platform activates it on a checkout session, the business returns a detached JWT signing the checkout state, the platform generates a CheckoutMandate and a PaymentMandate on user consent, and the business and payment processor verify one each.

Here is the gap. Not one of the 21 live UCP profiles we read declared an AP2 payment handler. All 21 declared the same three conventional handlers. The trust layer that both commerce protocols name as their answer to agent fraud is documented, versioned, donated to a standards body, and absent from every production storefront we could read.

AP2 is also explicitly neutral about how money actually moves. Asked in its own FAQ whether it works with x402, the answer is that "we designed AP2 to be a payment-agnostic protocol, so that agentic commerce can securely take place across all types of payment systems."

x402 is not unadopted. It is being measured on the wrong surface

Our M3 check looks for an x402 signal on commerce sites. Across 181 commerce sites it has returned zero passes for a fourth consecutive week. Read alone, that number says x402 has no adoption. The number is correct and the reading is wrong.

x402 describes itself as "an open, neutral standard for internet-native payments." Its own site reports 75.41M transactions, $24.24M volume, 94.06K buyers and 22K sellers over a trailing 30-day window. Treat that figure carefully: the identical four numbers were on the page on 6 September and again on 8 September, so it is a published snapshot in the served HTML rather than a live counter, and it covers all x402 traffic rather than any commerce category.

What is verifiable in one command is where the live deployments sit. Both re-checked on 8 September 2026:

Neither is a shop. One is a publisher network charging crawlers per page, the other is a developer tool selling scans to machines. The commercial detail worth keeping: Cloudflare's own AI Crawl Control documentation set never uses the word x402 anywhere, while emitting a valid x402 payload in production. We published the full mechanics in our Pay Per Crawl analysis, and this measurement extends it rather than restating it.

MPP sits in the same category. Agent Ready publishes /.well-known/mpp as an OpenAPI 3.1.0 document whose x-payment-info block declares both x402 and MPP for the same endpoint. Zero storefronts published one.

The scoreboard

Everything measured, in one place. Storefront column is 30 probed hosts on 8 September 2026; corpus column is our 494-site population, 181 of which carry commerce checks.

138 of 181 commerce sites (76.2%) pass none of M1, M3 or M4. Add the MCP server card and 134 of 181 (74.0%) pass none of the four. The protocol conversation is loud and the deployment is concentrated in one platform's default configuration.

Where AIScan fits, and where it doesn't

Run one command and read four rows:

npx aiscan-cli yourstore.com

Or paste the URL at aiscan.site with no account and no card. The rows that matter for this article are M1 (Universal Commerce Protocol), M3 (x402 Payment Required signal), M4 (machine-readable pricing) and P2 (MCP Server Card), and you should read E1 (correct 404 handling) first, because a site that answers 200 for everything makes all four of the others meaningless.

If you would rather check by hand, three commands cover the same ground:

curl -s https://yourstore.com/.well-known/ucp | head -c 400
curl -s -X POST https://yourstore.com/api/mcp \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'
curl -s -o /dev/null -w '%{http_code} %{size_download}\n' \
  https://yourstore.com/aiscan-probe-does-not-exist

The third command is the control. If it returns 200 with a large body, your host answers 200 for paths that do not exist and every well-known probe above is worthless.

What our scanner cannot see, stated plainly. AIScan grades none of the following: whether your MCP endpoint answers, which tools it exposes, whether an AP2 handler is declared, whether ACP is configured, or what any of these endpoints return to a crawler identity rather than to us. Four of those are checks that do not exist yet. The fifth is a known limitation we have already published.

Two scanner bugs this study found, and one of them is ours

The honest-scanner position means printing our own defects next to everyone else's.

Ours: M1 decides on a status code. Its complete evidence string on a passing site is the literal text HTTP 200, and on a failing site HTTP 404. There is no assertion that the body parses, and none that it carries a ucp.version field. That is the same failure family as the Markdown-negotiation check we published in the WebMCP study, and it has a live victim. One retail host in this sweep returned HTTP 200 with 179,935 bytes of HTML on all three of /.well-known/x402, /.well-known/mpp and /.well-known/mcp/server-card.json. A status-code-only check would record three adopted protocols on a store that has adopted none. The fix is one line: require the body to parse and to carry the protocol's own required key.

Cloudflare's: its UCP check passes on a version field alone. Scanning a storefront that publishes a complete profile, the free scanner returned ucp: pass with hasVersion: true, hasServices: false, hasCapabilities: false. We fetched the identical URL by hand on the same day and the document carries both services and capabilities populated. The verdict is right and the evidence is wrong, which is the harder kind of bug to notice.

And a third, smaller one, also ours. Our platform detector identified one of these Shopify storefronts as shopify with 99% confidence and returned unknown at 0% confidence for another, despite both serving the same Shopify-generated UCP profile from the same infrastructure.

What a merchant should actually do this week

The realistic answer for most stores is: read your own profile, then fix the layer nobody generated for you.

If you sell on Shopify. The UCP profile, the MCP endpoint and the catalog tools were switched on for you. What was not switched on is everything an agent reads before it reaches a commerce protocol: llms.txt, agents.md, product and offer schema, and the AEO and GEO signals that decide whether an assistant surfaces your store at all. StoreSEO is the direct fit here, because it generates llms.txt from your products, collections, pages and articles, has an agents.md editor, and ships an MCP server, which is exactly the half of the stack Shopify's own rollout does not touch. It is rated 5.0 from 739 reviews on the Shopify App Store as of 8 September 2026, with a free plan. Alternatives are real: Yoast SEO for Shopify and Avada SEO both handle schema and metadata well, and neither currently generates llms.txt or agents.md. Our platform notes for stores are on the Shopify guide and in our Shopify setup walkthrough.

If you sell on WordPress or WooCommerce. Nothing generates a UCP profile for you, so the winnable check is M4, machine-readable pricing, which is a JSON-LD Offer block with a price, a currency and a billing period. ThinkRank is the sensible starting point because it handles schema, robots.txt, robots meta, sitemaps and llms.txt from one plugin, which avoids the usual situation of three plugins fighting over the same file, and it migrates settings from Rank Math, Yoast, All in One SEO and SEOPress so switching costs nothing in re-entered configuration. Rank Math and Yoast both produce good product schema and have larger plugin ecosystems; neither manages llms.txt today. Our llms.txt generator will write a starting file for any platform.

If you are being asked to adopt x402 for your shop. The measured answer is that it has no storefront deployment we can find, and its live use is publishers charging crawlers. That is a legitimate thing to watch and a poor thing to build against this quarter.

Four mistakes this measurement kept catching

Anyone repeating these probes will hit the same four traps, and three of them produce a confidently wrong answer rather than an obvious error.

Reading a status code as a file. One host in this sweep returned HTTP 200 on three different well-known paths and served the same HTML error page every time. Always fetch a deliberately nonexistent path first and compare the byte count against the file you care about. Identical sizes mean both are the shell.

Probing the file and stopping. The discovery document and the live endpoint disagree. 21 stores published a UCP profile, 19 answered an MCP tools/list call, and only 10 returned the full tool set. Whichever one you probe alone gives a different adoption rate.

Treating one probe as a measurement. A store that returned five tools on 2 September returned one on 4 and 8 September. Sample twice, hours apart, and report a range.

Assuming a protocol is absent because its well-known path is. ACP has no discovery file by design, and a scanner that grades its absence is grading a convention the specification never asked for.

Where to start on your own store

Scan the store, read five rows, and fix them in this order: E1 first, because a soft 404 invalidates everything below it, then M4 because JSON-LD pricing is the one row you control entirely, then M1, P2 and M3, which are mostly decided by your platform rather than by you.

npx aiscan-cli yourstore.com

The full rubric for these rows is documented on the commerce checks page and the capabilities checks page, and every platform walkthrough we have published is indexed at aiscan.site/guides.

Every figure in this article was measured on 8 September 2026 and every command is reproducible. Protocol versions, storefront defaults and vendor documentation all move; re-run the probes before quoting these numbers back.