Preparing your checkout for agentic commerce

Declaring dev.ucp.shopping.checkout in your UCP profile is a promise. The profile is a description of what you support; your storefront is where that description turns out to be true or not.

This is about the second part: the things that make a checkout work perfectly for people and fail for software.

Accurate as of July 2026.

The gap between declaring and delivering

An agent that reads your profile now believes it can build a basket and complete a purchase. If your checkout then depends on dismissing a newsletter modal, the profile was accurate and the outcome is still a lost sale.

Nothing in the specification catches this. A conformance check tells you the declaration is valid; it cannot tell you the flow behind it works. That part is on you.

Patterns that break agents

Anything that must be dismissed

Cookie banners, newsletter popups, region selectors, app install prompts, the "are you sure you're in the right country" interstitial. Each is one click for a person and a wall for software that does not know the click exists.

The worst version is an overlay that intercepts pointer events while looking, in the DOM, as though the button underneath is perfectly available. The agent tries to click the real button, the overlay swallows it, and nothing happens with no error.

If you cannot remove these, make sure they are dismissible from the accessibility tree, properly labelled, and not blocking interaction with what is behind them.

State assembled across pages

A checkout that only works if the customer passed through product, then basket, then delivery, in that order, holding session state at each step, is a checkout that breaks the moment anything arrives sideways.

Agents do arrive sideways. They deep link, they retry, they open a step directly because that is where the useful control is. Each step should either work from a clean entry or redirect somewhere that does.

Controls that are not controls

A "size" selector built from styled divs with click handlers. A quantity stepper made of two icons. A delivery option that is a coloured card rather than a radio input.

These are invisible as controls to anything reading the accessibility tree. The agent can see text and cannot see that any of it is selectable.

The fix is the same fix as for screen readers: real form elements where possible, correct roles and states where not. If you have been deferring an accessibility audit, this is a second reason to do it, and the work counts twice.

Information rendered where software cannot read it

Prices baked into images. Stock status conveyed only by colour. Delivery timescales in a tooltip that appears on hover. Variant availability implied by a greyed-out swatch with no aria-disabled.

A person infers all of this instantly from visual context. An agent gets the markup, and the markup does not say it.

Timeouts tuned for humans

A basket that expires in ten minutes, or a checkout token valid for one submission attempt, assumes a person moving at human pace with no interruptions. An agent may pause for the person to confirm something and come back. Be generous, and fail into something recoverable rather than a dead session.

What good looks like

Semantic, labelled markup end to end. Every control a real control with an accessible name. This single thing fixes more agent problems than anything else on the list.

Each step works on its own. A direct request to any stage either functions or redirects cleanly.

State is explicit, not visual. Availability, selection and errors expressed in markup, not only in styling.

Errors say what to do. "Something went wrong" gives an agent nothing to act on. "Postcode not recognised, expected UK format" lets it retry correctly.

Nothing blocks the path by default. Consent and marketing interruptions belong where they cannot intercept the flow.

Where the human has to stay

There is a line worth drawing deliberately, because a checkout that is too easy to automate is its own problem.

Payment authentication is meant to involve the person. Strong customer authentication, 3-D Secure and passkey confirmations exist precisely to require a human decision at the point of payment, and you should not be trying to route around them for the convenience of an agent.

The emerging standards recognise this. AP2, now with the FIDO Alliance, exists to carry cryptographic proof that a human authorised a specific purchase at a specific price. The direction of travel is not "let agents pay unattended"; it is "let agents do the work, and prove the person agreed".

So the target is a checkout an agent can drive right up to the point of payment, where the human steps in. Everything before that should be machine-navigable. The authorisation itself should not be.

Testing it

You do not need agent infrastructure to find most of these problems.

Read the flow as text. Disable CSS and images and walk your checkout. Anything you cannot determine from what remains is something an agent cannot determine either.

Keyboard only. Complete a purchase without touching the mouse. Anything you cannot reach or operate is likely unreachable programmatically too.

Enter at each step directly. Paste the URL of your delivery step into a clean session. Does it work, redirect sensibly, or produce a broken page?

Run an accessibility audit on the flow. Most of what it flags is also an agent problem. This is the highest-value hour available.

Do this in order

Remove or unblock anything that overlays the path
Make every control a real, labelled control
Move state out of styling and into markup
Make each step survive direct entry
Loosen human-paced timeouts
Keep payment authentication firmly with the person
Then check your profile genuinely reflects what you support

The order matters. There is no point advertising a capability you cannot deliver, and no point perfecting a profile that points at a checkout an agent cannot use.