Agentic Commerce in WooCommerce: What Ships Today, What Is Only Announced
- Agents can already read a WooCommerce store. They cannot check out through WooCommerce core. The Model Context Protocol integration arrived as a beta in WooCommerce 10.3 on 21 October 2025, and the Abilities API it builds on is in WordPress 6.9 core. Neither exposes a checkout.
- WooCommerce lists both agentic checkout protocols as coming, not shipped. Its own agentic commerce page marks MCP and the Abilities API as live, and Google’s Universal Commerce Protocol and Stripe’s Agentic Commerce Protocol as coming soon — the latter through the Stripe for WooCommerce extension.
- The seven canonical abilities in WooCommerce 10.9 are products and orders only.
products-query,product-create,product-update,product-delete,orders-query,order-update-status,order-add-note. There is no cart ability and no payment ability. - ACP does not run over the Store API. It defines its own surface —
POST /checkout_sessionsthrough/complete— with anIdempotency-Keyon every write and a delegated payment token capped by amount, merchant and expiry. - The work that pays off before either protocol lands is unglamorous. Correct structured product data, idempotent order creation, and a deliberate decision about how your bot protection treats cryptographically signed agents.
The gap between “AI agents are buying things” and “AI agents can buy things from your WooCommerce store” is a protocol layer that, for WooCommerce, has been announced but has not shipped. Reading is solved: an assistant can query your catalogue through MCP today. Buying is not: WooCommerce core has no checkout ability, and the two protocols that would provide one are both listed by WooCommerce as forthcoming. That distinction matters because the preparation work is real and the deadline is not yet fixed — you can do the useful parts now, cheaply, and skip the parts that depend on decisions Stripe and Google have not finished making. This post covers what each protocol actually specifies at endpoint level, why the Store API is the wrong surface for agent checkout, and the eight things worth changing in your store this quarter.
On this page
- What has actually shipped for WooCommerce
- Three protocols doing three different jobs
- Why the Store API is not an agentic checkout API
- How does ACP agentic checkout work?
- How does an agent pay without holding a card number?
- How does UCP differ from ACP?
- The three paths a request can take into your store
- What breaks when an agent hits an ordinary checkout
- How do you tell an authorised agent from a scraper?
- Why idempotency stops being optional
- Who is the seller of record?
- Eight things worth doing this quarter
What has actually shipped for WooCommerce
Two things are live in core, and both are read-and-manage, not buy. The WooCommerce MCP integration shipped as a beta in WooCommerce 10.3 on 21 October 2025, letting any MCP-compatible client interact with a store through a standardised protocol. It rests on the WordPress Abilities API, which is in WordPress 6.9 core — a registry where plugins declare typed, discoverable, permission-checked functions.
WooCommerce 10.9 then defined the canonical set of abilities: woocommerce/products-query, woocommerce/product-create, woocommerce/product-update, woocommerce/product-delete, woocommerce/orders-query, woocommerce/order-update-status and woocommerce/order-add-note. Read that list for what is absent: no cart, no checkout, no payment. An agent holding valid credentials can create an order record; it cannot take money for one.
The distinction is not pedantry. It sets what an agent can do against your store today without your involvement — which is browse and read — and what still requires a protocol neither shipped nor finalised. The Abilities API is the substrate for the rest, so a store that is discoverable and correctly described today inherits the benefit when checkout does land. If MCP itself is unfamiliar, the mechanics are covered in our explainer on what the Model Context Protocol is and why it matters to software teams.
Three protocols doing three different jobs
MCP, ACP and UCP are not competitors for the same slot, and treating them as a three-horse race produces bad architecture decisions. MCP is a tool-calling transport: it lets an assistant discover and invoke your store’s declared abilities. ACP is a checkout protocol: it specifies how an agent creates, updates and completes a purchase, and how payment is delegated. UCP is a broader commerce framework: discovery, checkout and post-purchase support, with the transport left open.
They overlap deliberately. UCP explicitly accommodates MCP bindings — Google’s own description notes a checkout capability “can have a REST API binding or a MCP binding depending on your platform’s needs” — and states compatibility with Agent2Agent (A2A) and the Agent Payments Protocol (AP2). ACP likewise offers REST and MCP-compatible integration patterns. So MCP can be the pipe through which either checkout protocol travels.
For a WooCommerce operator the practical mapping is: MCP is the part you already have, ACP is the part Stripe intends to deliver through its extension, and UCP is the part Google intends to deliver for retailers eligible for checkout in Search AI Mode and the Gemini app. This sits inside the wider shift covered across our AI for commerce teams guide hub.
Why the Store API is not an agentic checkout API
The Store API was built for your own front end, and its security model says so. WooCommerce documents it as an unauthenticated, public API: there are no API keys, and write endpoints instead require a nonce token. Requests to /cart endpoints return a Cart-Token header, and when a client uses that Cart-Token, a nonce is not required. Checkout lives at /wc/store/v1/checkout.
That design is coherent for a headless storefront you control. It is a poor fit for a third-party agent for three reasons. There is no identity: an unauthenticated API cannot distinguish a shopping assistant acting for a customer from a scraper. There is no negotiated versioning: the contract moves with your WooCommerce version, and 10.7 alone added weight, dimensions, embeddable _links for upsells and cross-sells, and a ?related=ID parameter. And there is no delegated payment concept at all — the Store API expects a payment method to be resolved in a browser session.
So an agent driving the Store API is doing something closer to automated browsing than to commerce. It works until a nonce expires, a cache layer intervenes, or a payment method needs a redirect. Both ACP and UCP exist precisely to replace that arrangement with a contract.
How does ACP agentic checkout work?
ACP gives the merchant a dedicated checkout surface that the agent calls directly. The Agentic Commerce Protocol is an open standard created by Stripe, OpenAI and Meta, published under Apache 2.0, with the current stable specification versioned 2026-04-17. Its agentic checkout API defines four operations:
POST /checkout_sessions
GET /checkout_sessions/{checkout_session_id}
POST /checkout_sessions/{checkout_session_id}
POST /checkout_sessions/{checkout_session_id}/complete
POST /checkout_sessions/{checkout_session_id}/cancelEvery POST carries four headers: Authorization, Content-Type, an Idempotency-Key, and an API-Version expressed as a dated string. The session object holds line_items, fulfillment_options, selected_fulfillment_options, totals, messages and buyer, among others.
The status enumeration is where the protocol earns its keep, because it makes the awkward cases explicit rather than leaving them to fail: incomplete, not_ready_for_payment, requires_escalation, authentication_required, ready_for_payment, pending_approval, complete_in_progress, completed, canceled, in_progress and expired. A checkout that needs a human decision returns requires_escalation instead of silently stalling — the failure mode that makes browser-driving agents unreliable today.
How does an agent pay without holding a card number?
Through a delegated token that is scoped before it is issued. ACP’s delegate payment API is a single endpoint, POST /agentic_commerce/delegate_payment, carrying the same Idempotency-Key and API-Version header discipline. The request submits the payment method plus an allowance object and a set of risk_signals. The response returns a vault token identifier prefixed vt_.
The allowance is the interesting part, because it converts an open-ended payment credential into a bounded one. Its fields are reason, max_amount, currency, checkout_session_id, merchant_id and expires_at. A token is therefore constrained to one amount ceiling, one merchant and one expiry window, which is a materially different risk object from a stored card an agent can reuse.
Stripe positions its Shared Payment Token API as one route into this, and states that merchants on other processors can participate by adopting the delegated payments part of the specification without changing processor. For a WooCommerce store this remains prospective: WooCommerce’s own materials describe agentic checkout as coming to the Stripe for WooCommerce extension, announced on 11 December 2025 with a waitlist rather than a shipped feature.
How does UCP differ from ACP?
UCP is wider in scope and starts from discovery rather than checkout. Google announced the Universal Commerce Protocol on 11 January 2026 as an open standard covering the whole shopping journey — discovery, buying, and post-purchase support. According to Google’s announcement it was co-developed with Shopify, Etsy, Wayfair, Target and Walmart, and endorsed at launch by more than 20 further companies including Adyen, American Express, Best Buy, Flipkart, Macy’s, Mastercard, Stripe, The Home Depot, Visa and Zalando.
Architecturally, a business publishes a JSON manifest at /.well-known/ucp. Agents read it to discover which services the store supports — a shopping service is identified as dev.ucp.shopping — and which capabilities sit inside them, capabilities being building blocks such as checkout and product discovery, extensible with things like discounts. Transport is not fixed: REST, MCP and A2A bindings are all permitted.
Payments are modelled as a separation between payment instruments, which the consumer holds, and payment handlers, which process them, using tokenised payments and verifiable credentials so that each authorisation carries cryptographic proof of user consent. Google states retailers remain the seller of record. The first surfaces are checkout in Google Search AI Mode and the Gemini app for eligible US retailers.
The three paths a request can take into your store
An agent reaching your store today takes one of three routes, and only one of them is available to WooCommerce right now. The diagram below shows what each path touches and where it terminates.
What breaks when an agent hits an ordinary checkout
Every failure in the left-hand column below comes from the same root cause: an ordinary checkout assumes a browser with a human in it. The right-hand column is not aspiration — each entry is a mechanism the ACP specification actually defines, which is why the comparison is worth making now rather than after the protocol lands.
| Concern | Ordinary WooCommerce checkout | What ACP specifies instead |
|---|---|---|
| State | Session cookie, or a Cart-Token header issued by /cart |
A server-side checkout session with an id and an explicit status |
| Blocked flow | Fails or stalls with no machine-readable reason | Status requires_escalation or authentication_required |
| Duplicate submission | Browser guard plus nonce reuse rules | Idempotency-Key required on every POST |
| Payment authority | Card or redirect resolved in the browser | Vault token bounded by max_amount, merchant_id, expires_at |
| Contract stability | Moves with your WooCommerce version | Negotiated through a dated API-Version header |
| Caller identity | Unauthenticated; user agent string and IP only | Authorization header, with signed-agent verification alongside |
Read down the middle column and the pattern is that every safeguard is implicit, carried by the browser rather than by the contract. Read down the right and every safeguard is named in a header or a field. That is the whole difference, and it is why bolting an agent onto the Store API produces a demo rather than a channel.
How do you tell an authorised agent from a scraper?
By checking a cryptographic signature rather than a user agent string. Web Bot Auth, an IETF draft effort led by Cloudflare, builds on RFC 9421 HTTP Message Signatures. An agent operator publishes a public key directory, requests carry Signature and Signature-Input headers, and a Signature-Agent header names the domain hosting the keys. The site fetches the key from the directory published by that domain — the companion IETF draft is http-message-signatures-directory — verifies the Ed25519 signature, and checks that the created and expires timestamps in Signature-Input fall inside a valid window.
This is the piece most stores get wrong, because the instinct is to tighten bot rules and treat all automation as hostile. That instinct blocks the buyers as well as the scrapers, silently, with no order to investigate afterwards. Infrastructure is moving the other way: AWS announced Web Bot Auth support in AWS WAF on 21 November 2025, with verified bots allowed by default rather than caught by the blanket AI category rule.
The decision to make is a policy one, not a technical one, and it should be made deliberately: which signed agents may read your catalogue, which may reach cart endpoints, and which are refused. Write it down before an assistant starts sending buyers, because the default — block everything unrecognised — is a decision too, just an unexamined one.
Why idempotency stops being optional
An agent retries where a human gives up, and it retries fast. A shopper who sees a spinner waits, then reloads once. An agent hitting a timeout re-issues the request on its own schedule, and it may be running several candidate purchases in parallel while it decides. Without a deduplication key at the API layer, the same intent lands as two orders and two charges.
ACP’s answer is to make the key mandatory: an Idempotency-Key is required on every POST, and in the delegate payment API the specification defines it as an opaque string capped at 255 characters, recommending a UUID v4. Note what a required key implies for the merchant side — the endpoint has to store it and return the original result on a repeat, not merely tolerate the header.
You do not need to wait for a protocol to benefit from this. Any custom order-creation path in your stack — a middleware integration, a bespoke endpoint, an ERP sync writing orders back — should already deduplicate on a caller-supplied key. Retries without an idempotency key are a routine cause of duplicate order records in integrated stacks, and agent traffic multiplies the retry rate rather than introducing a new failure mode.
Who is the seller of record?
Under both protocols as currently specified, the merchant is. Google states plainly that retailers remain the seller of record under UCP, with the ability to customise the integration. UCP’s own architecture notes place merchant-of-record status alongside business logic on the merchant’s side of the boundary. ACP is built on the same premise: the agent orchestrates and the payment is delegated to the merchant’s processor, which is why Stripe describes participation as possible without changing processor.
That answer matters more than it first appears, because it settles who owns the consequences. Tax determination, fulfilment obligations, chargeback exposure, refund policy and consumer-protection duties stay with you. The agent is a new channel into your existing responsibilities, not a reseller absorbing them.
It also sets a limit on how far preparation can run ahead of the specifications. Fee structures, dispute handling for agent-initiated orders, and the escalation path when an agent misreads an option are precisely the areas still moving. Treat any confident public claim about agentic commerce economics with suspicion until the party charging the fee has published it.
Eight things worth doing this quarter
All eight are useful whether or not your store ever serves an agent, which is the test a preparation task has to pass while the protocols are unfinished. None of them depends on choosing between ACP and UCP.
1. Audit Product structured data on every product page: price, currency, availability, SKU, and condition where relevant. Ambiguity here is what makes an agent pick the wrong variant.
2. Make variant naming machine-legible. “Blue / L” beats a colour swatch with no text equivalent, because an agent reads the text.
3. Confirm price and availability agree across the product page, the Store API response and any feed you publish. Disagreement between surfaces is a checkout failure waiting for a trigger.
4. Add idempotency to every custom order-creation path you own, keyed on a caller-supplied value, returning the original result on a repeat.
5. Decide your signed-agent policy explicitly — read, cart, refuse — and record the decision where the next person will find it.
6. Check whether your bot protection currently blocks declared agents by default, and whether you would be able to tell.
7. Inventory the checkout steps that assume a browser: interstitials, redirects, anything requiring a click to proceed.
8. Keep WooCommerce current. The Abilities API contract is where agent-facing capability is accumulating, and it is a core-version dependency.
Items 1 to 3 are catalogue hygiene that improves ordinary search visibility too. Items 4 to 7 are risk controls that pay for themselves the first time a retry storm hits. Item 8 is the only one that is purely about the future, and it costs nothing beyond your normal update discipline. The broader trajectory — what changes when a meaningful share of orders arrive without a human at the keyboard — is covered in our analysis of what autonomous shopping means for your store.
If the constraint is engineering time rather than knowing what to change, SoftXone builds and operates the integration layer underneath stores like this one — catalogue data, order pipelines, and the ERP sync that has to stay correct when a new channel starts writing to it.
Get the working checklists
The runbooks and decision checklists from these guides, as printable PDFs — free in the SoftXone guide library.
References
- WooCommerce — Agentic CommerceWooCommerce’s own status page: MCP and the Abilities API listed as live, UCP and ACP listed as coming.
- Canonical WooCommerce abilities for products and ordersWooCommerce Developer Blog — the seven canonical abilities introduced in 10.9 and their exact names.
- WooCommerce 10.3: COGS comes to core and MCP betaWooCommerce Developer Blog — the 21 October 2025 release that first shipped the MCP integration in beta.
- WooCommerce MCP integrationWooCommerce developer docs — exposed abilities, permission levels, and the deprecated endpoint’s authentication.
- WooCommerce Store APIWooCommerce developer docs — the unauthenticated model, nonce tokens, Cart-Token, and the checkout route.
- Agentic Commerce ProtocolThe ACP specification home — checkout, cart and feed, delegated payment, delegated authentication, orders.
- ACP specification repositoryApache 2.0 source of truth, including the OpenAPI definitions for spec version 2026-04-17.
- Stripe — Agentic Commerce ProtocolStripe’s implementation documentation, including delegated payment and the Shared Payment Token route.
- Google — new tech and tools for retailers in an agentic shopping eraThe 11 January 2026 UCP announcement, co-developers, endorsers, and seller-of-record position.
- Under the Hood: Universal Commerce ProtocolGoogle Developers Blog — services, capabilities, the /.well-known/ucp manifest, and payment handlers.
- Cloudflare — verifying bot and agent traffic with cryptographyWeb Bot Auth: the Signature, Signature-Input and Signature-Agent headers and the key directory.
- RFC 9421 — HTTP Message SignaturesIETF — the signature standard Web Bot Auth builds on.
- AWS WAF announces Web Bot Auth supportAWS — 21 November 2025; verified Web Bot Auth traffic allowed by default rather than blocked by category.
Frequently asked questions
Can an AI agent complete a purchase on my WooCommerce store today?
Not through WooCommerce core. The canonical abilities WooCommerce ships cover querying and updating products and orders, with no cart ability and no payment ability, so an agent holding valid credentials can create an order record but cannot take payment for one. The routes that do exist are indirect: an agent driving your ordinary checkout as if it were a browser, or a future extension implementing a checkout protocol on your behalf. Test the first case against your own store before assuming it fails, because the outcome depends on your payment method and bot rules rather than on WooCommerce itself.
Do I have to choose between ACP and UCP?
No, and in the near term the choice is unlikely to be yours to make in code. Both protocols are expected to reach WooCommerce stores through extensions rather than through anything you write, so the practical decision is which extension you install and when. The specifications are not mutually exclusive either: the Universal Commerce Protocol treats transport as pluggable and states compatibility with the Model Context Protocol and the Agent Payments Protocol, while the Agentic Commerce Protocol offers REST and MCP-compatible integration patterns. Nothing in either specification prevents one store from supporting both.
Will agent-initiated orders appear normally in WooCommerce?
That depends on which path the order takes, and it is worth confirming before the channel carries volume. An order placed through your ordinary checkout is an ordinary order. An order placed through a protocol extension should also land as a normal record, but the questions to put to any extension are where the order is created, which status it starts in, and whether existing hooks and ERP sync fire on it. Integrations that key off checkout-page events rather than order status transitions are the ones most likely to miss agent orders silently.
Should I block AI agents from my store?
Blocking is a defensible policy, but it should be a decision rather than a default. Blanket bot rules do not distinguish a shopping assistant carrying a real buyer from a scraper harvesting prices, and a blocked buyer leaves behind no order to investigate. Web Bot Auth exists to make that distinction available, because a signed request can be verified against a published key instead of guessed at from a user agent string. Decide separately for catalogue reads and cart writes, and check what your current rules already do before changing them.
Does structured product data still matter if agents use a protocol?
Yes, because discovery and transaction are separate problems. Both protocols standardise the transaction; neither invents product information a store does not publish. An agent still has to work out which variant matches a request, and it does that from the text and structured data on the page. Ambiguous variant labels, prices that disagree between the product page and an API response, and missing availability fields all produce the same result: the agent selects the wrong item or abandons the attempt. That same work improves ordinary search visibility, which is why it is worth doing first.
Leave a Reply