#sreekanth_api

1 messages · Page 1 of 1 (latest)

wild vineBOT
pastel kernelBOT
#

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.

wild vineBOT
#

đź‘‹ 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/1245684233721348096

đź“ť Have more to share? Add more details, code, screenshots, videos, etc. below.

cedar viper
#

Hi

#

i dont understand how Proration applied... can you please check and explain

drifting harness
#

hi! did you have a more specific question?

cedar viper
#

Yes, I am not understanding how proration got applied to the above response

drifting harness
#

well what change did you make/what API call/code, what did you expect to happen?

cedar viper
#

Earlier, I was not aware of proration. After checking with your team, they advised me to go through some documentation. Is it possible to check what the earlier plan was before upgrading or downgrading?

drifting harness
#

it's possible but I think you would know this

#

you can look at the customer.subscription.updated event that's generated when you make the API call to update the subscription , the previous_attributes field describes the previous state.

cedar viper
#

If I turn off proration, it will not affect the ongoing plans, right? They will remain separate, correct?

wild vineBOT
drifting harness
#

not sure what you mean but you can create new subscriptions and test all this in test mode.

cedar viper
#

okay

#

Upgrade or downgrade actions are typically performed using the subscription ID, which identifies the specific subscription being modified ?

marsh ether
#

Exactly, yes. Upgrades/downgrades will only affect the sub_xxx ID you provide. And you set your proration preference on a per update level, as opposed to at the subscription level

cedar viper
#

Yes, but in my application, we don't have upgrade and downgrade functionality. How does proration get applied?

cedar viper
marsh ether
#

Well it's because you passed cancel_at on creation, which was a timestamp that predates the regular monthly billing cycle of the item(s). So we charge for a prorated amount to reflect that:

Scheduling a cancel date that’s before the billing period end updates the subscription’s current_period_end to match the cancel_at. This creates prorations for the change in current period unless your update disables them.
https://docs.stripe.com/billing/subscriptions/cancel#:~:text=Scheduling a cancel,update disables them.

Cancel subscriptions

Learn how to cancel existing subscriptions.

cedar viper
#

got it, Will updating cancel_at_period_end to true affect proration, considering the subscription will continue until the end of the current billing period before being canceled?

marsh ether
#

No, there'd be no proration if you set cancel_at_period_end instead of cancel_at

cedar viper
#

okay

cedar viper
marsh ether
#

Seems accurate yep

#

But the timestamps are to the second, and we prorate to the second

#

So you've set it to cancel at midnight, yet the anchor was not midnight. So we prorate for that time difference

#

You should just use cancel_at_period_end if you want to cancel after the first cycle (1 week)

cedar viper
#

that means, if I subscribed to a 3-week weekly subscription, I should schedule the cancellation for midnight at the end of the third week to avoid being charged for the next billing cycle ?

marsh ether
#

It means that your cancel_at timestamp should be equal to your billing_cycle_anchor timestamp, plus 3 weeks

#

So if billing_cycle_anchor is June 1st at 09:10.09, then cancel_at should be June 22nd at 09:10:09

cedar viper
#

okay, thanks

marsh ether
#

Should be easy enough to test the behaviour works as needed with a test clock

cedar viper
#

okay

#

any idea about this error: error: StripeInvalidRequestError: billing_cycle_anchor cannot be later than next natural billing date (1717142417) for plan ?

marsh ether
cedar viper
#

okay

marsh ether
#

Always share the req_xxx so we can see exactly what parameters you set