#kerneldeimos_api
warm flickerBOT
đ 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/1303206825822519309
đ 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.
- kerneldeimos_api, 7 hours ago, 11 messages
kindred needle
I think as I was typing this I figured it out partly - if the user "upgraded" for 3 weeks and "downgraded" before the next billing cycle, their next invoice will reflect that accordingly (i.e. they'll pay for 3 weeks of upgraded service).
That's all well and good, but now there's a strange inconsistency - a user now has two different ways to subscribe to a higher tier. They can just subscribe to it, or they can subscribe to a lower tier and then upgrade as a way of deferring a portion of the cost for a month.
broken trail
hello! we're looking into this, give us a while
warm flickerBOT
umbral iris
Hi @kindred needle Can you tell me what you want to achieve? do you want to charge the customer immeidately when upgrading the subscription?
kindred needle
Hi <@220633325688061953> Can you tell me what you want to achieve? do you want t...
Yes - if not, why charge the user immediately when they create one?
Ideally they'd be charged the difference (upgraded plan minus old plan multiplied by how much of the billing cycle is left) up front upon upgrading
umbral iris
Sure, you can achieve by seting proration_behavior to always_invoice. https://docs.stripe.com/billing/subscriptions/upgrade-downgrade#immediate-payment
kindred needle
Thanks!
Can I set this through the dashboard or do I need to set the variable on individual subscriptions?
umbral iris
Using a test clock is the best way to test a billing integration https://docs.stripe.com/billing/testing/test-clocks
kindred needle
That sounds like the answer to a different question
umbral iris
You can update the susbcription through Dashboard or API, but I'd highly recommend you using the test clock to simulate time advancement.
kindred needle
only individual subscriptions then?
umbral iris
I don't quite follow you, maybe you want to add more context?
kindred needle
The linked document says to set proration_behavior. It doesn't say on what object to set it or if it's possible to configure this globablly for all subscriptions from the dashboard. The document talks about parameters you can set on items, subscriptions, and prices, so the fact that this isn't specified for proration_behavior is a little confusing.
umbral iris
https://docs.stripe.com/api/subscriptions/update?lang=curl#update_subscription-proration_behavior yes it's on the subscription object.
kindred needle
Should I set this to always_invoice on every update, or just the initial creation? (i.e. is this a persistent or transient property of Subscription?) If I set it to always_invoice on an update to a subscription (where previously it had not been set), will it take effect for the same update if that update also changes the amount?
umbral iris
You should set proration_behavior to always_invoice whenever you want the subscription update to generate an invoice immediately.
kindred needle
You should set proration_behavior to always_invoice whenever you want the subscription update to generate an invoice immediately.
This brings to mind an issue I take with language, generally speaking. "whenever" in this statement could mean at the time of update, or that I set it on creation whenever this is the behavior I want for the subscription. i.e. this statement can be interpreted two different ways to mean each of the two answers to my question.
umbral iris
Let me be clear, in your use case, you set should proration_behavior to always_invoice when you update the subscription.
You can also set proration_behavior when creating a subscription, but that's for another use case (i.e., backdating https://docs.stripe.com/billing/subscriptions/backdating#backdating-no-charge)
kindred needle
So it's transient? That should be written in the description of that property on the Subscription object - I would have assumed the opposite because most other properties are persistent and this isn't specified.