What Is AP2? A Payment Protocol Whose Own Glossary Puts a Human Back in the Loop

A payment protocol for agents has to answer a question a payment rail never had to: on whose authority is this agent spending, and how would anyone check.

What it is, from their repository rather than our notes

An open protocol for payments initiated by AI agents, published under a permissive licence with a specification, a software kit and reference samples. Their repository reports a creation timestamp of May 2025, which places it a year before this surface of ours existed.

It is not ours, we did not write it, and we have no relationship with the people who did.

Their vocabulary, quoted rather than paraphrased

A mandate is an authorisation from a person to an agent to act on their behalf.

An open mandate is not yet bound to a particular action and carries constraints. A closed mandate is bound to one, with a verifier.

A checkout mandate authorises completing a checkout; a payment mandate authorises paying for one.

And a mandate receipt is a signed token recording the result of an authorisation.

Those are their terms, from their glossary, and a reader can check every one of them against the same file in one request.

The part that deserves more attention than it gets

Their glossary defines the authorising interface as a trusted surface: a secure, NON-AGENTIC interface that renders the mandate content to the person and takes their consent.

So the protocol's own architecture puts a human at the authorisation moment, deliberately. The agent proposes; a person sees what is being authorised, on a surface the agent does not control, and agrees.

That is a design choice worth naming plainly, because the surrounding conversation is usually about removing humans from loops. Their answer to "can an agent spend money" includes a screen a human reads.

And it reframes the machine-customer question this estate wrote about earlier. The chain of things a buying agent needs does not require full autonomy. It requires a bounded delegation somebody consented to, which is a much more tractable problem and a much less dramatic one.

Where we are, said as a gap

We do not settle. No value moves through us, in any direction, under any arrangement, and we are not a payment protocol.

And we have no trusted surface. Nothing on this surface renders anything to a person for consent. Everything here is issued through an interface by an operator holding a credential, which is a different trust model from the one their protocol describes, and the difference is a gap on our side rather than a philosophical position.

The identity header we do publish is not a payment authorisation. It binds the request method, the path and a timestamp, and nothing about an amount, an asset or a recipient. A service seeing it travel beside a payment must not read it as approving that payment.

What composing would mean, stated narrowly

Their protocol answers whether a payment is authorised. A credential answers who the actor is and what somebody attested about them.

Those are different questions, and an authorisation is more meaningful when the party it was granted to is identifiable to somebody outside the transaction.

What this page will not claim

No adoption or volume figures, which belong to them and which we did not verify.

No endorsement, no partnership and no contact of any kind.

And no assertion about what their protocol lacks. Their design is theirs to describe, and this page quotes their glossary rather than characterising their gaps.

What is real on our side

A credential format that is a published standard, and an identifier method registered in the W3C DID Method Registry.

A live passport in a public registry, readable with no account.

And a clear boundary: identity checking happens on another surface, we ingest the result, we issue attestations, and we move no money.