What a checkout API call looks like from the other side.
Strip away the protocol names and an AI agent completing a purchase is, from a business's own system, just another API request arriving with a specific, checkable shape. Here's roughly what lands, and what a business's system has to do with it.
6 min read
The request that arrives
Pull back the protocol names and what lands on a business's server is a single, structured request, worth looking at directly.
A checkout call carries a handful of things together: the item or booking being confirmed, the price agreed at the moment it was quoted, a credential reference proving which agent is making the request, a mandate reference proving the spend was authorised, and an idempotency key, a unique tag for this exact attempt. None of it looks unfamiliar to a system that already processes online orders. It's just arriving with an agent's credentials attached instead of a person's session.
What a business's system has to check, in order
Whether the credential is valid and hasn't expired, first. Whether the mandate covers this amount, the same check AP2 defines, second. Whether the price quoted still matches what's live, third, since availability and rates can shift between an agent's first look and its final request. And whether the idempotency key has already been seen, to catch a duplicate before it becomes a duplicate booking or a duplicate charge.
What it sends back
A confirmed reference: a booking number, an order ID, whatever the business's system already generates for a normal transaction. Plus anything the agent needs to relay back to the person it's acting for, a check-in time, a contact number, cancellation terms, so the confirmation is useful once it reaches them.
Why the idempotency key matters more than it looks
An agent can retry a request that appears to have failed, a timeout, a dropped connection, without knowing whether the first attempt succeeded. Without an idempotency key, a business's system has no way to tell a genuine second request from a retry of the first, and ends up double-booking or double-charging on exactly the requests that were already technically fine.
What a business's own system never has to do
Selfe runs this whole sequence, credential, mandate, price, idempotency, for every checkout it processes, so a business's own system only ever sees the result: a confirmed order, not four separate protocol checks it has to implement and maintain itself.
Do we need to build all these checks ourselves?
Not with Selfe. The sequence runs automatically, and a business's system only sees the confirmed result.
What if the price has changed since the agent last checked?
The request is refused rather than silently honoured at the old price, so the business never completes a sale at a rate it no longer offers.
The plumbing behind every agent purchase.
Every purchase an AI agent completes, whatever it's buying, passes through the same four jobs: proving who the agent is, proving what it's allowed to spend, connecting to the business's own systems, and completing a transaction the business can settle. The protocols in this hub each do one of those jobs. None of them does all four.
Holds, mandates and spend limits: how a business keeps control of an automated payment.
A mandate only says what an AI agent was allowed to try. What protects a business is what happens on its own side of the transaction: the hold it places, the ceiling it enforces, and the mandate scope it insists on before a booking or order is allowed to proceed.
UCP and the checkout handoff: what changes when a purchase completes inside the conversation.
Every other protocol in this hub gets a purchase ready. UCP is the one that completes it: the point where a business hands back a confirmed order without sending the customer off to finish the job on a website.