Four protocols, one problem, four different cuts through it
An agent that wants to buy something on a person's behalf has to solve four
separate problems: reach a tool at all, find out what a merchant sells, agree a
price, and pay. Four public specifications now address different parts of that,
and they are easy to confuse because three of them are recent and two of them
share an acronym. This is a reading of what each one covers, from its own
documentation, fetched today.
Nothing here is a comparison of quality, and no relationship is claimed with any
of them.
MCP: how an agent reaches a tool
The Model Context Protocol, at modelcontextprotocol.io, fetched 16 September
- Current specification revision
2026-07-28.
It standardises the connection between an LLM application and an external
capability, over JSON-RPC 2.0, between hosts, clients and servers. A server
offers resources, prompts and tools. It says nothing about commerce, which is
the point: it is the layer underneath, and a commerce API can be exposed through
it the same way anything else can.
If the question is "how does my agent call a thing", this is the answer and the
other three are not.
ACP: how a checkout happens inside an agent
The Agentic Commerce Protocol, at agenticcommerce.dev, fetched 16 September
- "Stripe and OpenAI developed the Agentic Commerce Protocol to define a
common language for how agents and businesses transact." Apache 2.0, REST and
MCP compatible, with ChatGPT named as the first AI platform implementation.
OpenAI's developer documentation, fetched the same day, splits the work in two:
merchants implement the Agentic Checkout Spec, payment service providers
implement the Delegated Payment Spec, and product feed data arrives by API or by
SFTP.
The centre of gravity is checkout and payment. A merchant integrating it is
answering the question "how does a purchase complete inside an agent surface".
AP2: how a payment is authorised and proven
The Agent Payments Protocol, at ap2-protocol.org, fetched 16 September 2026.
Google, described as "an open protocol for the emerging Agent Economy", at
v0.2, published as an extension of the Agent2Agent (A2A) protocol.
Its subject is authorisation rather than catalogue: verifying that a user
actually authorised a purchase, that a transaction is authentic, and that there
is a tamper evident record of who agreed to what, using cryptographically signed
verifiable digital credentials. Standardisation work is underway in FIDO
Alliance working groups.
If the question is "how do we prove the human agreed to this", that is AP2 and
not the others.
OSP: what a merchant publishes before any of that
Which is where this project sits. Specification v3.0, wire revision
2026-03-01.
OSP is about the part before checkout: what an agent may see, what it may be
offered, and what it may not do. A storefront publishes a manifest declaring its
capabilities, and an agent reads that declaration before it asks for anything. A
catalogue read needs no credential. Prices come from the catalogue and never
from the request body. Cresva is not in the payment path at any point: completing
a checkout session returns a link the buyer opens to pay the merchant.
The custody position is the clearest line between OSP and ACP. ACP's own
documentation puts a delegated payment spec at the centre of the design. OSP
hands the buyer back to the merchant's own checkout and stops there.
They are not competing for the same slot
It is tempting to read four specifications as four candidates for one job. They
are not.
- MCP is transport and tool exposure.
- OSP is what a merchant declares and what an agent may read.
- ACP is how a purchase completes inside an agent surface.
- AP2 is how the authorisation behind a purchase is proven.
An agent could plausibly use all four in one transaction and each would be doing
something the others do not. Where they genuinely overlap, OSP and ACP both
describe a checkout, they disagree about who holds the money, and that
disagreement is a design position rather than a gap.
Reading them yourself
Every fact above is from the linked source, fetched 16 September 2026. These are
young specifications and three of the four moved this year, so check the version
string before you trust a summary, including this one.