We tried to make billing backendless

I find this "backendless billing" approach fascinating because it highlights the tension between DX and security. As someone who's built payment systems, I understand the appeal of reducing backend boilerplate, but there's always a security tax to pay.

The real issue seems to be that they're trying to make billing "feel frontendish" when it's inherently a backend concern. The encryption approach in Part 3 is essentially recreating auth tokens but with extra steps, as others have noted - they're basically reinventing JWTs.

What struck me most was the security vulnerability they discovered with server actions. If you can make calls with any customer_id without verification, that's a textbook IDOR vulnerability. A simple curl request with a different customer_id would let you upgrade/downgrade other accounts! No amount of client-side magic can fix fundamentally flawed authorization.

Their conclusion is telling, sometimes the "boring" approach (proper backend routes with auth) exists for good reasons. I appreciate their transparency about the journey though, we learn more from these explorations than from pretending everything works perfectly from day one.

Yes you're right -- payments can definitely be done without webhooks, but it is typically all controlled server-side. Especially things like upgrade and downgrade flows, as they involve automatically charging a user's card.

What we were exploring is whether there's a way to do this securely from the frontend (eg on a pricing page) without needing to open up backend routes.

You're also correct that our niche is trying to control feature permissions, so that we can decouple pricing logic from an application (which makes it easier to handle pricing changes, custom plans etc). We are moving more towards a solution that just uses the JWTs to handle this instead of a customer_id.

Give yourself some credit here, I'm a web developer who works on billing systems and I also have no idea what it is that they mean. My best guess is that they're making a marketing message that they do not have a very particularly annoying workflow of a very particular billing integration (Stripe webhooks maybe?).

My problem is when you know that workflow, and that integration... you actually don't need it, its just nice to have. Its just a way for Stripe to send you updates to an endpoint with the status, like if say a card has declined as the charge is closing. But you can just poll.

Maybe we didn't phrase it as well as we should've. We meant to say API routes in general are public, and so the server actions could be called by anyone.

Authentication is definitely possible, but we were trying to brainstorm a way where users could have protected routes with as little set up as possible, the ideal being they just pass in customerId into a Provider component

We also did think about things like registering an auth function but felt that being able to just pass in customerId would be a magical experience!

Definitely acknowledge that the current mechanism has flaws though -- it's really more of an experiment at the moment, and if it does indeed become very popular with users we would implement auth mechanisms like JWT and what not -- though that would kinda be reinventing the wheel

The title is lying then, hope the mods change it because I only clicked thinking it would be about something backendless and then it talks about one of the crappiest server frameworks available.