ChatGPT Instant Checkout for WooCommerce: What's Real in 2026

Does WooCommerce support ChatGPT Instant Checkout yet?

Not natively. As of October 2026, WooCommerce's own agentic commerce status page marks the Model Context Protocol and the WordPress Abilities API as live, and both agent checkout standards — the Stripe/OpenAI Agentic Commerce Protocol and Google's Universal Commerce Protocol — as coming soon. The Stripe for WooCommerce extension is described there as something you install now to prepare, not something that already sells through ChatGPT.

That last row is where most of the confusion starts. WooCommerce core carries an AGENTIC_COMMERCE value in its payment gateway feature enum, and several write-ups read that as “Woo shipped ACP”. It is a flag a gateway declares about itself so the rest of the stack can branch on it. Declaring it does not create a checkout session endpoint, does not produce a product feed, and does not put a single SKU in front of a ChatGPT user.

The practical reading: MCP lets an AI assistant read your store once someone connects it. Instant Checkout is an AI agent transacting with your store on a shopper's behalf, and that path is still something you build or buy yourself.

How Instant Checkout works, in four moving parts

Strip away the marketing and ACP is four responsibilities with a clear owner for each. Knowing which ones are yours is most of the estimate.

Three consequences that catch store owners out:

• You stay the merchant of record. The checkout UI renders inside ChatGPT, but the session state, the tax and shipping maths, the charge and the order all live on your infrastructure. If your totals are wrong, they are wrong in someone else's interface.
• The protocol is processor-agnostic. Stripe's Shared Payment Token is the first compatible implementation, not a requirement baked into the spec. If you are not on Stripe, the real constraint is whether your processor supports delegated payment credentials yet — most do not, which in practice makes Stripe the short path.
• Implementing the protocol does not list you. The ACP specification's own FAQ is explicit that each AI platform runs its own participation process. Spec compliance is the price of entry, not the entry.

Step one: get your WooCommerce catalog into ChatGPT

Feeds come first, and this is the part worth doing even if you never ship a checkout endpoint. OpenAI's ACP getting started guide describes the integration path as feed-first, with two delivery methods: file upload or API. The recommended pattern is a full catalog snapshot once a day by file upload, with intraday changes pushed through the API; promotions can only go through the API. Feed onboarding is currently limited to approved partners, and the application lives at chatgpt.com/merchants.

The same guide carries a prohibited products policy — adult content, alcohol, nicotine, gambling, weapons, prescription-only medication and unlicensed financial products among them. If that describes your catalog, stop here and spend the budget elsewhere.

Assuming you qualify, feed quality is where WooCommerce stores lose. The data model is flexible, which is exactly why it is usually messy. These are the failures that recur:

None of this is new work if you already maintain a Google Merchant Center feed — it is the same discipline pointed at a different endpoint, which is why stores with a clean Merchant Center history clear validation quickly and stores without one spend two weeks on data cleanup. If that cleanup is the part you would rather hand over, it is what our product feed management service covers.

What you actually have to build on WooCommerce

The checkout half is a small REST surface with strict semantics. The spec defines a session lifecycle — create, retrieve, update, complete, cancel — and the work is mapping each step onto WooCommerce without inheriting assumptions that only hold for browser traffic. Confirm exact paths, headers and the protocol version you are targeting against the current specification before writing code; the shape below is what the mapping looks like.

Registering the surface is the easy part. What matters is what sits in the permission callback:

add_action( 'rest_api_init', function () {
    register_rest_route( 'acp/v1', '/checkout_sessions', array(
        'methods'             => 'POST',
        'permission_callback' => 'netalith_acp_authorize',
        'callback'            => 'netalith_acp_create_session',
    ) );

    register_rest_route( 'acp/v1', '/checkout_sessions/(?P<id>[A-Za-z0-9_-]+)', array(
        'methods'             => 'POST',
        'permission_callback' => 'netalith_acp_authorize',
        'callback'            => 'netalith_acp_update_session',
    ) );
} );

function netalith_acp_authorize( WP_REST_Request $request ) {
    // 1. Bearer credential compared with hash_equals(), never ==
    // 2. Signature verified against the RAW body, not the parsed array
    // 3. Replay window enforced on the timestamp header
    // 4. Idempotency key recorded BEFORE any write happens
    return netalith_acp_verify( $request );
}

