Under the Agentic Commerce Protocol, an agent does not click through your checkout UI. It exchanges structured messages with your backend, and your checkout has to return specific, machine-readable responses at each step: a priced and validated cart, available fulfillment and payment options, and a confirmed order with a stable identifier. If any of these comes back as HTML, as an ambiguous error, or as a human-only flow, the agent cannot complete the purchase and abandons it. This is what your checkout must return at each stage, and where existing checkouts most often break.
The Agentic Commerce Protocol, co-developed by OpenAI and Stripe and behind ChatGPT Instant Checkout, forces a shift that is conceptual before it is technical. Your checkout was built for a human: a sequence of pages, forms, buttons, and visual confirmations. ACP requires you to expose that same flow as a structured exchange, where the buyer is an agent that reads responses and makes decisions programmatically. The agent never sees your checkout page. It sees what your backend returns, and it needs that to be clean, complete, and unambiguous at every step.
Most checkouts fail not because they lack the capability but because the capability is locked inside a human interface. The cart total exists, but it is rendered into a page rather than returned as a value. The shipping options exist, but they appear as radio buttons rather than a structured list. ACP compliance is largely the work of exposing what you already have in a form an agent can consume. Here is what has to come back at each stage.
Stage 1: Cart validation must return a priced, validated cart
When an agent submits items to your cart, it needs back a complete, structured statement of what that cart is: each line item with quantity, the validated availability of each, the itemized price, tax, any discounts, the total, and the currency. The agent uses this to confirm the purchase still matches what the user wanted before it proceeds. If the price changed, if an item went out of stock, if tax shifts the total beyond a threshold the user set, the agent needs to know from the response, not from a rendered page it cannot read.
The most common break here is that the total is computed server-side and then written into HTML rather than returned as a value. A human sees "$142.50" on the page; an agent receives a blob of markup it has to scrape, and scraping a price out of HTML is exactly the fragile, error-prone step ACP exists to eliminate. Return the cart as structured data with every monetary value as a typed number in a named field.
Stage 2: Fulfillment options must return as a structured list
The agent needs to choose a shipping method on the user's behalf, which means it needs to see all of them as a list it can enumerate and compare: each method with its cost, delivery estimate, and eligibility for this cart and destination. A human reads three radio buttons and picks one. An agent needs those same three options as structured entries with comparable fields, so it can apply the user's preference, fastest, cheapest, or whatever was specified.
Checkouts break here when fulfillment options are generated as interactive UI elements with no structured equivalent. The options exist, but only as things a human can click. The fix is to expose the same fulfillment logic as a structured response: given this cart and this destination, here are the available methods as data. The eligibility logic you already run to decide which options to show a human is the same logic; it just needs a machine-readable output path.
Stage 3: Payment handoff must not require a human
This is the hardest stage and the one most likely to block ACP entirely, because payment is where human-only assumptions are most deeply baked in. Many checkouts route payment through a widget, an iframe, or a redirect that assumes a human will type a card number and pass a challenge. An agent cannot do that. ACP defines structured ways for an agent to submit payment on the user's behalf, often through tokenized or delegated payment methods the protocol specifies, so that the sensitive step happens through a channel built for agents rather than a form built for fingers.
The practical implication is that you may need to accept payment methods and flows you currently do not. A checkout that only accepts a card typed into a hosted field is a checkout no agent can complete. Supporting the payment handoff the protocol defines is often the single largest piece of ACP implementation work, and it is the one to scope carefully because it touches your payment processor and your compliance posture.
Stage 4: Order confirmation must return a stable identifier
When the purchase completes, the agent needs proof it can hold and reference: a stable order ID, a confirmed status, the total actually charged, and the fulfillment timeline. This is what the agent reports back to the user and what it uses if it needs to check on or modify the order later. A thank-you page that says "your order is confirmed" with no machine-readable identifier leaves the agent unable to confirm the transaction succeeded or to reference it afterward.
The break here is treating confirmation as a UI event rather than a data event. The order ID exists in your system the moment the order is created; ACP just requires you to return it in the response rather than only displaying it on a page. Return the full confirmation as structured data, with the order ID as a stable, durable reference the agent can store.
The pattern across all four stages
Every stage breaks the same way and gets fixed the same way. The capability already exists in your checkout; it is locked inside a human interface, and ACP requires you to expose it as a structured response. Cart totals, fulfillment options, payment, and confirmation are all computed server-side already. The work is giving each one a machine-readable output path alongside the human-readable page.
The contrarian takeaway is that ACP compliance is mostly not new functionality, it is exposure of existing functionality, with the single exception of the payment handoff, which often genuinely requires new capability. Teams over-scope ACP by assuming they need to rebuild checkout, when most of the work is returning values they already compute. Start by auditing each of the four stages for whether its output is a value or a page, fix the ones that are pages, and scope the payment handoff as its own project. This connects directly to the transaction schema that describes how an agent initiates the purchase, and it assumes your catalog is already legible per the UCP layer beneath it. Get the four responses clean and an agent can carry a user all the way from intent to confirmed order without ever touching your interface.
Sources
- Agentic Commerce Protocol (OpenAI and Stripe): the official open spec for agent-driven checkout, Apache 2.0. agenticcommerce.dev/docs
- Stripe, Agentic Commerce Protocol: the payment-handler and checkout building blocks for ACP. docs.stripe.com
- Schema.org, Order and BuyAction: the vocabulary behind order confirmation structures. schema.org/Order
- Website AI Score, agentic transaction schema: the BuyAction structure for initiating a purchase. View article
- Website AI Score, UCP guide: the catalog layer your checkout sits on top of. View article
