#jayamini_code

1 messages ¡ Page 1 of 1 (latest)

vale wedgeBOT
#

👋 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/1324281710606815284

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

radiant dove
#

Our goal is to ensure that both existing and future subscriptions align perfectly with the external coupon system's fixed 30-day and 365-day expiration cycles, without causing billing disruptions, incorrect current_period_end values, or unexpected webhook behavior.

When updating an existing subscription's price ID to one with a different interval (30 days or 365 days), will Stripe adjust the current_period_end correctly? If the interval change shortens or lengthens the billing period, will there be proration charges or credits?
Also Is there a better way to handle this issue than the way we have planned?

#

Thanks in advance for your help

sturdy matrix
#

hello! gimme a while to think about this!

#

When updating an existing subscription's price ID to one with a different interval (30 days or 365 days), will Stripe adjust the current_period_end correctly?

Maybe can you illustrate this with an example of what is "correct"?

If the interval change shortens or lengthens the billing period, will there be proration charges or credits?

yes, there may be proration charges or credits. In case you haven't seen this yet, you can use test clocks to mimic the passing of time : https://stripe.com/docs/billing/testing/test-clocks

Test your integration with test clocks

Learn how to move Billing objects through time in test mode.

radiant dove
#

will check the scenario with test clock

vale wedgeBOT
radiant dove
#

subscription ID: sub_1QbxsGKk6Qk5jHuWiCtEbYQ5
I've tested this subscription by updating price to a new price with interval: day, interval_count: 30 (new price id: price_1QcjhKKk6Qk5jHuWdXOvmzee)
user was charged with proration
Invoice Id: in_1QcjwbKk6Qk5jHuWAWYJaEU1

fresh quarry
#

Hey! Taking over for my colleague. Let me catch up.

#

If you don't want to have proration, you'll need to set proration: none

radiant dove
#

actually proration won't be an issue, what we want is to migrate current monthly and yearly active subscriptions to plans with 30days and 365 days plans.
But we want this changed from their previous subscription start date (current_period_start) to the end date set from the new 30days plan. instead of creating a new plan starting from today.
would this be possible to achieve?
we don't won't to confuse users with a new charge with the plan change.

fresh quarry