#cjobeili
pastel talon
I don't think you need a schedule for this
In the downgrade scenario, when you make the update call you can disable prorations with proration_behavior=none
This will downgrade the plan without prorations, then the next renewal would be at the lower price
Is there some other reason you want to use a subscriptionschedule? Or is it only because of this end result you're trying to achieve?
worn ivy
I was thinking i will need this because i want to start the next plan (the one with the lower price) AFTER the current billing period of the current price.
If a customer take a 1 year account, i don't want him to be able to go back to the lower account right away . He pays the year directly and after the year, the switch happens
pastel talon
ok, if you want the actual saved price to be the pro one until end of cycle, you need the schedule for that
but if its just the invocied amounts you care about, you dont need to defer the change
worn ivy
I dont want him to change right away yes 🙂
pastel talon
Ok, then sure, you can use a schedule
What part of that is not working for you, then?
worn ivy
So, i dont want to pro rate any change but when a create the schedule there is a proration applied. I tried to update the subscription before creating the schedule with Subscription::update($stripeSubscription->id, ['proration_behavior' => 'none']); but in the UI i still see the toggle ON for proration
the subscription has been created with the default parameter (aka create_prorations)
pastel talon
creating a schedule using from_subscription shouldnt be making any changes to the subscription
You'd create the schedule then update it to add future phases
It's worth clarifying that proration_behavior is not sticky
It applies only to the change you're making to the subscription at that moment
Every update to a subscription creates prorations by default unless you specify disabling it as part of that change
that is, it is not a setting on the subscription, it's a modifier for a specific change (an update request, a phase change in a schedule, a cancellation, etc)
worn ivy
Okai so if i do :
$schedule = SubscriptionSchedule::create(['from_subscription' => $stripeSubscription->id]);
SubscriptionSchedule::update($schedule->id, [
'proration_behavior' => 'none',
'phases' => [
[
'items' => [
[
'price' => $stripeSubscription->items->data[0]->price->id,
'quantity' => 1,
],
],
'proration_behavior' => 'none',
'start_date' => $stripeSubscription->current_period_start,
'end_date' => $stripeSubscription->current_period_end,
],
[
'start_date' => $stripeSubscription->current_period_end,
'items' => [
['price' => $price->id, 'quantity' => 1],
],
'iterations' => 1,
'proration_behavior' => 'none'
],
]
]);
I should see an full invoice for pro plan and next a full invoice for Basic ?
teal gladeBOT
pastel talon
So for the schedule update, a couple things:
1/ you likely want to reflect the items and start_date from the auto-created first phase of the schedule (ie, inspect $schedule instead of $stripeSubscription)
2/ you don't specify the first phase end date and the new phase start date, only one is needed, and I'd suggest the new phase start date
But otherwise wise yes that looks right, your customer would remain on the current price until the end of the current period then move to the new price
Since the phase transition should happen at the cycle renewal i would expect no prorations anyways, but its fine to specify none
I'd recommend you test this with Test Clocks to ensure you get the behaviour you're seeking
worn ivy
yes i'm using test clocks.
Now i'm getting this (since i removed end_date) on phase 0
Phase 0 is invalid. Each phase must specify either iterations (recommended) or end_date (advanced), unless it is the last phase and end_behavior is release.
pastel talon
Ah, did i get that wrong?
My bad -- start date is required only on the first phase
Use the end_date like you had
(which will implicitly define the start date of the second phase)
worn ivy
Okai will test this
Ok it's seems like it work, i will re-try the test case one more time to confirmed it
Okai : sub_1NxycpDZIolCYxkRA6Y2o7xv here is the subscription . it seems OK.
it just seems i've lost taxes
pliant mesa
Hi 👋
I'm stepping in as @pastel talon has to go.
What do you mean you've "lost taxes"?
Oh wait, I think I see
You had a tax rate txr_1NleTmDZIolCYxkR2VLaSW0x specified in the original Subscription and it was in the initial phase when you converted it to a Schedule
worn ivy
'dynamic_tax_rates' => [$this->stripeTaxId]
i need to set this in the items on the schedule
i think
worn ivy
Okai will try it, i don't know what you did but it seems to work.
The only thing i really change is use the "schedule" instead of subscription in the update
pliant mesa
In case it helps, when I am adding phases to a Subscription Schedule with an update API call, I usually copy the existing array of phases and append a new phase to it.
worn ivy
So you don't loose anything right ?
pliant mesa
Because the phases array you pass in overwrites the entire set of phases currently on the schedule
So you don't loose anything right ?
Yup! That way the current phase is completely unchanged.
Honestly I was just lazy and didn't want to type that stuff all over again 😅
worn ivy
haha 😄 Lazy is good
i still don't know why i was getting proration and now its working fine
pliant mesa
Well the way the phases work the changes are occurring right on the billing cycle so they don't generate prorations
worn ivy
Okai but i was using phases too before calling for help . What change fix this?
pliant mesa
That I don't know 😅
But I'm happy to hear it's working now 🎉
worn ivy
yes thank you ! will try to fix everything tonight ! thanks again for the help