The Agentic Commerce Readiness Checklist: What Actually Matters After March 2026

The most useful thing that happened in agentic commerce this year was a retreat.

On 24 March 2026, OpenAI told merchants it was stepping back from running checkout inside ChatGPT. The wording was careful: "We've found that the initial version of Instant Checkout did not offer the level of flexibility that we aspire to provide, so we're allowing merchants to use their own checkout experiences while we focus our efforts on product discovery."^[1]

Read that again, because most of the advice written before it is now aimed at the wrong target. The company that started the agent-checkout race has said, in public, that it is concentrating on discovery. Purchases complete on the merchant's own storefront, in an in-app browser or a new tab.^[2]

If you were about to spend a quarter building a checkout API for agents, stop and read this first. If you were about to do nothing because the hype cooled, that is the wrong conclusion too, and this guide explains why the discovery half got more important, not less.

Everything here is checkable. You can run the same audit on your own store with the free AI-readiness scanner, which uses exactly the field definitions and weights described below.

The one-paragraph version

Four protocols exist and they do different jobs. Only one of them, the humble product-data layer, is worth most merchants' attention today. The three attributes that decide whether an agent will actually recommend your product are priceValidUntil, shippingDetails.deliveryTime and hasMerchantReturnPolicy.merchantReturnDays. They are all "Recommended" rather than "Required" in Google's documentation, which is precisely why almost nobody has them, and precisely why having them is an advantage. Everything else on this page is detail.

What actually happened, in order

The chronology matters because vendors quote whichever moment suits them.

Date	Event
29 Sep 2025	OpenAI and Stripe publish the Agentic Commerce Protocol (ACP) under Apache 2.0, launching with Etsy and "coming soon, over a million Shopify merchants"[3]
11 Jan 2026	Google publishes the Universal Commerce Protocol (UCP), developed with Shopify, Etsy, Wayfair, Target and Walmart[4]
24 Mar 2026	Shopify activates agentic storefronts for eligible stores. It is active by default, not opt-in[5]
24 Mar 2026	OpenAI steps back from Instant Checkout and redirects effort to product discovery[1]
17 Apr 2026	ACP's current spec revision lands, adding cart, feed, orders, authentication and MCP[6]

Two things are true at once. The transaction layer got harder and quieter. The discovery layer got switched on for millions of stores in a single afternoon.

Why the checkout half stalled

Onboarding merchants proved slow and error-prone, and the integration count stayed small relative to the ambition.^[2] This is not surprising to anyone who has integrated a payment flow. Agent checkout has to solve tax, multi-item carts, loyalty, partial refunds and merchant-of-record questions before it can solve convenience.

The lesson for a merchant is not "agents don't matter". It is that the expensive half retreated and the cheap half shipped. That is an unusually favourable position, and it will not last indefinitely.

The four protocols, and which ones you can ignore

These get listed together as if they compete. They mostly do not.

MCP: how an agent reaches a system

The Model Context Protocol is a general-purpose way for a model to call tools. It is not a commerce standard and it has no opinion about carts or prices. It is how an agent talks to something; commerce meaning comes from the layer above.

ACP: OpenAI and Stripe's checkout protocol

ACP is a real, published specification with dated revisions: 2025-09-29, 2025-12-12, 2026-01-16, 2026-01-30 and 2026-04-17.^[6] Its checkout surface is small and conventional:

POST   /checkout_sessions
POST   /checkout_sessions/{checkout_session_id}
GET    /checkout_sessions/{checkout_session_id}
POST   /checkout_sessions/{checkout_session_id}/complete
POST   /checkout_sessions/{checkout_session_id}/cancel

Every request carries an Authorization bearer token and an API-Version header in YYYY-MM-DD form. Every POST must carry an Idempotency-Key. The spec states an idempotency key "MUST be present on all POST requests".^[7]

That is a genuine engineering project. Given OpenAI's own March statement, it is also the piece with the least certain payoff for a mid-sized merchant right now.

UCP: Google's discovery and transaction protocol

UCP starts from a file. An agent reads /.well-known/ucp to learn what your store supports. Google's requirement is unambiguous: the profile "must be publicly accessible and not require any authentication."^[8]

The shape, from Google's own published example, nests everything under a ucp key, versions by date, and names capabilities in reverse-DNS form:^[4]

