Creating accounts and managing billing across multiple platforms is a real pain. This is a good solution, but I’m wondering if this should be more like an open standard that platforms implement, with Stripe providing a way for platforms to charge and optionally for users to pay (in addition to credit cards, wallets like Tempo, etc)
Use cases: create accounts, set up billing, manage secrets, manage resources, get invoices/receipts
Finally, I don’t know if it’s better to use a CLI imperative approach or a more declarative one like IaC
That last part struck me as well. I don't want an imperative solution, but... I'm not sure if that's just me.
Declarative solutions are perfectly fast and capable as well. They can use all the same tooling under the hood. Why choose imperative? At least I can record, validate, and version control a declarative solution. And imperative process is nice for exploration and one-off needs, but... I don't know when I'd really need that or when that's a bottleneck for me.
And I get that this is probably more of a tool for agents than humans, despite that agents are only mentioned in passing. But that's even more concerning in a way. I'm not yet comfortable with giving them tools like this.
Hi there! Developer at Supabase here. I'm happy to finally see live what I've been working on for the last two months. I'm excited to see that Stripe users can finally use Supabase services in a seamless way. For new Supabase users, there is no need to leave the CLI. One command, and you'll have a brand new Supabase account, including a new Supabase resource provisioned just for you. This means that you'll be able to not only use a PG database from the get-go, but it also comes with Storage and Authentication for free. I'm really excited to finally see this project come to light. More to come!
As a developer tool, integrating Stripe Projects felt a lot like adding "Sign in with Google" - Stripe acts as a trusted identity and billing provider, but for agents instead of humans. The core insight is that agent commerce is a trust problem: an agent can't (shouldn't?) enter a credit card or verify an email, so you need a trusted third party to KYC both sides. Stripe already has that relationship with both developers and customers.
Sadly it doesn’t seem to do anything innovative to protect your api keys from getting exfiltrated by tricking the AI. Looks like they are stored in an ordinary config file:
Nice idea, but I'd love a more open approach to this (or more support for OpenTofu / Terraform). This is just another vendor-locked-in way and might only work with selected platforms.
Stripe has the incentive to add platforms that use Stripe as a payment processor so they can cash on the payment fees, they don't really have any incentive to add a platform that doesn't bring money to them (except affiliates are possible with this)
Yeah, strikes me as unnecessarily braggy and wasteful; "Look, here's how much we can spend on vanity domains to showcase projects that probably we'll lose interest in within 2-3 years".
> Maybe time for their own .stripe TLD or something
How about subdomains? Free and widely supported already, won't confuse anyone either.
Creating accounts and managing billing across multiple platforms is a real pain. This is a good solution, but I’m wondering if this should be more like an open standard that platforms implement, with Stripe providing a way for platforms to charge and optionally for users to pay (in addition to credit cards, wallets like Tempo, etc)
Use cases: create accounts, set up billing, manage secrets, manage resources, get invoices/receipts
Finally, I don’t know if it’s better to use a CLI imperative approach or a more declarative one like IaC
That last part struck me as well. I don't want an imperative solution, but... I'm not sure if that's just me.
Declarative solutions are perfectly fast and capable as well. They can use all the same tooling under the hood. Why choose imperative? At least I can record, validate, and version control a declarative solution. And imperative process is nice for exploration and one-off needs, but... I don't know when I'd really need that or when that's a bottleneck for me.
And I get that this is probably more of a tool for agents than humans, despite that agents are only mentioned in passing. But that's even more concerning in a way. I'm not yet comfortable with giving them tools like this.
Hi there! Developer at Supabase here. I'm happy to finally see live what I've been working on for the last two months. I'm excited to see that Stripe users can finally use Supabase services in a seamless way. For new Supabase users, there is no need to leave the CLI. One command, and you'll have a brand new Supabase account, including a new Supabase resource provisioned just for you. This means that you'll be able to not only use a PG database from the get-go, but it also comes with Storage and Authentication for free. I'm really excited to finally see this project come to light. More to come!
I built Chroma's integration for Stripe Projects.
As a developer tool, integrating Stripe Projects felt a lot like adding "Sign in with Google" - Stripe acts as a trusted identity and billing provider, but for agents instead of humans. The core insight is that agent commerce is a trust problem: an agent can't (shouldn't?) enter a credit card or verify an email, so you need a trusted third party to KYC both sides. Stripe already has that relationship with both developers and customers.
It's a smooth experience overall - try it out.
I wrote more about agent experience here: https://www.philipithomas.com/agent-experience
Sadly it doesn’t seem to do anything innovative to protect your api keys from getting exfiltrated by tricking the AI. Looks like they are stored in an ordinary config file:
https://docs.stripe.com/stripe-cli/keys
Nice idea, but I'd love a more open approach to this (or more support for OpenTofu / Terraform). This is just another vendor-locked-in way and might only work with selected platforms.
Stripe has the incentive to add platforms that use Stripe as a payment processor so they can cash on the payment fees, they don't really have any incentive to add a platform that doesn't bring money to them (except affiliates are possible with this)
Aside: did they really need to use that generic projects.dev domain? Maybe time for their own .stripe TLD or something
Yeah, strikes me as unnecessarily braggy and wasteful; "Look, here's how much we can spend on vanity domains to showcase projects that probably we'll lose interest in within 2-3 years".
> Maybe time for their own .stripe TLD or something
How about subdomains? Free and widely supported already, won't confuse anyone either.
Yeah, I hate this trend. AWS did it too with CDK: https://constructs.dev/