devendra_api

[deft meteor]

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

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

[silk arrow]

https://dashboard.stripe.com/test/customers/cus_RvFVC5N04F9ny3/upcoming_invoice/sub_1R1P0FIE5Vvk0efGLZstVc7Z
this is the next invoice there item which start with Remaining time on and Unused time on I dont want to showing this.

[weak dune]

Hi there 👋 taking a closer look at the history of the Subscription.

Those lines are generated when prorations aren't disabled for a Subscription update request:
https://docs.stripe.com/api/subscriptions/update#update_subscription-proration_behavior
https://docs.stripe.com/billing/subscriptions/prorations

I see this Subscription is also being controlled by a Subscription Schedule

[silk arrow]

prorations i just use for charge.

{
"items": {
"0": {
"id": "si_RvFVKOLtrWXL0r",
"price_data": {
"currency": "GBP",
"product": "prod_MyCH7O83sYIl",
"recurring": {
"interval": "month"
},
"unit_amount": "5000"
},
"quantity": "2"
}
},
"proration_behavior": "always_invoice"
}

this is payload which i used for Subscription update

[weak dune]

Yup, I saw that, which created an Invoice that is now paid for. Since the Invoice is paid, that shouldn't be contributing to what's on the upcoming Invoice. So instead I'm looking at this request that was made to update the Subscription Schedule that is controlling this Subscription:
https://dashboard.stripe.com/test/logs/req_0MhrexfznEIV14

I do believe that update request to the Subscription Schedule is the problem. If you want to avoid creating prorations as part of that update request, can you try this flow again and pass none to the top-level proration_behavior parameter?
https://docs.stripe.com/api/subscription_schedules/update#update_subscription_schedule-proration_behavior
(not the ones nested inside of the phases array)

[silk arrow]

please explain me more

[weak dune]

Happy to, can you help me understand what you want me to elaborate on further?

[silk arrow]

If a subscription is active and I want to update all phases while charging for the changes, I need to ensure that the first phase (which is active) reflects the updated quantity. I also want to charge the customer immediately and prevent any invoice items from being marked as "remaining" or "unused" in the invoice.

[weak dune]

Gotcha, so then when updating the Subscription Schedule, since you're making changes to the current phase, you'll want to leverage the top-level proration_behavior parameter. That's the parameter that is used to indicate whether prorations should be created for the update you're making to the current phase, and in this case it sounds like you want to set that to always_invoice.

Those Invoice lines on the generated invoice will show our remaining and unused verbiage. If you want to charge the customer for these changes, and also avoid that verbiage, then you will need to disable our proration logic and instead build your own.

[silk arrow]

if I disable our proration then stripe don't take any charge when update Subscription.
I need to charge but i dont want showing item remaining and unsed like item in next invoice. its mean upcoming invoices.