Your SaaS pricing page was built for a person with a cursor, not an agent with an API key. That gap is about to matter, because a new open standard now lets AI agents complete purchases directly, including subscriptions, without a human clicking a single checkout button.
The standard is called the Agentic Commerce Protocol (ACP). If you sell anything online, including recurring software seats, it is worth fifteen minutes to understand what it actually does, who built it, and what your site needs to expose before an agent can act on it.
Key takeaways
- ACP is an open commerce standard built by Stripe, OpenAI, and Meta that lets AI agents browse products, build a cart, and complete checkout on a buyer's behalf.
- It explicitly covers physical goods, digital goods, subscriptions, and asynchronous purchases, which puts SaaS billing inside its scope, not just retail checkout.
- The business stays the merchant of record. ACP standardizes the handoff between agent, buyer, and seller; it does not replace your payment processor.
- An agent can only act on what it can parse. A pricing page built as a JavaScript-rendered table with no structured product or offer data is invisible to an ACP-compatible agent, even if a human sees it fine.
- Supporting ACP starts with the same groundwork as general AI readiness: clean server-rendered HTML, accurate structured data on products and pricing, and a machine-readable description of what you sell.
What is the Agentic Commerce Protocol?
The Agentic Commerce Protocol is an open standard that defines how AI agents interact with businesses to complete purchases on a buyer's behalf. According to Stripe's own documentation, it was "created by Stripe, OpenAI, and Meta," and the project's specification site describes it as covering "physical and digital goods, subscriptions, and asynchronous purchases." The business selling the product remains the merchant of record throughout; ACP standardizes the conversation between the agent, the buyer, and the seller, not the underlying payment relationship.
Think of it as a shared language. Before ACP, every AI platform that wanted to let its agent shop would need its own one-off integration with every retailer and every payment processor. ACP gives agents and businesses a common set of building blocks instead, so a merchant implements the spec once and becomes reachable by any compatible agent, not just one vendor's.
How does an AI agent actually check out with ACP?
Stripe's documentation breaks the protocol into five building blocks, and together they describe the whole purchase lifecycle an agent walks through. Cart and feed lets an agent browse a product catalog and assemble a cart before checkout. Agentic checkout creates and updates a checkout session, handling cart changes, fulfillment options, and payment processing. Delegate payment passes a payment credential, such as Stripe's Shared Payment Token, between buyer, agent, and business without exposing the buyer's raw card details to the agent or the merchant. Delegate authentication uses OAuth 2.0 so an agent can act on a buyer's behalf with a specific business without the buyer handing over their account password. Orders and webhooks then track what happens after the purchase: confirmation, shipping, delivery, and refunds.
In practice, that means an agent reads your catalog, builds a cart against your checkout session, authenticates on the buyer's behalf, passes a tokenized payment credential, and gets a webhook back when the order updates. None of that works if the agent cannot read the catalog in the first place, which is where most sites will actually fail.
Does ACP cover subscriptions, or only one-time purchases?
Yes. The protocol's own description explicitly lists subscriptions alongside physical goods, digital goods, and asynchronous purchases as in scope. That is the detail most coverage of ACP skips, because the early public rollout centered on retail checkout inside ChatGPT. But the spec itself was not written as a retail-only tool. A recurring SaaS seat, a usage-based API plan, or an annual license renewal all fit the same purchase lifecycle: browse an offer, build a cart or selection, authenticate, delegate payment, and track the resulting order.
For a SaaS company, this matters more than it looks at first glance. Retail checkout is a single transaction an agent either completes or does not. A subscription is a standing relationship: tier selection, seat count, billing interval, upgrade and downgrade paths, and renewal. An agent attempting any part of that needs your pricing structure exposed in a form it can parse, not just a page a human can click through visually.
What does your site need to expose before an agent can buy from you?
An agent compatible with ACP is still bound by the same limits every AI crawler and agent has on the open web: it reads the HTML a server sends and the structured data embedded in it. It does not reliably execute client-side JavaScript to discover content that only renders after a script runs. A pricing page that builds its tier table, its toggle between monthly and annual billing, or its "contact us" enterprise tier entirely in JavaScript is functionally blank to that agent, the same way it is functionally blank to most AI search crawlers today.
The fix is the same groundwork AI visibility work already asks for. Pricing and plan details need to exist in the server-rendered HTML, not only behind a client-side render. Products and offers need structured data using schema.org's Offer type, which defines standard properties for price, price currency, availability, and the seller, so an agent does not have to guess what a number on the page means. And a catalog or feed describing what you sell, in a format an agent can fetch directly rather than scrape from rendered markup, turns "browse the catalog" from a guess into a reliable first step.
Do you need to rebuild your site to support ACP?
No, and that is the more useful way to think about this. ACP is published as an open specification that a business implements on top of its existing commerce backend and payment processor, not a platform you migrate onto. The actual work is making sure what an agent needs to read is actually readable: server-rendered pricing, structured product and offer data, and a checkout flow that does not assume every visitor is a human with a mouse. Those are the same fixes that improve how ChatGPT, Claude, and Gemini describe your pricing today, whether or not a given agent ever completes a purchase through ACP specifically.
That overlap is the real takeaway. Agent commerce readiness is not a separate project from AI visibility. It is the next step on the same checklist: can an agent find your site, can it read what you actually offer, and now, can it act on that information on a buyer's behalf. Run a scan to see where your pricing and product pages currently stand before worrying about checkout specifically.
What should SaaS companies do first?
Start with the pricing page itself, since it is the page most likely to hide the exact detail an agent or a buyer needs. Pull tier names, prices, billing intervals, and what is included in each tier into the server-rendered HTML, not a client-side widget. Mark up each plan as a schema.org Offer with explicit price and currency rather than leaving it as styled text in a table. If an enterprise tier is "contact us," say so in text an agent can read, rather than hiding it behind a form that only renders after a script runs.
From there, treat the same discipline that applies to AI visibility for SaaS companies generally: a clean, crawlable site is the prerequisite for being findable in an AI answer, being cited correctly, and now, being a candidate for an agent to transact with at all. None of this requires predicting which agent-commerce standard eventually wins. It requires making sure your product and pricing information exists somewhere other than inside a rendering pipeline.
Faro's structured data check flags exactly this gap: pricing and product information present on the page visually but missing or incomplete in the structured data an agent would actually parse. Pair it with a machine-readable site file built with the OKF generator, which gives any agent a single, direct place to find what you sell and what it costs, instead of making it reverse-engineer your catalog from rendered HTML.
How does this connect to WebMCP and the rest of agent infrastructure?
ACP solves the payment and checkout half of agent commerce. WebMCP solves a related but separate problem: giving an agent a defined way to take action on your site at all, beyond just reading it. Faro has already covered what agent commerce readiness looks like in general and looked specifically at which online stores AI agents can actually buy from today. ACP is the first time that general readiness question has a named, open specification behind it rather than a patchwork of one-off integrations, which is exactly why it is worth tracking now instead of after your competitors have already implemented it.
Frequently asked questions
What is the Agentic Commerce Protocol in plain terms?
It is an open standard that lets an AI agent browse a business's products, build a cart, and complete a purchase on a buyer's behalf, using a shared set of technical building blocks instead of a custom integration for every agent and every merchant.
Who created the Agentic Commerce Protocol?
Stripe, OpenAI, and Meta built it. Stripe's documentation describes OpenAI as the first AI platform to implement it inside ChatGPT, and Stripe as the first compatible payment service provider.
Does ACP work for software subscriptions, or only physical products?
The protocol's own scope explicitly includes subscriptions alongside physical goods, digital goods, and asynchronous purchases, so a recurring SaaS plan fits the same purchase lifecycle as a retail order.
Do I need to switch payment processors to support ACP?
No. ACP is an open specification implemented on top of existing commerce and payment infrastructure. A business stays the merchant of record and keeps its existing processor relationship; ACP standardizes how an agent initiates and completes the transaction.
What is the single biggest blocker to a site working with ACP?
Pricing and product information that only exists after client-side JavaScript renders it. An agent that cannot read your tiers, prices, or availability in the server-rendered HTML and structured data cannot act on them, no matter how well the checkout flow itself is built.
In short
The Agentic Commerce Protocol is an open standard from Stripe, OpenAI, and Meta that lets AI agents browse, select, and pay for products on a buyer's behalf, and it explicitly covers subscriptions, not just one-time retail purchases. Businesses stay the merchant of record; ACP standardizes the handoff, not the payment relationship itself. The real prerequisite is not implementing the spec, it is making sure your pricing and product information exists in a form an agent can actually read: server-rendered HTML and structured offer data, not a JavaScript widget. That is the same groundwork AI visibility already requires, which means the sites doing it today are the ones ready for whichever agent tries to buy from them tomorrow.
See where your own pricing and product pages stand with Faro's AI visibility scan, or go straight to the structured data check to find exactly which prices and offers are missing from your markup.