Subscription Payments on 31st of Month

cfncfn Member
in Help edited September 2008
We're curious - what happens when a member signs up on the 31st of the month for a monthly billing? In months without at 31st, does it go through on the 30th, or on the 1st?

Thanks!
Comments
  • brettbrett FoxyCart Team
    edited September 2008
    Good question. Currently it goes forward, not backward. We've discussed it internally (since we use our own system to handle the subscriptions), but at the time didn't modify the behavior.

    Thoughts?
  • Forward is the best option for us. Do Feb 29/30/31 also all bill on March 1st?

    (I think it could possibly be a minor problem if a company recognizes subscription revenue -- and doesn't think about how this works on the accounting/reporting side -- as 30th months would not include billings for active 31st subscriptions, and then 2 billings accrue in the next calendar month. But always better in my opinion to *never* bill the customer early.)
  • brettbrett FoxyCart Team
    I honestly wasn't expecting forward to be a good option for anybody, but yes, forward is how it works now, including February. (FoxyCart has a ton of subscriptions that run on the 1st and no old ones that run after the 28th.)

    As far as subscriptions, we've compared with other SaaS webapps and it seems like the dates they process seem to bounce around slightly even when they're not at the end of the month, so I'm not sure what they're doing, but based on your parenthetical I think we need to clarify something:

    Once a subscription date is "moved", it's "moved". If a sub is on the 31st and the month doesn't have a 31st, it gets moved to the 1st of the next month, where it stays.

    Does the explanation make sense, and in light of that do you still think it's a good idea?
  • tookingstookings Member
    edited September 2008
    So that means...after any February, you essentially will have no subscriptions on the 29-31st, and they will all have been moved to the 1st.

    Good to know, hadn't really put all that much thought into it -- but our customer side is the most important part to us "always in their favor" and I'd rather move it forward a little, than bill early. In our case, we can just add a "* note about sub date" somewhere in a FAQ, and be done with it. Once the API is available, maybe we'll force the date move out of the 29-31 range from our end pro-actively after the first sale, so it's already taken care of and keeps accounting/reporting easier and more consistent.

    Just thinking out loud too....this is probably a fairly minor for us. I'd probably say leave it the way it is, and when the subscription API is online, users can override the default behavior with code that reviews and resets the dates if needed, from their end.
  • It seems the best way may be to pro-rate and start every subscription on the first. Has anyone done this?
  • brettbrett FoxyCart Team
    You could prorate by using some javascript to create a prorated non-subscription product and then use the start date for the subscription to the next 1st.

    I think it'd depend on your needs. For us it's easier to just start the sub on checkout rather than prorate, but I could see both being useful.
  • The 1st + pro-rate system works well for services and electronic subscriptions IMHO.

    ...but we have actual product subscriptions so (a) different customers want things to arrive at different times in the month, and (b) some smaller vendors that will ship for us prefer to have mass shipments spread out, instead of all at once, and (c) you can't really pro-rate a unit product...you'd have to have an initial order system...or a delayed order...using the order day of month works well, and seems to be understood by customers. (They can change their date on request, of course.)
  • My vote would be for purchases on the 31st to always be billed on the last day of the month, meaning the 29th for leap years in February.

    For those on the 30th or 29th, the 30th/29th except for the last day of February.

    Any other day, just use on that day.
  • brettbrett FoxyCart Team
    I'm glad Ryan chimed in here because I think bumping things forward has some potential problems in terms of reporting and revenue and such. For example, may companies must report and pay taxes quarterly. So somebody signs up on Jan 31. That counts as January's revenue. Then it'd skip February (with the current move-ahead functionality), and March would see it on the 1st.

    So Q1 should have had 3 transactions, but only saw two. I don't disagree with the concept of erring in the customers' favor, but I don't really see it as that big a deal for the customer, and it's potentially a much larger deal for the company. If you're running a subscription based business (like we are), and you're doing monthly projections and such, that extra day (or two or three) could be a significant issue.

    We'd love to get more opinions on this one if anybody has anything to add.
  • tookingstookings Member
    edited December 2008
    We've actually had a change of heart, and would have to support the last day of the month, backdated as required if that day "doesn't exist" in the current month -- as mthrash said. Mainly for the accounting/business reasons, and some other specific details to our application. (At the moment, we've setup an internal notification trigger when reading the initial datafeed to check for the offending 29-31st days, and we can go back and reset the recur date by hand to the 28th starting with the next month...making our customers aware when they order...and with the coming-soon API we could automate this change with a callback, if it isn't an option in foxy first.)

    Perhaps it's an configurable option whether to push ahead or push back? (With a subscription API we can implement this externally as well. The main thing that won't work for us at all is "pro-rate and start every subscription on the first" in a product subscription model.)

    Thanks!
  • lukeluke FoxyCart Team
    Thanks for the input, everyone. We're getting pretty close with 041 which includes full recurring complete transactions (including shippable ones) and we can probably make this change as part of the process. We'll probably end up just changing it to stay in the same month and then seeing if anyone has a problem with that. Just to be clear, though, eventually all of the end of the month transactions will hit on the 28th... since transactions on the 31st will get bumped to the 30th and eventually, in February, will get bumped to the 28th (or 29th). That might be a little strange for some customers, but it would probably be complex to do it differently.
  • rthrashrthrash Member
    edited December 2008
    I'm gonna strongly strongly disagree with permanently moving the order date forward. Some folks get paid on the last day of the month. They place an order for a recurring subscription item to correspond with the pay day. They're habitually running out of money for the last few days of the month, so your payment bounces and there's a multitude of problems to deal with to save a few if statements based on the order day being the 29th, 30th or 31st:
    [ulist]
    [li]the sale doesn't go through, so the company looses the sale[/li]
    [li]the customer is upset, because their order doesn't ship[/li]
    [li]now a human has to take the time to sort out this mess of lost revenues, unhappy customers or both[/li]
    [li]then Ryan has to go write his own bleeping subscription system to eliminate humans having to be involved at all because at the end of the day, it really should be that way[/li]
    [/ulist]

    This plays a big role in subscription payments, especially for pills, powders and potions that many folks sell auto-ship reorders for. Lots of companies do in fact pay at the end of the month. You should ask customers to jump through hoops to order on a day that's convenient for the logic in your application. It's really fundamentally no different than a recurring meeting that occurs on the last day of the month.
  • rthrashrthrash Member
    edited December 2008
    Here's some rough pseudo-logic for figuring out the billing date:

    if (original subscription day = 29) & (current year mod 4 = 0) & (current month = 2) then bill on Feb 29 for current cycle // handles Feb in leap year

    elseif (original subscription day = 28) & (current month = 2) then bill on Feb 28 for current cycle // handles Feb normally

    elseif (original subscription day = 31) & (current month is in (4,6,9,11)) then bill on day 30 of current month for current cycle // handles Apr, Jun, Sep and Nov

    else bill on original subscription day of current month


    It'd probably be more efficient to insert an additional condition to test for dates billed <= day 28 at the beginning since more days fall in that range and it'd exit the comparison earlier, but there's probably a decent number of businesses that sell a lot in the last few days of the month too. And I probably forgot something in the logic above but hopefully it's close enough ... it definitely requires storing the original subscription start date as a key determining factor, so it may not fit the current data model, which would be a problem that I'm not considering.
  • tookingstookings Member
    edited December 2008
    elseif (original subscription day = 28) & (current month = 2) then bill on Feb 28 for current cycle // handles Feb normally

    I think that would be:
    elseif (original subscription day = 30) & (current month = 2) then bill on Feb 28 for current cycle // handles Feb normally

    ...but that is besides the point. Yes, I would actually prefer any rebill date on the 29-31 float to the "last day of the month" than change permanently to the 28th over time. (And a rebill date of the 31st would still "officially" be the 31st.)

    Looking back at some old psuedo code, I think this is how we planned to code our cart before we found foxy. But, we can live with quite a few different options...although I would pick rthrash's approach if I had one choice. (I think this would be doable with datafeed+API too, but it would be messy with callbacks every month.)
  • lukeluke FoxyCart Team
    Thanks again for the input, guys. Ryan, you're right in assuming we don't store the original subscription date in the subscription record though it is stored on the original transaction detail record... I'll take a look and try to implement what you're both describing. Worst case scenario, things get bumped back as needed, but I agree ideally we want things to adjust back as needed and then move back to their original day if possible.

    Thanks again.
  • If you store a pointer to the original subscription record then you should be fine so that's good (I think you do). I can't reiterrate enough though about how uncool it is at least for a products company selling monthly subscriptions to mess with EOM order dates.
  • lukeluke FoxyCart Team
    We spent a good amount of time on this and it should be ready to go in the next version. It correctly bumps dates back when needed and then forward again as needed. Here are some examples of how it will work:

    If your subscription starts on the 28th, it will always run on the 28th. If it starts on the 30th, it will run on the 30th for every month except February. If you start on the 31st, it will run on the 31st for months that have 31 days or the 30th/28th/29th for the other months. We're not planning on implementing an "end of the month" flag but we're hoping this will be sufficient for now. Will that work for everyone?
  • Sounds great to me! No more annoying posts on the subject from this part of the country. Thanks FoxyFolk.
  • Can ya'll confirm how this is currently operating in v060? Thanks!
  • lukeluke FoxyCart Team
    woah... digging up some skeletons here. This thread is almost a year old. We didn't make any changes to 060 with regards to this so at the time of this posting "the next version" was something else that has already been released (050? 051? not really sure). That being said, it should be working as described.
  • tookingstookings Member
    edited November 2009
    Sorry/thanks. Just checking. :)
  • lukeluke FoxyCart Team
    No problem at all. If for some reason it's not working as described, please let us know so we can take a closer look.
Sign In or Register to comment.