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.
6 min read
What used to happen at this exact point
Everything else in this hub gets a purchase to the point of being ready. This is the protocol that finishes it.
An AI agent could do everything right, find the option, confirm it's genuinely available, even establish that the spend is authorised, and still hit the same wall: handing the person off to a normal web checkout to finish there instead. That's where a lot of otherwise-successful agent journeys used to fall over, at the last step rather than the first.
What UCP changes
UCP defines a structured checkout call an agent's own interface can complete directly: the item or booking, the confirmed price, the delivery or arrival detail, a reference to the payment authorisation already established. The business's system responds with a confirmed order, and whatever detail the agent still needs to relay back, a booking reference, a check-in time, without either side leaving its own interface.
What still has to be true before UCP can run
UCP only makes sense once everything else has already checked out: the agent's identity verified, the spend authorised, and the price and availability confirmed against live data. It doesn't check any of that itself, and it doesn't need to, because the item, the confirmed price, the delivery detail and a reference to the payment authorisation are already established by the time its own handshake begins. That's what makes it the last step rather than a new one: it turns an already-verified transaction into one the business's own systems recognise as done, not a fresh place to sell or another set of checks to pass.
One handoff a business never has to build itself.
Selfe handles the UCP handoff as part of every completed transaction it processes, so a business's booking or order system receives a confirmed, verified transaction the same way it would from any other channel, without building a separate checkout flow for agents.
Does UCP replace a business's existing checkout?
No, it sits alongside it, as the path for a transaction that started with an agent rather than a person browsing directly.
What does a business receive?
A structured, confirmed order or booking, the same core information its own systems already expect.
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.
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.