WooCommerce Agentic Checkout: The Toggle Isn’t the Work

If you run a WooCommerce store, you have probably read that AI agents are about to start buying things on your customers’ behalf, and that you should get ready. What almost none of that coverage tells you is that the readiness work is already sitting in your plugins directory. WooCommerce 11.0.0 ships a complete implementation of the Agentic Commerce Protocol — the standard behind ChatGPT’s Instant Checkout — and it is switched off.

I went looking on a production store to find out what “switched off” actually means, what turning it on would require, and whether the store would work if I did. The short version: the toggle is the easy part, and the thing most likely to stop an agent buying from you has nothing to do with WooCommerce at all.

What the Agentic Commerce Protocol actually is

The Agentic Commerce Protocol (ACP) is an open standard for letting an AI agent complete a purchase on a buyer’s behalf. It was codeveloped by Stripe and OpenAI and announced on 29 September 2025, alongside Instant Checkout in ChatGPT — at launch, US Etsy sellers, with Shopify merchants named as coming next. The specification is published at agenticcommerce.dev under the Apache 2.0 licence.

The important design decision, and the one that makes it worth a store owner’s attention, is that the merchant stays the merchant of record. The agent is not a reseller. It holds a conversation with the buyer, then drives a checkout session against your store using your prices, your tax rules, your shipping options and your inventory. ACP defines the shape of that session: create it, update it, complete it.

That is a very different integration from a marketplace feed. It is also a much smaller one than most people assume, which is why WooCommerce was able to put it in core.

What WooCommerce 11.0.0 actually ships

Searching the WooCommerce plugin directory on this install for the string agentic returns 17 files. They are not stubs. There is a schema class, a utilities class that maps WooCommerce error codes onto ACP error codes, a webhook manager, a payload builder, and three route classes whose source comments state plainly that they implement objects “as defined in the Agentic Commerce Protocol”. The routes controller registers them under a comment that reads, in full, // Agentic Commerce Protocol endpoints.

Those three routes are the entire checkout lifecycle:

The implementation goes further than the happy path. WooCommerce echoes the Idempotency-Key and Request-Id headers that ACP clients send, which is what stops a retrying agent from creating two orders. Its session validator returns structured messages against JSON paths — $.fulfillment_address when a shipping address is missing, $.fulfillment_option_id when no shipping method has been chosen — so the agent gets told what to ask the buyer for rather than a generic failure. Somebody thought carefully about a conversation being the interface.

And on this store, none of it exists

WooCommerce gates the whole thing behind a feature flag. Reading the live features registry rather than the release notes, the registration says:

Agentic Checkout API — “Enable the Agentic Checkout API for AI-powered checkout experiences (e.g., ChatGPT). This adds REST API endpoints that allow AI agents to create and manage checkout sessions.”

The registration also carries 'enabled_by_default' => false, and on this install the flag reads no. That is not cosmetic. Asking the running REST server for its route table returns 1,057 registered routes, and not one of them is a checkout session. Requesting the create endpoint returns a flat 404 — not a 401, not a permission error. The route is not there.

This is worth stating clearly in both directions, because coverage of AI features in e-commerce platforms tends to pick one. Updating to WooCommerce 11 does not quietly open your store to AI agents. It also does not make your store agent-ready. Both fears are wrong, and the default is the conservative one.

The neighbouring flag is worth knowing about too. mcp_integration — WooCommerce MCP, which lets an AI client operate the store as a set of tools — is also off by default and off here. I audited what that surface exposes when it is on a few days ago, and the summary is that the blast radius is the thing to think about, not the endpoint.

ACP and MCP are not the same thing

These two get conflated constantly, including by people selling things to store owners. WooCommerce ships both, both are off, and they solve different problems:

The requirement nobody mentions: you need a Jetpack connection

Here is the detail that will decide whether this is a ten-minute job or a project for you, and I have not seen it in a single write-up.

The agentic endpoints do not authenticate with a WooCommerce REST API key. Their permission callback is a method called is_authorized(), and what it checks is whether the request is signed with a Jetpack blog token. If it is not, WooCommerce returns a 401 whose message is exactly: “This endpoint requires Jetpack blog token authentication.”

So the shape of the feature is not “expose an API to any agent that wants it.” It is “let requests brokered through the WooCommerce/Jetpack connection reach your checkout.” Practically, that means a store on a self-managed host with Jetpack deliberately not installed — a very common setup among the developers most likely to be interested in this — cannot enable agentic checkout by flipping the flag. The flag will flip. The endpoint will register. Every request will 401.

Whether you regard that as a sensible trust boundary or as a platform tollbooth depends on your priors. Either way, find out before you promise anyone a launch date.

The part that is not in the documentation: can the agent reach you at all?

Suppose the flag is on and Jetpack is connected. An agent still has to find the product before it can check out, and that is where the audit produced its most useful result.

I requested the same URLs twice — once through the CDN the way any outside client would, and once directly against the application server — using a plain HTTP client with no JavaScript, which is what a shopping agent is. The home page, the shop archive and every blog post returned 200 both ways. The Store API product catalogue, /wp-json/wc/store/v1/products, returned 200 as well, publicly and without authentication.

All four product pages returned 403 through the CDN and 200 at the origin.

The response header explains it: the CDN is issuing a managed challenge. A managed challenge is a small JavaScript proof-of-work. A browser solves it invisibly. A crawler or an agent that cannot execute JavaScript gets a 403 and nothing else.

