johan_unexpected

[lunar quail]

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1468530582056341750

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

[sand kiln]

This is the subscription id: sub_1SuGaaBUZvnZNCOX3M7uBYws

[tender solar]

Taking a look

[sand kiln]

They got billed the day they purchased the subscription 27th january, then a schedule was created to set a trial period in the future and they got charged again on the 2nd of february

thanks a lot for your help! let me know if you need more details

this is how we create schedules in our end

[tender solar]

OK, so:

• I see the initial invoice (in_1SuGaaBUZvnZNCOX8MrBlhAo) for £299
• You updated the sub here on 2026-01-28 to set a trial period ending 2026-03-02. That generated a new zero-amount invoice, in_1SuWkeBUZvnZNCOXI17Gxcfp
• On 2026-02-02 you created a schedule for the sub (here) and then a day later updated it (here)
• The update set the initial phase (phases[0]) to start on 2026-01-28 (backdated) and end on 2026-03-01. There was no trial set in that phase, so we created an invoice: in_1SwHuLBUZvnZNCOXU0XFw8ak

If your intention is to continue the trial, you need to set a trial period in the phase when you create/update the schedule

[sand kiln]

thanks a lot for the details. I can't access the links because im viewing connected accounts from the platform account. how do I see the logs at the connected account level?

for example this https://dashboard.stripe.com/acct_1Q5oNxBUZvnZNCOX/logs/req_YqyRGltqNILYhf redirects me to https://dashboard.stripe.com/acct_1CYhS4B45ZPr5ETA/dashboard

[tender solar]

You'd need to use the 'View as Dashboard' button when viewing the connected account in the platform

[sand kiln]

I understand. how do I do this in this case? I thought we were doing it when creating the schedule

[tender solar]

You can see the issue here in the .update payload. phases[0] is missing a trial (or trial_end): https://docs.stripe.com/api/subscription_schedules/update#update_subscription_schedule-phases-trial

[sand kiln]

we're actually creating it in the phase 2

[tender solar]

Right, but that's the issue that's causing the invoice from being generated for the first phase. You're telling us to backdate a phase and end it in March and to effectively charge the user the full amount

[sand kiln]

why phases[0] should have one set too? say for example we have a connected account which customer would like to set a trial period from Thursday untll Saturday. they create the schedule now and leave the subscription running normally (phases[0]) until Thursday. then on Thursday phases[1] will trigger and set the trial period until Saturday. Then on Saturday the subscription gets released and continue as normal

[tender solar]

If the sub is trialing now and you want to continue the trial when you create the schedule, then the initial phase (assuming it ends in the future) needs to also have a trial

I'd recommend testing it out

[sand kiln]

oh I see

so based on the details you shared above. the subscription was already trialing when the schedule was created to set the trial in the future?

this could be a edge case in our end

[tender solar]

Essentially when you create/attach a schedule to a sub, you should assume a 'blank slate' and that whatever you set in the phases of the schedule takes precedence. In this case, there's a new period that ends in March with no trial so we invoice

[tender solar]

Yes:

You updated the sub here on 2026-01-28 to set a trial period ending 2026-03-02. That generated a new zero-amount invoice, in_1SuWkeBUZvnZNCOXI17Gxcfp

[sand kiln]

so for my understanding the issue can be resolved if we just consider the trial_period currently rolling and add it to phases[0]?

[tender solar]

Yes, or just set phases[][trial]: true and it considers the whole phase a trial

e.g. the trial ends when the phase ends

[sand kiln]

I was thinking something like this to take whatever trial is currently running in the subscription?

[tender solar]

Yep, that should work too

But you might end up with an invoice still if trial_end !== end_date

[sand kiln]

if I do this it would treat all subscriptions as if they had trial set right? but just a small number of them are running a trial when the schedule is created.

[tender solar]

Yes you'd need to add some conditional check I guess

[sand kiln]

I understand. so your solution of phases[0][trial]: true is far better I just need to add a condition.

this might work for our case assuming trial: true will only be active during that phase

I'm saying here if trial_end exists in the current subscription, set phases[0] to be on trial

[tender solar]

Could there be a scenario where the current trial_end is greater/less than end_date? In effect there would be a mismatch

[sand kiln]

yes there could be

[tender solar]

Yeah I guess this is an application specific thing for you to figure out, but that's the root issue as to why there's a 2nd invoice for the same peripd

[sand kiln]

yeah unsure how to go ahead to be honest

what if I remove the trial period from the subscription just before creating the schedule so it would be a fresh start?

I assume it would create an invoice, is there any way to prevent this?

[tender solar]

By recommendation: use the existing trial_end date from the current phase and set it as both the end_date and trial_end dates in the new phase

(don't know what this freezeFrom timestamp is you have)

[tender solar]

Assuming there is a trial, obviously

[sand kiln]

so we have in the UI a date picker where the connected account selects a start and end date in the future that sets the trial period

[tender solar]

Which is in effect the same as:

end_date: schedule.phases[0].trial_end ?? moment(freezeFrom).unix(),
trial: !!schedule.phases[0].trial_end

I think

[sand kiln]

and when it's like this we don't create a schedule we just update the subscription and set the trial_end

so I think what's happening is a customer did this initially then they did it again with a freeze from date if you get me?

yeah I think that should resolve it

fantastic man thanks so much for your help. I appreciate you took all this time to go through this together with me. have a great day sir

[tender solar]

np. You too!

[sand kiln]

one last question sorry

for the next phase the start should be updated accordingly so?

I read in the docs they should start immediately after and they must be the same

you can see the new (updated) start_date in phases[1]

[tender solar]

You don't really need to set a start_date in subsequent phases. They'll automatically transition: https://docs.stripe.com/billing/subscriptions/subscription-schedules#phase-transition