Three things that are not obvious from the spec. Verify the signature against the raw request body — WordPress parses JSON into an array, and re-encoding it changes byte order, so your HMAC will not match. Record the idempotency key before you create anything, because the retry you are protecting against is the one where your first attempt timed out mid-write. And keep the whole namespace out of every cache layer in front of the site; an agent reading a total cached thirty seconds ago will complete a session at a price you did not expect to be paid.

Do the WooCommerce ACP plugins get you into ChatGPT?

Partly. Several plugins now implement the ACP surface for WooCommerce, ranging from feed-only exporters to full session lifecycles with published signing keys, Stripe Shared Payment Token handling and an admin screen. The good ones genuinely save you the adapter work.

What none of them can do is get you listed. Onboarding is OpenAI's decision and runs through their application process. A plugin that presents “Buy it in ChatGPT” as an install-and-go outcome is selling you the technical half while implying the commercial half. Treat conversion-lift claims in plugin marketing the same way — nobody has a representative sample of agentic checkout data yet.

If you evaluate one, these are the criteria that decide it, in the order worth weighing them:

1. Maintenance and licence. This plugin opens a permanent, publicly reachable write endpoint on your store. An abandoned one is a liability, not a feature. Look for a named maintainer, a real changelog, and a GPL-compatible licence you can audit and fork.
2. Authentication depth. Does it verify a request signature against the raw body, or just compare a shared secret? The second is not acceptable on an endpoint that creates orders.
3. Idempotency. Send the same completion twice on staging. Two orders means it is not production-ready.
4. Payment path. Real delegated-token handling with declines surfaced back to the agent, versus a mock handler shipped for demos. Check which one is wired by default.
5. Versioned conformance. Ask which protocol version and date it targets. “ACP compliant” with no version is marketing; the spec moves.
6. Stock semantics. Find out whether it decrements inventory on create or on complete. Both are defensible; not knowing which is not.
7. Clean removal. Deactivate it and confirm the routes return 404. Some leave rewrite rules and option rows behind.

Five WooCommerce behaviours that break an agent checkout

These are platform-specific, and they are where a working staging integration turns into declined orders in production.

1. The cart is session-bound, the agent is not. WC()->cart assumes a customer session backed by a cookie. An agent has neither. Model the checkout session as its own record with its own identifier and lifetime; borrowing the cart object looks faster for a week, then collides across concurrent sessions.
2. Caching in front of /wp-json. Host-level page cache, object cache and CDN rules all need an explicit exclusion for the ACP namespace. A stale total is a mispriced order you are on the hook for.
3. Shipping and tax must be recomputed on every update. Woo resolves shipping from zones and packages against a concrete destination. Returning an estimate at create and a different number at complete produces exactly the price-change decline the protocol exists to prevent.
4. Stock drift between create and complete. Minutes can pass while a shopper deliberates in chat. Decide the reservation policy deliberately: reserve and risk phantom holds, or do not reserve and risk declines. Declines are visible to the agent and affect whether it surfaces you again.
5. Order creation under retries. Retries are part of the protocol, not an exception. Store the idempotency key against the order, return the same order on replay, and set a distinct created_via value so agent orders stay separable in reporting. Keep fulfilment side effects out of the completion request entirely — queue them, because the agent has a timeout and your ERP sync does not care.

Build now, or wait for Stripe's Agentic Commerce Suite?

Because WooCommerce has publicly committed to ACP through the Stripe extension, building a full custom adapter today means possibly building something you will be able to configure in a dashboard later. That is a real risk, and it is not the same risk for every store.

The honest summary: the feed work is the only part of this guaranteed not to be wasted. It is the same structured catalog data Google's surfaces consume, it survives whichever protocol wins, and it is the prerequisite for every path above. The checkout adapter is a bet on timing — worth placing if your margins justify being early, worth deferring if they do not.

If you want a second opinion on which row your store falls into before spending the budget, tell us about your store and we will scope it — including the unglamorous answer where the right move is to fix the catalog and wait.