Live data from Hacker News

We tried to make billing backendless

useautumn.com

21–30 of 43 posts

Re: We tried to make billing backendless

#21
If you don't have a backend, how do you make sure I'm billed?

What's stopping me from opening the console and calling the "addMoreCredits" function? Why can't I just edit the code to remove any mention of consuming credits?

I think you're about to discover why most multiplayer games have moved authoritative simulation to the server.

Re: We tried to make billing backendless

#22

I find everything about web technology nowadays to be extremely obtuse. I am mostly an embedded/Linux driver engineer, but I think I know the basics of HTTP, REST APIs, Docker containers, how the web works overall etc. But, like. What are we doing? What do you mean make the billing backendless? Obviously there has to be a backend to process the payment. What are you even saying? You are presumably not building a dist…

I believe the marketing material around serverles functions is at fault. Clearly there is a server, because there is a computer answering requests on a specific ip address mapped to dns. So the wording is maddening. It’s a bit like cgi-bin except it spins up a vm or other sandbox to run the serving code instead of just starting a process.

Re: We tried to make billing backendless

#23
post #4

You should look deeper into JWTs and what you can do with them. Sounds like you are on the way to reinventing them.

Yes! This is exactly what we're doing now which also helps us be a little more framework agnostic. Nextjs kind of just lets us have them built-in

JWT is a standard that is supported by a lot of frameworks and auth libraries. It’s also reasonably straightforward to implement yourself. It’s very easy to make big security mistakes when you roll your own security, though, so it’s best to at least stick with proven paradigms even if you implement it yourself for a new framework. Also read up on the mistakes people have made in implementing it and avoid repeating those mistakes.

Re: We tried to make billing backendless

#24
post #9

> Server actions are public, unauthenticated routes Why can't they be authenticated? That seems like the obvious fix. Otherwise how you are handing out the correct customer_id unless you authenticate somehow? This scheme also complicates API key rotation, although you can work around it by trying to decrypt with both the old and new key if you use e.g. authenticated encryption. This also has no mechanism for expirati…

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 regist…

The current mechanism has security flaws that are hiding because of SSR. Try to implement the same flow in pure-vanilla-js and you'll realize that you're hitting replay attacks instantly. This is the same vulnerability that companies which try to "hash the password on the client side to protect it" face - they've merely transformed the password to a different one (the hashed one) which has the exact same semantics as the original password for an attacker.

Your encrypted customer ID has the exact same semantics as the original customer ID for an attacker, and is insecure.

Re: We tried to make billing backendless

#25

If you don't have a backend, how do you make sure I'm billed? What's stopping me from opening the console and calling the "addMoreCredits" function? Why can't I just edit the code to remove any mention of consuming credits? I think you're about to discover why most multiplayer games have moved authoritative simulation to the server.

it was more of a figure of speech where the entire implementation for the user would be on the frontend (React). Sensitive operations are being called securely on the backend, just through Next.js server functions!

Re: We tried to make billing backendless

#26
post #3

I'm rather confused by this article - I've made products and pricing services, and just on the first line its said that billing requires webhooks and state syncing.. but why? Is it a way to utilize payments in an otherwise static site? Whats the benefit? You can absolutely accept payments without webhooks. Please help, I really don't understand the niche! I'm left with the sense that this is a sort of solution that's…

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…

I've made solutions before that a product can have many permissions, a product can have many prices, and a product can also be a bundle of products. The products service does the heavy lifting by having systems to determine things like addons (If have Product1 that gives Permission1, you can purchase Product43 as an Addon to give Permission2).

This will not give you clean easy to understand reporting if you make bundles willy-nilly (N product line makes $ dollars, if bundled products exist), but to me, it gives accurate data that matches up with the pricing complexity that the business is designing.

Re: We tried to make billing backendless

#29
post #3

I'm rather confused by this article - I've made products and pricing services, and just on the first line its said that billing requires webhooks and state syncing.. but why? Is it a way to utilize payments in an otherwise static site? Whats the benefit? You can absolutely accept payments without webhooks. Please help, I really don't understand the niche! I'm left with the sense that this is a sort of solution that's…

I work in the billing space at Lago, so I think I can add a bit of color (though I'm also somewhat confused).

Technically speaking, billing and payments are two separate things.

For example: OpenAI needs to calculate how much you need to pay for the tokens you consumed across all of its models. That usage aggregation, calculation and then issuing of an invoice is billing—payments is only the transfer of money.

Re: We tried to make billing backendless

#30

I find everything about web technology nowadays to be extremely obtuse. I am mostly an embedded/Linux driver engineer, but I think I know the basics of HTTP, REST APIs, Docker containers, how the web works overall etc. But, like. What are we doing? What do you mean make the billing backendless? Obviously there has to be a backend to process the payment. What are you even saying? You are presumably not building a dist…

I believe the marketing material around serverles functions is at fault. Clearly there is a server, because there is a computer answering requests on a specific ip address mapped to dns. So the wording is maddening. It’s a bit like cgi-bin except it spins up a vm or other sandbox to run the serving code instead of just starting a process.

Functions-as-a-service was a better descriptor.

This is just billing as a service.

Post reply on HN