#ere
1 messages · Page 1 of 1 (latest)
Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- ere, 2 days ago, 4 messages
Hi 👋 you can't set the billing cycle anchor based on a reference to a time of day, such as Dec 1st at Midnight, or Dec 1st at Noon. The billing cycle anchors accept unix timestamps though, so you can be precise with the time that you select to set those to by passing a timestamp for the specific time you want to use.
Yes this is what I'm doing, but say if the monthly price is 400 and I set the anchors as described, and the current time is 6PM, the invoiced amount will not be 400 but something like 409.68 since the time between 00:00 and 6PM seems to be added
Hm, sorry, but I'm not grasping how the current time is relevant there (it may be that the coffee hasn't fully kicked in yet). Both backdate_start_date and billing_cycle_anchor accept second-precise timestamps, so I believe you have full control over the timeframe that is billed for and can avoid any impact from the current time.
The proration seems to not be calculated strictly like that though, example timestamps are "backdate_start_date" => 1714510800, "billing_cycle_anchor" => 1717189200, test clock time 15 May 2024 at 20:00 EET
Those are for different dates/times in the month. One is on the 30th, the other is on the 31st. Do you see one month's charge if you align those to the same date/time of different months?
Seems to work! What if there is a daylight saving time change in between those two anchors, should I account for that?
I don't think so, I think we handle that as long as you provide the same date/time for each month.
Ok thank you very much