News for hackers. Stuff that matters.
Re:Things I learned while developing a billing system by tzs on Monday April 05, 2021 @04:23PM (#26704177)
If I ever get to redesign the billing system at work, I'm going to go with fixed day of the month billing. We currently do 30 day billing, and most customers are fine with that, but there are some who need their bill to not come the same week as their rent is due, or not come until after they receive their monthly pension payment, or something like that. Right now we have to have special handling for those people.

For handling the different lengths between the months, I've considered a few approaches.

1. If re-bill is supposed to be the Nth of each month, that simply means N-1 days after the 1st. If that falls into another calendar month, fine. So if someone asks to be billed on the 30th of each month, they will be billed on Jan 30th for January, Mar 2nd for February, Mar 30 for March, and so on. I'd make sure the receipt explicitly says "Re-bill for January", "Re-bill for February", etc., so that bill the see on Mar 2nd hopefully will not confuse them, nor will seeing another bill later that month.

2. If re-bill is supposed to be on the 29th-31st, for February it takes place on the 28th (29th in leap years). For other months, if re-bill is supposed to be on 31st, it takes place on the 30th in April, June, September, and November.

3. If you initially order on day 1-21 of the month, your re-billing is the same day ever month. If you initially order on day 22+, your re-billing is on the same number of days before the end of the month as was your initial order. For example, someone who orders on May 30th would re-bill on the 30th in 31 day months, the 29th in 30 days months, and the 27th in February (28th in leap years). If you ask for a change in fixed billing date, you can do so either as Nth day of the month or Mth day from the end of the month, but N or M must be <= 28.

Re:Things I learned while developing a billing system by mr-wendel on Monday April 05, 2021 @05:15PM (#26704834)
If you ever get to... GET TO? You must love pain! Actually, I wonder what business you're coding for to have those be important criteria and wish you all the best of luck!

In general, however:

Don't fall victim to one of the classic dev blunders -- the most famous of which is "don't roll your own crypto" -- but only slightly less well-known is this: "Never write your own billing logic when business is on the line!"

Re:Things I learned while developing a billing system by thaumasiotes on Monday April 05, 2021 @06:36PM (#26705526)
> For handling the different lengths between the months, I've considered a few approaches.

> 1. If re-bill is supposed to be the Nth of each month, that simply means N-1 days after the 1st.

I have a credit card that takes the much simpler approach "Your payment due date is the Nth of each month. N can be any value from 1 to 24."

This seems to basically match your approach 3.

If you ask how I think you should bill ( :p ), do it on a fixed day and don't try to do rebilling at a fixed interval. If the day somebody buys your thing is unsuitable for fixed-date billing, the answer is prorating their first period, not interval billing.

Re:Things I learned while developing a billing system by arnon on Monday April 05, 2021 @04:31PM (#26704295)
> If I ever get to redesign the billing system at work, I'm going to go with fixed day of the month billing.

This may have unintended consequences. Some examples we faced around this:

1. Stress on our APIs when 15,000 invoices are created in the span of a couple of minutes. We had to build more queueing mechanisms around this. Some services just can't handle more than 100 calls a second.

2. Getting rate limited by MasterCard

3. Some payment providers thinking we're brute-forcing them

Re:Things I learned while developing a billing system by virtue3 on Monday April 05, 2021 @04:35PM (#26704353)
Aren't all of these handled by a queue and some reasonable sense of going through it slowly? (I can just say that on the internet, I know designing it that way is not exactly trivial).
Re:Things I learned while developing a billing system by arnon on Monday April 05, 2021 @04:44PM (#26704450)
Not all systems have sane defaults or queues built-in.

I'm just saying this needs consideration when you reach a certain scale.

Re:Things I learned while developing a billing system by PeterisP on Monday April 05, 2021 @05:02PM (#26704692)
For additional fun, consider how this would work with the added constraint of needing the date be a business day, so you need to take into account how weekends (which vary across the world, by the way; in a bunch of countries sunday is a business day but friday is off) and banking holidays in every locale in which you do business.
Re:Things I learned while developing a billing system by notimpotent on Monday April 05, 2021 @05:31PM (#26704966)
First time learning that weekend days vary by country. I looked up [1] some of the more curious ones.

Brunei weekends are Friday and Sunday. Those poor folks work Mon-Thurs, and then go back to work Saturday!

[1] https://en.wikipedia.org/wiki/Workweek_and_weekend

Re:Things I learned while developing a billing system by thaumasiotes on Monday April 05, 2021 @06:39PM (#26705555)
For reference, in China there are a bunch of legally mandated holidays that convert the weekend days around them into normal working days. (The conversion is not legally mandated; think of it as a response to laws that generate many more holidays than the economy supports.)
Re:Things I learned while developing a billing system by xyzzy21 on Tuesday April 06, 2021 @05:17PM (#26717500)
Depending on the power-relationship with any given customer, you may not get the option to dictate this - sometimes the customer tells you want it will do and you have to follow. Other times you can dictate but without the flexibility, you put the company at a competitive disadvantage.