AP2 vs ACP: Authorization Layer or Commerce Layer?
Two protocols dominate the “agent payments” conversation above the settlement rail: Google’s AP2 (Agent Payments Protocol) and ACP (Agentic Commerce Protocol), backed by Stripe and OpenAI. They sound interchangeable — both let AI agents buy things — but they answer different questions:
- AP2 answers: “Is this agent allowed to pay?” — mandates, spending limits, delegated authority.
- ACP answers: “How does an agent complete a purchase?” — discovery, checkout, payment, confirmation.
Most production systems will end up using ideas from both. Here’s how to choose where to start.
The 30-second answer
- Choose AP2 if your core problem is trust and control: an agent acting on a user’s behalf needs verifiable mandates, spending caps, and an audit trail before any money moves.
- Choose ACP if your core problem is the purchase flow itself: you want agents to discover products, check out, and pay — especially if you’re a merchant already on Stripe.
- You still need a settlement rail under both. That’s where x402 (or card rails in ACP’s case) comes in — see x402 vs AP2 for how the layers compose.
What they share
Both protocols assume a world where the buyer is software, not a person. Both therefore define machine-readable ways to express what is being bought and under what authority, and both are designed to sit on top of existing payment rails rather than replace them. And both are young enough that the open-source implementations in our protocols category are early but real.
What’s different
| Dimension | AP2 | ACP |
|---|---|---|
| Backer | Stripe + OpenAI | |
| Layer | Authorization & mandates | End-to-end commerce flow |
| Core concept | Verifiable credentials: intent mandates, cart mandates | Agentic checkout sessions |
| Primary user | Agent builders delegating payment authority | Merchants selling to agents |
| Settlement | Rail-agnostic (cards, x402, stablecoins) | Stripe-first, extensible |
| Question answered | ”May this agent spend, and how much?" | "How does an agent buy this item?” |
AP2: the authorization layer
AP2’s central object is the mandate — a cryptographically signed, verifiable statement of what an agent may do: which merchant, what category, how much, until when. A user issues an intent mandate (“buy me a flight under $400”); the agent later presents a cart mandate proving the specific purchase fits. Any party in the chain can verify the delegation without trusting the agent’s operator.
This solves the problem every team hits second (right after “hello world” payments): an agent with a wallet is a liability. Mandates turn unbounded spend into bounded, auditable authority. Read the AP2 guide for the mandate model in detail.
ACP: the commerce layer
ACP standardizes the shopping itself: an agent discovers a product, opens a checkout session, gets a priced offer, pays, and receives confirmation — all in a machine-readable contract. For merchants, the pitch is concrete: your existing Stripe account becomes sellable to agents (ChatGPT being the flagship buyer) without rebuilding your stack.
ACP deliberately stays above the rail: payment details plug into the session, whether that’s a card token or a stablecoin transfer.
How they compose with x402
The cleanest mental model of the 2026 stack:
- ACP structures the purchase (what, from whom, how much).
- AP2 authorizes it (the agent may spend this much, here).
- x402 settles it (USDC moves, request fulfilled).
They are complements, not rivals — which is why our agent payment protocols map places them on different layers.
The open-source reality check
Protocol specs are free; implementations are what matters. In the mpp.best directory:
- AP2 projects — mandate tooling, verifiable-credential libraries, and authorization demos. Smallest of the two families today; a genuine green field for builders.
- ACP projects — agentic checkout handlers and commerce demos, growing fast since the Stripe/OpenAI launch.
- The reference settlement layer remains coinbase/x402, and trust/escrow experiments like internet-court-skill show what mandate-style delegation looks like in practice (ERC-7710).
Which should you build on first?
- Building an agent that spends user money? Start with AP2-style mandates (even informally) plus an agent wallet with hard limits — authorization is where the risk lives.
- Running a merchant or API that agents should buy from? Start with ACP if you’re Stripe-native, or an x402 paywall if your buyers are crypto-native agents.
- Building infrastructure? The mandate/verification niche (AP2) is the least crowded and most defensible — see who’s already there in the AP2 category.
Bottom line
AP2 and ACP are layers, not competitors: one governs authority, the other governs the purchase. Pick the layer that matches the problem in front of you, and let x402 do the settlement underneath. For the full side-by-side of every protocol in the stack, see the protocol comparison.