{
  "ucp": {
    "version": "2026-01-11",
    "services": {
      "dev.ucp.shopping": {
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specs/shopping",
        "rest": {
          "schema": "https://ucp.dev/services/shopping/openapi.json",
          "endpoint": "https://yourstore.com/ucp/v1"
        }
      }
    },
    "capabilities": [
      {
        "name": "dev.ucp.shopping.checkout",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specs/shopping/checkout",
        "schema": "https://ucp.dev/schemas/shopping/checkout.json"
      }
    ]
  }
}

A warning worth more than the snippet. Plenty of blog posts, and until we corrected it our own scanner, hand out a manifest with a flat "version": "1.0", a merchant object and a feeds array. None of that exists in the protocol. If you publish an invented shape you have not become discoverable; you have published a file that fails to parse. Worse, if you declare dev.ucp.shopping.checkout, the endpoint you name will be called. Declaring a capability you have not built is worse than declaring nothing.

Capability names in the published set include dev.ucp.shopping.checkout, dev.ucp.shopping.fulfillment, dev.ucp.shopping.discount, dev.ucp.shopping.order and dev.ucp.common.identity_linking. Signed webhooks use a signing_keys array of public keys in JWK format.^[8]

AP2: the payments layer

The Agent Payments Protocol handles the authorisation question: proving a human actually consented to a purchase an agent is making. UCP is documented as compatible with it.^[4] Unless you are building your own agent, this is your payment provider's problem, not yours.

So which do you implement?

Protocol	Job	Most merchants, mid-2026
Product schema	Let an agent describe and trust your product	Do this. It is the whole game right now
MCP	Tool access for agents	Only if you are building agent-facing tools
UCP profile	Declare capabilities at a known path	Cheap insurance, if honest about what you support
ACP	Agent-initiated checkout	Wait, unless a partner requires it
AP2	Payment authorisation	Your PSP's job

How an agent actually finds you

Before the checklist, it is worth being precise about the mechanism, because a lot of advice assumes agents work like a crawler and they do not.

There are three distinct ways your product can end up in an answer, and they have different requirements.

1. Through a platform catalogue

This is the Shopify Catalog route. Your platform syndicates structured product data to an agent surface directly, and you did not have to build anything. It is also the route you have least control over: the fields the platform chooses to send are the fields the agent sees, and Shopify notes that turning catalogue access off can take up to seven days to take effect.^[11]

2. Through a merchant feed

The Merchant Center route, and the most underrated one. A feed is machine-readable by construction, so it sidesteps every rendering problem on your site. If your product pages are JavaScript-heavy and you cannot fix that this quarter, a clean feed is the fastest way to become legible.

The catch is that a feed and a page can disagree. When they do, you have taught the agent that your data is unreliable, which is a worse position than being absent. Whatever you do, make the feed and the page agree on price, availability and returns.

3. Through the open web

The route everyone thinks of: an agent fetches your page and reads it. This is where crawler access and server rendering decide everything, and it is the only route available to most non-Shopify merchants today.

It is also the route where the failure is silent. Nothing errors. Your page returns 200. The agent simply forms a worse impression of your product than your competitor's and never tells you.

Why this matters for prioritisation

If you are on Shopify, route 1 is already running whether you like it or not, so your job is making sure the data it syndicates is good. If you are on WooCommerce or Magento, routes 2 and 3 are your whole strategy, and route 3 is where the cheap wins are.

In all three cases the same fields decide the outcome, which is why the checklist below is platform-agnostic.

What an agent actually needs

Strip away the protocol names and an agent is trying to answer three questions before it will put your product in front of someone as a recommendation rather than a mention.

1. Is this still the price?
2. When would it arrive?
3. Can it be sent back?

Those map exactly onto three schema.org properties, and this is the single highest-value paragraph in this guide:

Question	Property	Google's requirement level
Still the price?	priceValidUntil	Recommended
Arrives when?	shippingDetails.deliveryTime	Recommended
Returnable?	hasMerchantReturnPolicy.merchantReturnDays	Recommended

Google describes priceValidUntil as "the date and time after which the price will no longer be available, in ISO 8601 format", shippingDetails as "nested information about the shipping policy associated with an Offer", and hasMerchantReturnPolicy as "nested information about the return policies associated with an Offer". All three are listed as recommended, not required.^[9]

