#sukatoa

1 messages · Page 1 of 1 (latest)

pure copperBOT
jade goblet
#

Hi
Not sure I understand the "maintenance period" is this something really related to your integration/Design ?

#

What I personally think is you just need to set every think in UTC...

verbal shard
#

our app utilizes server time (in JPT), we knew later time that Stripe only understands UTC, so we created a Scheduler that manages the translation of timing incoming/outgoing.

#

The maintenance period occurs because of ....

#

Business Logic is that, when user purchases sub on April 1, 1am JPT, this considered user purchasing strictly on month of April,

In reality, when we use the actual time JPT and push it to Stripe via subscription, April 1, 1am becomes March 31, 4pm UTC. We like to have subscriptions being in uniform in recurring charge. To avoid all confusions, we tend to follow the UTC. So that's 12:00am UTC (9AM JPT).

The maintenance period term occurred due to the business logic of 12am JPT is not yet the 12am UTC, we have to wait for UTC to become 12am so that the charging will be consistent and Stripe will obey the "monthly" concept (regardless of 1number of days on any month 28, 29, 30, 31) it consistently charges the same value

#

"What I personally think is you just need to set every think in UTC..." - we already did this currently, and the term maintenance period occurs, as explained above

jade goblet
#

Business Logic is that, when user purchases sub on April 1, 1am JPT, this considered user purchasing strictly on month of April,
Depending on what Timezone ? for JPT it's actually strictly on month of April... You want to have subscription strictly on month of April regardless of any timezone ?

verbal shard
#

No not regardless of any timezone, but April 1, 12am JPT - this is the 1st case, and we initially thought it will work immedidately on Stripe. But we realized Stripe only understands UTC, so we make adjustments.

So our business logic of strictly April 1, 12am start time /charging, is now being reconsidered and temporarily accepted to becoming April 1, 9am the starttime/charging because of the limitation

#

If we are just allowed to change our server timezone into UTC, there should be no maintenance period like this that's gonna happen

#

but unfortunately, they want server time to be JPT

#

I also initially thought that, if we set the timezone in Stripe account, Stripe will undertand and automatically understands JPT and will take care of time conversion, but I think it's not implemented

jade goblet
#

If your server is another timezone, you can handle times in UTC, I don't know what is the framework you are using, but you can integrate some date converter and handle utc times in your server.

verbal shard
#

"If your server is another timezone, you can handle times in UTC, I don't know what is the framework you are using, but you can integrate some date converter and handle utc times in your server." - we already did this, and this is currently in production, no issues so far honestly. It works like a charm.

pure copperBOT
verbal shard
#

But, for that case, we're not following the business logic anymore (strictly April 1, 12am JPT), and instead we have to adjust and make it happen on April 1, 9am JPT (April 1, 12am UTC). For this case, no problem on not following the timing in charging. Stakeholders understood the situation

#

Here's our experience -> if we'll not follow the 1st-day-of-month 12am UTC, the Stripe will not going to obey the "monthly" concept and instead use the 30-day rule with 100% ratio. Correct? We encountered issues like over/under charging of subscriptions. because the next month is 31 days, the next month has 30 days, and on Feb only 28/29 days under charge

That's why we tend to follow the exact 1st-day-of-month 12am UTC so that regardless of how many days on succeeding months there is, Stripe will keep charging the same price.

Now our app is forcing final timing to be UTC all the time, it works like magic

#

but again, just like I've mentioned earlier, we got this term "maintenance period" as explained above. Is there any way we can avoid that maintenance period? or we should stick on our current solution and just make patches for any issues encounter?

harsh gale
#

Hi! I'm taking over my colleague. Please, give me a moment to catch up.

verbal shard
#

No worries Vanya. Please don't archive this convo yet, I'm going to check on this later. Thanks much in advance, Vanya

harsh gale
#

I am trying to wrap my head around this, there's a lot of context, but I see very little direct connection to Stripe. I don't know what's a "maintenance window", and I don't know if you can avoid this as this is definitely not Stripe-specific. Could you please summarise the exact question related to Stripe?