If in my project someone buys a membership for 1 month, how long should that "month" be?
Always 30 days, no matter the month of the year (e.g 23/2/2016 => 25/3/2016)
The same day number of the next month (e.g 10/5/2016 => 10/6/2016)
Or another?
-
2Possible duplicate of How to apply a Changed a monthly plan?– jazZRoMay 3 '16 at 21:20
-
2The question is nowhere close to the supposed duplicate, although the approved answer is related.– DevinMay 3 '16 at 22:04
-
1Why not ~30.4735 days?– Austin FrenchMay 3 '16 at 22:47
-
@Devin, you are correct, it is related not a duplicate.– jazZRoMay 4 '16 at 9:44
Add a comment
|
Stick to conventions and consistency
This is really simple: if user is charged on day 5 of the month, he should be charged on day 5 next month. Most users plan in anticipation and they know that every fifth day of the month they will be charged for a service. Otherwise, see what would happen
January 5
February 4
March 5
April 4
May 4
June 3
July 3
August 2
September 1
October 1
**October 31** (2 charges on the same month!!!!??????)
November 30
**December 30 = 1 year**
As you may see, your user was paying the fifth day of each month. 10 months later, he pays at the end even though, in his view, he didn't even reach that month. By the end of December, he has paid for a year even tho a year would be on January 5th.
While this may not be a great deal, for some people it is. You'll be seen as trying to take advantage of a customer, or as too greedy/cheap to do what EVERYBODY ELSE does (let alone the confusion you'll be causing).
In short: if 99.99999999999999% of people is doing it... you can't go wrong
EDIT: Another common alternative to make dates consistent: charge the proportional rate for the remaining of the month, then start charging a full rate at the beginning of the month. This way, users will always know the date is the first day of the month, and companies have less accounting work.
An alternative to this alternative is to have a few dates (or date ranges) for users to choose. This is quite common for banks and financial institutions, allowing clients not to have all charges at the beginning of the month.
But even within these alternatives, there's a common factor: date always stays the same month to month
-
I'd agree that once recurring charges commence then one should bill on the same day each month. But offering 30 days free up front is closest to the average number of days. Also, one has to be careful. For example, if billing started on Jan. 30th the customer couldn't be automatically billed on February 30th.– StonetipMay 3 '16 at 23:01
-
again, let's stick to conventions: for last couple of days of January to February, the norm is to make the charge on the last day of February or first day or March, but then it goes back to normal– DevinMay 3 '16 at 23:06
-
-
Where do these conventions and norms originate? I haven't dealt with these issues that much and would like to learn more.– StonetipMay 4 '16 at 14:11
-
I know at least 1 person who uses 30 as one month. And thus i falsified your percentage May 8 '16 at 18:01
You don't need to over think this. Unless there are regulatory constraints it can be whatever you want it to be and your users will take it as corporate policy. (By the way is there existing corporate policy relating to the definition of a month in other areas? If so leverage those decisions.)
If you want to be thorough, and have the time and resources, you could chart what your competitors do. You could also run tests on your users. Pick one and then make the wording consistent. for instance "Enjoy your 30 day membership with XYZ Corporation"
According to Dr. Math there are 30.42 days in an average month so you'd be "safe" rounding down to 30. :-) That aside, 30 days seems like a fair and intuitive number to use for most people. From a practical standpoint it's usually easier for a programmer to deal with too. Of course, whoever inserts the data into a datastore would be wise to use a reliable calendar library to take into account leap years and the +- one day difference found from month to month!
