#thomasst

1 messages · Page 1 of 1 (latest)

digital pierBOT
limpid light
#

Hi there! Taking a look

vernal dome
#

Thanks

limpid light
#

Hm, I think the trial might have something to do with it here. the subscription was created with a trial_end value that is 30 seconds after the period start

vernal dome
#

It is true that the trial is 30 seconds, but why would subscription.current_period_start - subscription.trial_end be another 30 seconds?

limpid light
#

not sure i follow what you mean by "another 30 seconds". subscription.current_period_start matches the time on the test clock you're using, and subscription.trial_end matches the trial_end value that was passed when creating the subscription

vernal dome
#

Why is the test closk time relevant? As in, why doesn't subscription.current_period_start start immediately when the trial ends?

#

Actually the main question is still why the schedule phase is off by 30 seconods

limpid light
#

okay, let me take a step back. the current period matches up with invoices. once a subscription period ends, a new invoice will be generated. since this subscription was created with a trial, the current_period refers to the trial period, which is 30 seconds. this means the trial end and current_period_end should match

#

the test clock is relevant because the schedule was created once the clock had been advanced past the trial end time

#

at the time the schedule was created, the subscription's current period corresponded to the period after the trial had ended. does that make sense?

vernal dome
#

So the test clock was advanced 30s past the trial time and then we created the schedule in req_ftZ07N7LFd4X0e.

#

At that point the schedule phase and subscription period did not match anymore.

#

In that request, I changed to an annual price and posted the trial end date as the phase start.

#

As a result, the phase is now 1 year backdated from the trial end. Is that expected?

#

Shouldn't the request have failed?

limpid light
#

the test clock was advanced to the exact time the trial ended. request req_ftZ07N7LFd4X0e updated the schedule but didn't create it.

#

the phase is now 1 year backdated from the trial end.
i don't follow what this means. the phase started right at the trial end, and the current period start/end is as expected

vernal dome
#

At the point of req_ftZ07N7LFd4X0e the test clock was 1671147413 according to what I'm seeing, no?

#

The trial ended at 1671147383, so 30s earlier.

#

The test clock was never advanced to the exact time the trial ended.

#

Actually it was, but then it was advanced again

limpid light
#

ah, i see. that's correct, the test clock had already been advanced past the trial end at the point of req_ftZ07N7LFd4X0e. that said, this was not the request that created the schedule

vernal dome
#

Okay, so the schedule was updated 30 seconds past the trial to change the product. At that point the phase end time and subscription end time also got off by 30 seconds.

#

Does the phase end time default to one billing interval?

limpid light
vernal dome
#

And the schedule phase is not expected to be adjusted when the subscription period is updated?

#

that said, this was not the request that created the schedule
The schedule was also created 30 seconds past trial time though.

vernal dome
#

In my opinion that request req_ftZ07N7LFd4X0e should have failed since I'm modifying a phase that started in the past, and ask me to create a new phase. What do you think?

limpid light
#

Just putting together the timeline to be sure

limpid light
#

So, the ultimate question is why the start date of shcedule sub_sched_1MAMIcBSqAkKUXpQQhSNyC4S is 30 seconds after current_phase.start_date, correct?

vernal dome
#

So I think I understand what is happening now. Can you confirm these 2 points are true:

  1. The subscription schedule operates on phases independent from the subscription phases. So when I create a schedule the current period is inherited from the subscription period, but after that it operates independently. That means when I want to apply a change to a subscription that should go for 1 billing interval starting now, I should cut a new phase with start_date=now rather than modify the current_phase.
  2. When modifying products/prices in the schedule's current phase, Stripe will by default assume interval=1 (if no interval or end date is given) and set the end of the current phase to one interval from the original phase start date. The changes are applied to the subscription immediately, which changes its billing period but does not affect the schedule's phase.
warped pecan
#

Hi @vernal dome I'm taking over, give me a min to catch up.

vernal dome
#

Thanks, I think you can just read the last message.

warped pecan
#

About 1), you mention about start_date, so I guess you are still updating the subscription schedule instead of updating the subscription directly, am I right?
2) can you share with me a request ID where you see such behaviour?

vernal dome
#
  1. correct
#
  1. req_ftZ07N7LFd4X0e
warped pecan
#

Are you talking about the recurring interval_count? it's already set in the price and you don't need to specify it when updating a schedule.

vernal dome
#

yep

#

I know

#

I'm just trying to understand how subscription periods vs schedule phases work.

warped pecan
#

And for 1, if you want the new phase to start after the current phase, you can set the start_date to the end_date of the current phase, and you shouldn't modify the current phase.

vernal dome
#

That's if I want to make the change at the end of the current billing period.

#

But I found that Stripe's API lets you modify the price/product on the current phase, in which case the change gets applied immediately to the subscription but the current phase's start date stays the same.

#

In this case a new subscription period starts (from now until the next billing period), but the schedule phase start date remains the same (what it was originally), and the schedule phase end date is set to one billing interval from the phase's start date.

#

I just wanted to confirm that this is how it's designed to work.

#

I would have expected the schedule API to reject such a request, but this is the behavior I've observed.

warped pecan
#

The phase's start_date and end_date don't necessarily need to follow the subscription's billing cycle, you can modify the current phase with new prices and it give your more flexibility should your business needs to handle such scenario.