#hanners_best-practices

1 messages ยท Page 1 of 1 (latest)

lucid craterBOT
#

๐Ÿ‘‹ 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/1358682464486166531

๐Ÿ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

ebon gorge
#

yo

mystic loom
#

Hello

languid rose
#

However, if customer upgrades the plan midway, Stripe calculates the price based on the new price, instead of the old one
Hi, could you elaborate a bit more here? With some example numbers?

mystic loom
#

Okay, here is a scenario (ignoring proration): (1) User purchase a pro plan at $96. (2) We update the subscription via API with new price at ($150). (3) User upgrades to a premium plan at $300 before end of billing cycle. User needs to pay $300 - $150 = $150 (calculated by Stripe). But ideally, it should be $300 - $96 = $204.

languid rose
#

Um that should be expected, since you already updated the Subscription to $150 and any further change should be based on the "current" pricing = $150

#

Or am I misunderstanding?

mystic loom
#

You got it right :). I understand we can use subscription schedules to change to new price only in the next billing cycle, and if user does upgrade to the premium, the price will still be based on current price, but after that, we need to release the schedule.

#

But that will introduce another problem: if we (1) schedule new price P2 for next billing cyce, (2) user decides to downgrade the plan (3) we create a schedule to downgrade the plan at the next billing cycle. But since we can only create one schedule at a time, we have to delete the new price change schedule first.

#

Is there some way easier way around it, or we have to manage the conflicting schedule (new price change -> downgrade), and if user cancels the downgrade, to restore the original schedule (downgrade -> new price change)? Not sure if my explanation was clear ๐Ÿ™‚

languid rose
#

I kinda getting what you say, but on:

(1) schedule new price P2 for next billing cyce, (2) user decides to downgrade the plan (3) we create a schedule to downgrade the plan at the next billing cycle
On (3) do you still want to upgrade to P2 then downgrade? Or do you want to downgrade straight away? It's totally up to you.

Subscription Schedule is a "future" plan and you can freely override it to behave as what you like. If user then want to cancel the downgrade, you would want to override the future again, revoking the last downgrading step.

And yes, this is how you will need to manage the schedule

mystic loom
#

Say, we schedule new price P2 for future. When (3) user downgrades, we don't really care about the upgrade to P2 anymore because we're going in the opposite direction. And we want downgrade to happen for next billing cycle as well.

languid rose
#

Yeah so override it

mystic loom
#

Override it, means simply deleting the phase, and changing it right?

languid rose
#

Yes. Each time you call Subscription Schedule, you can change anything other than the current and past phase

mystic loom
#

I see. So, if the current phase is ongoing, I need to keep it there?

languid rose
#

Yeah (You can test all this in Test mode)

mystic loom
#

I think you have a pretty good understanding of the use case. So, between (1) updating the subscription and (2) schedule, (2) is definitely the way to go right?

languid rose
#

Yes!