HN Explorer

Ask HN: Which Subscription Model?

5 points by hknmtt ↗ HN
I am working on a website with recurring payments for subscriptions and am wondering which approach is the best.

I have came up with tree options:

1. fixed 30 days recurring subscription

2. payment is always made on the day of the month that it was initially created (ie 12th march -> 12th april -> 12th may...) with shift when days don't match(ie february with 28 days or 30 vs 31 day months)

3. charged on 1st day of the month with first payment increased by the time left in current month with following rules: 1st week of the month adds 75%, 2nd weeks adds 50%, 3rd week adds 25% of the monthly subscription price and 4th week ads 0(essentially free couple of days until the month ends)

Which one would you prefer or which other option would you suggest?

4 comments

[ 2.9 ms ] story [ 27.6 ms ] thread
throw03172019
Option #1 is the simplest to explain to the user. Showing a prorated price is extra work. Option #3 is way overkill and even harder to explain to the subscriber.
gnicholas
We use Stripe and I believe it uses 2. We see small spikes on certain dates due to clumping caused by months having different numbers of days.

Option 1 isn't that much different, but why complicate things? There's virtually no difference in revenue, but people's payment dates are changing in ways that could misalign with their other monthly payments/inflows. I have all sorts of bills and credits that come in at the same time each month. To my knowledge, I have none that migrate through the month by following a 30-day timer. Most people wouldn't notice though, of course.

Don't do 3. Way too complicated, and adding complications means losing customers.

hknmtt
with #2 you have an issue with days of 29-31 due to uneven months. so if someone would subscribe on 29th of january, then it would mean the next payment would be on 1st march and it throws off the entire thing from there on. same for 31th march and april having only 30 days. so some people would get those shifting dates anyway. i could make it so that 29-31 are forbidden and it would move forward to 1st and then there is no problem from the get go, the user just gets couple of free days - BUT i have to handle it in the logic so it will give the user access(technically the access is not valid just yet). the other way round would be to move it backwards to 28th but then the user did not receive the access in case it is 30th, for example. hence why i am inclined to go with #1.
gnicholas
It doesn't throw things off for future payments — it just makes it so that on short months the payment is taken slightly earlier/later. This is presumably not a core part of your business, and you're spending a lot of time thinking about it. I would google to see how others have handled this problem and just do what they do. Otherwise you are spending too much time reinventing the wheel for a presumably-ancillary part of your business.

If someone subscribes during a short month, they are always billed on that day of the month.

If someone subscribes during a month with more than 28 days, they are always billed on that day of the month during months with sufficient days. During months without sufficient days, they are billed on the first of the following month. When that happens, they will be billed twice during the long month and zero times during the preceding short month. No one should mind this.

Option 1 will seem identical to most users, but some may notice. Why not give them 31 days though? That way no one can complain.