Live data from Hacker News

Billing systems are a nightmare for engineers

getlago.com

211–220 of 372 posts

Re: Billing systems are a nightmare for engineers

#211
post #62

Absolutely agree with the poster. This is my life at the moment. Just to take money for a small piece of software I built. Multiple currencies, trial periods, when in the process do you ask for the creditcard, country specific taxes,... And the worst: invoices. While paddle.com takes care of many of those things - I was shocked after realizing how much work this is going to be. Please think carefully about those thin…

Have also been considering Paddle. Would love to know what you found it's missing?

Re: Billing systems are a nightmare for engineers

#212
post #27

Earlier quoted context omitted.

Not the OP, but anybody who has built a deep integration with any billing provider (inclusive of Stripe) knows there are some bodies buried, although you typically don't discover them until you're late in the game. 90% of your use cases are covered, and with excellent UX and docs to boot. But that sweet 10%! --- For a concrete example, Stripe has a very nice "subscription" abstraction that makes it easier to operate…

I think it's easier for billing systems to have 1 subscription for 1 customer. The reason behind this is mainly because you can apply several prices to the same feature belonging to two different subscriptions. Stripe does not work on it because they might consider this as a edge case. When you look at usage-based billing, even if a billed feature is linked to consumption, it needs to be related to a subscription giv…

This is what I’m doing, but then you don’t get a clean history in Stripe, which is annoying to folks (e.g. to our support team). So, it’s something I’m thinking about changing.

Re: Billing systems are a nightmare for engineers

#213
post #177

Earlier quoted context omitted.

They can disclose their interests without the repetitive intro. But for the above comment, just asking a question, even this is unnecessary.

I agree it was repetitive, but indeed, I did not want people to think I was trying to pretend to be unrelated to the post. Thanks for the constructive feedback!

you're welcome

Re: Billing systems are a nightmare for engineers

#214
post #4

A classic, from http://www.canonical.org/~kragen/tao-of-programming.html > There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: ``Which is easier to design: an accounting package or an operating system?'' > ``An operating system,'' replied the programmer. > The warlord uttered an exclamation of disbelief. ``Surely an accounting package is trivial next to th…

Which came first? I am pretty sure it was computer accounting systems. Which is older, the oldest continuously supported operating system, or the oldest continuously supported (computer) accounting system?

The oldest computer accounting system was likely LEO - https://en.wikipedia.org/wiki/LEO_(computer), online in 1951 and doing accounts probably by 1955, if not earlier.

I believe it predate operating systems by a few years. (Wikipedia claims the first OS was the GM-NAA I/O, produced in 1956.)

Re: Billing systems are a nightmare for engineers

#215

Earlier quoted context omitted.

Thank you Anh-Tho for your response. What is the mechanism for French government to subpoena a non-EU business to find this invoice? If the customer (instead of vendor) produced an invoice that matched their bank statements and non-conforming receipt, hypothetically, would anyone really know the difference?

Probably they wouldn't as full audits aren't that common, but audits do happen and most accountants won't care about your purchase as much to personally commit a felony and forge documents for no good reason (accountants do have personal responsibility, and every accounting course reminds wannabe accountants that "the boss ordered it" is not an excuse) so they simply say that they can't/won't do it and if the vendor…

How would a French audit uncover anything wrong with a conforming format invoice under the name of some random American company that exactly matched the bank statement, physical goods, and customs paperwork?

Re: Billing systems are a nightmare for engineers

#216

As someone, who has built a billing system not once in my life, but twice (one for an internet privider I worked for, which counted the amount of traffic , and another one for a SaaS project(, I fully sympathize with the post. Billing is an unbelievable can of worms even before you get to taxes. Add in all the things the marketing people want from billing (trials, discounts, per-seat per usage pricing, etc), and you…

Yep, do agree that non tech team created a lot of pricing complexities, sometimes without any reasons. Remember a marketing team updating plans on webflow and telling the product team « see, not that hard » ;) Ended up with a whole squad of engineers called « the pricing cross functional team » …

Re: Billing systems are a nightmare for engineers

#217
post #62

Absolutely agree with the poster. This is my life at the moment. Just to take money for a small piece of software I built. Multiple currencies, trial periods, when in the process do you ask for the creditcard, country specific taxes,... And the worst: invoices. While paddle.com takes care of many of those things - I was shocked after realizing how much work this is going to be. Please think carefully about those thin…

Agreed! But I do prefer to build it for me rather than someone else’s startup, though

Re: Billing systems are a nightmare for engineers

#218
post #123

Problem is it still requires an API to integrate. Stripe has all these capabilities but API integrations are needed to use them. If you are looking to build a micro SaaS without needing to deal with billing API integrations check out our software: https://saasbox.net . Built for completely eliminating any billing related SW development. It doesn't handle all the corner cases mentioned in the article, but some of them…

Why is it a problem to use an API?

Re: Billing systems are a nightmare for engineers

#219
post #194
post #183

Earlier quoted context omitted.

Yes, almost everything ended as temporal or bitemporal model. Pain to work with. Even for simple questions like "What is the customer #1234 company name?" the system needs to know when are you asking.

By "temporal model" do you mean relational tables of "customer X used Y amount of this resource at price Z from timestamp A to timestamp B" or ... ?

In field metering situations you can have the timeline of each meter, when it records data points, and then you have the different timeline of the backend service, when it actually _receives_ data points.

Bonus points if the meters can send data out of order.

Re: Billing systems are a nightmare for engineers

#220
post #111

Earlier quoted context omitted.

>. With business customers, leaning back in the legal framework encouraging tax fraud will not fly. Yes which is why in nations like Portugal, where any business invoice may be subject to accountability to government, there totally isn't a massive informal (read: tax-evading) economy to deal with the fact that the government makes it literally impossible (at least in above words) to accept an invoice legal in the jur…

There isn’t a massive tax evasion economy in the USA?

Yes. It would be even larger if US companies couldn't accept foreign invoices without being in a special format. Does tax evasion in the US somehow disprove tax evasion in Europe?
Post reply on HN