If you are a merchant trying to make sense of agentic commerce, two acronyms come up constantly: AP2 and ACP. They are easy to confuse because both appeared in 2025, both are open, and both describe agents buying things. But they answer different questions, and knowing which is which tells you what you actually have to verify.
At a glance
| AP2 (Agent Payments Protocol) | ACP (Agentic Commerce Protocol) | |
|---|---|---|
| Led by | Google, with 60+ payment and commerce partners | OpenAI and Stripe |
| Introduced | 2025, at ap2-protocol.org | 2025, powering Instant Checkout in ChatGPT |
| Core question | Did the buyer authorize this, and is it bound to this cart? | How does the order and payment move between agent and merchant? |
| Core artifact | Signed mandates (verifiable credentials), including a cart mandate bound to the exact basket | A checkout session plus a shared, delegated payment token |
| Payment model | Payment-method agnostic by design | Card-centric, via tokenized payment through existing rails |
| Merchant of record | Unchanged; AP2 is an authorization layer | Typically the merchant, who keeps the customer relationship |
| Open standard | Yes | Yes |
What AP2 actually does
AP2 is about provable authorization. Instead of an agent simply asserting "my user wants this," AP2 carries cryptographically signed mandates: tamper-evident credentials that capture the buyer's intent and bind it to specifics. A cart mandate, for example, ties the authorization to the exact basket and amount, so it cannot be quietly reused against a bigger order.
In the current AP2 drafts these mandates are expressed as selectively disclosable signed tokens, carrying a hash of the checkout so the cart cannot be altered after signing, and a key-binding claim so only the intended holder can present them. The practical upshot for a merchant: a valid AP2 mandate is something you can check, not just something you have to trust.
What ACP actually does
ACP is about moving the transaction. It defines a checkout session between the agent platform and the merchant, and a shared payment token that lets the purchase settle through normal card rails without the agent ever handling raw card details. It is the protocol behind agent checkout experiences shipping inside large assistants today, and it keeps the merchant in their usual role rather than inserting a new processor.
Where AP2 asks "is this authorized," ACP asks "how do we complete the order and collect payment." That is why the two compose cleanly rather than compete.
How they fit together
Picture a single agent purchase. AP2 supplies the proof that a real person authorized a specific basket at a maximum amount. ACP supplies the checkout session and the token that settles it. Adjacent network efforts, including Visa and Mastercard agent-payment programmes and Web Bot Auth for identifying the agent itself, sit alongside both. No single one of these answers every question at the till.
AP2 proves the buyer said yes. ACP moves the money. Web Bot Auth says who is knocking. A merchant needs all three answered, not one.
What this means for a merchant
You do not want to implement four protocols and re-implement them every time the specs move. The durable position is a merchant-side verification layer that recognizes the agent, verifies its AP2 cart mandate against the basket your server actually built, and checks ACP-style spend allowances before settlement, with a step-up to review when a payment needs extra authentication.
That is the role Agent Gateway plays. It does not replace your payment processor and it does not pick a winner among the protocols. It verifies authorization and cart binding, returns allow, review, or deny with a specific reason code, and records every decision. To see it in practice, read how it works on WooCommerce.