benclum11

[wary halo]

👋 happy to help

taking a look

AFAIK all dates are calculated with GMT timestamps

[tight python]

Hello 👋
A quick correction, the timestamp in Stripe are always in UTC time.

We have a support article here
https://support.stripe.com/questions/subscription-charge-date#:~:text=We recommend seting up Subscriptions,date%2Ftime values in Stripe.

[craggy ibex]

it seems to be operating in EST, because the payments were

1. June 30th EST - https://dashboard.stripe.com/acct_1N0evp2nSvK0uBc6/events/evt_1NOqJA2nSvK0uBc6YspVEFLI
2. and then July 30 EST. - https://dashboard.stripe.com/acct_1N0evp2nSvK0uBc6/events/evt_1NZjed2nSvK0uBc6RB3YKwcp

if that were calculating in UTC, they why would the montly payments happen at:

1. 6/30/23, 11:00:56 PM UTC - https://dashboard.stripe.com/acct_1N0evp2nSvK0uBc6/events/evt_1NOqJA2nSvK0uBc6YspVEFLI
2. 7/31/23, 12:08:07 AM UTC - https://dashboard.stripe.com/acct_1N0evp2nSvK0uBc6/events/evt_1NZjed2nSvK0uBc6RB3YKwcp

Since 7/30 would have been 1 month after 6/30

actually nevermind I think you're right based on this Stripe doc: https://stripe.com/docs/billing/subscriptions/billing-cycle

If a month doesn’t have the anchor day, the subscription will be billed on the last day of the month. For example, a subscription starting on January 31 bills on February 28 (or February 29 in a leap year), then March 31, April 30, and so on.

regardless, any ideas on how to accomplish this?

[tight python]

Pulling in a teammate as discord is a bit busy, hang on!

[faint edge]

👋 hi there stepping in

This is a bit tricky. Especially if you're dealing with a region that has daylight savings. There's not a way in Stripe to natively have subscriptions pin to a certain day/time in a certain timezone. All our subscriptions go off of UTC time. So, even if you calculate the time difference between your native timezone and UTC and just schedule in the UTC converted time, the date/time will still be inaccurate whenever daylight savings rolls around. You'd need to manually reset the subscription's billing cycle anchor: https://stripe.com/docs/billing/subscriptions/subscription-schedules/use-cases#resetting-anchor. You'd also need to manually reset the billing cycle anchor in the following example. Since BST is +1 from UTC, to get the sub to start on July 1st, you'd need to start it at June 30th 23:00 UTC. The problem with this is the next month, it will renew on July 31st BST. You'd need to manually reset the billing cycle anchor in this case as well.

Overall this is a tricky scenario where there isn't a built-in solution for. You'd need to manually reset the billing cycle anchor if it's a hard requirement for the sub to always recur at the same date/time in your customer's native timezone.

If this really is a hard requirement, it might actually be easier to run your own Subscription logic for recurring payments on top of our PaymentIntents API or Invoicing API then mess around with the billing cycle anchor that frequently