ACP, UCP and AP2 Compared: The Agentic Commerce Protocols in October 2026, and Which One Your Store Needs

Three open protocols now describe how an AI agent buys from a store. The Agentic Commerce Protocol (ACP) comes from OpenAI and Stripe. The Universal Commerce Protocol (UCP) comes from Google and Shopify. The Agent Payments Protocol (AP2), which Google started and gave to the FIDO Alliance in April, is not a checkout protocol at all: it defines signed proof that a user authorised a payment, and it is designed to sit inside UCP. All three are Apache 2.0.

On 22 October 2026 they are in very different states. ACP is labelled beta, its latest release is 2026-04-17, and nothing has been committed to it since 17 July. ChatGPT, its main consumer, moved away from standalone checkout in March and now uses ACP mostly to receive product data. UCP published a breaking version, 2026-08-25, in August, while Google's own surfaces still run 2026-04-08 and its checkout is early access, US only. AP2 is at v0.2, and no Google product documents using it.

This article is for CTOs and lead developers of stores and commerce platforms deciding what to implement. For what each AI platform asks of a store as a business, start with our agentic commerce overview.

Side by Side

ACP: The Agentic Commerce Protocol

Governance and Versions

The specification repository says ACP is maintained by OpenAI and Stripe and labels it beta. Its governance document makes the two Founding Maintainers: they appoint the steering committee's seats (up to seven) and keep a veto for use "as a last resort". Meta joined as the third lead maintainer and committee member on 24 April 2026. Stripe's documentation calls ACP "created by Stripe, OpenAI, and Meta", but the repository's notice file credits only OpenAI and Stripe. A neutral foundation is only a stated future path.

There are five dated releases: 2025-09-29 (checkout and delegated payment), 2025-12-12 (breaking changes learned from the URBN and Etsy adapters), 2026-01-16 (a merchant-chosen 3DS provider), 2026-01-30 (capability negotiation, extensions and a breaking payment handlers framework) and 2026-04-17 (cart, feed, orders, delegated authentication, discovery and MCP), which deprecated 2026-01-30. Nothing has been released in the six months since. The unreleased/ folder holds smaller changes dated up to 17 July, such as a feed update id and an optional product URL on checkout items.

What a Merchant Implements in 2026-04-17

The checkout API is hosted by the merchant and called by the agent:

• POST /checkout_sessions creates a session, POST /checkout_sessions/{checkout_session_id} updates it (a POST, not a PUT), GET on that path retrieves it, and .../complete and .../cancel end it.
• Requests carry a bearer API key and a required API-Version header. Since 2026-04-17 an Idempotency-Key is mandatory on every POST, with defined errors: 400 idempotency_key_required, 409 idempotency_in_flight and 422 idempotency_conflict.
• The create request carries a capabilities object. The agent declares what it supports and the seller returns the intersection, so an incompatibility shows up before payment.
• The merchant POSTs order events to a receiver OpenAI hosts at /agentic_checkout/webhooks/order_events, signed with HMAC-SHA256 in a Merchant-Signature header. Statuses run from created to delivered or canceled, and adjustments[] carries refunds, returns, disputes and chargebacks.

The 2026-04-17 release also added a static, public /.well-known/acp.json, whose transports field says whether the store speaks rest, mcp or both. It added an MCP binding over Streamable HTTP with five tools (create_checkout_session, get_checkout_session, update_checkout_session, complete_checkout_session, cancel_checkout_session), authenticated in the server configuration rather than per request. And it added a Feed API that the agent hosts and the merchant pushes to (POST /feeds, PATCH /feeds/{id}/products), a single-seller cart with no payment data (POST /carts, PUT /carts/{id}), and delegated 3DS2 authentication (POST /delegate_authentication). There are no subscriptions: the extensions RFC lists subscription as "Recurring billing support (future)".

How Payment Works in ACP

ACP's original answer is delegated payment. The PSP or card vault implements POST /agentic_commerce/delegate_payment, which turns a card (the only credential type) into a token the merchant's PSP may use only within an allowance: reason (only one_time), max_amount, currency, checkout_session_id, merchant_id and expires_at. In the RFC's words, "Payments, settlement, and compliance remain on the merchant's rails." Worldpay documents its own version of the call, and PayPal supports ACP through delegated tokens in Braintree.

Since 2026-01-30, accepted methods are declared as handlers under capabilities.payment.handlers. The changelog's example payment data:

