Comment by ivanmontillam | Hacker News Reader

Comment by ivanmontillam | Hacker News Reader

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.

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?

> 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.

> 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.

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.

Ok. Hold my beer.

What time zone is the billing performed in? And what time zone is the user in? Is the user part of a group billing scheme that is billed in a different time zone? Or do you bill everyone in the same time zone regardless of where they sign up? You need to know this in order to compute both "n" and "m".

Do you need to break the billing into separate line items, for example, a service component and an entitlement component? What about addons or powerups? Are they all prorated? are you sure?

What about fixed up-front charges? Surely these are not prorated?

Do you charge in arrears or in advance? If you charge in advance, how many days/months in advance? If in arrears, when do you actually raise the charge? You need to know this to compute "m" and "n". How do you remember to pro-rate it? Bonus question: what's the process you use to ensure that arrears charges are always raised? Not a cron job, surely?

Is your billing cycle even monthly? Could it be quarterly? Weekly? Annual?

Do you need to prorate entitlements? What about quantity entitlements like download volume? What about fixed entitlements like per seat licenses?

Do you prorate to the millisecond, or the day? Is there a minimum proration period?

Are there any accounting rules related to proration in the accounting regime of the user being billed?

If you provide a signup bonus or coupon that exceeds the value of the prorated first billing period, how do you apply it to the account?

Ok. That covers the stuff I can think of off the top of my head. There are probably just as many questions that I’ve forgotten.

Ultimately, the problem is not determining how to prorate, since that's a simple ratio. The problem is to work out what "m" and "n" even means, and to compute their values in a way that works within the policies of the business you're billing for. And even a simple business will change requirements over enough time.

Then, of course, there’s dealing with things like refunds and cancellations. Which, in my experience, everyone gets wrong and pushes off to manual processes. And then there's the other 12 things in TFA, each of which has at least as many twists and turns.

(edited to focus only on proration.)

+1 for the details, and it gets even worse when we have to bring these kinds of billing complexity into our product designs! Especially when we need to take care of budgeting... which has all of its own complexity as well.

Thanks, yes I have to say I get a bit frustrated with the frequent cycle of “ proration is not easy”, followed up by someone posting “proration is a simple division”! And then repeat for all the other complexities.

I built out billing in grocery, supply chain, oil & gas, tabs and subscriptions and without a doubt, they all have annoying complications that a person without experience would probably not consider.

I wouldn’t call billing “difficult” as much as it is “annoying”, but I also have ~18 years experience in it.

I think it’s difficult because it’s like an iceberg, there is so much more to it than what’s obvious.

I build billing systems in telco for 20+ years, so I don’t think it’s difficult any more either, but with that experience, I’d certainly do it very differently to how most people would approach it.

Yeah. Maybe what I’m calling “annoying” is what makes it “difficult”.

The features and ideas billing usually needs aren’t “difficult” to write, but if you have someone inexperienced designing the system, your project is inevitably going to run face first in to these “annoyances” and this may present as somewhere between difficult and impossible where if you had an experienced person at the helm from the get go, you won’t be running in to the same issues.

Yeah. I guess the iceburg will present as difficulty in some ways.

Yeah, I don't disagree. There are a small number of "actually difficult" problems but the vast majority are run-of-the-mill.

For example when presenting an invoice, you end up needing to be able to access just about any part of the system. In telco you need the invoice, line items, past payments, CDRs, entitlement, pre-paid, ...

Without a global data model this becomes really complicated. It's not hard (we settled on GraphQL), but it ends up being big. And it needs to be pretty fast, too.

I have worked in billing for 20 years. Each country has its own laws & quirks. Things like having to issue corrective invoices instead of refunds/adjustments in some countries. Others require document numbering to be sequential in different ways (by customer, period etc). Rounding is another fun thing - want that done at an invoice level, line level? Up or down? Taxes are not fun, especially geocoded US taxes. You've got a leased line with rented equipment at both ends - Which of these is the service address for tax purposes? Both with different rates? Something else?

I could go on.

Just when you think you've learned it all, another crazy requirement pops up.

You're correct when you say people underestimate the complexity.

Yes exactly. The thing I learned is that it all has to work independently, then you glue it together with policies. Even the simplest hard coded decision is going to be wrong in some context.

Even with such an approach, you’ll still miss something, but at least policy mechanisms provide a pattern for refactoring and new features.

I ended up building what we might call a declarative billing platform. You tell it what you want, and it tries to make it happen. Very successful, technically, but sadly I left the industry before it got into serious production.

If you're able to open source it, I'd encourage you to do so. After all, old projects might have an after life in the open.

Billing systems are complex... but so are most other SaaS systems. If you take any other SaaS product, it generally seems simple, "i could build it in a weekend". But having worked at these "simple" SaaS products, there is always a long tail of edge cases that you need to deal with that get deeper and deeper into complexity. That is what these articles about billing systems usually dive into. I agree they exist, but you see this on any system or platform when you start building it for many customers/users.

I say this because building your own Billing System isn't any harder than any other platform problem. The difference is that most companies aren't in the business of building a billing system. They could hire engineers to focus on it, and they could build it just fine (it's not THAT difficult). It would just cost a lot of money and all they would do is recreate something similar to Stripe, Chargebee, and the other billing platforms out there, which have already solved these problems for you. These platforms charge you a relatively low fee (lower than the cost of a team of skilled engineers and PMs) to use it, so it doesn't make sense.

It's not that the problem is debilitatingly difficult. There is just not enough value in building it when off-the-shelf solutions exist. There are some businesses that might benefit from a custom billing solution because they are too unique to use an off-the-shelf solution. These companies do build their own billing systems and do just fine, but maintain a large team of developers dedicated to the billing product. Examples of this might include AWS with their billing, AT&T or Verizon with their billing, and so on. For most companies though, it would cost far more to build and maintain your own billing system, than it might generate in revenue. Especially relative to just paying a 3% finance fee and getting it "for free" with a provider like Stripe or paying a low fee for a wrapper like Chargebee (which charges only $500 for $100,000k in MRR).

So if you generate $100k MRR, would you rather go through the headache of building a billing system and spend $50k a month in a small team of engineers to maintain it, or would you rather just pay $500 for essentially the same thing with no headache? THe choice seems simple to me.

So it's not that Billing Systems are hard... they just don't make sense to build. Any competent engineering team could solve the problems from a billing system, it just isn't worth it.

Reply on news.ycombinator.com