The Agentic Commerce Protocol Stack: UCP, ACP, AP2, MCP, A2A Explained
Five protocols. Three layers. One coherent stack for the agent economy. This is the definitive guide to how MCP, A2A, UCP, ACP, and AP2 fit together -- and what technical leaders need to know before choosing an implementation path.
The Agentic Commerce Protocol Stack: UCP, ACP, AP2, MCP, A2A Explained
Last updated: March 2026
Five protocols. Three layers. One coherent stack for the agent economy. This is the definitive guide to how MCP, A2A, UCP, ACP, and AP2 fit together – and what technical leaders need to know before choosing an implementation path.
The Emerging Consensus
After eighteen months of fragmented announcements, white papers, and competing demos, the agentic commerce landscape has arrived at something resembling consensus. The pattern is clear:
- MCP handles tool integration (how agents access external systems).
- A2A handles agent communication (how agents collaborate with each other).
- UCP and ACP handle commerce semantics (how agents discover, cart, and check out products).
- AP2 handles payment authorization (how agents pay on behalf of users, with cryptographic proof).
These are not competing standards. They are complementary layers in a protocol stack – each solving a distinct problem, each maintained by a different organization, and each designed to interoperate with the others. Understanding this layered architecture is the single most important conceptual shift for anyone building agentic commerce infrastructure in 2026.
The Layer Model
The agentic commerce protocol stack follows a clear layered dependency model. Lower layers provide foundational capabilities; higher layers add domain-specific semantics.
| Layer | Protocol(s) | Function | Maintained By |
|---|---|---|---|
| Foundation | MCP, A2A | Tool access (MCP) and agent-to-agent communication (A2A) | Anthropic, Google / Linux Foundation |
| Commerce | UCP, ACP | Product discovery, checkout sessions, order lifecycle | Google + Shopify (UCP), OpenAI + Stripe (ACP) |
| Payment | AP2 | Cryptographic payment authorization, mandate signing, VDCs | Google + 60 partners |
| Settlement | x402 (optional) | HTTP-native stablecoin settlement for machine-to-machine payments | Coinbase / x402 Foundation |
The key insight: you do not pick one protocol. You implement layers. A merchant might expose UCP capabilities via MCP transport, accept AP2-signed payment mandates, and be discoverable by A2A-compatible shopping agents – all simultaneously.
MCP: The Tool Integration Layer
Maintainer: Anthropic Transport: stdio, HTTP SSE Payload: JSON-RPC 2.0 Spec: modelcontextprotocol.io
The Model Context Protocol, originally developed by Anthropic in late 2024, has become the de facto standard for connecting AI agents to external systems. In the commerce stack, MCP operates vertically – it defines how a single agent accesses tools, data sources, and APIs.
MCP is not a commerce protocol. It is a general-purpose tool integration layer. Its relevance to commerce is that both UCP and ACP explicitly support MCP as a transport binding, and major commerce platforms have shipped MCP endpoints.
Commerce Adoption
As of March 2026, MCP has achieved broad adoption across the commerce ecosystem:
- Shopify ships MCP endpoints on every store by default at
/api/mcp, exposing product search, cart management, and checkout URL generation. - Shopify Catalog MCP at
discover.shopifyapps.com/global/mcpenables cross-merchant product discovery across all Shopify stores via OAuth2-authenticated requests. - PayPal, Visa, Marqeta, and Worldpay have launched MCP servers for payment operations (invoicing, order creation, virtual card issuance, dispute management).
- Salesforce B2C Commerce and commercetools provide MCP-based agent access to their commerce platforms.
- OpenAI announced MCP support across all products, including the ChatGPT desktop app.
Role in the Stack
MCP sits at the foundation. It provides the plumbing through which commerce-specific semantics (defined by UCP or ACP) flow. A UCP checkout capability exposed as an MCP tool is accessible to any MCP-compatible agent – Claude, Cursor, custom agents – without requiring those agents to understand UCP directly.
The analogy is instructive: MCP is to agentic commerce what HTTP is to the web. It is the transport, not the application.
A2A: The Agent Communication Layer
Maintainer: Google, now under the Linux Foundation Transport: HTTPS, gRPC (v0.3+) Payload: JSON-RPC 2.0 Streaming: Server-Sent Events (SSE) Spec: a2a-protocol.org GitHub: github.com/a2aproject/A2A
The Agent-to-Agent Protocol enables AI agents from different vendors and frameworks to communicate, collaborate, and exchange information. Where MCP connects agents to tools (vertical), A2A connects agents to agents (horizontal).
Core Concepts
Agent Cards. Every A2A agent publishes a JSON metadata document at /.well-known/agent.json describing its identity, capabilities, supported skills, authentication requirements, and service endpoint. Agent Cards serve as a discovery mechanism – a shopping concierge agent can fetch a merchant’s Agent Card to learn what commerce operations it supports.
Tasks. The fundamental unit of work. Tasks are server-generated, stateful objects with a defined lifecycle: working -> input-required -> completed (or failed, canceled, rejected). This lifecycle directly maps to multi-turn commerce interactions: a checkout that pauses for address input, resumes for shipping selection, then completes with payment.
Messages and Parts. Communication turns consist of Messages containing typed Parts – text (natural language), file (media), or data (structured JSON). This enables agents to exchange both conversational intent (“find me organic face cream under $50”) and structured operations ({ "action": "add_to_checkout", "product_id": "SKU-123" }).
Commerce Patterns
A2A enables multi-agent commerce workflows that mirror how human organizations operate:
User --> Shopping Concierge Agent
|
+--> Product Discovery Agent (search, compare prices)
+--> Inventory Agent (real-time stock, delivery estimates)
+--> Checkout Agent (cart management, payment)
+--> Logistics Agent (fulfillment, tracking)
Google’s reference implementation demonstrates this with a Purchasing Concierge (built on ADK/Vertex) coordinating with a Burger Agent (CrewAI) and a Pizza Agent (LangGraph) – three different AI frameworks interoperating via A2A. The protocol is framework-agnostic by design.
Relationship to UCP
UCP explicitly supports A2A as one of its three transport bindings. A merchant’s UCP profile at /.well-known/ucp can advertise an A2A endpoint, and the merchant’s Agent Card can declare UCP capabilities via the extensions field. This means UCP commerce operations (checkout, discount application, order management) can flow over A2A messages between agents.
UCP: The Commerce Orchestration Layer
Maintainer: Google + Shopify (with Etsy, Wayfair, Target, Walmart, and 20+ partners)
License: Apache 2.0
Spec Version: 2026-01-11 (stable), 2026-01-23 (Google integration)
Spec: ucp.dev
GitHub: github.com/Universal-Commerce-Protocol/ucp (2.4k stars)
The Universal Commerce Protocol is an open standard that defines building blocks for agentic commerce – from product discovery and buying to post-purchase experiences. UCP’s core philosophy is decentralized and merchant-as-source-of-truth: merchants declare what they support, agents discover and negotiate capabilities dynamically, and no single platform mediates the relationship.
Architecture
UCP follows a three-tier design:
- Shopping Service Layer – Fundamental transaction primitives: checkout sessions, line items, totals, status.
- Capabilities Layer – Major functional domains with independent versioning: Checkout, Orders, Identity Linking, Fulfillment, Discounts.
- Extensions Layer – Domain-specific schemas composed on top of capabilities (e.g., AP2 mandates, loyalty programs, subscriptions).
Discovery
Merchants publish a JSON manifest at /.well-known/ucp enabling agents to dynamically discover supported services, transport bindings, capabilities, and payment handlers. No registry, no crawling, no hard-coded integrations.
https://merchant.example.com/.well-known/ucp
The manifest declares which transports the merchant supports (REST, MCP, A2A), which capabilities are available (checkout, fulfillment, discounts, identity linking), and which payment handlers are configured (Google Pay, Shop Pay, Stripe, Adyen, regional processors).
Transport Bindings
UCP is transport-agnostic. Merchants choose how to expose their capabilities:
| Transport | Binding | Use Case |
|---|---|---|
| REST | OpenAPI-based HTTP endpoints | Direct API integration |
| MCP | JSON-RPC via MCP servers | MCP-compatible agents (Claude, Cursor, etc.) |
| A2A | Agent Card + JSON-RPC messages | Multi-agent orchestration |
| ECP | Embedded Checkout Protocol | Inline checkout within agent UIs |
Checkout Flow
Agent Merchant Server
| |
|-- POST /checkout-sessions -------->| (line items, buyer info, payment handler)
|<--- session ID, totals, caps ------|
| |
|-- PUT /checkout-sessions/{id} ---->| (apply discount, select fulfillment)
|<--- updated session ---------------|
| |
|-- Complete with AP2 mandate ------>| (cryptographic proof of user consent)
|<--- order confirmation ------------|
Capability Negotiation
Both the agent and merchant publish profiles declaring their capabilities. The merchant computes the intersection – which capabilities both support, which payment handlers overlap, which extensions are mutually understood – and responds with the negotiated result. Negotiation happens per-transaction: changing the cart, buyer location, or currency can shift available capabilities.
Ecosystem
UCP’s partner list reads like a who’s-who of global retail and payments: Shopify, Etsy, Wayfair, Target, Walmart, Adyen, American Express, Best Buy, Flipkart, Macy’s, Mastercard, Stripe, The Home Depot, Visa, and Zalando. It is live in Google Search AI Mode and Gemini.
ACP: The Platform-Mediated Checkout Protocol
Maintainer: OpenAI + Stripe
License: Apache 2.0
Spec Version: 2026-01-30 (current stable)
Status: Beta
Spec: agenticcommerce.dev
GitHub: github.com/agentic-commerce-protocol
The Agentic Commerce Protocol is an open standard for programmatic commerce flows between buyers, AI agents, and businesses. Co-developed by OpenAI and Stripe, ACP enables AI agents to conduct end-to-end purchases without the agent becoming the merchant of record. Merchants retain full control over products, pricing, fulfillment, and customer relationships.
How ACP Differs from UCP
The distinction is architectural. UCP is a decentralized discovery protocol – merchants publish capabilities, any agent can discover and transact. ACP is a platform-mediated commerce layer – merchants submit product data to OpenAI, Stripe handles all payments, and ChatGPT surfaces products to users during conversations.
| Dimension | UCP | ACP |
|---|---|---|
| Model | Decentralized, merchant-as-source-of-truth | Platform-mediated, agent-led |
| Discovery | /.well-known/ucp manifest |
Product feeds (CSV/JSON) to OpenAI |
| Payment | Any handler (negotiated per-transaction) | Stripe (via SharedPaymentTokens) |
| Live surfaces | Google AI Mode, Gemini, any compliant agent | ChatGPT |
| Fee | Protocol itself is free | OpenAI charges 4% transaction fee (plus Stripe’s ~2.9% + $0.30) |
Four-Party Transaction Model
ACP defines four parties: the Buyer (consumer), the AI Agent (ChatGPT or any ACP-compatible agent), the Business (merchant of record), and the Payment Provider (Stripe, initially). The agent never holds payment credentials – it provisions a SharedPaymentToken (SPT), a single-use, time-bound, amount-restricted tokenized credential that the merchant uses to create a PaymentIntent.
Core API
ACP’s API surface is deliberately minimal:
| Endpoint | Method | Purpose |
|---|---|---|
/checkouts |
POST | Create checkout session |
/checkouts/:id |
GET | Retrieve session state |
/checkouts/:id |
PUT | Update items, fulfillment, buyer info |
/checkouts/:id/complete |
POST | Complete with payment token |
/checkouts/:id/cancel |
POST | Cancel checkout |
Sessions transition through states: not_ready_for_payment -> ready_for_payment -> completed (or canceled). All amounts are in integer cents. Currency is ISO lowercase.
Recent Evolution
The 2026-01-30 release introduced significant features: a Payment Handlers Framework replacing simple payment identifiers with structured handler objects, Capability Negotiation (mirroring UCP’s approach), an Extensions Framework for composable optional capabilities, and a Discount Extension as the inaugural extension. This convergence toward UCP’s patterns suggests the protocols may eventually harmonize.
MCP Compatibility
ACP can be implemented as either a RESTful HTTP interface or an MCP server. This means a merchant’s ACP checkout endpoints can be wrapped as MCP tools, making them accessible to any MCP client – not just ChatGPT.
AP2: The Payment Authorization Layer
Maintainer: Google + 60 partners (Mastercard, Adyen, PayPal, Coinbase, Visa) License: Apache 2.0 Schema Version: 2025.0 Spec: ap2-protocol.org GitHub: github.com/google-agentic-commerce/AP2
The Agent Payments Protocol addresses a fundamental gap in existing payment infrastructure: current systems assume direct human-to-trusted-interface interaction. AI agents operating autonomously break this assumption. Without standardized mechanisms to validate agent authenticity and authority, financial institutions face unacceptable fraud risk.
The Core Innovation: Verifiable Digital Credentials
AP2’s central contribution is the use of Verifiable Digital Credentials (VDCs) – tamper-evident, cryptographically signed digital objects expressed as W3C Verifiable Credentials – as the building blocks of every transaction. Three mandate types provide a complete authorization chain:
Intent Mandate. Critical for “human-not-present” scenarios. Captures the conditions under which an agent can make a purchase autonomously – product category, price ceiling, time window. Cryptographically signed by the user via a hardware-backed key on their device. Example: “Buy me the cheapest flight to NYC next Friday under $300.”
Cart Mandate. Used when the user is present and authorizing a specific cart. Generated by the merchant and signed by the user, binding authorization to specific items, quantities, and prices.
Payment Mandate. Shared with the payment network and card issuer to provide visibility into the agentic nature of the transaction. Helps networks and issuers apply appropriate fraud rules to agent-initiated transactions.
Six-Actor Architecture
AP2 defines six roles: User, Shopping Agent, Credentials Provider (digital wallet), Merchant Endpoint, Merchant Payment Processor, and Network/Issuer. The architecture enforces PCI-compliant data handling – payment credentials stay with the Credentials Provider, shopping agents never see raw card numbers, and merchants receive tokenized payment methods.
UCP Integration
AP2 integrates with UCP as an extension (dev.ucp.shopping.ap2_mandate). When a merchant’s UCP manifest declares AP2 support, checkout sessions include cryptographic mandate fields. The business signs the checkout object with a detached JWS signature, the platform presents the mandate to the user for consent, and the signed mandate flows back with the payment token to complete the transaction.
Trust Model
The current version (V0.1) uses curated allow lists – manually maintained registries of trusted agents, merchants, and credential providers. The roadmap includes real-time trust establishment via HTTPS certificate verification, mutual TLS, DID systems, and DNSSEC.
How They All Fit Together
The full stack, from bottom to top:
+------------------------------------------------------------------+
| SETTLEMENT LAYER (Optional) |
| x402: HTTP-native stablecoin payments (Coinbase) |
+------------------------------------------------------------------+
| PAYMENT AUTHORIZATION LAYER |
| AP2: VDCs, Intent/Cart/Payment Mandates, cryptographic consent |
| (Google + Mastercard, Adyen, PayPal, Visa, Coinbase) |
+------------------------------------------------------------------+
| COMMERCE LAYER |
| UCP: Decentralized discovery, checkout, orders, fulfillment |
| ACP: Platform-mediated checkout, SharedPaymentTokens |
| (Google+Shopify / OpenAI+Stripe) |
+------------------------------------------------------------------+
| FOUNDATION LAYER |
| MCP: Agent-to-tool integration (Anthropic) |
| A2A: Agent-to-agent communication (Google / Linux Foundation) |
+------------------------------------------------------------------+
A concrete transaction flow through the full stack:
- A shopping concierge agent discovers a merchant via its A2A Agent Card at
/.well-known/agent.json. - The Agent Card’s extensions reference UCP capabilities at
/.well-known/ucp. - The agent initiates a checkout session using UCP semantics, transported over MCP (JSON-RPC).
- The merchant responds with cart totals, fulfillment options, and an AP2 Cart Mandate for signing.
- The user reviews and cryptographically signs the mandate on their device.
- The agent submits the signed mandate and payment token to complete the purchase.
- The payment network receives an AP2 Payment Mandate contextualizing the agent-initiated transaction.
Alternatively, for ChatGPT-mediated purchases, the flow uses ACP instead of UCP, with Stripe SharedPaymentTokens instead of AP2 mandates, and product discovery via feed ingestion rather than /.well-known/ucp discovery.
What About x402?
Maintainer: Coinbase / x402 Foundation (with Cloudflare) Spec: x402.org
x402 revives the long-unused HTTP 402 Payment Required status code to enable instant, automatic stablecoin payments over HTTP. When a client requests a resource, the server responds with 402 plus payment details. The client creates a payment payload (stablecoin transfer on Base or Solana) and resends the request with a PAYMENT-SIGNATURE header. The server verifies payment and serves the resource.
x402 is relevant to agentic commerce as a settlement rail – particularly for machine-to-machine transactions where traditional card networks are unnecessary overhead. AP2 is designed to accommodate x402 as a payment method. The relationship is complementary: AP2 provides the trust framework (who authorized this payment, under what conditions), while x402 provides a specific settlement mechanism (stablecoins over HTTP).
For most commerce scenarios involving physical goods and traditional merchants, x402 is not yet a primary concern. It becomes relevant for digital goods, API access, and autonomous agent-to-agent transactions where sub-second settlement and zero interchange fees matter.
Implementation Order Recommendation
For technical leaders evaluating where to start, the recommended implementation sequence reflects dependency order and market readiness:
Phase 1: MCP foundation. Expose your commerce capabilities as MCP tools. This is the lowest-friction entry point – Shopify stores already have it, and any MCP-compatible agent can immediately interact with your catalog and cart. If you are on Shopify, you already have this.
Phase 2: ACP checkout (if targeting ChatGPT). Implement the ACP checkout API to make your products purchasable within ChatGPT. The API surface is minimal (five endpoints), Stripe handles payment processing, and ChatGPT is the largest consumer-facing agent surface today. Consider the 4% platform fee in your margin analysis.
Phase 3: UCP manifest and capabilities. Publish a /.well-known/ucp manifest to make your store discoverable by Google AI Mode, Gemini, and any UCP-compliant agent. Implement checkout, fulfillment, and discount capabilities. This gives you decentralized discoverability – not tied to any single platform.
Phase 4: A2A Agent Card. Publish an Agent Card at /.well-known/agent.json to enable multi-agent workflows. This matters when you want specialized agents (logistics, inventory, pricing) to collaborate with shopping concierge agents on your behalf.
Phase 5: AP2 payment mandates. Integrate AP2 for cryptographic payment authorization. This becomes critical as agent-initiated transactions scale and payment networks require verifiable proof of user consent. The UCP AP2 mandates extension provides the integration path.
Phase 6: x402 (optional). Evaluate x402 for digital goods, API monetization, or autonomous agent-to-agent settlement where stablecoin rails offer advantages over traditional card networks.
Comparison Matrix
| Dimension | MCP | A2A | UCP | ACP | AP2 |
|---|---|---|---|---|---|
| Created by | Anthropic | Google + Shopify | OpenAI + Stripe | ||
| License | Apache 2.0 | Apache 2.0 | Apache 2.0 | Apache 2.0 | Apache 2.0 |
| Layer | Foundation (tools) | Foundation (agents) | Commerce | Commerce | Payment |
| Scope | Any AI-to-tool connection | Agent-to-agent communication | Full commerce lifecycle | Checkout and payments | Payment authorization |
| Transport | stdio, HTTP SSE | HTTPS, gRPC, SSE | REST, MCP, A2A, ECP | REST, MCP | Extends A2A/MCP |
| Discovery | Server manifest | Agent Cards (/.well-known/agent.json) |
/.well-known/ucp |
Product feeds (CSV/JSON) | Via UCP/A2A |
| Payment model | N/A (tool layer) | N/A (communication layer) | Any handler (negotiated) | Stripe SPTs | VDCs + Mandates |
| Auth model | Per-server | Security schemes in Agent Card | OAuth 2.0 + capability negotiation | API keys + Delegated Payment | Cryptographic VDCs |
| Architecture | Vertical (agent-to-tool) | Horizontal (agent-to-agent) | Decentralized | Platform-mediated | Decentralized |
| Live surfaces | Claude, Cursor, ChatGPT, IDEs | Google ecosystem, Linux Foundation | Google AI Mode, Gemini | ChatGPT | In development |
| Merchant of record | N/A | N/A | Merchant | Merchant | Merchant |
| Partner count | Broad adoption | 50+ (Linux Foundation) | 20+ (retail + payments) | OpenAI + Stripe ecosystem | 60+ (payments + tech) |
| Maturity | GA | v0.3 (production-ready) | v2026-01-11 (stable) | Beta (v2026-01-30) | Schema v2025.0 |
Frequently Asked Questions
Do I need to implement all five protocols?
No. The protocols are layered, and you implement based on your distribution goals. If you only want MCP-compatible agent access, implement MCP. If you want ChatGPT commerce, add ACP. If you want Google AI discoverability, add UCP. AP2 becomes necessary when payment networks require cryptographic proof of agent-initiated transactions at scale.
Are UCP and ACP competing standards?
They address the same problem domain (agentic checkout) but with different architectural philosophies. UCP is decentralized – merchants publish capabilities, any agent can discover and transact. ACP is platform-mediated – merchants submit data to OpenAI, ChatGPT surfaces it. In practice, merchants will likely implement both to maximize distribution, similar to how retailers list on both Google Shopping and Amazon. The protocols are converging in design: ACP’s January 2026 release adopted capability negotiation and payment handler patterns that mirror UCP.
What is the relationship between MCP and the commerce protocols?
MCP is a transport layer, not a commerce standard. Both UCP and ACP can be implemented as MCP servers, meaning their commerce-specific operations (product search, cart management, checkout) become MCP tools callable by any MCP-compatible agent. Think of MCP as the wire protocol and UCP/ACP as the application protocol – analogous to HTTP vs. REST.
How does AP2 relate to Stripe’s SharedPaymentTokens in ACP?
Both solve the same problem – secure payment authorization without exposing credentials to agents – but with different mechanisms. AP2 uses Verifiable Digital Credentials (W3C standard) with cryptographic mandate signing, providing a decentralized, PSP-agnostic authorization chain. ACP’s SharedPaymentTokens are single-use, time-bound tokens provisioned through Stripe’s Delegated Payment spec, tightly coupled to Stripe as the payment processor. AP2 is more general; SPTs are more pragmatic today.
Can I use A2A without UCP?
Yes. A2A is a general-purpose agent communication protocol. You can build agent-to-agent workflows (customer support delegation, inventory queries, logistics coordination) without any commerce semantics. UCP adds commerce-specific capabilities on top of A2A for shopping, checkout, and order management. A2A without UCP is useful for non-transactional agent collaboration.
What happens if a merchant supports UCP but not ACP?
That merchant’s products are discoverable and purchasable via Google AI Mode, Gemini, and any UCP-compliant agent, but not via ChatGPT’s Instant Checkout. And vice versa – an ACP-only merchant is visible in ChatGPT but invisible to UCP-compatible agents. For maximum reach, support both. The implementation effort overlaps significantly since both use similar checkout session models and can share backend logic.
Where does Shopify fit in all of this?
Shopify is uniquely positioned across the entire stack. It co-developed UCP with Google, supports ACP (over one million Shopify merchants are in ChatGPT), ships MCP endpoints on every store by default, and operates the Catalog MCP server for cross-merchant discovery. Shopify’s Agentic Storefronts feature allows merchants to configure their data once and have it distributed across all agent surfaces – ChatGPT, Google AI, Gemini, and others – from a single admin interface.
Sources
- UCP Specification – Google + Shopify
- UCP GitHub Repository
- Under the Hood: Universal Commerce Protocol – Google Developers Blog
- ACP Specification – OpenAI + Stripe
- ACP GitHub Repository
- Developing an Open Standard for Agentic Commerce – Stripe Blog
- AP2 Specification – Google
- AP2 GitHub Repository
- Announcing Agent Payments Protocol (AP2) – Google Cloud Blog
- A2A Protocol Specification – Linux Foundation
- A2A GitHub Repository
- MCP Specification – Anthropic
- x402 Specification – Coinbase / x402 Foundation
- Shopify Agentic Commerce – Shopify Developer Docs
- OpenAI’s ACP vs Google’s UCP – Checkout.com
- Making Sense of the AI Shopping Protocol Moment – PayPal
Hexagon Team
Published March 8, 2026
