Ask HN: Why every company writes their own billing solution?

There are a lot of solutions out there that tackle billing but they may not necessarily be open source. Examples being chargify [0], recurly [1] etc.

A couple of open source solutions that I found are killbill[2], laravel spark [3], bullettrain [4], opensourcebilling [5]. Again, they may not necessarily be 100% free but they are open source.

Also, billing is a very subjective term. Do you mean subscription billing or just plain old invoice type solutions or a combination ? There are tons of invoicing tools like invoiceninja [6] and plenty others.

[0] https://chargify.com

[1] https://recurly.com

[2] https://killbill.io

[3] https://spark.laravel.com (billing plus SAAS)

[4] https://bullettrain.co (billing plus SAAS)

[5] https://opensourcebilling.org

[6] https://invoiceninja.com

If you don't write your own billing system, either:

>Option one:

The group managing your billing system is going to take a cut of your revenue, and if you're really big, that's unacceptable.

One example: Stripe takes about 3% [1]. If you're a major commerce company like Ebay which made roughly 10 billion dollars [1] last year and you used stripe (and lets say you did no negotiation and just used their defaults, unlikely but possible) that's 300 million dollars plus change you're leaving on the table by outsourcing. This means if you're in a position like that and it costs you less than 300 million dollars to build and maintain your billing system (and keep in mind 300 million buys you a team of 2,000 engineers and managers all working at fully loaded costs of 150k), then you're not going to outsource.

>Option two:

You're going to use an open source solution. Risk aversion is the critical point here: If your billing fails, or gives out product for free, in many cases, you no longer have a business. You cannot afford to get billing wrong, and so, in an environment where no "It just werks" open source solution exists, this isn't really a choice most management types can stomach.

[1]https://memberful.com/blog/stripe-vs-paypal/

[2]https://www.statista.com/statistics/507881/ebays-annual-net-...

Disclaimer: I work at Cheddar, a billing company.

I think it's crazy that everyone writes and maintains their own billing solutions too.

I think people build their own billing solution because for a long time, there wasn't one well-known tool out there that could handle all of the complexities of a software company's billing (dunning, customer emails, assembling invoices, usage tracking and metering, etc.).

And when a well-known company like Stripe comes along and offers billing, people are hesitant and have a little sticker shock because at scale, they charge a lot of money for billing. Stripe Billing costs 0.4% of revenue (after $1m in lifetime revenue) and then 0.7% at scale on top of their payment processor which already costs 2.9% + 30% per transaction[1]. And while that rate is pretty standard, if you have high and growing revenue, you can often negotiate a lower payment processor rate with other payment processors, but Stripe locks you in to using them.

So, instead, developers choose to build billing systems themselves using tools out there (Stripe for payments, X for dunning, Y for customer communicating, etc.). However, that also creates a lot of complexities because if you need to change anything down the line or update how exactly you charge for your product, you'll probably have to go back to the codebase, meaning developers will have to dive into code they haven't touched in a while and rework things.

That's why we created Cheddar (https://getcheddar.com), a usage-based billing platform and API that lets software engineers finally decouple billing from the codebase, track usage data (that you're not even billing for), and flexibly apply and iterate pricing plans to that usage data.

[1] https://stripe.com/us/billing/pricing

(I work on Stripe Billing.) Broadly we think most people should buy rather than build here, because billing is infrastructure and doesn't create the unique value in your product that makes more customers willing to pay. Why is there relatively little OSS for it? Probably because it's difficult to do right, a bit crufty, and tough to motivate a volunteer workforce to wake up in the morning and crank through some tickets about German invoice formatting.

Here's the evolution that we see at a lot of companies as they grow: the table stakes version of billing ("just get something that lets us charge for our MVP!") is an N week project. Everyone gets it wrong, but right enough to not kill the business. Then it worms the way into the rest of their systems, because of a lack of clear design boundaries or a documented internal API to answer questions like "Should account X have access to feature Y?", and it becomes an ongoing maintenance task both for the billing system and all the code which touches it, which is everything.

Once your business gets big, billing isn't just annoying and taxing on your productivity: you have to start telling the business "No, you can't do that, because the billing system won't support it and we can't fix that in less than 6 months." There are products which are not available in Japan because billing systems hardcode currency formats. There are marketplaces that can't tolerate cross-border commerce because they can't accept a pay-in and pay-out with different currencies, as a purely technical limitation.

These are not good problems to have. We think startups should just adopt a billing system which was written by a team of people who breathe billing issues. We feel so strongly about this that we subsidize startups use of our billing product down to free, for their first million dollars in sales.

There, of course, exist other options. As someone who works on this every day: please adopt one of them. You will save yourself a lot of toilsome work which largely doesn't advance your business goals.