3 ms·

I'd argue that the pains of building a billing system are not the right approach to the topic. If building your own billing system is a path so much sought afte

I'd argue that the pains of building a billing system are not the right approach to the topic. If building your own billing system is a path so much sought after, well, let that be. Billing systems are of high complexity; I recognise that. However, if Chargebee, Solvimon, Stripe, Recurly, Orb, Metronome, Lago, Togai or anyone else has that body of knowledge, we could instead collect that knowledge in one place. Indeed, there's no better approach than the one that serves you. If you're a subscription-based SaaS, you have specific solutions for your business. If you're a usage-based API, you have specific solutions to the billing. But we could have all that knowledge, approaches, paradigms, programming patterns, better and best practices in one place, instead of discouraging the practice. There are also edge cases where a company is not U.S.-based or European, and a billing solution like Stripe wouldn't work, e.g. your company is based in Venezuela, and you can't have a Stripe account. What do you do in that case? You must forcefully build your own billing solution and connect it to the local payment gateways with their arcane SOAP-XML APIs. -- On a separate note, "building your own billing system" reminds me of the topic of "rolling your own SIEM" with the typical Elastic + Grafana setup. I don't recommend it, but I understand why it's such a hot path for an IT Security department to do it.

gopher_space 3y ago
The article considers billing systems in an interesting way. There are topics presented as problems that I'd hand off to accountants or other specialists we're probably already employing. > Billing systems are of high complexity; I recognise that. [...] They're less complex than whatever your developers are working on. The article tries to paint hard legal requirements as a difficulty, but in practice this means the specs are easy to find and well documented. Parts of the process do change frequently, but those parts are well labeled and well explained. > Indeed, there's no better approach than the one that serves you. If you're a subscription-based SaaS, you have specific solutions for your business. If you're a usage-based API, you have specific solutions to the billing. I mean, will your customers allow you to shift the burden of responsibility? Is your income important enough to verify? Can you afford the haircut?
- doctor_eval 3y ago
  > There are topics presented as problems that I'd hand off to accountants or other specialists we're probably already employing. But aren’t we supposed to be automating this stuff? What software do you think the accountants use? You go to the accountants to ask the questions, but if you’re billing at scale you can’t just push the problem aside. The accountants already have jobs to do and billing is not one of them. > They're less complex than whatever your developers are working on I worked on billing systems for a long time. They are definitely more complex than whatever your developers are probably working on. It’s all in the article. Just take proration. The user joins half way through the month and you have a monthly billing cycle. How much do they get charged? If you think this is an easy question, you don’t understand billing. > The article tries to paint hard legal requirements as a difficulty, but in practice this means the specs are easy to find and well documented. That’s the funniest thing I’ve read here in a while! The legislation is not even kept in one place. It’s often opaque. You need an accountant to explain it to you. It gets worse when you’re working with public companies. I’m sorry but your replies are the typical “billing is not that hard” of an inexperienced engineer, posted to an excellent article explaining exactly why billing is hard.
  - meekaaku 3y ago
    > Just take proration. The user joins half way through the month and you have a monthly billing cycle. How much do they get charged? If n days of m day month is used, the charge will be n/m * monthly_rate, no? And it would be just another line item in the monthly invoice.
    - arnon 3y ago
      1. You assume monthly_rate exists. It's usually not defined that way... 2. Imagine some things are billed on a recurring basis (e.g., every 30 days), and some are every 1st of the month... 3. Assume, for example, that you charge per-user. What if there are 300 users added and 20 removed in one day. Do you refund the remaining time in the month? Is this a credit on their next invoice, a negative item on the current invoice, etc... There are many more situations that can mess this up even further.

gopher_space 3y ago

The article considers billing systems in an interesting way. There are topics presented as problems that I'd hand off to accountants or other specialists we're probably already employing. > Billing systems are of high complexity; I recognise that. [...] They're less complex than whatever your developers are working on. The article tries to paint hard legal requirements as a difficulty, but in practice this means the specs are easy to find and well documented. Parts of the process do change frequently, but those parts are well labeled and well explained. > Indeed, there's no better approach than the one that serves you. If you're a subscription-based SaaS, you have specific solutions for your business. If you're a usage-based API, you have specific solutions to the billing. I mean, will your customers allow you to shift the burden of responsibility? Is your income important enough to verify? Can you afford the haircut?

doctor_eval 3y ago
> There are topics presented as problems that I'd hand off to accountants or other specialists we're probably already employing. But aren’t we supposed to be automating this stuff? What software do you think the accountants use? You go to the accountants to ask the questions, but if you’re billing at scale you can’t just push the problem aside. The accountants already have jobs to do and billing is not one of them. > They're less complex than whatever your developers are working on I worked on billing systems for a long time. They are definitely more complex than whatever your developers are probably working on. It’s all in the article. Just take proration. The user joins half way through the month and you have a monthly billing cycle. How much do they get charged? If you think this is an easy question, you don’t understand billing. > The article tries to paint hard legal requirements as a difficulty, but in practice this means the specs are easy to find and well documented. That’s the funniest thing I’ve read here in a while! The legislation is not even kept in one place. It’s often opaque. You need an accountant to explain it to you. It gets worse when you’re working with public companies. I’m sorry but your replies are the typical “billing is not that hard” of an inexperienced engineer, posted to an excellent article explaining exactly why billing is hard.
- meekaaku 3y ago
  > Just take proration. The user joins half way through the month and you have a monthly billing cycle. How much do they get charged? If n days of m day month is used, the charge will be n/m * monthly_rate, no? And it would be just another line item in the monthly invoice.
  - arnon 3y ago
    1. You assume monthly_rate exists. It's usually not defined that way... 2. Imagine some things are billed on a recurring basis (e.g., every 30 days), and some are every 1st of the month... 3. Assume, for example, that you charge per-user. What if there are 300 users added and 20 removed in one day. Do you refund the remaining time in the month? Is this a credit on their next invoice, a negative item on the current invoice, etc... There are many more situations that can mess this up even further.