[jacobheric]

Wow, the amount of reactionary doomsaying in this thread is offputting. I built the Stripe Projects agentic provisioning integration (what this post is about) at Inngest and when I saw it actually work in action I thought it was actually kind of magical. Basically, hey agent, use my stripe account to provision a pro plan at Inngest, build me an app and deploy it. The agent does it and logs me into the Inngest dashboard. Agentic provisioning seems inevitable given the way we work now, and deferring to Stripe for kyc seems a reasonable way to do it.

[tiffanyh]

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.

[jacobheric]

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.

[aleqs]

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.

[jacobheric]

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.

[tiffanyh]

Super helpful. If you don't mind me asking, why are CLI so popular for agent use - as opposed to just raw APIs?

Sorry if this is a naive question.

[jacobheric]

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.

[xena]

AI models have better tool latching on a `bash` tool than they do MCP tools.

[tiffanyh]

Would you mind explaining more. Sorry, I'm not following but find your comment super interesting.

[aleqs]

What KYC does Stripe Projects do other than email verification?