How to Make Your Commerce Platform Agent-Ready: Implementing ACP, UCP, and AP2

Agent-ready commerce means an AI agent can read your catalog, build a cart, run checkout, and hand you a payment token without a human ever loading your website. Two standards now define how that happens. ACP came from OpenAI and Stripe in September 2025 and powers Instant Checkout in ChatGPT. UCP arrived on January 11, 2026, announced by Google at NRF with Shopify, Etsy, Wayfair, Target, and Walmart as co-developers.

If you sell on both ChatGPT and Gemini, you implement both. They cover the same operations with different paths, different verbs, different status values, and different payload shapes. That is the part the strategy pieces skip.

This is a build guide. What the layers do, where the two specs diverge in ways that matter to your code, how to structure the adapter so you write the commerce logic once, and which part of the whole thing actually breaks in production. That last one is not checkout. It’s the feed.

Ready to make your commerce platform agent-ready?

Consult Our Expert

The stack, and which parts you own

Five specs get named in agentic commerce conversations. They sit at different layers and only two of them compete. 

MCP handles discovery and tool invocation. A2A carries conversation between the shopper’s agent and yours, if you run one. Those two are plumbing you may never touch directly, though UCP can run over either as a transport. 

The commerce layer is where your work lives. ACP and UCP both define product data, cart state, and checkout. AP2 sits above, defining how a payment gets authorized when an agent, rather than a person, is the one clicking. 

And underneath everything sits a product feed pipeline that no spec diagram shows and every implementation depends on. 

ACP and UCP: the same job, a different contract

Here is the comparison that matters once you start writing code. Both specs are public, and both move, so treat this as a snapshot rather than a reference. 

	ACP	UCP
Maintainers	OpenAI and Stripe	Google, with Shopify, Etsy, Wayfair, Target, Walmart
Published	September 2025	January 11, 2026, spec v2026-04-08 in April
Live surface	ChatGPT Instant Checkout	Search AI Mode and the Gemini app
Discovery	Product feed submitted to the platform	GET /.well-known/ucp manifest on your domain
Create checkout	POST /checkout_sessions	POST /checkout-sessions
Update checkout	POST /checkout_sessions/{id}	PUT /checkout-sessions/{id}, full replacement
Checkout states	not_ready_for_payment, ready_for_payment, completed, canceled	incomplete, requires_escalation, ready_for_complete, complete_in_progress, completed, canceled
Agent identity	Authorization plus Signature, Timestamp, API-Version headers	UCP-Agent header carrying a platform profile URI
Idempotency	Idempotency-Key header	Idempotency-Key, required on every mutating call
Payment	Delegated token, Stripe’s Shared Payment Token first	Payment handler negotiated from your profile, token passed in payment.instruments
Transports	HTTPS and JSON	REST, MCP, A2A, or an embedded surface
Human handoff	Error message codes such as requires_3ds	requires_escalation state plus a continue_url

Read the two path names again. One underscore, one hyphen. That is the whole flavor of this problem: close enough that a reasonable person assumes one integration will cover both, different enough that it won’t.

The state machines are the bigger divergence. ACP gives you four states. UCP gives you six, and two of them exist to model something ACP handles through messages: what happens when checkout can’t continue inside the API and a human has to finish it somewhere else. UCP makes that a first-class state with a required continue_url. ACP expects you to return a message with a code like requires_sign_in or requires_3ds and let the agent surface it.

Neither is wrong. They are different opinions about where the escape hatch belongs, and your state machine has to satisfy both.

UCP also does something ACP doesn’t: capability negotiation. You publish what you support in /.well-known/ucp, the platform sends its own profile URI on every request, and the two intersect. Extensions declare a parent, so when a parent capability drops out of the intersection its children get pruned, and the pruning repeats until nothing changes. Version handling is strict, and the rule has teeth: the platform’s version must be equal to or older than yours, otherwise you return version_unsupported.

That rule has a scheduling consequence. You upgrade before the platforms do, not after.

The feed is where this actually breaks

Now the part that surprised us. 

We assumed checkout would be the hard problem. It isn’t. Checkout is a well-specified state machine over an API you already have. The failure mode that shows up in production is a price or stock value that was true when the feed was pushed and isn’t true when the agent tries to buy. 

Here is why. Neither ChatGPT nor Gemini calls your catalog live when a shopper asks for running shoes. The platforms index feeds you push ahead of time, because they need control over ranking for sponsored placement and because real-time callbacks across millions of SKUs aren’t practical. ACP’s own documentation tells merchants to send a sample feed for validation, then refresh as often as every 15 minutes. 

Every 15 minutes is the ceiling. Most teams won’t run the whole catalog that hot, and that choice determines your error rate. 

