#nukesforbreakfast_api
ruby girderBOT
👋 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/1423110864571076644
📝 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.
- nukesforbreakfast_sub-schedule-prorations, 45 minutes ago, 37 messages
- nukesforbreakfast_docs, 6 hours ago, 8 messages
- nukesforbreakfast_best-practices, 6 days ago, 12 messages
sand tiger
hello! gimme a while to go through your question 👀
sacred mango
This was the previous thread before I had to step away for a bit: https://discord.com/channels/841573134531821608/1423081458393677914
sand tiger
hmmm, so if I understood req_G0TC8XGiXxlFwR correctly - looks like you're backdating the subscription schedule, and setting proration_behavior: "none"?
sacred mango
yes, because I want to charge the full invoice subscription item amount, not some prorated amount.
sand tiger
I see... so I think there's a misunderstanding here about how prorations work. When you set proration_behavior: "none" while backdating, it won't charge the full amount; in this case, it simply won’t charge anything at all.
Essentially, backdating does generate prorations, but when you use proration_behavior: "none" at the same time, no charges will be applied during the backdating process.
gimme a while to see how to achieve what you want via workarounds, which is to charge the full subscription amount when backdating.
sacred mango
let me explain why I backdate too
because maybe there's a different way to achieve what I want
so I'm backdating to basically align the pending_invoice_item_interval to the start of the month. If I have a yearly subscription, there is also the chance for additional one off pending invoice items to be added throughout the month. I set the pending_invoice_item_interval to 1 month on a yearly subscription so additional invoices get generated on the first of each month if there are pending invoice items for the subscription.
if there's a different way to align the interval other than backdating the subscription, that would probably work too.
sand tiger
hmmmm, have you tried using the billing cycle anchor config? https://docs.stripe.com/api/subscriptions/create#create_subscription-billing_cycle_anchor_config
sacred mango
there isn't a way to set that value in a subscription schedule.
sand tiger
ah, I was thinking without a subscription schedule
I'm not entirely certain if you actually need a subscription schedule, so typically I'd try things out without one first. Having said that, I do want to mention that I haven't tried using billing cycle anchor config hand in hand with pending_invoice_item_interval, so I don't know if it would work as per what you want yet
sacred mango
well, I need a schedule to change the subscription data at a later date.
so I'm using subscription schedules for that reason.
sand tiger
aaaah, okok
so the workaround that comes to mind for you to try : set prorations:"none", and at the same time, add a one-time price for the same amount of your yearly price in https://docs.stripe.com/api/subscription_schedules/create#create_subscription_schedule-phases-add_invoice_items
so that would handle charging the full amount for the first year
sacred mango
I also remember the last staff member mentioned this: #1423081458393677914 message
but I didn't understand what they meant.
sand tiger
In that case it would make more sense to create the Subscription Schedule in the previous month with a future start date so you don't run into this situation.
it will only work if you want the subscription to start in the future e.g. first of Nov. But if you want the subscription to start now, then you need to travel back in time 😆 so....I don't think this is going to work for your use case (unless I've misunderstood it)
maybe give add_invoice_items a try by adding the one-time price to charge for the first year to the first phase, and see how that works out for you
sacred mango
ok, so maybe I don't understand what proration_behavior=none means.
does that not mean "charge the full amount"?
sand tiger
nope, it just means, don't charge for proration
sacred mango
and the proration would be 1 year minus however many days have already passed from the backdated start?
sand tiger
hmmmm, i'm looking into some docs about backdating and the amount charged
okay, I think I may have found the solution here : Can you set proration_behaviour="always_invoice" for your first phase, and see what happens?
sacred mango
Sorry, still checking
sand tiger
no problem, take your time!
sacred mango
req_98HHTOAcaVRy24
it looks like it worked. Let me try another scenario.
ok, it still worked when created and backdated on the same date.
let me try one other
ok, so that seems to work, but I have no understanding as to why.
I thought it would try to generate a proration saying "sure, you backdated to the 1st of the month, but you only signed up on the 15th. Since you'll start your next cycle 15 days early, we'll credit you 15 days off the price."
Am I missing something in the docs that talks about this?
sand tiger
it's not explicitly in any doc right now. It's just that Billing is inherently complicated, and add the fact that you're also using billing_mode: "flexible" which is something that we just made publicly available recently, there's some stuff which could clearly be better documented.
I think this section says this in part : https://docs.stripe.com/billing/subscriptions/backdating
but it doesn't explain the proration bit and how it works for subscription schedule in detail
it's something that we'll look into how we can better document / explain
sacred mango
ok, so if i understand correctly: Since the billing cycle is a year, and I backdated to the beginning of the month, the proration_behavior=always_invoice will generate the invoice item for that first billing cycle we are still in, regardless of when the subscription is actually created vs the backdate date?
and if I left it at default, it would generate a pending invoice item?
sand tiger
I'm a bit confused by the sentence, but the problem here for your scenario seems to actually be when you pass in proration_behaviour="none" - it will not charge the full amount for the full period i.e. sep 2025 to sep 2026, or any amount for that matter. If you leave the proration_behaviour as the default or proration_behaviour="always_invoice", it will charge the full amount - you can try running this, and see that the generated invoice item is still charged
essentially proration has to occur for you to charge the backdated period
sacred mango
right, but that's not really "proration"
at least how I understand the word
it's just a normal billing.
I was expecting "proration" to mean that because I created the subscription 15 days into the billing period, it would cut off 15 days of cost. That would be the "proration" amount.
sand tiger
yeah, I get where you're coming from, but in this case, I think the approach we took for billing_mode="flexible" was that when you backdate, we are charging you for the full period from backdating since the customer hasn't charged for that period yet
sacred mango
that's cool