{ "handler_id": "card_tokenized", "instrument": { "type": "card", "credential": { "type": "spt", "token": "spt_123" } } }

The spt is Stripe's Shared Payment Token, available "in the US, Canada, and select European countries". A Stripe seller charges it with payment_method_data[shared_payment_granted_token] on a preview API version; a seller on another processor can resolve it to network credentials once. Our agentic payments article covers who carries the risk.

What OpenAI's March Move Changed

On 24 March 2026 OpenAI wrote that "the initial version of Instant Checkout did not offer the level of flexibility that we aspire to provide", let merchants use their own checkouts, and said it was "extending ACP to be the connective layer between merchants and users throughout discovery." Target, Sephora, Nordstrom, Lowe's, Best Buy, The Home Depot and Wayfair had integrated ACP for discovery, and Shopify catalogues arrive through Shopify Catalog. What that means for a developer:

• The feed is the live part. OpenAI's merchant page says purchases "are completed on merchant-owned websites or apps" and that shopping is live for US users. Feed onboarding is for approved partners from a waitlist: a daily full file over SFTP with nine required fields, API updates during the day, promotions only by API. The standard upload "currently targets the US".
• Checkout is a separate gate. The feed specification says checkout "requires a separately enabled integration". For ChatGPT apps, the generally available route is external checkout on the developer's own domain. The in-chat payment sheet is a private beta "limited to select marketplaces", which hands a payment token to the app's MCP server in a complete_checkout tool call.
• OpenAI's pages lag the spec. Its checkout reference still shows API-Version 2025-09-12 and a provider enum of stripe, adyen and braintree. Build to the repository and confirm with OpenAI which version it accepts.

PSP pages that still present Instant Checkout as live are out of date.

UCP: The Universal Commerce Protocol

Governance and Versions

Google launched UCP on 11 January 2026, co-developed with Shopify, Etsy, Wayfair, Target and Walmart. The governance rules give Google and Shopify one permanent vote each on the Governing Council, which Stripe joined on 28 April 2026, and state that "Google holds proxy vote for all open seats until Dec 2028". On 24 April the Shopping Tech Council grew to 16 seats, adding Amazon, Meta, Microsoft, Salesforce and Stripe, so Meta and Stripe now sit on both ACP's committee and UCP's council.

The repository has four releases. 2026-04-08 added cart and catalog capabilities, request and response signing, and Get Order. 2026-08-25 is breaking: signing_keys[] gave way to a JWK Set in keys[], payment extensions moved from dev.ucp.shopping.* to dev.ucp.common.payment.*, shared schemas moved and changed their $id URLs, and PAN and network tokens became separate credential types. It also added vendor-agnostic 3DS2, split payments, payment terms and Web Bot Auth interoperability.

Here is the trap. Google's profile guide covers 2026-04-08 and 2026-01-23 only, Google's own agent profile at ucp.goog declares "version": "2026-04-08", and Salesforce B2C Commerce 26.9 serves the same two versions. Shopify's Checkout MCP, meanwhile, links 2026-08-25. Build to the latest release and you build a version Google does not document. The spec's answer is a supported_versions object that maps each older version to its own profile URI.

Discovery, Transports and Authentication

Every business publishes a profile at /.well-known/ucp with ucp.version, ucp.services and ucp.payment_handlers, and Google requires it to be public and unauthenticated. The agent's platform publishes one too, and every request carries its URI in a UCP-Agent header, over HTTPS with TLS 1.3 at minimum. Authentication is the business's choice: none, X-API-Key, OAuth 2.0, mutual TLS or RFC 9421 HTTP Message Signatures. Google sends a bearer token, and its FAQ also offers mTLS. An Idempotency-Key is only a "SHOULD"; a server that accepts one keeps it for at least 24 hours and answers 409 when it is reused with a different body.

REST is the core transport, alongside MCP, an A2A extension and an embedded mode reached through a continue_url. Orders are a GET /orders/{id} plus a business-to-platform webhook signed per RFC 9421. Cart paths are the same as ACP's. The checkout operations look alike and are not interchangeable:

One checkout core can serve both. One route table cannot.

How Payment Works in UCP

UCP does not move money. A payment handler is a specification written by a credential provider, such as com.google.pay for Google Pay or dev.shopify.shop_pay for Shop Pay. The business lists the handlers it accepts, the platform runs one, and on complete the business receives an opaque token to charge through its own PSP.

