As someone not well versed in these topics, would you mind helping me understand how this is different than an MCP for your onboarding & account provisioning APIs.
It's provisioning expressed as an API, but wrapped in a cli that agents can very easily use. Then anyone that implements the API is added to a marketplace of services. And the ability to pay for service is baked in because it's stripe. The end result is that as an engineer I can ask an agent to use the stripe cli to discover and provision, including paying for, a wide variety of services and it mostly just works.
Is it expressed as an API though? Does Stripe Projects have a documented public API? Also isn't the payments for this involve manually entering payment/card info (meaning it could theoretically be done a dozen different ways which do not require Stripe)?
In theory, this is a cool idea, but in practice I think this being done through a proprietary, locked-in Stripe product, is going to ultimately hinder adoption.
The security implications here are also concerning - from what I can tell - Stripe seems to have access to all of the keys/credentials for third party accounts/resources provisioned via Stripe Projects.
So stripe has centralized control over payments, KYC, credentials/keys (full lifecycle, not just storage), the provider marketplace, and even over the availability/reliability of anything built with on top of Stripe Projects (since now your credential/key lifecycle has Stripe on the hot path).
This is like a more janky/less reliable loveable, without the handrails, and with a mere illusion of less lock-in.
Imo, this kind of thing will only work long-term as an open protocol without Stripe lock-in, and I know certain people/companies are already working in this direction.
I asked them and they said the plan is to make the spec public. I'll leave it up to them to say when that will happen. I'll say the spec is pretty flexible/configurable. You can swap our payment providers, it does not have to be stripe. And you can configure who does kyc and you can do that yourself.
I'm no expert. But I think it's the same thing that makes it easier to use for humans. So, `stripe projects --help` and then `stripe projects catalog` is super easy for me to grok and use versus reading some api docs and curling some endpoints.