Stripe launched Projects on April 30, 2026, a commerce protocol that lets AI agents create accounts, buy domains, upgrade plans, and deploy infrastructure on behalf of human owners. Cloudflare, Vercel, and Netlify shipped as launch partners. The protocol runs in parallel to Stripe's existing Agentic Commerce Protocol, which handles retail commerce. Together the two protocols define a clean split between buying things (ACP) and buying capabilities (Projects).
That split is the structural fact worth sitting with. The first wave of agentic commerce, from September 2025 through early 2026, was retail-shaped. Agents browsed product catalogs, added items to carts, completed checkouts at retailers like Etsy and Walmart and Glossier. The mental model was always a digital version of a human shopper. Stripe Projects breaks that frame. The buyer is still an agent acting under user authorization, but the merchant is a cloud platform, the catalog is a set of plans and resources rather than products, and the transaction completes by provisioning capability rather than by shipping a box.
Infrastructure buying is the second commerce category of the agentic web, and the audit questions for vendors in this category are not the same as the audit questions for retailers.
GET WEEKLY WEB STRATEGY TIPS FOR THE AI AGE
Practical strategies for making your website work for AI agents and the humans using it. Podcast episodes, articles, videos. Plus exclusive tools, free for subscribers. No spam.
What Stripe Projects Actually Does
Stripe Projects exposes four primary flows to AI agents acting under user authorization.
The first is account creation. An agent can register a new account at a participating vendor on behalf of a human owner, using the owner's verified identity and payment instrument. The vendor gets a structured signup request that includes the owner's identity, the agent's identity, and the authorization scope.
The second is plan and product purchase. An agent can read the vendor's catalog of plans, resources, or domains, select the one matching the owner's stated requirement, and complete the purchase. The flow uses Shared Payment Tokens for the actual transaction, the same primitive ACP uses for retail. The token is scoped to the vendor, the amount, and the time window.
The third is provisioning and configuration. After purchase, the agent can configure the resources for the owner. Cloudflare's launch description names this explicitly: an agent buying a Cloudflare account can also configure DNS records, deploy a Worker, attach a domain, and produce a working setup at the end of the flow rather than only a paid invoice.
The fourth is subscription management. Ongoing relationships, including upgrades, downgrades, billing-cycle changes, and cancellations, are agent-addressable. The agent can act on the owner's instruction to change the subscription state at any time. The vendor receives an authenticated request from the agent, validates the authorization, and updates the subscription.
The four flows together cover the lifecycle of an infrastructure relationship. An agent can start the relationship, run a transaction, configure the work, and maintain the subscription over time. The retail equivalent would be an agent that not only bought sneakers but also returned them, exchanged for a different size, and managed the loyalty membership. Most retail agents today stop at the purchase.
Why Cloudflare, Vercel, And Netlify Were At Launch
The launch cohort signals the category Stripe is targeting first. All three launch partners sit at the developer-platform layer of cloud infrastructure: edge compute, deployment platforms, and content delivery. None of them are general-purpose cloud providers in the AWS, Azure, or GCP mold. The choice reads as deliberate.
Cloudflare's launch description covered the full lifecycle. Agents create Cloudflare accounts, register domains, attach the domains to the account, deploy Workers, and configure DNS records. The transaction is one piece of the flow, and the configuration is the rest. Cloudflare framed Projects as agent-driven infrastructure provisioning that completes by producing a working setup, not by completing a checkout.
Vercel published a changelog entry supporting Pro plan purchases through Projects. The integration covers the upgrade flow specifically: an agent can move a human owner's Vercel account from the free tier to Pro, with the billing relationship managed through Projects from that point forward.
Netlify launched with a LinkedIn announcement from CEO Matthias Biilmann. Netlify's framing emphasized that the integration covers both new-account creation and existing-account subscription management, the two halves of the customer relationship.
The shared characteristic of the launch cohort is that all three vendors already had API-first product surfaces before Projects. Cloudflare's API, Vercel's API, and Netlify's API were each built for developer-driven workflows. Projects sits on top of those APIs and adds the commerce protocol layer for agents specifically. The vendors with API-first surfaces are the vendors who can ship Projects support fastest. Vendors who only expose human-facing dashboards have a more substantial build ahead of them.
The category Stripe is signaling first, then, is developer-adjacent cloud infrastructure. The next ring out, plausibly, is SaaS subscriptions for non-developer audiences: project-management tools, marketing platforms, design software, anything that sells a subscription with a tier ladder. The ring after that is general-purpose cloud and traditional B2B SaaS. None of those have shipped yet. The question for each vendor in those categories is whether to be early or to wait.
How Stripe Projects Differs From ACP
ACP and Stripe Projects share the same underlying payment infrastructure. Both run on Stripe's payment rails. Both can use Shared Payment Tokens for the agent-on-behalf-of-user transaction. Both go through Stripe Radar for fraud detection. The shared plumbing is meaningful and probably the reason both protocols can coexist cleanly under the same vendor.
The differences are at the merchant-side instrumentation layer.
ACP assumes a retail merchant exposes a product catalog. The agent reads the catalog through ACP's Feed surface, selects products, and completes a checkout. The merchant's responsibility is to keep the catalog clean and to handle the Complete Checkout endpoint. The agent's job is to read, select, and confirm. Most of the commerce-shaped patterns inside ACP map cleanly to existing e-commerce websites.
Projects assumes the merchant exposes a capability or subscription. The catalog is a set of plans, tiers, resources, or domains. The selection criteria are different from retail: an agent buying a Vercel Pro plan is not optimizing for size, color, and customer reviews, it is matching the plan's resource limits against the owner's stated workload. The agent's reading task is closer to a product spec sheet than to a product listing page. Merchants supporting Projects need to expose those specs in a structure agents can read, not only in a human-facing pricing page.
The authorization shape differs too. ACP authorizes a one-time purchase, where Projects authorizes an ongoing relationship. An agent buying through ACP needs permission for the specific transaction. An agent buying through Projects needs permission for the transaction plus, often, permission to manage the resulting subscription. The user-side authorization grants are wider for Projects, and the merchant-side authorization checks need to keep up with that wider scope.
The fraud-detection picture is also different. ACP fraud signals lean on transaction-level patterns: known card, known shipping address, plausible purchase composition. Projects fraud signals lean on relationship-level patterns: account creation under unusual conditions, configuration changes that exceed the agent's stated authorization, resource provisioning that does not match the human owner's verified workload. Stripe Radar handles both, but the model has to learn the second pattern separately from the first.
The Infrastructure-Buying Surface Has Different Audit Questions
Vendors who want to be agent-buyable through Projects face a different audit than retailers being audited for ACP or UCP readiness.
The first audit question is whether the account-creation surface accepts programmatic onboarding. Most cloud and SaaS vendors built their signup flows for human users entering email addresses and verifying them, then walking through an onboarding wizard. Agents working under user authorization need a structured signup endpoint that accepts the owner's verified identity, the agent's identity, and the authorization scope as a single request. Vendors whose only signup path is a marketing-page form with email verification are not agent-buyable today, regardless of what their pricing page says.
The second is whether the plan or product catalog is exposed in a structure an agent can read. Pricing pages designed for human consumption typically render plans in feature-comparison tables with marketing copy interleaved. Agents reading those pages have to parse the table semantically, infer feature equivalences across plans, and guess at the resource limits implied by the marketing copy. A vendor that exposes a clean, structured catalog through Projects, or through a parallel agent-readable endpoint, removes the inference problem. The vendor that does not is the one the agent skips or misconfigures.
The third is whether the subscription and billing surface handles agent-initiated upgrades, downgrades, and cancellations without requiring a human to log into a dashboard. Most SaaS billing flows assume the human owner is the one making changes. Projects authorizes the agent to make changes on the human's behalf. Vendors whose billing flow requires session-level authentication from the human user, with no path for an authenticated agent acting under user delegation, cannot handle Projects subscription management even if they can handle Projects account creation.
The fourth, more subtle, is whether the vendor's customer-facing documentation is in shape for agent consumption. An agent buying infrastructure for a human owner often needs to read product documentation to make the buy-vs-configure decision: which plan covers the workload, which feature requires the higher tier, which configuration step needs to happen before deployment can succeed. Documentation written for human developers, with implicit assumptions about prior knowledge, is harder for agents to use than documentation written with clean canonical answers per question. The retail-commerce audit does not include a documentation-readability axis. The infrastructure-buying audit does.
Each of the four is an independent audit. Most vendors today have zero of the four in shape for agent access. A few have one or two. The vendors that audit all four and fix the gaps are the vendors who will be reachable by Projects-driven agents over the next twelve months.
What Stripe Projects Means If Your Website Sells Subscriptions Or Services
Three categories of vendor should be reading the April 30 launch as a forward-looking signal rather than as an event that does not affect them.
The first is SaaS vendors selling subscription products. Project-management tools, design platforms, marketing software, developer tools, analytics services. If a user can set up an agent to manage their subscriptions and the user is willing to delegate that work, Projects is the protocol the agent will reach for. SaaS vendors who do not show up in the Projects-readable catalog will lose those workflows to vendors who do. The choice is to be agent-readable through Projects or to be invisible to that flow entirely.
The second is hosting, DNS, and cloud-infrastructure vendors outside the launch cohort. The categories Cloudflare, Vercel, and Netlify already cover are now agent-buyable. The categories adjacent to them, including specialty hosting, security platforms, content delivery, observability, and database-as-a-service, are next. Vendors in those adjacent categories who watch the launch cohort succeed and do not move are placing a bet that their customers will keep doing the configuration work themselves. That bet is plausible today and will be less plausible each quarter through the rest of 2026.
The third, more interesting, is professional-services vendors selling structured engagement work. Anything that gets sold as a defined scope at a defined price, including agency engagements, freelance contracts, structured consulting, and packaged service offerings. The protocol does not currently address these categories, but the gap will be the next surface someone builds for. A user with an authorized agent who can buy infrastructure can plausibly authorize the same agent to buy structured services from a known provider. The vendors who think now about how to expose their service catalog in an agent-readable structure will be in a position to ship support when the protocol layer arrives.
The shorter version of all three: infrastructure-buying is the second commerce category of the agentic web, the audit is different from retail, and the vendors who run that audit early will be the ones agents can find when the user delegates the work.
Related reading on No Hacks: Selling to AI: The Complete Guide to Agentic Commerce, Sixty Organizations Joined Google's AP2 Donation to FIDO, and All You Need to Know About Cloudflare's Agent Readiness Score.