AgentReady.
Start free
Menu

Blog · Guide

Agentic checkout in 2026: how to make your site something an agent can act on

Where UCP, ACP and AP2 stand after ChatGPT Instant Checkout was retired, and how browser agents see your buy button. With a checklist.

By Sascha Hoffmann · Published · Markdown

A grid of small grey outlined buttons on a dark background, a dashed path winds across the grid and ends at the one button outlined in yellow.

An AI agent can complete a purchase with you in one of two ways: through a documented protocol or API it can call, or by operating your website like a very literal user who only sees your page as a list of controls.

Most sites are ready for neither. The good news is that the work for the second path is mostly plain, well-built HTML.

The short answer

If you run a shop, get onto a commerce protocol through your platform or payment provider where one is available, and declare any checkout API you have in your llms.txt.

Independently of that, make sure every step from product page to confirmation uses real form controls with distinct, descriptive labels, shows prices before login and does not hide the path behind a challenge on every click.

Where the protocols stand in September 2026

A year ago, the story was "the AI buys inside the chat". That story changed.

OpenAI launched Instant Checkout in ChatGPT in September 2025, built on the Agentic Commerce Protocol (ACP) it open-sourced with Stripe. In March 2026 OpenAI retired Instant Checkout. CNBC reported the new shopping experience focuses on finding and comparing products, with the purchase handed back to the merchant.

ACP itself continues, now mainly as the way merchants share structured product feeds and catalog data with ChatGPT's discovery.

Google took the other route. The Universal Commerce Protocol (UCP), co-developed with Shopify and announced at NRF on January 11, 2026, covers the whole journey from discovery and cart to checkout and orders. Merchants publish what they support in a manifest at /.well-known/ucp, and agents can reach those capabilities over REST, MCP or A2A.

The third name you will hear is AP2, the Agent Payments Protocol. It does not move money. It carries cryptographically signed mandates that prove the buyer authorised the agent to make this purchase, and UCP uses it as its payment authorisation layer.

The practical reading: these are layers more than rivals. UCP and ACP describe what is sold and how the cart works, AP2 proves consent, and payment providers increasingly speak several of them at once so individual merchants do not have to.

Why a protocol alone is not enough

Protocols only help where an agent is inside an ecosystem that speaks them. A lot of agent traffic is not.

Custom agents built by developers, research agents and the growing number of agentic browsers still arrive at your normal website and try to use it. For those, your storefront is the API.

This is also why our Check does not only reward a protocol. The actionable part gives credit for a recognised shop platform with an agentic storefront and for a documented API endpoint an agent can call, because either is a real path.

How a browser agent sees your buy button

Here is the detail that changed how I look at checkout pages.

Browser Use published an open agent in September 2026 that uses TypeSafe's Jev model to decide each step. On every observation, the page becomes a numbered table of visible elements, each labelled by type, such as button, combobox or textbox, with its current value. Jev then picks an operation and a target from that table in a single call. A small language model is only asked to write text when a field needs typing.

The fastbrowse project, built on the same model, puts the consequence plainly: the agent picks one of the candidates on the page, so it cannot click something that is not there.

Read that from the merchant's side. If your "Add to cart" is a div with a click handler and no role, it may not be a candidate. If your size selector is a custom widget with no accessible name, the agent sees an unlabelled element and has to guess. If five buttons on the page all say "Select", the agent is choosing between five identical options.

That last one is not hypothetical. One of the fixes listed in the fastbrowse release notes is teaching the agent to tell identically labelled controls apart. Your checkout should not need that fix.

A checklist for an agent-operable checkout

Work through your flow from product page to order confirmation with these in mind. Most of them are ordinary accessibility practice, which is not a coincidence: agents and screen readers both depend on the accessibility tree.

  • Use real controls. button, a, input, select. If a custom component is unavoidable, give it the correct role and an accessible name.
  • Make labels distinct. "Add Trail Runner 3, size 42 to cart" beats "Add". Where the visible text must stay short, an aria-label can carry the full meaning.
  • Label every form field. A label element tied to each input, with the expected format in the text ("Postcode, 5 digits").
  • Show the price before login. An agent comparing offers will not create an account to find out what you charge.
  • Offer guest checkout. An account wall in the middle of the flow ends most agent sessions, and plenty of human ones.
  • Do not challenge every step. Bot protection has its place, but a challenge on each click turns a three-step purchase into a dead end.
  • Keep irreversible actions explicit. A clear final "Place order and pay" step helps well-built agents stop and ask their user before committing, which is what you want too.

The markup difference is small. This is the pattern to avoid and the one to use:

<!-- Hard for an agent: no role, no name, no way to tell it apart -->
<div class="btn btn-primary" onclick="addToCart(8812)">Add</div>

<!-- Easy: a real button whose name says what happens -->
<button type="button" aria-label="Add Trail Runner 3, size 42, to cart">
  Add to cart
</button>

Declare what an agent cannot discover

If you have an order or quote API, an agent will not find it by reading your homepage. Say so where agents look.

A short section in your llms.txt is enough to make the path provable:

## Ordering

- [Order API documentation](https://example.com/docs/orders): create a quote and place an order via REST. Public product endpoints need no key.
- Checkout for humans and browser agents: https://example.com/checkout (guest checkout supported)

Our Check explicitly notes that an agent-usable path may exist behind a documented API we cannot see from outside, and that declaring it in llms.txt is what makes it visible. The llms.txt guide covers the file itself.

What to do if you do not sell online

If your domain does not sell anything directly, none of this is a failure. Our Check leaves the actionable part out of your score entirely instead of counting it as zero.

For service businesses the equivalent is a bookable next step: a clearly labelled contact or booking form that works without JavaScript tricks, and, if you have one, a documented booking endpoint declared the same way.

The honest part

Agent-completed purchases are still a small share of orders, especially in Europe. The wave that looked imminent a year ago turned into "discover in the AI, buy on the merchant's site" for most of 2026.

That does not make this work premature. The same fixes that let an agent operate your checkout make it faster to use with a keyboard or a screen reader, and they cost you nothing if agentic buying grows slower than the headlines suggest.

Run your domain through AgentReady Check to see where your actionable score stands, and whether we could find a shop platform or a declared API at all.