The trap nobody mentions

Google adds a warning to priceValidUntil that deserves to be on a poster: "Your listing may not display if the priceValidUntil property indicates a past date."^[9]

An expired priceValidUntil is worse than a missing one. A store that added the field once, hardcoded a date, and never revisited it is actively suppressing its own listings. This is a real and common failure: the field looks present to a casual audit, and it is doing harm.

If you take one action from this guide, make it this: check whether the priceValidUntil your store emits is in the future, and make sure it is generated as a rolling date rather than a literal.

Why "recommended" is the opportunity

Because these fields are optional, platforms do not emit them by default, so almost nobody has them. When we audited 36 product pages across 14 UK and EU stores in July 2026, reading only raw HTML with an identified crawler, not one page carried all three, and thirty of the thirty-six carried none. priceValidUntil appeared on 18% of pages, shippingDetails.deliveryTime on 13% and merchantReturnDays on 11%. The full method is in our PDP optimisation guide.

Optional fields that agents depend on are the definition of a cheap advantage.

Getting the return policy right, specifically

Of the three attributes, the return policy is the one most often filled in badly rather than left out, so it deserves its own note.

merchantReturnDays must be a number. A great many stores emit prose in a field an agent expects to compare numerically, and "30 days from delivery on unworn items" is not a number. Put the integer in the structured data and keep the nuance in the policy page where a human reads it.

Two further properties change the answer materially and are worth adding at the same time, because you are already in the file:

• returnPolicyCategory distinguishes a finite window from no returns at all. Omitting it leaves an agent guessing whether 30 days is generous or the legal minimum
• returnFees and returnShippingFeesAmount decide whether a return is genuinely free. "Free returns" is one of the strongest purchase signals there is, and it is invisible unless you say it in the data

If you sell into the EU or UK there is a further reason to get this exactly right: your published window and your statutory obligations are two different things, and an agent quoting the wrong one to a customer is a support problem you will inherit. Our article on the EU right of withdrawal covers where the statutory floor sits and how it interacts with the window you advertise.

The general principle: the structured data should describe the policy a customer actually gets, not the most flattering reading of it. An agent that recommends you on a promise you do not honour produces a refund and a bad review, which is worse than not being recommended.

The checklist

Hand this to a developer. It is ordered by what moves the needle, and the weights are the ones our scanner actually uses.

1. Crawler access (weight 22)

• Confirm robots.txt does not block GPTBot, OAI-SearchBot, ChatGPT-User, PerplexityBot, ClaudeBot, Google-Extended or Bingbot
• Check for a blanket User-agent: * / Disallow: / left over from staging
• Check your WAF or bot protection separately, because robots.txt can be permissive while Cloudflare returns 403 to the same agents
• Blocking Google-Extended opts you out of Gemini grounding. Decide that deliberately rather than by inheritance

2. The three agentic attributes (weight 28)

• priceValidUntil on every offer, generated as a rolling future date
• shippingDetails.deliveryTime with real handling and transit times
• hasMerchantReturnPolicy.merchantReturnDays as a number, not prose
• Verify against a page fetched without JavaScript, not against your CMS

3. Product schema completeness (weight 13)

• Valid Product with a nested Offer
• availability from the schema.org set, updated from real stock
• price and priceCurrency as separate machine-readable values

4. Identifiers (weight 8)

• gtin in numerical form where one exists, plus mpn and sku^[9]
• Identifiers are how an agent knows your listing and a competitor's are the same object. Without one you are an unmatched string

5. Server rendering (weight 9)

• Price, availability and schema must be in the first HTML response
• Test honestly: curl -s https://yourstore.com/products/x | grep -i price

6. Category and collection pages (weight 6)

• Category pages must contain crawlable <a href> links to products in raw HTML
• A JavaScript-rendered product grid is invisible to most crawlers. This is the single most common silent failure we see

7. Policy pages (weight 4)

• Returns and shipping reachable in one hop from the footer, rendered server-side, with the number of days in text

8. Protocol manifests (weight 4)

• /.well-known/ucp if and only if you can honour what it declares
• llms.txt as a low-cost pointer to your key pages

