Stripe Projects launched April 30, 2026, letting AI agents buy infrastructure plans and SaaS subscriptions. What it means for your pricing page, and the detect/serve/sell checklist for API-first founders.
On April 30, 2026, Stripe announced Projects: a set of primitives that let AI agents create accounts, purchase plans, provision resources, and manage subscriptions on cloud infrastructure platforms. Cloudflare, Vercel, and Netlify were the launch partners. The coverage from Search Engine Journal called it straightforwardly what it is: cloud infrastructure buying, opened to AI agents. That is accurate, and it is the part worth sitting with if you build or sell SaaS.
The question is not whether agents will buy software. They already do, on the platforms that wired it up first. The question is whether your product shows up as a legible option when they do.
Projects is a set of four flows an AI agent can invoke through Stripe's APIs. They map to the stages a human goes through when signing up for a cloud product.
Account creation. The agent creates an account on your platform on behalf of the user. No human walks through a signup form. The agent handles identity and credentialing via delegated tokens.
Plan purchase. The agent selects a plan, presents a payment method, and completes the transaction. This is the moment Stripe's payment rails enter the picture: the same infrastructure that processes millions of human SaaS signups now handles programmatic ones.
Provisioning and configuration. After purchase, the agent configures the acquired capability. On Cloudflare this might mean spinning up a Worker and setting environment variables. On Vercel it might mean creating a project and deploying a branch. The provisioning step is what separates infrastructure commerce from retail: there is a resource to configure, not just a product to ship.
Subscription management. The agent can query, upgrade, downgrade, or cancel on behalf of the user. If a coding agent builds something that exceeds a free-tier limit, it can request a plan upgrade mid-task rather than halting and waiting for a human to notice.
The reason Cloudflare, Vercel, and Netlify were first is legible in retrospect. They are API-first platforms with machine-readable primitives already baked in. The agent path was a natural extension of the developer API they already maintained. Most SaaS products were not designed with that constraint, which is exactly the gap this post is about.
The agent-commerce stack is splitting in a way that matters for how you think about readiness. The retail lane and the infrastructure lane have different mechanics.
The retail lane runs through protocols like ACP and integrations like Visa-in-ChatGPT, announced June 10, 2026. An agent browses product pages, extracts price and availability, selects an item, and completes a cart-and-checkout flow. The product is a physical or digital good. The purchase is one-directional: money changes hands, something is delivered. We covered that lane in depth in our AI agent commerce post.
The infrastructure lane, where Stripe Projects operates, has a provisioning step after payment. Buying a $20/month compute plan is not the end of the transaction; it is the prerequisite for the actual task. The agent's goal is deploying something, not owning a plan. The plan is instrumental. This changes what "readable pricing" means and what a machine-readable commerce layer needs to expose.
For a SaaS product, the agent needs to know: what does each tier let me do, what are the rate limits or seat limits, how does provisioning work after purchase, and what is the programmatic path to billing management? A pricing table with three column headers and checkmarks does not answer those questions, for a human or an agent.
Pull up a typical SaaS pricing page in a crawl simulator or a browser with JavaScript disabled and you will see the problem immediately. Prices rendered in a React component that fires on interaction. Tier names that are marketing copy ("Starter", "Pro", "Scale") with no semantic meaning attached. A "contact us" button that replaces any pricing information for the enterprise tier. Feature comparisons locked in an accordion that requires a click to open.
An agent crawling your pricing page encounters all of this. It does not click. It does not wait for JavaScript. It reads what the server sent, and if what the server sent is a loading skeleton, the agent has no pricing data to work with.
The three failure modes appear consistently across B2B SaaS pricing pages:
JS-only rendering. Price and plan details exist only after client-side JavaScript executes. Agents using the crawler model, rather than a browser-driving model, never see them. Even browser-driving agents have timeout budgets and may not execute every interactive element.
"Contact sales" opacity. Hiding pricing behind a form is a deliberate choice for many enterprise products, and that is a legitimate business decision. But it is invisible to an agent. If your mid-market plan is gated behind a demo request, an agent evaluating your product versus a competitor whose $299/month plan is openly listed will select the competitor without any signal that it made a tradeoff.
No structured metadata. Schema.org has Offer and Product types that carry price, currency, and availability in a machine-readable format. SaaS pricing pages almost never use them. Without that layer, an agent must infer plan details from prose, which introduces errors.
There are three layers, and they compound. You do not need all three to be useful to an agent, but each one significantly improves what an agent can do with your pricing.
Layer 1: Server-rendered HTML. Plan names, prices, billing cadence, and the most important feature distinctions must exist in the initial HTML response. This is the minimum. If a crawler fetches your /pricing and parses out "Starter: $29/month, up to 5 seats — Pro: $79/month, unlimited seats, API access," that agent has what it needs to make a comparison. This takes an afternoon to fix if your current pricing is JS-rendered.
Layer 2: llms.txt with pricing context. Your llms.txt file should link to your pricing page with a one-line description. Something like: "Pricing (/pricing): three tiers, Starter at $29/month for individuals, Pro at $79/month for teams up to 25 seats, Enterprise custom, annual and monthly billing available." An agent that reads your llms.txt before crawling your site now knows what to expect and which URL to prioritize. Without that signal, it may spend its context budget on your blog rather than your pricing page.
Layer 3: WebMCP commerce tools. The WebMCP protocol lets you expose your plans as callable tools. An agent that supports tool calls can invoke get_plans() and get back a structured JSON response with your current tier names, prices, limits, and feature flags. It can invoke check_availability() to confirm a plan is open for signup. It can invoke begin_checkout(plan_id: "pro") to start a purchase flow. This is categorically different from scraping your pricing page: it is durable, versioned, and does not break when your marketing team redesigns the page.
The sequence matters. Layer 1 makes you readable. Layer 2 makes you findable within your site context. Layer 3 makes you buyable by agents that support tool invocation. Skipping Layer 1 while adding Layer 3 is like building a checkout flow before you have a product listing.
Before you change anything, the most useful question is whether agents are already visiting your pricing page. The answer will surprise many SaaS operators who have not looked.
Agent traffic appears in your server logs under distinct user agents. GPTBot and ChatGPT-User come from OpenAI's crawler and browsing agent respectively. ClaudeBot appears when Anthropic's systems fetch pages. PerplexityBot is Perplexity's crawler. In aggregate, these bots were responsible for a meaningful fraction of crawl activity across the web by mid-2025, and that share has grown since. Google Analytics filters most of them out by design, so if your analytics tool is your only window into traffic, you are missing this entire category.
What matters for a SaaS product is not just whether these bots hit your site, but which pages they prioritize. A bot hitting your blog is interesting context. A bot hitting your /pricing page repeatedly is a signal that something is routing agents to evaluate your product. That is a commercial signal worth knowing before you spend time restructuring your pricing page.
Crawlytics pulls AI bot and agent visits from your traffic and shows you the per-page breakdown: which crawlers, which pages, at what frequency. The Agent-Ready Grader gives you a baseline score that includes whether your pricing page is reachable at all. Run that first. The results will tell you whether you are early-stage (build readiness before the traffic arrives) or whether you are already behind (agents are showing up and finding a JavaScript skeleton).
Practical, in order.
Detect. Check your server logs for AI user agents hitting /pricing, /plans, or your trial signup page. If you are on Crawlytics, look at the per-page bot breakdown. Note frequency and which agents are most active. This takes 30 minutes and tells you whether you are optimizing proactively or reactively.
Serve. Audit your pricing page with JavaScript disabled. If the prices disappear, fix that first. Add your pricing page to llms.txt with a one-line description per tier. Add schema.org/Offer markup for each plan with price, priceCurrency, name, and a brief description. Audit your trial signup flow: does it require a human email verification loop that blocks automated paths? Fixing that is a larger project, but documenting it as a known gap is step one.
Sell. Implement WebMCP tools for your plan catalog. The minimum useful surface is get_plans(), returning structured plan data, and a begin_checkout(plan_id) that hands off to your existing Stripe checkout flow. If you are already using Stripe, the checkout side is largely solved. The question is whether you are exposing your plan catalog as a callable tool. The WebMCP documentation covers the implementation pattern. The agent transactability guide covers the DOM-level audit you should run on the checkout flow itself, because even with WebMCP, many agents complete checkout by driving your actual form fields.
Stripe Projects is live. The platforms that built API-first products shipped first because they already had the primitives. The gap between them and a typical SaaS product is not insurmountable. Structured pricing HTML, an updated llms.txt, and a WebMCP commerce layer are achievable in days, not quarters. The harder question is whether you know what agents are doing on your site right now. Start there.
Written by Crawlytics Team. Crawlytics tracks AI bots, generates llms.txt, and powers WebMCP commerce, all from one snippet on any stack. See how it works →
This page is part of Crawlytics.app. View all pages: llms.txt · llms-full.txt