Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Billing systems are a nightmare for engineers

getlago.com

Post reply on HN
Print view View original

161–170 of 372 posts

Re: Billing systems are a nightmare for engineers

#161

Post by dqv »

phphphphp wrote: post #71
gen220 wrote: 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…

A lot of the time there’s trade-offs that can be made that engineers don’t even consider because they’re not pure. For example, why do you need a one-to-one relationship between your customers and Stripe customers? I am guilty of it myself, where an 80% solution is unacceptable from an engineering perspective but, actually, when balanced against the cost of building out a perfect solution, the business may well find…

>One of the most important things I’ve learned about working with third-party systems is that there has to be some amount of surrender to their way of doing things. Essentially, the price of using Stripe is not being able to use invoices as a quote, and that has to be articulated to the business.

We have this same limitation on another payment platform. We just change the concept on our end to "payers" and allow an account to have multiple payers. When the user adds a payment method, they can either select that existing payer or, if they need to change the name or address, they create a new one.

The provider we use had an invoicing product, but it has several misfeatures that just make the product unworkable. We absolutely have to be able to enforce first-in-first-out invoice payments. Users will pay the May invoice before the April invoice and pretend like they are all paid up. I'm not sure why they didn't consider this with a subscription-invoice product... users paying the invoices out of order was a big problem because users saw it as an exploitable vulnerability they could use to get a free month here and there.

Re: Billing systems are a nightmare for engineers

#162

Post by bokohut »

As a co/founder and core architect of multiple PCI level 1 compliant payment processing companies in the last two decades I will add as others have that billing and payments is exactly like anything else which is "difficult". Once you spend enough time in the trenches dealing with the challenging technical issues your experience and creativity leads to the proper solutions that further enhance the system. Everything is just inputs and outputs yet it is what one does in between those "puts" which matters and thus where experience can reduce such challenges.

Re: Billing systems are a nightmare for engineers

#164

Post by gopher_space »

spookthesunset wrote: post #124
dboreham wrote: post #108

Note OP makes a billing product (OSS, granted) so is motivated to characterize the field as complex and hard. In reality billing is just like many other processes humans engage in. For sure it's more complex than computing prime numbers, but hey try writing software to capture medical services processes :) In the end this is exactly what engineers are supposed to do: figure out ways to model/capture/represent complex…

Or better, buy a billing system instead of inventing one inhouse. Billing is hard to do correctly. For one thing it interconnects with so many different platforms in your company. For another thing, the cost of fucking something up is high--people don't exactly like seeing mistakes in their bill. Hell, think about tax... you wanna deal with that shit? To do it "correct" you've got to have people who truly understand…

"How to realize when you're about to build your own billing system" would be a more useful discussion.

Re: Billing systems are a nightmare for engineers

#166

Post by Rafsark »

nikanj wrote: post #28
api wrote: post #13

Any kind of business or accounting system tends to be an endless long tail of "can the invoicing system send the invoice in Esperanto using only 16-bit Unicode characters on Tuesdays but only while it is raining and only for customers whose last names end with E and who signed up more than one year ago according to the Chinese calendar?" type features. That's why attempts at "no-code" systems where biz/accounting peo…

The #1 reason those systems are moderately successful: When your sales person needs to write the logic for billing customer X, they'll try to make the customer contract more reasonable. Normally sales people are deal-driven, and if promising the customer "14% off on the first three transactions on every rainy Tuesday, unless Monday was also rainy" gets the deal closed, then that's going in the contract. No better way…

Agreed! this triggers also complex behaviors because sales people want to handle this in their env (Salesforce, hubspot or whatever); You also have to build the logic to update subscriptions and pricing directly from it, in a two-way sync. Things getting crazier ;)

Re: Billing systems are a nightmare for engineers

#167

Post by einpoklum »

> Why billing systems are a nightmare for engineers

My guess: Because basically nobody wants to develop one of these as a hobby FOSS project. The whole idea is collecting people's money, which when you write your own code for public benefit, you basically don't do :-)

> We quickly decided to add plans, and 'pay-as-you-go' features

So, the author talks about things getting more complex, beyond their expectations. But - why did they not expect this? I mean, they know that companies pricing changes over time; that payment models change, including rates, cadence, use of internal credit etc. We all know this without ever having worked on a billing system.

> Qonto is a 'neobank' ... Fintech unicorn

So they were expecting billing to be easy for a bank-like endeavor? Hmm.

> #1 - Dates

The date problems per se are quite mundane and any non-trivial software system which involves timed activity deals with them. The billion period problems are not really date problems and are a recap of what OP had already written about. They are also problems most of us are well aware of from our personal experience as people in modern society ("Does my bus pass expire a day after I bought it, i.e. 24 hours later, or does it expire at the turn of the day = at midnight?")

etc.

Re: Billing systems are a nightmare for engineers

#169

Post by tabtab »

hammock wrote: post #163

Double-entry accounting is tough for a lot of people. It's a different domain and trying to fit it into traditional "math" will only cause headaches.

An alternative to DE is "Assume Balance". See near the bottom of http://wiki.c2.com/?AccountingModeling

Re: Billing systems are a nightmare for engineers

#170

Post by janci »

I was working on a billing system for utility company and it was a nightmare but not for the reasons from the article.

Dates are no problem, everything is billed at the end of month, quarter or year.

Upgrades are downgrades are simplified, customer can legally change tariff only on predefined dates/events.

Usage - yes, but exampled in the article do not even scratch the complexity of this

Idempotency is not really needed, the billing process is not continuous, it is a batch job.

Cash collection is out of scope of billing software.

Taxing was clear. Yes, there were multiple billable items with different tax rates, but not too complex. All customers were local.

The nightmare part was:

- customers can have multiple consumption locations, location can have multiple meters and customer can request to split the bill on multiple invoices or combine multiple bills to single invoice as they please

- meters can be replaced at any time

- meter readings are available on dates totally independent from billing cycle. Most of consumption data are mere forecasts.

- when the actual consumption data is available, everything must be recalculated AND compensated (on a correction invoice showing the difference)

- actual consumption data can be wrong and may be corrected at a later date, even multiple times

- consumption points can be added or removed or moved to different customer at any time, but this information is only available after the fact

- the prices can change mid-billing cycle for some customers but the consumption data is not available with that granularity

- customer legal information (company name, address) can change mid-cycle

Post reply on HN