#brayden-subscription-bca

1 messages · Page 1 of 1 (latest)

vocal thistleBOT
#

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.

calm lintel
tardy temple
#

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

calm lintel
#

Trying to understand how this was started on the 6th of Nov. but is now renewing annually on the 5th?

tardy temple
#

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

calm lintel
#

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.

tardy temple
#

It is from the 6th to the 6th in UTC\

calm lintel
#

Yeah I know, but I need it from the 6th to the 6th in EST

#

Is there a way I can do that?

tardy temple
#

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?

calm lintel
#

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?

tardy temple
calm lintel
#

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?

tardy temple
#

(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

calm lintel
#

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

tardy temple
calm lintel
#

Okay I don't know that this method is something we want to pursue. Thank you though!

#

Appreciate all the info.

tardy temple
#

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

vocal thistleBOT