ACP vs AP2: Two Agentic Commerce Protocols Compared

ACP and AP2 both exist to let an AI agent complete a purchase on a user's behalf, but they authorize that purchase through genuinely different mechanisms. ACP (Agentic Commerce Protocol), from Stripe, OpenAI, and Meta, hands the merchant a narrowly-scoped payment token and lets the merchant process it through its own payment stack. AP2 (Agent Payments Protocol), from Google, builds a chain of cryptographically signed Mandates that records what the user actually authorized before any payment executes. Both are open, pre-1.0 standards evolving through 2026 — this post compares the mechanisms, not the marketing.

For the deep-dive on AP2's Mandate model specifically, see AP2 explained. This post assumes that background and focuses on the contrast.

Origins and current versioning

ACP was released under the Apache 2.0 license on September 29, 2025, originally co-developed by Stripe and OpenAI and documented at agenticcommerce.dev; Stripe's own documentation now describes it as created by Stripe, OpenAI, and Meta. It has shipped several versioned updates through early 2026 — capability negotiation in January 2026, extensions and discounts later that same month, and cart, feed, orders, and authentication updates in April 2026 — and was in beta as of February 2026 per public reporting. Re-verify its current production-maturity status and any specific merchant-count figures against Stripe's or OpenAI's own newsroom before citing them; those numbers move quickly and are easy to cite stale.

AP2 was announced by Google on September 16, 2025, with more than 60 launch partners across card networks and payment platforms. It shipped v0.2 on April 28, 2026, and Google announced the same day that it is donating AP2's governance to the FIDO Alliance. As of this writing, AP2 is pre-1.0 and mid-transition between Google stewardship and FIDO Alliance stewardship.

The core mechanism: scoped token versus signed Mandate chain

This is the structural difference that matters most.

Under ACP, the agent collects the buyer's payment selection and passes the merchant a payment token scoped narrowly enough that the merchant can charge it without ever seeing the underlying payment credential — the merchant then processes the charge through its existing payment infrastructure and payment service provider relationship, and stays the merchant of record throughout. The record of authorization is essentially the token's scope: what it was good for, and where it was redeemed.

Under AP2, authorization is not a single artifact but a chain: an Intent Mandate captures what the user asked the agent to do, a Cart Mandate captures the specific purchase the agent proposes, and a Payment Mandate authorizes payment against that specific cart. Because each Mandate is signed and references the previous one, any party — not just the merchant who processed the transaction — can later verify that what was paid actually traces back to what the user authorized. That is a materially different design goal from ACP's token: ACP optimizes for the merchant retaining control of a transaction it already knows how to process; AP2 optimizes for a portable, independently verifiable proof of authorization.

Where each one keeps commerce infrastructure unchanged

Both protocols share a design instinct worth naming directly: neither one tries to become a new payment rail. ACP is explicit that the business remains the merchant of record and keeps using its existing payment service provider — ACP is the layer that gets a compliant checkout token from agent to merchant, not a replacement for how the merchant actually settles funds. AP2 similarly does not replace card networks, ACH, or existing rails; the Mandate chain is an authorization and evidence layer that sits on top of however payment is ultimately executed.

Where they diverge is what "compliant" checkout looks like from the merchant's side. ACP-compliant businesses implement agentic checkout, cart and feed, delegated payment, delegated authentication, and orders/webhooks as composable building blocks against Stripe's documented spec — a REST- and MCP-compatible integration pattern. AP2 compliance means being able to generate, sign, and verify the three Mandate types and check a Payment Mandate against its referenced chain before settling.

Delegated authentication: a distinguishing detail

ACP explicitly builds delegated authentication into the protocol using OAuth 2.0, letting an agent act on a buyer's behalf with a specific business without the buyer re-authenticating for every transaction — the same delegation pattern discussed generally in agent-to-tool authorization via token exchange, applied to commerce rather than tool calls. AP2 does not center delegated authentication the same way; its authorization question is answered by the Mandate chain itself rather than by an OAuth grant establishing that the agent may act for the user in the first place. In practice, a real deployment is likely to need both kinds of delegation reasoning — proving the agent may act for the user at all, and proving what specific action the user actually authorized — regardless of which commerce protocol sits on top.

Which protocol fits which buyer

Neither protocol has "won," and both are pre-1.0. A rough decision lens, not a recommendation of one over the other:

• If your business already runs a Stripe-adjacent or OpenAI-agent-facing checkout and wants to stay merchant of record with minimal change to existing payment processing, ACP's scoped-token model integrates closer to what you likely already have.
• If your priority is a portable, independently verifiable audit trail of what a user authorized — particularly for dispute resolution, compliance, or cross-platform interoperability where the payment might not be processed by the party that captured the authorization — AP2's Mandate chain is purpose-built for that.
• If you operate across both ecosystems, plan to support both rather than betting on one; card networks and major platforms are backing AP2 while OpenAI, Stripe, and Meta back ACP, and buyer-side agents may arrive using either.

Whichever protocol you evaluate, treat the version number and production-maturity claims as perishable facts. Both protocols are actively developed, pre-1.0, and have shipped breaking or additive changes multiple times within a single year — the same discipline this blog recommends for tracking MCP's 2026-07-28 spec revision applies equally here.

External authorization versus internal spend governance

Both protocols answer the same narrow question — was this specific external purchase authorized, and can that authorization be verified after the fact — and neither one answers a related but separate question: how much is an agent allowed to spend in total, across every purchase and every tool call, before someone needs to intervene. That is internal spend governance, and it sits alongside ACP and AP2 rather than being replaced by either. An agent could hold a perfectly valid ACP checkout token or a correctly signed AP2 Payment Mandate for an individual transaction while still being on pace to blow through a monthly budget across many such transactions, the same failure mode covered in threat modeling runaway agent spend and addressed with mechanisms like hard spend caps and the choice between budgets and rate limits. Internal ledgering of what an agent has consumed — the concern behind credit wallets for agent payments — and per-transaction external authorization via ACP or AP2 are complementary controls, not substitutes for each other, and the broader discipline both feed into is covered in FinOps for AI agents.

Common questions

Is ACP or AP2 more widely adopted? Both report significant backing — ACP from Stripe, OpenAI, and Meta with a growing set of implementing businesses, AP2 from more than 60 launch partners including major card networks. Neither protocol has published adoption figures solid enough to declare a clear leader as of this writing, and both are still pre-1.0; verify current adoption claims against each project's own primary sources before repeating a specific number.

Can a business support both ACP and AP2? Yes, in principle — the two are not mutually exclusive integration targets, since they operate at the authorization layer above existing payment processing rather than replacing it. A business that wants to be reachable by agents built on either standard would need to implement both.

Does either protocol replace my existing payment processor? No. Both ACP and AP2 explicitly sit above existing payment rails and processors. ACP keeps the business as merchant of record processing through its existing payment service provider; AP2's Mandate chain is an authorization and evidence layer, not a settlement mechanism.

What is the single biggest mechanical difference between them? ACP authorizes a purchase with a scoped payment token the agent hands the merchant; AP2 authorizes it with a chain of signed Mandates (Intent, Cart, Payment) that any party can later verify independently. Token-based authorization is simpler to integrate against existing checkout flows; Mandate-chain authorization produces a more portable, independently verifiable audit trail.

Are ACP and AP2 finished specifications? No. Both are pre-1.0 as of this writing. ACP has shipped multiple versioned updates through April 2026 and was reported in beta as of February 2026; AP2 is at v0.2 and mid-transition to FIDO Alliance governance. Re-check both before treating either as a stable, unchanging interface.