#alexelba
tender duneBOT
Hello alexelba, we'll be with you shortly! 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.
• alexelba, 30 minutes ago, 26 messages
• alexelba, 9 hours ago, 17 messages
• alexelba, 23 hours ago, 11 messages
• alexelba, 1 day ago, 3 messages
• alexelba, 1 day ago, 5 messages
• alexelba, 1 day ago, 31 messages
and 1 more
native nest
or what is correct way to do so?
2nd case, if someone upgraded to 1 to 100, and reduce to 20, and upgrade 30 until next period start I don't want to second time charge them for extra 10
because they technically paid when upgraded to 100
👋 happy to help
true plinth
thanks
native nest
for the stripe subscription, if I want to reduce the count of product, but I want to take effect end of billing cycle should I set proration_behavior to none?
yes this is one way of achieving it
true plinth
should I do it before updating the items
or after I can after update is done and call update on subscription
native nest
I think in your case a subscription schedule might be a better solution
true plinth
how would be a good way, to make sure I don't double charge the client
native nest
as I said I think it's probably best to use subscription schedules
this way you would always update on the next cycle instead of updating immediately
true plinth
what will happen if count upgrade happen and there is active SubscriptionSchedule for end of period to downgrade
will it automatically calculate detla?
native nest
it really depends on how you want to handle the different upgrade/downgrade
you can simply limit the number of upgrade/downgrade during one phase
you can decide to charge directly with prorations
and change the billing cycle
true plinth
I want to do way I originally posted in main chat
native nest
you can decide to only apply on the next phase the change
you didn't really explain what the user should be paying and when
and when the quantities should apply
true plinth
Lets say 1 -> 100 get downgraded to 20 , got upgraded to 30
end of month I want to downgraded to 30
end of month = end of billing period
native nest
1 -> 100 do you mean you did an upgrade from one quantity to 100
true plinth
User sign up count 1, they upgrade to 100 happens immediately and client get charged prorated fee, before billing period end they change the count to 20 (this will happen end of billing period), and after upgrade to 30 before end of billing period
so they technically already paid for this extra 10 until end of billing period
native nest
when the customer downgrades to 20 you don't want this to start until next billing cycle right?
true plinth
yup
native nest
I think it's really simple, if the quantity is > than the current quantity you immediately pay, otherwise you only apply the change on the next phase
native nest
the 30 comes in the first billing cycle?
true plinth
all during the same period
native nest
then you apply the change on the next billing phase,
so you update the subscription schedule
and instead of having the next phase be 20, it will be 30
true plinth
what I understand based on this chat, I should always check before upgrade if there is active subscription schedule
native nest
I think you should shift all your integration to subscription schedules instead of simple subscriptions
true plinth
how would that work?
true plinth
if there are two schedules one says now other says 30 days
I will still need to check 30 days schedule to change count
native nest
it's the same schedule, but you create multiple phases
true plinth
is there easy way to convert subscription object to subscription-schedules or I need to copy manually all items