Stripe made its checkout readable to AI agents: I tested which stores actually get it

If you take payments through a Stripe Payment Link or a Stripe-hosted Checkout page, your checkout already offers AI agents a set of tools to read the order and fill in the payment form. You didn’t have to do anything. Stripe announced on 22 September that it had switched this on for all of its Checkout pages, using a new browser feature called WebMCP. But I tested it on 13 October, and two things limit who benefits. The tools only appear in agent browsers that have WebMCP switched on, because Stripe’s page doesn’t turn it on by itself. And when Stripe’s payment form sits inside your own checkout page, as it usually does on WooCommerce, I couldn’t get any tools to show up. Here’s what Stripe shipped, what an agent actually sees, and how to tell which group your store is in.

What Stripe shipped

Stripe announced the change in an engineering post, How Stripe is designing Checkout for AI agents (22 September 2026): “we enabled WebMCP on all Stripe Checkout UIs resulting in 42% fewer tokens consumed and 38% fewer tool calls invoked against baseline measurements.” Stripe says Checkout “powers over 7.8M businesses,” and that the aim was to reach merchants “without them needing to change their integration.”

WebMCP is a proposed web standard that Chrome is trialling. It lets a web page hand an AI agent a short list of named actions, so the agent can call “fill the payment form” instead of reading the page and guessing where to click. Stripe’s reason is the agents that have their own browsers: “Agents like Muse, Instinct, and Grokbot, are launching and becoming popular.” Those are the agents that, in Forter’s order data, now place most agent orders by filling in normal checkout pages.

The numbers are Stripe’s own test, and the post describes it plainly: “60 tests across six models on a fictional outdoor retailer website using the Stripe Checkout full page UI.” Every agent finished the checkout with or without WebMCP. With it, they used fewer tokens and finished faster. Stripe’s baseline is the useful number for a merchant: without the tools, an agent averaged “1.8M tokens consumed, 38.83 tool invocations, and >2.5 minutes” to pay. In other words, agents can already get through your checkout. WebMCP makes it cheaper and quicker for them.

What an agent sees: my test

Stripe publishes a sample agent with a public test-mode payment link, so I loaded that page in a headless Chromium browser and listed the tools it registered. I ran it twice: once as a normal browser, once with Chrome’s WebMCP testing switch turned on.

As a normal browser, the page had no tools at all. There was no WebMCP API on the page and no origin-trial token, which is how a site switches a trial feature on for ordinary visitors. That’s different from Shopify, which adds that token to its stores for Chrome visitors. Stripe’s own sample says its agent “enables the browser flags.” So on Stripe’s page, the tools exist only for agents whose browsers turn the feature on themselves. I don’t know which of the shopping agents do. None of them say.

With the switch on, the page registered three tools when it loaded:

• get_order_summary, marked read-only. It returned the currency, the total “in minor units” (838, meaning 8.38 EUR), the line item name and the payment methods on offer (card and Apple Pay).
• select_payment_method. I chose card and it confirmed.
• fill_payment_form, with fields for email, card number, expiry, CVC, cardholder name and country.

There is no “pay” tool at the start, and that’s deliberate. Stripe says: “we do not reveal the submit_payment tool until all the fields have been filled.” The form tool filled the email field. The card fields didn’t fill in my run, and Stripe’s own sample warns that the form tool “often re-renders and never acks,” so its agent fills one field at a time. I didn’t complete a payment. Even on a test page, I had no reason to.

Two details matter for merchants. First, Stripe’s docs say the payment tool carries a “consequentialHint” and tell agent builders: “Before calling a tool with this hint, get the user’s confirmation.” The design expects a shopper to approve the payment. Second, when I typed in an email that already had a Stripe Link account, Link opened a “Confirm it’s you” one-time-code box over the form. An agent can’t get past that box without the shopper. That’s a sensible safeguard, and it’s also one more place an agent checkout can stall.

Which stores it reaches

Stripe’s WebMCP docs list four supported payment pages: the full-page Checkout, the embedded form, Elements built on Checkout Sessions, and the hosted invoice page. They also say the feature is “experimental” and that “tool schemas can change.”

I tested the embedded form on Stripe’s own demo site, checkout.stripe.dev. The page itself registered no tools. Every Stripe frame inside it refused with the same error: access to the feature “tools” is disallowed by permissions policy. Chrome’s WebMCP documentation explains why. The policy “defaults to self,” which “disables it for cross-origin iframes,” unless the iframe carries allow="tools". The embedded checkout frame on the demo had no such attribute. Stripe lists the embedded form as supported, so a later Stripe.js release may fix this. On 13 October, I couldn’t make it work.

That matters most for WooCommerce. The WooCommerce Stripe plugin puts Stripe’s card form inside your own checkout page. Reading the plugin’s source (version 11.0.1), it uses Checkout Sessions only when Adaptive Pricing is on under its Optimized Checkout setting. Otherwise it uses PaymentIntents, which isn’t on Stripe’s list. That’s my reading of the code, not something WooCommerce or Stripe has said. Either way, the parts of a WooCommerce checkout that come before payment, such as address and shipping, are your forms, not Stripe’s. Stripe’s tools don’t cover them.

None of this applies to Shopify checkout. Shopify runs its own checkout and adds its own WebMCP tools.

What to do with this

• If you sell through Payment Links or Stripe-hosted Checkout: it’s already on and there’s nothing to set. Look at what get_order_summary hands over: your product names, the total and your payment methods. If a line item is called “Bundle B v2,” that’s what the agent reads and repeats to your customer. Stripe tags that output with an “untrustedContentHint” annotation.
• If Stripe sits inside your own checkout page: don’t assume agents get these tools. Test it. In Chrome, turn on chrome://flags/#enable-webmcp-testing, open your checkout, and see whether any tools appear.
• Either way: nothing here replaces a checkout that works for a person. In Stripe’s test, every agent finished without WebMCP too. The tools make the same checkout cheaper for agents to get through. They don’t make a broken one work.

WebMCP is still a trial, in Chrome and on Stripe’s side. I’ll re-run this test when Stripe or Chrome changes how it’s switched on.