Two things must be said precisely here, because it would be easy to turn this into a scarier claim than the evidence supports.

First, the challenge is not aimed at AI agents. It fires for any client that cannot run the script, regardless of what user agent string it presents. I tested with agent user agents and with an ordinary desktop browser string; all of them got 403. It is not profiling.

Second, search engines are unaffected. Verified crawlers are exempted by the CDN on the basis of verified identity rather than a header, and the proof is in Search Console: over the last 28 days the flagship product page collected 28 impressions at an average position of 5.6. Google can see the page perfectly well. An AI shopping agent is not a verified search crawler, and would be treated like any other unverified client.

Why that is a tradeoff, not a bug

The obvious reaction is to call the challenge a misconfiguration and remove it. That would be a mistake, and understanding why is the actually useful part of this exercise.

That rule exists because of a card-testing attack in June 2026. Card testers do not go straight to a payment endpoint; they need a session and a nonce, so they traverse the real navigational pages — product page, then cart, then checkout — exactly as a customer would, from a rotating pool of IPs. Challenging those page loads stops them dead, because they cannot solve the challenge either. The attack in question produced a run of failed orders and zero successful charges, and the rule has held since.

Now read that description again with an agent in mind. Traverses the real navigational pages, from an unfamiliar IP, without a browser session. A card-testing bot and a shopping agent have close to the same network fingerprint. The defence that stops one will stop the other, and no amount of enthusiasm about agentic commerce changes the fact that the fraud is real and the agent traffic, for most stores today, is hypothetical.

That is the genuine tension, and it is the thing to take away: agent-readiness is not a feature you enable, it is a security posture you renegotiate. The store owner’s job is not to rip the rule out. It is to decide, deliberately, which paths need to stay hostile to unverified clients and which need to open — and to make that call knowing that today the challenge is protecting real money and the agent traffic is not yet buying anything.

What being agent-ready actually requires

Putting the audit together, here is the honest checklist, in the order the work actually bites:

The fourth row is where most stores will lose time, and it is the row that no plugin changelog will ever tell you about, because it is not in the plugin.

The last row is worth enabling deliberately if it is off. Order attribution is the only mechanism that will let you answer “did any of this work?” in six months, and a decision you cannot measure is a decision you will keep re-litigating.

Where a site chatbot fits into this

It is tempting to read all of the above as “the buying conversation is moving off my site, and I should prepare to be a back end.” That is one future. It is not the only one, and it is not the near one.

The agent-driven purchase requires the buyer to already know what they want well enough for an agent to shop for it. The much larger share of commerce still starts with somebody on your page, uncertain, with a question — does this work with my theme, what happens after the trial, is there a migration path. That conversation happens on your site or it does not happen at all, and an AI chatbot connected to your WooCommerce catalogue is how you answer it at two in the morning.

The useful framing is that both surfaces are fed by the same thing: structured, accurate, machine-readable product data. If your Store API returns wrong stock levels, the agent checkout fails and your on-site assistant lies to a customer. Fix the data and both get better. Fix neither and no protocol will save you.

This is also why the “AI features” in a platform release are usually less interesting than the plumbing underneath them, a pattern I keep running into — the knowledge store proposal that did not make WordPress core failed on adoption evidence rather than on the idea, and the abilities registry it would have built on is doing more real work than anything branded as AI.

Frequently asked questions

Does updating to WooCommerce 11 expose my store to AI agents?

No. Both AI-related feature flags — agentic_checkout and mcp_integration — ship disabled and stay disabled through updates. On the store audited here, the checkout session endpoint returns 404 because the route is never registered.

Do I need Stripe to accept agentic payments?

No. Stripe co-authored the protocol and offers the shortest path if you already process with them, but ACP is an open specification under the Apache 2.0 licence and includes a delegated-payments mechanism intended to let merchants participate without changing processor. WooCommerce’s own implementation is gateway-agnostic at the checkout-session layer.

Will enabling this help my SEO?

Not directly — these are authenticated POST endpoints, not crawlable pages. The indirect effect is real though: the work that makes a catalogue legible to an agent is the same work that makes it legible to a crawler, and product pages that are unreachable to non-JavaScript clients are a risk worth knowing about either way.

Should I remove a bot challenge from my product pages to let agents in?

Not reflexively. Find out first what the rule is protecting against. If it went up during a card-testing attack, it is doing paid work today, and agent traffic is speculative revenue tomorrow. A narrower rule — challenging cart and checkout while leaving product pages open — is usually the better negotiation, and it is a decision to make with your payment processor’s fraud data in front of you.

How do I tell whether an order came from an agent?

WooCommerce’s order attribution feature records order origin and is on by default. It is the only thing that will let you evaluate this in six months instead of guessing.

The takeaway

WooCommerce did the hard part quietly. The Agentic Commerce Protocol is implemented in core, it handles idempotency and structured validation properly, and it is sitting behind a switch on every store running 11.0. Whether you flip that switch this year matters less than knowing three things about your own store: whether you have a Jetpack connection, whether your product pages answer a client that cannot run JavaScript, and whether your catalogue data is accurate enough to be worth exposing.

Two of those three have nothing to do with WooCommerce. That is usually how this goes.

If you want the on-site half of the conversation working before the off-site half arrives, MxChat Pro connects an AI assistant to your WooCommerce catalogue, and the documentation covers the setup. If you are still deciding what to run, the comparison of WordPress chatbot plugins is the place to start.