Three of these four standards answer the same question and the fourth answers a different one, which is why reading them as competitors produces a roadmap that cannot be built. ACP, UCP and AP2 all end at an instrument: who may be charged, and up to how much. Poppy ends at a session. If you are a merchant, that means the first three land on your checkout team and the fourth lands on whoever owns your login — and the fourth is the one you have not staffed.
At a glance
Four standards, four different assumptions about what an agent is. Dates are the public announcement; versions move, so treat every number here as current to late October 2026 and read the spec before you build.
| Standard | Backers | Announced | Assumes the agent is… |
|---|---|---|---|
| ACP — Agentic Commerce Protocol | OpenAI, Stripe | 29 Sep 2025 | the platform's buyer, checking out inside the platform's surface |
| UCP — Universal Commerce Protocol | Google, Shopify | 11 Jan 2026 | a channel into the merchant's own catalog and checkout |
| AP2 — Agent Payments Protocol | 2025 | a party presenting a verifiable authorization it did not write | |
| Poppy — Personal Agent Protocol | Sierra, Meta | 6 Oct 2026 | one user's delegate, signing in as that user at one company |
First, the acronym problem
ACP means three different things in agent documentation and only one of them is about commerce. The Agentic Commerce Protocol is the OpenAI and Stripe standard discussed here. The Agent Client Protocol is Zed's editor-to-agent protocol, which has nothing to do with payments. The Agent Communication Protocol was an agent-to-agent REST standard contributed to the Linux Foundation in July 2025 and subsequently folded into A2A. Search results mix all three freely, and a comparison article that treats ACP as an alternative to A2A means the dead one. This wiki keeps them apart at the Agent Client Protocol and ACP: what happened.
ACP: the platform owns the surface, the merchant gets a token
ACP was released under Apache 2.0 on 29 September 2025 alongside Instant Checkout in ChatGPT, with a versioned specification that now carries the date 2026-04-17. Its architectural commitment is that the buyer stays inside the platform: the agent presents the merchant's catalog and takes the order in the platform's own interface, and the merchant exposes an agentic-checkout API behind it.
The part worth reading closely is the Delegated Payment Spec, because it is the cleanest expression of the pattern every one of these standards eventually needs. The platform prepares a one-time delegated payment request with a maximum chargeable amount and an expiry, derived from what the user actually selected; the payment service provider returns a token; the platform hands that token to the merchant to complete the charge. The card never reaches the agent. OpenAI's own documentation is explicit that only PSPs or PCI DSS Level 1 merchants should integrate the spec directly, and Stripe's Shared Payment Token is described as the first compatible implementation — which tells you the realistic integration path for everyone else runs through a provider.
A bounded, expiring, single-use authorization is the correct shape for agent spend, and it is the same shape this site argues for in denial of wallet and cost attacks: the defence is a ceiling in the credential, not a promise in the prompt.
UCP: the merchant keeps the surface, any agent may transact
Google and Shopify announced UCP on 11 January 2026 at the National Retail Federation show, with co-developers including Etsy, Wayfair, Target and Walmart. The bet is the opposite of ACP's: the merchant publishes its capabilities, and any compatible agent can discover and transact against them, rather than the transaction happening inside one platform's chat window. Shopify merchants selling into AI Mode in Google Search and the Gemini app is the visible consequence.
For payment, UCP reaches outward rather than specifying its own — AP2 mandates arrive through an extension, so the agent can present a cryptographic authorization the merchant verifies. That is a deliberate layering decision and the sources disagree about how tight the coupling is, which is itself worth knowing before you plan around it. The practical reading: UCP standardises discovery, catalog and checkout, and defers the instrument.
Note what ACP and UCP are actually fighting about, because it is not technology. Both can carry a bounded token. The disagreement is whether the primary commerce surface becomes the agent's interface or stays the merchant's — a distribution question with a protocol attached. Walmart's Agent Gateway drew its own line on the same axis, which is the argument in the store opened, the wallet stayed shut.
AP2: not a commerce protocol at all
AP2 is the one most often miscategorised, because it appears in every commerce comparison and is not a commerce standard. It models intent, cart and payment as verifiable credentials — a signed, checkable record of what a human authorized an agent to do — and it sits above A2A and MCP rather than inside either. Its unit of work is the mandate, not the checkout.
Which makes it the only one of the four that composes cleanly with the other three: a mandate is something ACP, UCP or a bespoke integration can carry. The pitch to stay sceptical about is the stablecoin-rail framing that often travels with it, and the mechanics are in AP2 and agent commerce. Read AP2 as the audit layer and most of the confusion in this space dissolves: it answers "prove the human agreed", and it is indifferent to who built the storefront.
Poppy: the one that collides with your login
Sierra and Meta announced the Personal Agent Protocol on 6 October 2026 and published a draft on 9 October, with design partners that third-party trackers counted at roughly 35 companies. It is moving fast — SDK releases dated 18 October target draft 0.2 while published examples already carry a protocol_version of 0.3 — so the version number is not a thing to code against. A company publishes a document at /.well-known/poppy.json declaring how an agent opens a session, which sign-in methods and scopes it offers, and which routes exist: a conversational endpoint, APIs, or a website session the agent drives.
Three design choices make it a different kind of standard rather than another commerce dialect. The session starts signed out, and sign-in attaches an account to an already-running session — so your authorization check cannot live at connection setup, because at connection setup there is nobody to authorize. The standard scope vocabulary is two values, poppy:read and poppy:write, with the poppy: prefix reserved so you cannot mint a finer standard scope; anything more granular is a custom scope under your own naming. And the user identifier is stable at one company and different at every other, so two merchants cannot discover they are serving the same person by comparing what their agents presented.
Payment is named as future work, and that absence is the most informative line in the draft. A delegate has no instrument of its own to present; the protocol stops, correctly, at the edge of a question that requires an instrument holder. The mechanics and what they cost your backend are in Poppy: the Personal Agent Protocol.
Cross-cutting: the contested layer is identity, not payment
Compare the four on who the authenticated principal is and the shape of the field changes. Under ACP the principal is the platform's account — the merchant sees a trusted intermediary transacting with a bounded token, and the end user is someone the platform knows and the merchant largely does not. Under UCP the principal is whoever the merchant's own login says it is, with the agent as a channel. AP2 declines the question and instead carries a credential naming a subject, which is why it layers under either. Poppy makes the end user the principal directly, at the merchant, through a pseudonym the merchant cannot join with anyone else's.
Payment, by contrast, has converged. All three commerce-side standards land on the same primitive — a bounded, expiring, single-use authorization held by somebody who is not the agent — and they differ mostly in who mints it. That convergence is why the payment column is the boring one and the identity column is where the next two years of argument will happen: a bounded token is a solved engineering problem, and "which party holds the mapping from pseudonym to human" is a market-structure question that no specification can settle.
One asymmetry is easy to miss, and it cuts against the privacy reading of Poppy. The per-company pseudonym stops merchants correlating a user across each other. It does nothing to stop the agent, which is the single party holding every pseudonym at once and knowing which human they belong to. Poppy does not remove the cross-merchant join; it relocates it to the agent vendor. Whether that is an improvement depends on who you think should hold it, which is the principal-agent problem and not a technical dispute.
When to pick which
| If you are… | Implement first | Can defer | Because |
|---|---|---|---|
| A merchant with a PSP and traffic from assistant surfaces | ACP or UCP, whichever your sales channel actually sends buyers from | Poppy | Both are checkout integrations; your PSP carries the token work |
| A merchant whose own account is where the value lives (subscriptions, bookings, support) | Poppy | ACP, UCP | The hard part is a stranger's agent acting as your customer, not paying you |
| A platform or marketplace building the agent surface | ACP, then AP2 mandates | UCP | You are minting the authorization, so the instrument design is yours |
| In a regulated flow needing a record of consent | AP2 | the rest | It is the only one whose unit of work is the provable authorization |
And one thing to do regardless of which you pick, because all four push the same way: move your authorization check from the session to the individual action, and put a risk gate under the coarsest write permission you expose. That work is protocol-independent, it is a prerequisite for three of the four, and it makes you safer against the agents already driving your site with no standard at all.
FAQ
Are these four protocols competitors?
Only two of them are. ACP and UCP compete over whether the primary commerce surface is the agent's interface or the merchant's. AP2 layers underneath either as an authorization format, and Poppy addresses a different problem entirely — a personal agent signing in as a user — with no payment story at this stage.
Which one should a merchant implement first?
Follow where your buyers actually arrive from. If assistant surfaces are already sending you traffic, that integration pays first and your payment provider carries most of the work. If the value in your product sits behind a customer login rather than in a cart, Poppy is the one that touches your real problem.
Does Poppy handle payments?
No. The draft covers identity, sign-in, sessions and scopes, and names payment as future work. That is consistent with its design rather than a gap: it treats the agent as the user's delegate, and a delegate has no payment instrument of its own to present.
Why does ACP mean three different things?
Because three unrelated groups chose the same acronym: the Agentic Commerce Protocol (OpenAI and Stripe), the Agent Client Protocol (Zed, editor to agent), and the Agent Communication Protocol (contributed to the Linux Foundation in July 2025 and later folded into A2A). Check which one an article means before trusting its comparison.
How stable are these specifications?
Unevenly. ACP carries a dated versioned specification and has been in the field for a year. Poppy is a draft whose version moved twice in nine days in October 2026. Build against the discovery document a counterparty serves rather than against a revision string you read once.
Is the per-company pseudonym a real privacy win?
It is real and it is narrow. It makes cross-merchant correlation structurally unavailable to merchants, which is stronger than a policy asking them not to. It leaves the agent vendor holding every pseudonym for one person, so the join is relocated rather than removed.
Further reading
On this wiki:
- Poppy: the Personal Agent Protocol — the session model, the reserved scopes, and what the inversion costs your backend.
- AP2 and agent commerce — mandates as verifiable credentials, and the stablecoin pitch to stay sceptical of.
- Agent payments — the primitives underneath all four standards.
- Shopping and checkout agents — building the buyer side.
- Third-party agents logging in as your users — the problem Poppy standardises, as it exists today without a standard.