On Google's surfaces the only handler is Google Pay, PAN_ONLY is the only auth method used, and your PSP "must be able to process our tokens". Stripe publishes com.stripe.payments for card and Apple Pay: "The agent sends a shared payment token (SPT) in the Complete Checkout request, and the seller charges it." Google Pay stays on its own handler. PayPal takes the Google Pay handler through Braintree or through its Orders v2 API.

What Google Requires Before It Calls You

Google's native checkout guide asks for the REST checkout API and keeps the payment step: the shopper enters sensitive details "only with the Google UI". Its service levels are at least 95% availability on each endpoint, with p50 and p95 latency of 1 and 4 seconds for create, 1 and 5 for update, and 6 and 10 for complete. After an order, you push status updates to a Google webhook with a partner id and key issued at onboarding. In Merchant Center, each product needs native_commerce(checkout_eligibility) set to true (it "defaults to FALSE"), a return policy and support contact are mandatory, and subscriptions, instalments, personalised, used and refurbished goods, pre-orders and age-restricted items are excluded.

The lighter option, since 2026-04-08, is cart transfer: you implement cart creation only, Google hands the cart to your site, and no payment handler or order webhook is needed.

Access is the real limit. Checkout is "available for select merchants" through an early access interest form, on which you commit to start within 30 days and accept that access "may be removed" if you make no progress. The UCP Checkout terms apply "to the United States only". The Merchant Center hub is to follow in Australia and Canada "early next year"; Google gives no checkout date for any other country.

UCP Outside Google

Microsoft Merchant Center has accepted UCP-ready feeds in the US since 21 April 2026. Copilot Checkout needs a UCP-compliant feed, takes English-language merchants selling to US buyers in dollars with one PSP each, and its store setting is marked "Pilot only to select customers". Shopify exposes UCP over MCP at https://{shop}/api/ucp/mcp and has removed its older catalog and cart tools. A lodging booking capability was merged as a draft on 24 September 2026 and is in no release.

AP2: The Agent Payments Protocol

AP2 is not a third way to check out. Its specification says it "operates as a security feature within a Commerce Protocol" and is "designed explicitly to be compatible with the Universal Commerce Protocol (UCP)". Version 0.1.0 came out on 16 September 2025 and v0.2 on 28 April 2026, the day Google donated AP2 to the FIDO Alliance. FIDO's announcement names an Agentic Authentication working group and a Payments working group chaired by members from Mastercard and Visa, and says the contributions "will be reviewed and further developed". FIDO has published no AP2 specification. The GitHub repository now takes only samples and SDK changes, and its last commit was on 29 April.

Version 0.2 defines a Checkout Mandate (what is bought) and a Payment Mandate (the payment, with constraints such as payment.amount_range, payment.budget and payment.allowed_payees). Each is an SD-JWT in a closed and an open form (mandate.payment.1 and mandate.payment.open.1, for example). In Human Present mode the user approves the closed mandates. In Human Not Present mode the user approves open mandates that set constraints, which carry the agent's public key in a cnf claim, and the agent assembles the closed ones within those limits. Tutorials about Intent and Cart Mandates describe v0.1; those terms are gone from v0.2.

Inside UCP, AP2 is the extension dev.ucp.common.payment.ap2_mandate (dev.ucp.shopping.ap2_mandate before 2026-08-25). Once it is negotiated, the business signs its checkout responses, the platform presents a checkout_mandate and a payment_mandate on complete, and the session is "Security Locked": neither side may fall back to an ordinary checkout.

Nobody asks for it yet. Google's FAQ calls AP2 "particularly useful for future scenarios involving autonomous AI agent transactions". Google's own agent profile lists Google Pay as its only payment handler and declares no AP2 capability, and its 2026-08-25 profile has no AP2 entry either. No Google product documents using AP2, so there is nothing for a merchant to build until a platform negotiates it.

The Neighbouring Protocols

MCP

ACP and UCP can both run over MCP, whose current specification, 2026-07-28, removes sessions and the Mcp-Session-Id header, drops the initialize handshake, requires server/discover, and has a client re-issue a request under a new ID when its stream breaks. ACP's binding still links the 2025-11-25 transport. A checkout session id is exactly the server-minted handle the new specification expects, and a complete lost mid-stream comes back as a fresh request: treat idempotency keys as mandatory on both protocols.

WebMCP

WebMCP is a proposed web standard for exposing a page's own functions to browser agents. Shopify offers UCP checkout both as Checkout MCP and as Checkout WebMCP, with the same checkout object, and recommends Checkout MCP. Our WebMCP guide covers its status.

x402 and MPP