So we modeled it. A 50,000 SKU catalog. Three volatility tiers, with 5% of SKUs repricing or flipping stock state several times a day, 25% moderate, and the rest close to static. Demand follows the skew every retailer recognizes, where the top 1% of SKUs take roughly 59% of orders. Promoted and dynamically priced items draw more traffic than their share of the catalog, so volatility and demand correlate rather than sitting independent. Then 400,000 simulated agent checkouts, each one drawing a feed snapshot of random age within the refresh window, testing whether price or stock drifted in the meantime. 

Refresh everything once a day and 18.3% of agent checkouts hit a stale value. Every four hours gets you to 4.8%. Hourly, 1.34%. Fifteen minutes across the whole catalog, 0.36%, at 4.8 million feed rows pushed per day. 

That last number is the problem. Running your entire catalog at the maximum cadence to protect a small fraction of it is an expensive way to buy accuracy. 

So we asked a different question: at a fixed feed volume, what is the best possible allocation of refresh intervals across SKUs? 

The answer falls out cleanly. Minimizing expected mismatches subject to a fixed push budget gives an interval for each SKU proportional to one over the square root of its demand times its change rate. Fast movers that nobody buys get left alone. Slow movers that everybody buys get left alone too. The budget concentrates on SKUs that are both popular and volatile, which is a much smaller set than either group on its own. 

At 1.2 million rows per day, the volume you’d spend refreshing everything hourly, that allocation drops stale-value checkouts from 1.34% to 0.44%. A 67% cut, same cost. To reach 0.44% with a single interval across the catalog, you’d need to push 4.8 million rows, four times the volume. 

We re-ran it across flatter and steeper demand curves, calmer and more volatile catalogs, and different random seeds. The improvement held between 62% and 73% every time. The shape of the result is not sensitive to the assumptions, which is what you want before you build something on it. 

In the baseline run, the square root rule gave a 15-minute lane to about 7.9% of SKUs. Those SKUs carried 66.9% of orders.

Two practical notes. First, your real volatility data already exists in your price change and inventory movement history, so you don’t need to guess the tiers. Second, recompute the allocation on a schedule, because a SKU’s position moves when it goes on promotion. A static tiering built in January protects the wrong products by March. 

Checkout sessions, and the things that go wrong mid-session

A checkout session is a conversation that can last minutes. Prices move inside that window. So does stock.

Both specs expect you to return the authoritative cart state on every update, not a diff. UCP goes further and makes the update a PUT with full replacement semantics, which removes a category of partial-update bugs and forces your handler to be genuinely idempotent rather than accidentally so.

Honor Idempotency-Key properly. Not “store the key and return early,” but store the key with the response body and return the same body on a retry. An agent that times out and retries a completion must not be able to create two orders. This is the single highest-consequence detail in either spec, and it’s the one most likely to pass a code review while being wrong, because the failure only appears under a network condition your tests don’t reproduce.

When the price changed between cart and completion, you have two defensible behaviors. Fail the completion with a clear error and let the agent re-quote. Or honor the quoted price within a tolerance you set deliberately. Pick one, write it down, and make sure finance knows, because the second option is a discount policy wearing an engineering costume.

ACP’s message error codes tell you what the agent can surface: missing, invalid, out_of_stock, payment_declined, requires_sign_in, requires_3ds. Note out_of_stock sitting right there in the spec. The protocol authors knew about the feed problem. They gave you a code for it rather than a way to avoid it.

Order lifecycle runs separately through webhooks. ACP defines order_created and order_updated, with order statuses created, manual_review, confirmed, canceled, shipped, and fulfilled, and signs the payload with an HMAC. Returns and refunds flow through the same channel, with refunds typed as either store_credit or original_payment. If your order management system can’t emit those transitions, that integration is a bigger job than checkout.

Payments, and how much autonomy you accept

In ACP, the agent asks its payment provider for a delegated token scoped to a maximum amount with an expiry, then hands you that token on completion. You charge it through your existing PSP. You remain merchant of record. OpenAI is explicit that it is not.

UCP negotiates a payment handler from your published profile, the platform runs that handler with a credential provider to get a token, and the token arrives in payment.instruments when checkout completes. You hold the PSP credentials. The platform never touches raw card data.

AP2 is the layer above both, and it’s the one worth understanding properly even though it’s the least mature. It defines three signed mandates that chain together:

An Intent Mandate captures what the shopper authorized, including constraints such as price limits and an intent_expiry. A Cart Mandate fixes the exact items and total, with its own cart_expiry and a merchant_authorization. A Payment Mandate binds a payment method to that specific cart, carrying a user_authorization that references the cart’s hash.

The chain is the point. In a dispute, the mandate set is evidence of what the shopper approved and what you were authorized to charge, cryptographically bound together rather than reconstructed from logs.

AP2 also separates human-present flows from delegated ones. Human-present is what you’d expect: the shopper sees a cart and approves it. Delegated is the interesting case, where a shopper pre-signs an intent along the lines of “buy these tickets the moment they go on sale under this price,” and a cart gets generated automatically when conditions hit. Nobody is watching at purchase time.