9. Hygiene (weight 4)

• Canonical URLs, a working XML sitemap, no soft 404s on discontinued products

Scores below 40 read as not agent-ready, 40–69 as partial, 70+ as ready. Our scanner also caps the band: if none of your sampled products carry any of the three agentic attributes, the result cannot score above "not ready" regardless of everything else, because an agent that cannot answer the three questions will not transact, however tidy the rest is.

The category-page failure nobody audits

Almost every agent-readiness audit on the market checks product pages. Very few check category pages, and category pages are where we find the most damage.

The reason is structural. An agent arriving at your store does not know your URLs. It finds products by following links from your homepage and your collection pages, exactly as a crawler does. If your product grid is rendered by JavaScript after the page loads, the raw HTML of that collection page contains no product links at all. The page looks perfect to you and contains nothing to follow.

We added a category check to our own scanner precisely because a product-only audit missed this. On one large UK retailer, two of three sampled category pages returned no crawlable product links because the grids were JavaScript-rendered. A product-only audit scored that store 64 out of 100 and reported no problem, because the product pages it was handed directly were fine. Nothing could reach them.

How to check in one line

curl -s https://yourstore.com/collections/all | grep -c '/products/'

A number in the dozens is healthy. 0 means your catalogue is unreachable by anything that does not execute JavaScript, which includes most crawlers most of the time.

The Magento wrinkle

Magento stores frequently use flat URLs like /lifejackets.html with no /category/ segment, so pattern-matching for category URLs finds nothing and an audit concludes there are no category pages. There usually are; they simply do not announce themselves in the URL. The reliable method is to follow the homepage navigation links, which is how an agent would find them too.

If you run Magento and a tool has told you it found no category pages, treat that as a limitation of the tool rather than a finding about your store.

Pagination and the long tail

A related failure: infinite-scroll collections with no paginated fallback. If page two of a collection only exists as an XHR response, everything past the first screen of products is invisible. Products deep in your catalogue are exactly the ones an agent could surface for a specific query, so this disproportionately costs you the long-tail recommendations that agents are best at.

Serve real paginated URLs alongside the infinite scroll. Both can coexist, and only one of them is legible.

Platform by platform, honestly

This is where most coverage becomes marketing. Here is what is actually documented.

Shopify

Shopify co-developed UCP with Google and contributed its Checkout Kit work to the protocol.^[10] For merchants, the important fact is that agentic storefronts are "active by default for eligible stores".^[5]

You are probably already in it. Controls sit under Sales channels → Agentic, where you deactivate "Allow Shopify to manage for me" before you can change Shopify Catalog access.^[11]

Two caveats from Shopify's own documentation are worth knowing before anyone panics or celebrates. Turning off Catalog access can take up to seven days to propagate. And even after opting out, "your products can still be found in AI channels in the same way that they're listed in traditional search engines".^[11] Opting out of the catalogue feed is not opting out of being findable.

WooCommerce, Magento and everyone else

Here I have to be careful, because this is where sourcing gets thin.

WooCommerce was not among the partners Google named at UCP's launch, which was Shopify, Etsy, Wayfair, Target and Walmart.^[4] Adobe Commerce was not named either. Stripe's ACP announcement named Etsy and Shopify and no other platform.^[3]

You will find plenty of posts asserting that WooCommerce, BigCommerce, Wix and Squarespace all support ACP today. We could not verify that from any primary source, and we are not going to repeat it. If your platform's own documentation says it, believe your platform. If only a vendor blog says it, treat it as marketing.

What this means practically is better than it sounds. If you are on WooCommerce or Magento, the protocol layer is not available to you as a checkbox, but the protocol layer is also the part that just stalled. The discovery layer is entirely within your control, because it is your own theme templates emitting your own structured data. A well-marked WooCommerce store beats a badly-marked Shopify store in every discovery surface, because the agent is reading HTML, not a platform badge.

This is the cross-platform argument in one line, and it is the reason we build the way we do.

What not to do

Do not declare capabilities you have not built

Covered above and worth repeating, because it is the most likely way to make things actively worse. A manifest is a promise. An endpoint that 404s when an agent calls it is a broken promise recorded at a well-known path.

Do not add a static priceValidUntil

A hardcoded date is a time bomb that suppresses your listings the day it passes.^[9]

