Agent Surface

Agentic Commerce

Checkout Protocols

UCP and ACP - how agents complete a purchase once they have found and trusted a product, and how the two relate to MCP and A2A

Last verified 2026-10-29

Summary

Once an agent has found a product it trusts (see Product Data), it needs a way to turn that into an order: negotiate what it can do, present terms for approval, and complete the purchase with a receipt. Two protocols do this today: UCP, launched by Google and Shopify with 20+ partners, and ACP, maintained by OpenAI and Stripe. Neither replaces or - they sit above them as the commerce-specific session layer.

  • UCP - Google + Shopify; standardized catalog, cart, identity, and checkout; current release 2026-08-25
  • ACP - OpenAI + Stripe; session-based checkout with explicit payment delegation; still Beta, latest released snapshot 2026-04-17
  • Both are commerce-session protocols, not tool protocols - each supports REST and MCP bindings, so MCP is one way to reach them rather than a requirement, and an agent can use A2A if a specialist agent handles the purchase
  • Pick one protocol per merchant relationship; don't hand-build a competing checkout surface where a platform already offers one

UCP - Universal Commerce Protocol

Status: open protocol, date-versioned releases. UCP was announced by Google and Shopify on 2026-01-11 at NRF, with a date-versioned spec and 20+ launch partners. The UCP Tech Council expanded on 2026-04-24 to add Amazon, Meta, Microsoft, Salesforce, and Stripe, and Stripe joined the Governing Council on 2026-04-28 (announcements).

The 2026-08-25 release is the current spec version. It lays the ground for Food and Lodging verticals alongside the original Shopping vertical (polymorphic binding, vertical-agnostic payment constructs), adds vendor-agnostic 3D Secure (3DS2) device-data-collection and challenge flows via the Actions primitive, adds response-carried request constraints so a merchant can return transaction-specific validation rules, and formalizes independent, date-based capability versioning across protocol updates. Governance has grown past the original Tech Council into vertical-specific technical councils: a Food TC (finalized 2026-07-16; Block/Square, DoorDash, Google, Toast, Uber Eats), a Lodging TC (closed 2026-08-11; Amadeus, Booking.com, Expedia, Google, Hilton, Marriott, Trip.com), and a Payments TC (closed 2026-09-02; Adyen, Ant International, Coinbase, Global Payments, Google, PayPal, Shopify, Stripe). A UCP Lodging booking capability (dev.ucp.lodging.booking) merged on 2026-09-25 as a draft covering availability and pricing, guest registration, and payment schedules; treat it as a draft, not a deployed retail capability (announcements).

UCP standardizes how a merchant catalog, cart, and checkout are exposed to agents, and how a purchase is authorized end to end: catalog search, cart, OAuth2 identity, checkout, and order tracking, published at a /.well-known/ucp profile. It is designed to be AP2-compatible, so its mandates can ride the authorization model described on Payments.

If you sell through Shopify or one of the launch platforms, UCP is likely to reach you as a platform feature rather than something you implement by hand - see Shopify for what that looks like concretely. Shopify now offers several agent checkout surfaces: Shop MCP (2026-10-13) for search, carts, and Shop Pay checkout after the shopper confirms; WebMCP checkout tools (2026-09-28) for browser agents, with hand-back to the buyer for 3DS; and cart and checkout permalinks at /buy now support UCP (2026-10-28), which is a browser hand-off rather than agent-native completion.

ACP - Agentic Commerce Protocol

Status: Beta. ACP (OpenAI + Stripe) defines how an agent completes a purchase on behalf of a user. The repository still labels it Beta, and the latest released snapshot is spec/2026-04-17. ChatGPT's Instant Checkout, which launched with ACP in September 2025, has been scaled back: on 2026-03-24 OpenAI said it is moving away from a standalone Instant Checkout so merchants can use their own checkout, while ChatGPT focuses on product discovery. ACP now carries that discovery - merchants share product feeds and promotions through it - and purchases complete on the merchant's site or in a merchant's own ChatGPT app. OpenAI's developer guide still describes the original in-ChatGPT checkout flow (Agentic Checkout and Delegated Payment, both parts of ACP); treat it as the spec, not as evidence the ChatGPT surface is live. Check current client support before building the checkout half.

