Stripe Enables AI Agents to Buy Cloud Services

On April 30, 2026, Stripe launched Projects, a commerce protocol designed to let AI agents handle the entire lifecycle of buying and managing cloud services on behalf of their human owners. This means agents can now create accounts, purchase domains, upgrade plans, and deploy infrastructure directly. The initial launch partners include Cloudflare, Vercel, and Netlify. Projects operates alongside Stripe’s existing Agentic Commerce Protocol (ACP) , which handles retail transactions. Together, these two protocols draw a clear line: ACP manages buying things, while Projects manages buying capabilities.

This structural split is significant. The first wave of agentic commerce, from September 2025 through early 2026, was retail-focused. Agents browsed catalogs, added items to carts, and completed checkouts at retailers like Etsy, Walmart, and Glossier. The mental model mirrored a human shopper. Stripe Projects breaks that mold. Here, the buyer remains an agent acting under user authorization, but the merchant is a cloud platform, the catalog consists of plans and resources rather than physical products, and the transaction completes by provisioning capability, not by shipping a box. Infrastructure buying emerges as the second commerce category of the agentic web, and the audit questions for vendors in this space differ fundamentally from those for retailers.

What Stripe Projects Actually Does

Stripe Projects offers four primary flows for AI agents acting under user authorization.

First, 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 receives a structured signup request containing the owner’s identity, the agent’s identity, and the authorization scope.

Second, plan and product purchase. An agent can read the vendor’s catalog of plans, resources, or domains, select the option matching the owner’s stated requirement, and complete the purchase. The flow uses Shared Payment Tokens for the transaction, the same primitive ACP uses for retail. The token is scoped to the vendor, the amount, and the time window.

Third, provisioning and configuration. After purchase, the agent can configure the resources for the owner. Cloudflare’s launch description illustrates this: 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, not just a paid invoice.

Fourth, 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.

These four flows cover the entire 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 partners operate at the developer-platform layer of cloud infrastructure: edge compute, deployment platforms, and content delivery. None are general-purpose cloud providers like AWS, Azure, or GCP. This choice appears deliberate.

Cloudflare’s launch description covered the full lifecycle. Agents create Cloudflare accounts, register domains, attach them to the account, deploy Workers, and configure DNS records. The transaction is one piece of the flow; 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. Vendors with API-first surfaces can ship Projects support fastest. Those who only expose human-facing dashboards face a more substantial build.

The category Stripe is signaling first is developer-adjacent cloud infrastructure. The next ring out, plausibly, includes SaaS subscriptions for non-developer audiences: project-management tools, marketing platforms, design software, anything selling 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 agent-on-behalf-of-user transactions. Both go through Stripe Radar for fraud detection. This shared plumbing is meaningful and likely why both protocols can coexist cleanly under the same vendor.

The differences lie 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 handle the Complete Checkout endpoint. The agent’s job is to read, select, and confirm. Most 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 differ from retail: an agent buying a Vercel Pro plan is not optimizing for size, color, and customer reviews; it matches the plan’s resource limits against the owner’s stated workload. The agent’s reading task is closer to a product spec sheet than a product listing page. Merchants supporting Projects need to expose those specs in a structure agents can read, not only on a human-facing pricing page.

The authorization shape differs, too. ACP authorizes a one-time purchase, whereas 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 must keep up.

The fraud-detection picture also differs. 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 exceeding the agent’s stated authorization, resource provisioning that does not match the human owner’s verified workload. Stripe Radar handles both, but the model must learn the second pattern separately from the first.

The Infrastructure-Buying Surface Has Different Audit Questions

Vendors wanting 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, 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 their pricing page.

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 must parse the table semantically, infer feature equivalences across plans, and guess at resource limits implied by the marketing copy. A vendor that exposes a clean, structured catalog through Projects or 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 makes 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 must 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 ones 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 read the April 30 launch as a forward-looking signal rather than 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 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. Adjacent categories, 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 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. 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.