#dick-flair_best-practices

1 messages ยท Page 1 of 1 (latest)

faint crestBOT
#

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

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

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

lofty bay
#

Hi sorry, let me properly type out my question

fluid oreBOT
lofty bay
#

I am currently trying out different permutations of my process to downgrade a subscription. I am utilise the subscription schedule to schedule an update to downgrade it, i.e. decreasing the quantity. I am coming across a bit of an issue and not sure how to handle this in best practice.

A problem I was having initially was that I created a subscription that was for November 13 to December 13 and linked this up with my customer on my web portal. I then initiated a downgrade on the 12th of December (today) to decrease the seats but this was applying the schedule to the end of the next billing cycle of December 13 to January 13 2025 rather than what I expected that it would apply the schedule for December 13 since I am still in the current phase. I made changes to my code to fix this but I am now coming across a different issue, so the above works now, and I fast forward the clock to December 14, and the changes get applied, etc. So I am now in the next cycle at this point of December 14 - January 14. I then initiate a downgrade to decrease the seats again, which gets set to the correct date of January 14. However, this is all prorating in that it's showing up as Remaing time, unused time, etc in the next invoice when I am just expecting it to be the product with the new decreased qty + vat.

So I have these event log IDS:
evt_1QVIvzDvmqvcAnANCg78CWcr

The above is when I did my first downgrade and this is the following downgrade:
evt_1QVIwoDvmqvcAnANC0y1BeVo

Sorry, the dates in my example might not line up with the event log data but I think it's mostly the phases in those event logs I need to check what the best practice is

#

Let me know if anything is unclear, might be a little confusing example

#

This is the subscription:
sub_1QVIvcDvmqvcAnANOuDDDZor

muted shell
#

Thank you for the clarification. I'm working on stepping through those events and related objects, but I'm not sure I'm clear on what your question is. Are you trying to disable prorations?

lofty bay
#

Sorry, got a bit caught up in typing all of that! But I guess my question is what the best practice is for my use case in terms of handling the phases when creating/updating a subscription schedule. When I initiate a downgrade, I take all of the current phase items in a schedule, and add an additional one for the actual downgrade phase. Ideally it shouldn't be prorating any items because the downgrade doesn't get applied until the next cycle

muted shell
#

It's hard to recommend changes for your flow without having a good understanding of which part of the behavior you're seeing currently that isn't desired, and know what you would like to happen instead.

Like if you want to do the downgrade in the next phase, and your Subscription Schedule already has more than one phase, then creating a new phase may not be necessary. However, if you want to schedule an additional downgrade after any currently scheduled changes, then creating a new phase does sound like the right approach.

#

It is a bit tricky to line up the scenario you laid out with the referenced objects, since the dates don't align between the two.

#

Oh I see, you backdated the start of the Subscription.

#

I think the reason that you're still seeing prorations, even though proration_behavior is set to none, is because tax_rates keeps getting changed with each update of the Subscription Schedule.

Like you add a Tax Rate to the second phase supplied here:
https://dashboard.stripe.com/test/logs/req_hPDJgNfqxARHWT
but didn't persist the Tax Rate that was included on the Subscription originally.

#

Phases are very finicky with Subscription Schedules, and a lot of the fields within them will be unset if you don't provide them in the Subscription Schedule update request. Even if you don't want to change their value, populated fields within a phase should be provided again in the update request.

#

That seems to be the key difference when seeing how the dashboard displays the preview of the next Invoice, is that the remaining time doesn't have a tax amount but the unused time does.

lofty bay
#

Yep, finding out now how finicky it is! ๐Ÿ˜† I can't quite find the event log now but I was having a problem before where I was re-setting the tax rate from the current phase but that might have been something to do with it not being the right format

#

I'll do some more investigation on the tax rates for this, it could be that that's the issue in all of this. I guess in a way, this is quite an edge case (at least in our situation) in that, it's probably quite unlikely someone will initiate a downgrade once they've been hooked up on our system and stripe, and this is if it's someone being ported from our previous system to stripe is mid way through their active subscription

#

But OK. I'll go with this for now and maybe I'll find the issue. I appreciate the help !