#geordi-product-migration
stuck solar
Just edited the message if that helps clarify
violet adder
It really depends. You just said you want to grandfather people. If you do that, they stay on the old price
stuck solar
To be clear:
- As long as the billing period does not change the price can be changed on a customers subscription, they will not be charged until the next billing date and that would reflect the new price
stuck solar
It really depends. You just said you want to grandfather people. If you do that,...
Ideally not - it was just an option on the table 🙂
Ideal situation is we update ALL customers on a specific plan (say, basic) to a new, higher price without interrupting their current subscription billing period, or charge them on the date of the change
violet adder
cool so the better way is to use the SubscriptionSchedules API to control the change at the next phase: https://stripe.com/docs/billing/subscriptions/subscription-schedules it allows you to let them on the current Price for the current phase and turn them into the new Price at the next cycle
It's a bit of a more advanced API, so the alternative approach is to change the Price now but disable any proration with proration_behavior: 'none' so that we don't charge them the difference and on the next cycle they get charged the right amount
stuck solar
Okay that's interesting. I'll take a look through that.
My assumption was that if we removed the current price (9.99usd) from the product, created a new price (12.99) keeping the same lookup_key & billing_cycle it would just charge the new price on the renewal date?
Or is it necessary to to the automation of this through the API?
violet adder
you can't "remove a price from a product", that's just not possible. You can mark it inactive, that's it.
And we never change the price on an existing subscription, you have to do the work to "migrate" each subscription to the new price
As for the lookup_key it really depends on your integration overall. If your code relies on lookup_key to find the correct active Price, then yes it would just work
stuck solar
Ahhh yes, archiving especially if there are existing subscriptions tied to it
Okay sorry for the Q's and unclarity but:
- We would use the Subscription Schedules API to upgrade a subscription to the new Price
Do you have an example of what that might look like moving a annual plan or monthly plan?
I'm a little confused as how you map the start and end date when creating a schedule
For example
Stripe::SubscriptionSchedule.create({
customer: 'cus_L7BweK4mO4T6os',
start_date: 1644945898,
end_behavior: 'release',
phases: [
{
items: [
{
price: 'price_1KKPssLLAsLlRiDeC90zYhKO',
},
],
iterations: 12,
},
],
})
In this example I assume:
- end_behaviour will continue the subscription on the new price after the phase is done
- the phases price is the new higher price we want to move to
- iterations equalling 12 is for a monthly billing cycle, and would be 1 for an annual plan?
Where does this start_date come from? the period_end of the current subscription?
violet adder
yeah sorry you've lost me overall
stuck solar
hahahaha
violet adder
like you example has only one phase, that runs 12 times, this is not a Price change at all