Do not assume a new file is required

Google's guidance on its AI features is explicit: "You don't need to create new machine readable files, AI text files, or markup to appear in these features. There's also no special schema.org structured data that you need to add."^[12]

That is often misread as "so do nothing". Google is saying there is no secret AI schema, not that your existing schema is complete. Most of it is not, and the gaps are exactly the three fields above.

Do not block crawlers by accident

Check the WAF, not just robots.txt. The two disagree more often than anyone expects.

How to verify, in ten minutes

# 1. Can the agents reach you?
curl -s https://yourstore.com/robots.txt | grep -iA2 'GPTBot\|OAI-SearchBot\|PerplexityBot'

# 2. Does a product page carry the three attributes, without JavaScript?
curl -s https://yourstore.com/products/example \
  | grep -o 'priceValidUntil\|deliveryTime\|merchantReturnDays'

# 3. Is priceValidUntil actually in the future?
curl -s https://yourstore.com/products/example | grep -o 'priceValidUntil[^,]*'

# 4. Do category pages expose product links in raw HTML?
curl -s https://yourstore.com/collections/all | grep -c '/products/'

# 5. Does your manifest parse, if you publish one?
curl -s https://yourstore.com/.well-known/ucp | python3 -m json.tool

If step 2 returns nothing, that is your quarter's work and it is smaller than it looks. If step 4 returns 0, your category pages are invisible and no amount of product markup compensates.

How to tell whether any of this worked

This is the part that gets skipped, and it is why agent-readiness work is hard to fund internally. There is no Search Console for agents. You cannot open a dashboard and see your ChatGPT impressions.

Three measurements are available, in ascending order of usefulness.

Server logs, which are underrated

Your access logs record every agent that fetched a page, by user-agent string. Grepping for GPTBot, OAI-SearchBot, PerplexityBot and ClaudeBot tells you three things a dashboard cannot: whether they are visiting at all, which paths they request, and what status codes they receive.

A store convinced it was blocked often turns out to be crawled constantly. A store convinced it is fine often turns out to be serving 403s from its WAF to every one of them. Look before theorising.

Referral traffic, which is thin but real

Assistant surfaces do pass referrers in some contexts. The volumes are small enough that people dismiss them, which is a mistake at this stage: you are not looking for volume, you are looking for the first non-zero. A trickle of referrals from an assistant is evidence the plumbing works, and it arrives before the volume does.

Asking the assistants directly

Crude, manual, and the most informative of the three. Ask several assistants a question a customer would ask, in the form a customer would ask it, and record whether you appear, how you are described, and whether the price and availability they quote are correct.

Do it monthly and keep the answers. The interesting signal is rarely absence. It is being described with a stale price, or without a returns window, or with a competitor's shipping time attributed to you, all of which are fixable and all of which map to a field in the checklist above.

What not to bother measuring

Ignore any vendor offering an "AI visibility score" without telling you what it measures. Ours is deliberately transparent about its weights for that reason, and you should hold every other tool to the same standard. A score you cannot decompose into actions is a number, not a measurement.

The honest summary

Agentic commerce in mid-2026 is not one thing arriving. It is a discovery layer that switched on quietly and a transaction layer that is being rebuilt in public after its first attempt underdelivered.

The correct response to that is not a protocol project. It is boring, durable product-data work that pays off in Google Shopping, in traditional search, in your feeds, and in whichever agent surface wins, because all of them read the same three things, and almost nobody publishes them.

There is a version of this advice that ages badly and a version that does not. The version that ages badly is "implement protocol X", because protocol X changed twice while this guide was being written and OpenAI's own priorities moved in March. The version that does not age is "make your price, delivery and returns machine-readable and true", because every surface that has ever wanted to sell your product has wanted those three facts, and every surface that comes next will want them too.

If you do nothing else this quarter, generate a rolling priceValidUntil, put an integer in merchantReturnDays, and check that a collection page returns product links to curl. That is perhaps a day of work for a competent developer, it costs nothing in licence fees, and on the evidence of our own audit it puts you ahead of roughly nine in ten of the stores we looked at.

Run the scanner on your own store. It reads your homepage, five products, three category pages and your returns policy the way an agent does, and it hands you the failing markup with the code to fix it.