At localhost, Rami Banna, Stripe's product lead for Ecosystems, Apps, and Stripe Projects, walked through Stripe Projects, a tool aimed at the very start of building something: before a product has users, before it's charging anyone, when a developer is still wiring up accounts and services for a new stack.
The pain point behind it has nothing to do with writing code. Setting up a new project usually means bouncing between dashboards: creating accounts, standing up services, copying environment variables, entering payment details, pasting all of it into a local file, and repeating that for every provider a stack needs. Stripe traced that pain back to payments: most of the SaaS and developer tools people reach for on day one already bill through Stripe. That overlap is what Stripe Projects builds on, letting a developer create an account, provision a service, manage environment variables, and pay for upgrades from a single CLI.
The network behind it is roughly 50 providers so far and growing, meant to work as an open ecosystem anyone can join.
Account, service, resource
The protocol behind Stripe Projects runs on three objects: an account (a developer's tenant with a given provider, an org or a team), a service (what that provider offers, its catalog of plans and prices), and a resource (the specific instance that gets created and hands back credentials).
Those three objects support a full lifecycle: create or connect a provider account, even without one already existing, using Stripe's own auth to spin up a new one; pull the live service catalog; provision a resource; return its credentials; rotate those credentials later; and remove the resource when it's no longer needed.
Each provider implements this by building a small set of endpoints around the same three objects: one for the initial account request, handled without any browser interaction; one for the services request, polled every ten minutes to keep prices and plans current; and one for the resource itself, covering the rest of that lifecycle. The service schema underneath is flexible enough to model usage-based pricing, flat plans, hybrid billing, or upfront credits, since providers differ widely in how they charge.
The protocol itself wasn't published at the time of the talk. The plan is to open it up later in the summer, with an eye toward it becoming a shared standard.
Payment needed its own permission model
Provisioning a resource still leaves the question of who pays for it, and the answer is a shared payment token. A developer enters a payment method once, through a Stripe checkout, and Stripe tokenizes that credential separately for each provider. Every provider bills against its own token the way it normally would, and the developer can set a spending limit for each one individually against that shared method.
The result is a single place to enter and view payment details across every connected provider, instead of a separate one for each, plus a natural point to cap what gets spent anywhere an agent is doing the spending. That layer sits above whatever the underlying payment method is; support currently covers bank transfers and buy-now-pay-later. A separate push API lets providers report changes back to Stripe directly, so an update made on a provider's own dashboard still shows up on the Stripe side.
Orchestration, not ownership
This is not a platform as much as an orchestration layer. It's an infrastructure layer that allows you to own your provider accounts.
The account created through Stripe Projects belongs to the developer, not to Stripe. When using Render infrastructure via Stripe, Render remains the actual service provider and the billing relationship; the credentials and environment variables stay inside the developer's own project. Stripe Projects coordinates the provisioning itself without sitting between the developer and the provider afterward.
Provisioning from the command line
Pulling up the Stripe Projects catalog from the CLI surfaces what Render offers on the network: Postgres, a web service, or a static site. Typing stripe projects add render brings that catalog up directly, and from there, the same commands can be handed to a coding agent like Claude, which connects a public GitHub repository and deploys it through Render straight from the command line. The same pattern extends to adding other providers, OpenRouter, Exa, Clerk, and PostHog among them, by asking the agent for what's needed in plain language; it uses the same underlying commands to fold everything into one project with one set of environment variables.
