3 ms·
After seeing billing done right, I cringe every time I see billing done wrong. For example, people building foreign keys to prices and receipt items. In what c
by withinboredom 4y ago
After seeing billing done right, I cringe every time I see billing done wrong.
For example, people building foreign keys to prices and receipt items. In what cases do you expect to retroactively change what you charged all customers? Copy that data to the receipt item, don’t give your accountant a headache and heart attack when you change pricing. I’ve also seen people using those same kinds of rows to determine what features a user gets access to. Don’t do that, use capabilities/roles. When a payment succeeds, update the user’s capabilities. When a payment fails, remove capabilities. This also allows support to just give a customer capabilities without a line item or changing their plan, because some customers are just annoying and it is less expensive to give them a feature. It also allows more easily selling custom-tailored solutions to bigger clients since the features aren’t linked to line items.
This article is more about usage-based billing, which is probably harder to get right, but feature-based billing is something I’m more familiar with and it’s so annoying to see all the ways people will fuck it up.
- deleted 4y ago[deleted]
- gryf 4y agoYour first point about foreign keys was the first contract I ever did. Someone built a billing system in perl+mysql for an ecommerce site. When prices changed so did historical invoices. I was hired to work this out because the existing developers couldn't. They only realised realised that something was wrong after a customer sued them after being paid the wrong amount in a refund. I rewrote the entire system to snapshot the committed values at the time of purchase and fixing all the old invoices from database backups.
- robertlagrant 4y agoThe way you'd assume they'd do it if they wanted relational values would be to never be able to edit prices, only create new ones.
- withinboredom 4y ago> never be able to edit prices I can't think of any database that makes a row strictly immutable, as in carved onto the platter immutable. People will find ways to undo any soft-guards you put into place, all in the name of being helpful.
- AnhTho_FR 4y agoOP here, totally agree! Feature-based billing is super hard too, and people underestimate the complexity even more. We were genuinely surprised that some companies wanted to use Lago even if they ""only"" had a "feature-based/subscription-based" pricing, that someone new would consider as "trivial".