#DeliveryTiem
fast lion
noble peak
Does it cause 2 net new Invoices to be created? Or do you mean that it finalizes the current draft Invoice and creates a second Invoice on top of that?
serene marsh
It creates 2 draft invoices then both are charged.
Subscription in question is sub_1MUDAiIUwLvVicLYszn5qE1n
You'll notice that two invoices were made on Feb 15th 8:23
When the $713.17 was a draft, we got a request to update the subscription to $848.17, was expecting the $848.17 to be charged on 15th March but it got charged on 15th Feb and 15th March
So invoices should be 0.00 (trial) on 15th Jan, 713.17 (original subscription amount) on 15th Feb, then $848.17 on 15th Mar
noble peak
Can you give a step by step (numbered or bullet points preferably) guide to what you want your Subscription to do? In addition to that, can you also give a step by step guide for what you believe it is currently doing? Please include API calls with Request IDs.
Here's how you can find a request ID: https://support.stripe.com/questions/finding-the-id-for-an-api-request
serene marsh
I want my subscription to have 10 instalments, each instalment happens every month.
The first instalment is a trial.
The rest of the instalments are paid for and they charge $713.17.
Currently, the trial instalment has ended and the second instalment of $713.17 has an invoice drafted.
The customer changes their plan to $848.71 while the second instalment of $713.17 has an invoice drafted.
What I want the subscription to do?
I want to keep the $713.17 invoice draft for the second instalment and charge it. Instalments 3 to 10 should charge $848.71.
What I believe is happening?
An invoice for $848.71 is instantly created. There are now 2 invoices ($713.17 and $848.71) created and charged for the second instalment.
Requests
Schedule creation, a 10 instalment schedule with 2 phases ( 1 instalment trial, 9 payable instalments ) with a plan of $713.17: req_YAcWoAptUE8GMX
Schedule update (change phase from using $713.17 plan to $848.71 plan): req_mMuC6AXA3AGO0G
vernal tiger
👋
Catching up
Yep okay
So on your update you want to instead have 2 phases
You want to have phase 0 be the current phase (the rest of the month for $713.17)
Then phase 1 will be 8 iterations on $848.71
And that starts at the next month
serene marsh
Okay I take that point, let me throw this scenario at you: The exact scenario but the customer changes their plan on the third instalment instead of the second... when I test it with that case there is no instant $848.71. The only difference is that the update is being done on the current phase's second instalment instead of the first. Not sure why a change of instalment number would change the behaviour.
vernal tiger
Hmm do you have a request ID i can look at for that?
serene marsh
Yep I do
Schedule creation, a 10 instalment schedule with 2 phases ( 1 instalment trial, 9 payable instalments ) with a plan of $713.17: req_7HbkWd7TOUpZ9g
Schedule update (change phase from using $713.17 plan to $848.71 plan): req_TK2sG3MnxGAiRx
vernal tiger
Hmm actually now that I think about it you may not even need to do what I stated above. Try this for me: try setting proration_behavior: none at the phase level (https://stripe.com/docs/api/subscription_schedules/update#update_subscription_schedule-phases-proration_behavior) and at the top level.
vernal tiger
I believe the difference here in your examples is that one is considering it to be a change in phase and assessing proration behavior that way and the other is a change "within the phase" which relies on the other proration param
serene marsh
Testing now
Didn't work, creation request id: req_ayjsilvWpVUDjI, update request id: req_SNEPombfVyDpZ9
serene marsh
Gonna try testing it with all phases marked with proration behaviour 'none' on both create & update, on all phases.
vernal tiger
Sounds good, let me know
serene marsh
Nah it didn't work, creation id: req_65v5hdZYVQ02Qw, update id: req_CNxQzb0drVngeF
vernal tiger
Ah you are resetting the billing_cycle_anchor
When you do that a new invoice will be automatically generated
Remove that and just let that be automatic
So that the period keeps the same billing anchor
serene marsh
Not intentionally resetting, more-so telling the update to keep the same billing cycle anchor as before. So on creation it's 'phase_start' so on update I wanted to make sure it stays the same, so added 'phase_start' again
Trying it without it
vernal tiger
Yeah when you update and set phase_start again it says "set it to the beginning of this new phase that I just passed in"
It doesn't "remember" the old phase when you update
serene marsh
This is looking like the culprit, running it through some unit tests (test clocks taking some time as expected)
vernal tiger
👍