Decide deliberately which of those you accept, and set different limits for each. A delegated purchase with no human at the moment of sale deserves a lower ceiling, tighter expiry, and a stricter risk check than one a person just approved on screen. UCP exposes AP2 through an ap2_mandate extension, so this is a capability you advertise rather than a mode you silently support.

Build the commerce logic once

The architecture that survives both protocols, and the third one that shows up next year, is an adapter layer over a protocol-agnostic core.

Your core owns pricing, tax, promotions, inventory reservation, fraud checks, and order creation. It knows nothing about ACP or UCP. It exposes operations like “price this cart” and “reserve this stock” and “create this order.”

Each protocol gets a thin adapter that translates. The ACP adapter maps POST /checkout_sessions/{id} and ACP’s four states onto core operations. The UCP adapter does the same for PUT /checkout-sessions/{id} and six states, plus the profile manifest and capability negotiation, which have no ACP equivalent and belong in the adapter rather than the core.

The feed service is its own component, not a cron job bolted to the catalog database. It needs per-SKU scheduling, format emitters per platform, and a delivery log. Teams underestimate this one consistently, because a feed export looks trivial until it needs to be differential, scheduled per SKU, and reconciled.

One rule worth enforcing early: the adapter must never make a pricing or inventory decision. The moment one adapter can approve something the other can’t, you have two commerce systems and a reconciliation problem.

A build sequence that works

1. Audit the catalog data first. Structured attributes, accurate pricing, real-time inventory, and a stable identifier per SKU. If this isn’t clean, nothing downstream matters, and no protocol work will hide it.
2. Expose pricing, tax, and shipping as services. Most commerce stacks calculate these inside a checkout controller. Agentic checkout needs them callable with a cart and an address, outside any session.
3. Build the feed service with per-SKU scheduling. Compute change rates from your own price and inventory history, apply the square root allocation, and emit each platform’s format from one internal representation.
4. Implement one protocol end to end. Whichever platform matters more commercially. Get the full loop working, including webhooks and refunds, before you start the second.
5. Add the second adapter. This is when you find out whether your core is really protocol-agnostic. Anything you have to change in the core is a design leak worth fixing now.
6. Wire payment delegation. Token handling, the amount and expiry checks, and your PSP path. Test declines and expired tokens explicitly.
7. Layer AP2 mandates. Signature verification, cart binding, expiry enforcement, and separate limits for delegated purchases. 
8. Instrument everything before launch. Mismatch rate, session abandonment by state, completion latency, and feed delivery lag per platform.

Testing: four categories, and the one everyone skips

Protocol conformance is the obvious one. Non-compliant feeds get rejected outright, so validate against each spec in CI rather than finding out from a partner email.

Behavioral testing asks what your agent-facing surface actually says across scenarios. A documented example worth borrowing: does it leak a discount code it shouldn’t?

Latency matters more than it does on a website. An agent comparing options across merchants will not wait politely.

Then the one teams skip: a replay suite for concurrency. Fire a completion twice with the same idempotency key. Change a price between cart and completion. Drop stock to zero mid-session. Expire a payment token before completion lands. Each of these has a correct answer in your implementation, and none of them show up in a happy-path integration test.

Run a stale-feed probe in production too. Sample agent-quoted prices against live prices and alert on the gap. That number is your real mismatch rate, and it will not match your model.

Hosted platform or custom stack

If you’re on Shopify, much of this is being handled for you, and your work is catalog quality and feed freshness rather than protocol implementation. 

Everyone else builds it. Custom storefronts, headless setups, marketplaces with third-party sellers, and B2B platforms with contract pricing all have the same problem, and the last two have it worse. A marketplace has to decide which seller fulfills an agent order before the cart is priced. A B2B platform has to answer whether an agent even sees contract pricing, which is a commercial decision wearing a technical disguise. 

When this isn’t your priority yet

Plenty of merchants should wait.

If agent traffic is a rounding error in your analytics and your category isn’t one shoppers delegate, the engineering effort buys you an option rather than revenue. If your catalog data is a mess, fix that first, because it’s the prerequisite for every path here and it has value on its own. If your margin can’t absorb a platform fee on top of acquisition cost, model that before you build.

The case for moving now is narrower than the announcements suggest, and it’s mostly about optionality. The feed and catalog work pays for itself regardless. The protocol adapters are the part you can defer.

Frequently asked questions

Getting the sequence right

The protocols are the visible part of agent-ready commerce and the smaller part of the work. Catalog quality, a feed service that schedules per SKU, and pricing exposed as a callable service are what decide whether any of it works. MindInventory’s commerce engineering team builds this layer, from the feed pipeline and refresh model through protocol adapters and payment delegation, for platforms that aren’t on a hosted storefront.