x402 and the Machine Payments Protocol, designed by Tempo and Stripe, charge an agent per HTTP request for an API, data or content. They are not store checkout protocols. See our x402 article.

Visa Trusted Agent Protocol and Mastercard Agent Pay

These sit beside ACP and UCP rather than replacing them. Visa's Trusted Agent Protocol gives an agent "a standardized, cryptographic method" to prove its identity and authorisation to merchants, and Mastercard Agent Pay is a tokenisation programme for agentic commerce. Mastercard's merchant guide puts UCP and ACP at its highest readiness level, notes that "Early adopters are integrating currently", and advises merchants to start with its two simpler levels. Our agentic payments article covers both programmes.

Personal Agent Protocol

Sierra says it announced the Personal Agent Protocol ("Poppy") with Meta on 6 October 2026, and it published a draft on 9 October. A company publishes one file at /.well-known/poppy.json; the protocol uses OAuth, JWTs, HTTPS, OpenAPI and MCP to let a personal agent identify itself and get the customer's permission for any kind of task, and Sierra calls it complementary to UCP. The protocol site shows version 0.2 and says "It's a draft". We found no post about it in Meta's own newsroom.

Which One Do You Need?

On Shopify

Nothing to build. Shopify's agentic storefronts are "active by default for eligible stores". ChatGPT receives your catalogue through Shopify Catalog and sends shoppers to your store. Google's direct checkout is on by default for stores based in and selling to the US, and Copilot enrolled Shopify merchants automatically. Your decisions are product data and whether to keep direct checkout on, knowing that custom pixels do not fire in Google's.

On Salesforce, commercetools or Another Platform

Salesforce B2C Commerce 26.9 serves UCP 2026-01-23 and 2026-04-08: /.well-known/ucp with a supported_versions map, and the checkout-session endpoints behind a SLAS token. Salesforce lists UCP checkout on Google as generally available in October 2026. A session is a headless view of a basket, and Salesforce's audit guide warns that SFRA and SiteGenesis controllers and "other SCAPI resources you use today don't run in this flow", so logic attached to them must be copied or bridged onto the UCP checkout-session hooks. The feed must target en-US, and Salesforce "doesn't skip Google's waitlist". For ChatGPT, Salesforce is one of the delivery paths OpenAI names for ACP feeds.

On commercetools or another platform, ask the vendor which UCP versions and capabilities it serves, which of your hooks run in an agent checkout, and whether it sends feeds to OpenAI.

On Your Own Software

1. Feeds first. Google Merchant Center and, once OpenAI admits you, its product feed. ACP's commercial use in ChatGPT today is exactly this.
2. UCP for Google, if you sell in the US and Google admits you. Build to 2026-04-08: the profile with com.google.pay, the checkout operations within Google's latency targets, a PSP that processes Google Pay tokens, the order webhook and the feed attribute. Or start with cart transfer alone.
3. ACP checkout only with a reason, such as a ChatGPT app admitted to the payment sheet beta. Build to the repository's 2026-04-17.
4. AP2: nothing yet.
5. One checkout core. Both protocols want a session that can be created, updated, completed and cancelled over an API and safely retried. Build it once over your order, tax and payment logic, with thin ACP and UCP adapters on top and MCP where agents need it.

Neither protocol gives a subscription business native agent checkout today.

Selling Only Outside the US

None of the three gives you an agent checkout today. ChatGPT shopping and OpenAI's standard feed upload are US; Google's UCP Checkout terms are US only; Copilot Checkout serves US buyers in dollars. Google's next announced step is the Merchant Center hub in Australia and Canada "early next year", with no date for the UK or the EU.

Keep your Merchant Center feed complete, and if you are rebuilding checkout anyway, build the API-driven core described above, so an adapter is a small job when your market opens. Selling into the US from abroad? Check where each programme requires the merchant to be based; Shopify's Google direct checkout, for one, requires a US store.

Where to Get Help

We build the protocol layer for stores that do not run Shopify: a /.well-known/ucp profile and checkout-session endpoints on top of your existing order, tax and payment logic, order webhooks to Google, product feeds for Google Merchant Center and OpenAI, and MCP servers that expose the same checkout to agents. Our AI agent development and MCP integration service is where that work starts.

Write to office@c9group.dev with your platform, your payment provider and the countries you sell in, and we will tell you which protocol applies and what implementing it would take. Google's and OpenAI's programme terms are contracts: we are engineers, not lawyers, so have an adviser read them before you sign.