#brayden-subscription-bca
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.
- braydensterrett, 5 days ago, 94 messages
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
All our timestamps are UTC and should be unaffected at a technical level
THough it's possible for rendered date on invoices to shift since those may be localized for the customer
Trying to understand how this was started on the 6th of Nov. but is now renewing annually on the 5th?
I see the current period start is 1699243272 (Mon Nov 06 2023 04:01:12 GMT+0000) and the end is 1730865672 (Wed Nov 06 2024 04:01:12 GMT+0000)
So that seems to be the expected 1 yr cycle
Hmmm but this sub was originally started on the 6th of November
So I'm trying to understand how it's now on a schedule that is starting it on the 5th (EST)
Is it because of daylight savings?
Due to the nature of our business, this date shouldn't change so I'm just wondering how I can fix this?
Can I reset this subscription to be from the 6th to the 6th somehow?
When I tried to update the sub schedule with a new start date, I got this error: You can not modify the start date of the current phase.
It is from the 6th to the 6th in UTC\
Yeah I know, but I need it from the 6th to the 6th in EST
Is there a way I can do that?
You could adjust the billing cycle anchor to a different time in the day if needed, but ultimately everything is driven by those UTC timestamps
I am inferring you;re seeing the Nov 5th date on the invoice lines in the pdf?
Find help and support for Stripe. Our support site provides answers on all types of situations, including account information, charges and refunds, and subscriptions information. Get your questions answered and find international support for Stripe.
Yeah we convert that UTC timestamp to our server's time zone (EST now) and that causes a mismatch. As well, Stripe now showing Nov. 5th, 2024 as the next invoice date is throwing a bunch of people off because it's supposed to be the 6th.
If I'm able to adjust it just a couple of hours into the future, that would do it, I think?
Right, that's one option. You cna review how to control billing cycle anchors and change them here: https://stripe.com/docs/billing/subscriptions/change
When I try to update via the Stripe::Subscription.update, with a couple of hours into the future on Nov. 6th I get this error: The parameter billing_cycle_anchorexpects a unix timestamp representing a date and time in the future. You specified the value1699232507 which is in the past.
Is there a different way to do this?
https://dashboard.stripe.com/logs/req_SJYADepzZudHyJ you cannot directly update the billing cycle anchor like this. You can choose it at creation, but after the subscription is started, you need to adjust it using one of the documented flows: https://stripe.com/docs/billing/subscriptions/billing-cycle#changing
(apologies, this is the doc i meant to link you to initially)
You can use a short trial period to shift the anchor, or reset it to now or use a subscription schedule to change it in the future
Sorry, I'm not sure I'm understanding.. none of these options will allow me to set the billing cycle anchor to Nov. 6th, from what I can tell..
Is that true?
My only option is to reset it to now which does not help me
You can effectively set the next renewal to a specific timestamp by way of setting trial_end and having a trial period until that time, or by using a subscription schedule. You cannot directly update the nachor of an existing subscription to anything but now.
https://stripe.com/docs/billing/subscriptions/subscription-schedules/use-cases#resetting-anchor
Okay I don't know that this method is something we want to pursue. Thank you though!
Appreciate all the info.
NP -- if you want to control this for future subscription creation, you can set the billing_cycle_anchor when you create the subscription, but you should make sure to test out these flows in test mode
braydensterrett-billing-cycle-anchor-timezones