Skip to content

What UCP reaches

UCP's checkout capability is a narrower contract than the Sessions API. This page says exactly where the edges are and what to use instead — so you find out here rather than three days into an integration.

How to read this

AgentAgent
Works end to end from the agent. No browser step.
EscalatesEscalates
Starts in the agent and finishes in the browser: the session returns requires_escalation with a continue_url that resumes where you left off.
ElsewhereElsewhere
Outside the checkout capability entirely. Use the public GraphQL API, the public MCP server, or webhooks.

Coverage

Every row of the Sessions checkout surface, and where it lands.

Products
PassesAgent
Bought and fulfilled through the agent, provided the buyer's identity is linked — the remaining visits have to live on an account.
Gift cardsAgent
Bought and fulfilled through the agent, anonymously or linked.
MembershipsEscalates
A membership is a subscription with its own recurring-charge consent and mandate. Consenting on the buyer's behalf isn't ours to do, so it always escalates.
Physical productsEscalates
No shipping address is collected, because UCP's fulfillment capability isn't implemented. Always escalates.
Gifting a productElsewhere
Buying a product for someone else, with a recipient and a scheduled send, has no UCP shape. Use purchaseProduct on the public GraphQL API.
Registrations
Class registrationAgent
One scheduled class session, registered for the buyer.
Waivers & intake formsEscalates
A waiver, contract, or required intake question has to be answered by the buyer, and UCP has no vocabulary for collecting it. Escalates.
WaitlistsEscalates
Joining a waitlist is a different promise from buying a spot, so the buyer should see it. The message carries requires_buyer_review and a link.
Choosing a spotEscalates
Sessions with assigned spots (a bike, a mat, a lane) need the buyer to pick one. Escalates.
Appointment bookingElsewhere
Booking a time range on a bookable activity isn't a line item — it's a start and an end. Use bookActivityTime on the public GraphQL API.
League & team sign-upElsewhere
Team and division sign-up has its own multi-step flow. Use the public GraphQL API.
Registering a child or guestElsewhere
Registering a child or a guest needs that participant's details, which UCP's buyer object doesn't carry. Use the public GraphQL API.
Money
Card paymentAgent
Charged on the business's connected account with the token you supply.
Free checkoutAgent
A zero-total checkout completes with no credential at all.
Discount & gift-card codesAgent
Both are supported, through a Sessions-namespaced extension on the checkout object.
Sales taxAgent
Computed by the same engine as the website, and reflected in the totals column before you complete.
3-D SecureEscalates
A bank challenge needs the buyer present. Escalates, with the payment left recoverable.
Paying with an existing passElsewhere
Paying for a registration by spending an existing pass or membership isn't a payment instrument in UCP's model. Use registerForActivity with a productPurchase.
The buyer’s saved cardsElsewhere
The buyer's cards saved in Sessions aren't selectable from an agent — you supply your own token. Saved cards stay a browser feature.
Refunds & cancellationsElsewhere
UCP cancel abandons an unfinished checkout; it never reverses a completed order. Cancelling a registration is cancel_registration on the public MCP server, and refunds are the business's to issue.
Around the purchase
Browsing what’s for saleElsewhere
There is no UCP catalogue capability, so an agent arrives with an item id. Find items with the public MCP server's discovery tools or the public GraphQL API.
Reading past ordersElsewhere
The checkout session returns its own order; reading a buyer's history is my_registrations on the public MCP server.
Order lifecycle eventsElsewhere
Order lifecycle events aren't emitted in UCP shape yet. Sessions' own signed webhooks already cover confirmation, purchase, and cancellation.

Shape of a checkout

Constraints that come from how Sessions sells, not from the protocol.

One line item
A checkout session takes exactly one item. Sessions' checkout buys one product or books one session per order, and splitting a basket across orders would silently change what the buyer pays.
Quantity is always 1
There is no quantity on a Sessions purchase — a pass is a pass, a seat is a seat. A request with a quantity above 1 is rejected rather than quietly rounded down.
Passes need a linked identity
Passes and memberships attach to an account, so they need OAuth identity linking. Gift cards and registrations don't.
Anonymous checkout is a business setting
Buying without a linked identity requires the business to have guest checkout enabled. When it's off, the session escalates so the buyer can sign in.
Paid checkout needs Stripe onboarding
A business that hasn't finished Stripe onboarding can still sell free items through UCP, but a paid checkout has nowhere to charge.

Parts of UCP not implemented

The spec is broader than what Sessions advertises. Nothing here is announced in the manifest, so a conformant agent already knows not to try — this is for humans planning an integration.

Cart capability
No dev.ucp.shopping.cart. Checkout sessions are the only container.
Fulfillment capability
Not implemented. Every checkout omits the fulfillment object, which is the spec's shape for a digital or service transaction.
Discount capability
Not implemented. Codes ride in a Sessions extension instead.
Order capability
Not implemented. There is no GET /orders/<id> and no UCP-shaped lifecycle webhook.
Message signing
No HTTP message signatures on requests or responses, and signing_keys is advertised empty rather than populated with a key nothing signs with.
Embedded (ECP) transport
Implemented: an agent host frames the checkout and drives it over postMessage, with payment delegated to the host so no card input is ever framed. Available on every public business.
A2A transport
Only rest, mcp, and embedded are advertised.
Localized messages
Protocol messages are English regardless of Accept-Language. Product and session names come back in the business's own content.

Reaching the rest

Everything marked Elsewhere is reachable today — just not through this capability. The public GraphQL API is the full surface the Sessions website itself uses, and the public MCP server wraps its most common tasks as agent tools.

Discovery pairs well with UCP
An assistant can browse a business's schedule with the public MCP server, then hand the session id it found straight to create_checkout — the ids are the same.

The full public schema is documented field by field. Public GraphQL API

Next

Checkout referencePublic MCP serverWebhooks