#やまだ えしら

1 messages · Page 1 of 1 (latest)

rich apexBOT
buoyant flame
#

The timestamp for billing_cycle_anchor is in UTC. You'd need to convert local timestamp into UTC

graceful nebula
#

Thank you, but the problem still.
I'm not a native English speaker, so I'll write slowly. sorry.

buoyant flame
#

No problem! Take your time. Could you share the request ID (req_xxx) which you set the billing_cycle_anchor and what is the expected outcome?

graceful nebula
#

The problem occurred from the dashboard. I am trying to fix it using the API.

The problem that is happening is :
Create Subscription with Start 2023/02/25, billing_cycle_anchor 2023/03/01 (from Dashboard shortcut “next billing cycle start” “次の請求サイクルの初日” in Japanese)

I set 2023/03/01 00:00 in Dashboard, but it is JST time so it is set as 2023/02/28 15:00 UTC(Stripe Internal).
As a result, billing_cycle_anchor of the subscription is set as the 28th of every month.

To correct this, I was recommended to add a trial.
And update trial_end of Subscription through API, It worked, but the time the invoice is made is off by 9 hours(JTS is +9, so that’s why)

I want to fix the wrong billing_cycle_anchor, but want the time the invoice is made to be 0:00.
what should i do?

buoyant flame
#

For the next billing cycle, do you intend to be 2023/03/01 00:00 JST or 2023/03/01 00:00 UTC?

graceful nebula
#

2023/03/01 00:00 JST! 👍

buoyant flame
#

I set 2023/03/01 00:00 in Dashboard, but it is JST time so it is set as 2023/02/28 15:00 UTC(Stripe Internal).
As a result, billing_cycle_anchor of the subscription is set as the 28th of every month.
Do you have a subscription ID to share for this scenario? This seems to be correct as 2023/02/28 15:00 UTC is equivalent to 2023/03/01 00:00 JST

graceful nebula
#

sub_1MewUEJrgt3ZD9jfJLQI3BV2

#

This seems to be correct as 2023/02/28 15:00 UTC is equivalent to 2023/03/01 00:00 JST

Yes, it's right.
But, set trial_end to correct billing_cycle_anchor as 2023/03/01 00:00 JST, The billing_cycle_anchor is internally interpreted as 2/28 and the billing cycle cannot be corrected.

buoyant flame
#

From the next upcoming invoice, I can see that it will be billed on 2023/03/01 JST

image.png
#

billing_cycle_anchor is in UTC. You can convert to JST for your reference

#

billing_cycle_anchor is internally interpreted as 2/28
billing_cycle_anchor is interpreted as 2/28 UTC (not JST) for Stripe system to meet JST timezone. You'd need to convert it to JST so that it will align with 3/1 when reading it at your end

graceful nebula
#

From the next upcoming invoice, I can see that it will be billed on 2023/03/01 JST
Yes. By adding trial_end padding, billing date is corrected. But, the invoice is created off 9 hours(2023 03/01 09:00 JST)

buoyant flame
#

This is expected since you set the trial end to 2023-03-01 09:00:00 JST

#

If you wish to end the trial on 2023-03-01 00:00:00 JST, you should set it to 2023-02-28 15:00:00 UTC instead

graceful nebula
#

Yes, so I want to set trial_end as 2023-03-01 00:00:00 JST = 2023-02-28 15:00:00 UTC . But, Stripe interprets the 28th as the anchor, so the 28th of each month becomes the billing_cycle_anchor.

Therefore, setting 2023-03-01 00:00:00 JST = 2023-02-28 15:00:00 UTC would result in the next invoice being 3/1~3/29.

#

Maybe this is the problem; I want to fix JST 2023/03/01 00:00 as anchor using trial, but I can't specify that day as anchor because there is a one day discrepancy when it is interpreted as UTC.

buoyant flame
#

But, Stripe interprets the 28th as the anchor, so the 28th of each month becomes the billing_cycle_anchor.
Could you share a subscription ID (sub_xxx) where you see such as case? When I tested, the billing_cycle_anchor is 28th UTC, but 1st in JST (which is what you're looking for)

graceful nebula
#

Ok, I'm creating the case! 👍

#

Done, sub_1MfxbEJrgt3ZD9jfCfZ3zw0c

Steps I did:

  1. create Subscription, start now(2023/02/27 12:42 JST) billing_start next cycle start (2023/03/01 00:00 JST)
  2. check next invoice, it's 2023/03/01~2023/03/29(THE PROBLEM i want solve)
  3. through API, update the subscription, trial_end 2023/03/01 00:00 JST
  4. trial is applied, but next invoice won't change
buoyant flame
#

Oh! I finally see where your problem comes from

#

It's the end date of the next billing cycle

#

I was looking at the start date of next billing cycle only

#

Let me check if there's any workaround

graceful nebula
#

Ok! Thank you!

buoyant flame
#

After checking, this is the known limitation that the billing_cycle_anchor or trial_end to be set in the timezone that is ahead of UTC, specifically to +9 for JST in your case.

In order for the billing_cycle_anchor and trial_end to work on 1st properly, it has to be 1st of month in UTC (not local timezone). However, this means that there will be +9 time shift for JST. I'm afraid that it's not possible to have subscription anchor at 1st of month 00:00 JST. It can only be 09:00 JST in order to anchor on the 1st of the month.

graceful nebula
#

Ok! As I thought.
I will be changing our billing hours or days policy.

Thanks a lot.