ACP, AP2, and MCP are three different layers of the agentic-commerce stack, not rival standards. ACP (OpenAI, Stripe) is the commerce/checkout layer and today mostly reports a product discovery plus a merchant-redirect click, not a completed sale. AP2 (Google) is the payment-consent layer and generates signed Mandates - a genuinely new, auditable record type - but only where a payment processor has wired AP2 into its rails. MCP is neither: it's the general agent-to-tool connection layer, and it emits no commerce record of its own.
Landscape as of September 2026: ACP's in-chat Instant Checkout was rolled back March 2026; AP2 moved to FIDO Alliance governance April 2026. Both are still moving monthly - recheck before citing either as settled.
Why "which protocol wins" is the wrong question for measurement
Every explainer on this stack answers an engineering question: how does an agent authenticate, discover a product, or move a payment. That's the right question for whoever builds the integration. It is the wrong question for whoever has to report on what these agents did to your funnel. The measurement question is narrower: what record does each layer actually leave behind, and can you capture it? That's what this page answers - not another rundown of what each acronym stands for.
The four layers, in the order they touch your data
ACP (Agentic Commerce Protocol) - OpenAI + Stripe, the checkout/commerce layer. Shipped September 2025, still maintained under Apache 2.0 with a dated-snapshot versioning scheme (latest stable spec update 2026-04-17, which added cart, feed, orders, authentication, and MCP-compatibility building blocks). Its consumer-facing Instant Checkout (buy inside ChatGPT) was rolled back in March 2026 after limited merchant uptake; the model since is product discovery inside the chat, then a redirect to the merchant's own site to complete the purchase.
AP2 (Agent Payments Protocol) - Google, the payment-consent layer. Announced September 2025 with 60+ launch partners (Mastercard, PayPal, Amex, Coinbase). Its core primitive is three signed Mandates - Intent, Cart, and Payment - issued as W3C Verifiable Credentials, meant to prove what a customer actually authorized their agent to do. Donated to the FIDO Alliance in April 2026, where two new working groups (Agentic Authentication, and Payments - chaired by Mastercard and Visa) now govern it alongside Mastercard's Verifiable Intent framework. ACP and AP2 are explicitly complementary layers: a single agent-driven purchase can use ACP for discovery and checkout mechanics while AP2 governs the payment consent underneath it.
MCP (Model Context Protocol) - Anthropic, the general agent-to-tool connection layer. Not commerce-specific: it's how an agent calls any tool, and ACP's own 2026-04-17 update added MCP compatibility so an ACP-aware storefront tool can be exposed through an MCP server. MCP itself carries no checkout or payment semantics - what you can capture from it is tool-call traffic, not a sale.
WebMCP - a page declares its own in-page tools (search, add-to-cart, checkout) that an agent calls directly, without scraping the DOM. Also in this stack by name only, not yet a measurement concern: A2A (agent-to-agent coordination), x402 (a payment-over-HTTP scheme), and UCP (Google's newer universal-cart framing, per some reporting the successor surface agentic checkout moved toward after ACP's Instant Checkout retreat - hypothesis, unverified which vendor's cart abstraction becomes the de facto one).
What each layer actually reports (the table the vendor pages skip)
| Layer | What it reports | Can you capture it server-side today |
|---|---|---|
| ACP | A product recommendation + redirect click - not a completed sale unless your own site logs the resulting session and checkout | Yes - it arrives as a normal referred session or a referrer-less direct hit, same capture problem as any other agent traffic |
| AP2 | A signed Mandate (Intent/Cart/Payment) - a structured, auditable consent record, when it exists | Only where your payment processor or card network has built AP2 support into its own rails; hypothesis - broad analyst-facing export tooling for Mandates does not yet exist as of Sept 2026 |
| MCP | Tool-call requests and responses between an agent and a tool server | Yes, if you run or instrument the MCP server yourself; no, if it's a third-party server outside your control |
| WebMCP | Client-side tool invocations a page exposes to an agent | Depends entirely on whether you log invocations server-side - tooling here is largely unbuilt; hypothesis given the standard's immaturity |
Why the ACP rollback matters more to you than the protocol news
Because Instant Checkout retreated to discovery-plus-redirect, most agentic-commerce traffic that reaches your own site in September 2026 does not arrive looking like a distinct "ACP event." It arrives looking like an ordinary referred session, or - per the wider undercounting problem - a referrer-less hit that a standard analytics setup drops entirely. The fix is the same one this cluster argues everywhere else: capture and reconcile it server-side, because an estimated majority of AI-agent referrals are already invisible to standard analytics, and agentic commerce specifically needs its own line in your attribution model, not a fold into "Direct" (see AI as the newest channel your attribution must cover).
What AP2's Mandates give you that ACP's current model doesn't
A Mandate is a materially different measurement primitive than a UA string or a referrer: it is signed and, in principle, verifiable independent of the request that carries it. hypothesis, unverified as of this writing: if AP2 Mandate data becomes routinely exportable to measurement stacks, it would let an analyst distinguish "an agent completed this on record consent" from "an agent completed this and we're inferring consent from context" - a distinction today's tooling can't make. That capability does not exist broadly yet; FIDO governance only started in April 2026, and the consent question itself - whether an agent can legally act and consent on a customer's behalf - is still open (see can an AI agent legally consent on your customer's behalf).
What to build now, given all of this keeps moving
Don't wait on protocol maturity to decide your measurement approach. Server-side capture of agent sessions, reconciled against your own checkout events, answers the question regardless of which protocol a given agent used to get there - the same logic behind agentic commerce attribution elsewhere in this cluster. Treat ACP, AP2, and MCP as three things to watch, not three things to instrument separately today.