"ACP" is an overloaded acronym. This page covers the Agentic Commerce Protocol (OpenAI + Stripe). The unrelated Agent Client Protocol (Zed-originated, editor-to-agent, stable protocol version 1, adopters include Zed, JetBrains, Neovim, and Emacs) and IBM's dead Agent Communication Protocol (absorbed into A2A in August 2025) also use it.

What a merchant needs to know

The released 2026-04-17 checkout does not define a discovery document: the agent declares its capabilities when it creates a session and the merchant answers with the intersection it supports. An RFC in the repository proposes a seller document at /.well-known/acp.json, but it is marked a proposal and is not part of the released contract.

The flow is a session that moves through explicit states (incomplete, ready_for_payment, completed, canceled, and others):

  1. Create session - the agent POSTs /checkout_sessions with line_items, currency, and its capabilities (payment handlers, interventions such as 3ds, extensions such as discount), with the required Idempotency-Key and API-Version headers. The merchant returns the session with priced line items, totals, the capabilities it supports, and any messages.
  2. Update - the agent POSTs /checkout_sessions/{id} to change items, buyer details, or fulfillment, and gets the refreshed cart state back.
  3. Payment delegation - the buyer grants a one-time, amount-capped, merchant-scoped payment credential through the Delegated Payment spec. This does not give the agent access to the buyer's general payment credentials.
  4. Completion - the agent POSTs /checkout_sessions/{id}/complete with payment_data. On success the merchant creates the order and returns the session in the completed state.
  5. Cancellation - POST /checkout_sessions/{id}/cancel abandons a session that is not yet completed. The optional intent_trace carries a structured reason_code (for example price_sensitivity, shipping_cost, or product_fit) so merchants can see why a buyer walked away.

Security: a in Authorization, a required Idempotency-Key on every POST, and the required API-Version header. Requests may also carry Timestamp and Signature headers. Errors come in two shapes: an HTTP-level Error (invalid_request, processing_error, service_unavailable) when there is no valid session to return, and in-session messages that carry severity and a resolution of recoverable (the agent can fix it through the ), requires_buyer_input, or requires_buyer_review.

The 2026-04-17 release also adds an MCP transport binding for the checkout operations, so the same session can be reached over MCP instead of REST (changelog).

Merchant checklist: return complete pricing (including tax and fees) when the session is created and updated, not first at completion; use machine-readable error codes and set resolution honestly so the agent knows who has to act; make completion safe to retry with the same Idempotency-Key.

Full spec references: ACP specification, OpenAPI under spec/2026-04-17.

How these relate to MCP and A2A

UCP and ACP are commerce-session protocols: they define catalog, cart, checkout, and payment delegation semantics, layered on top of MCP (agent-to-tool/data) and A2A (agent-to-agent delegation) rather than replacing them. A real system layers them: MCP for the surrounding tool calls, A2A where another agent handles the purchase, and UCP or ACP for the commerce session with the merchant. ACP's MCP binding above is exactly this pattern: the commerce protocol riding MCP transport rather than competing with it. Both protocols also support REST, so MCP is a binding choice, not a dependency.

Decision rule: which protocol by role

  • Merchant / commerce platform - enable whichever protocol your platform offers (UCP on Shopify, for example). Do not hand-build a competing checkout surface; ride the platform integration. See Shopify if that's your platform.
  • Selling through ChatGPT specifically - the product feed is what matters now: ChatGPT uses ACP for discovery and sends buyers to your own checkout (see Product Data). Shopify merchants are included through Shopify Catalog. ACP's Agentic Checkout and Delegated Payment specs (see Payments) still apply wherever a client supports agent-completed checkout.
  • Agent platform - adopt the mandate model (see Payments) as your internal representation of spending authority now; defer pinning to one protocol's wire format until your payment partner commits.

On this page

SummaryUCP - Universal Commerce ProtocolACP - Agentic Commerce ProtocolWhat a merchant needs to knowHow these relate to MCP and A2ADecision rule: which protocol by roleRelated Pages