#quintinatlater - upcoming invoice
thick notch
Alright, so briefly, no, that kind of breakdown of immediate vs recurring is not supported. The endpoint is designed to calculate the next invoice only, and will have things like one time discounts/credits rolled in to that projected amount (with respect to any other plan changes etc)
What in particular is the same vs different between the two contexts?
You might just be able to do this for example with two separate requests to the endpoint to provide suitable parameters for those two contexts
vestal goblet
Hmm thanks, what do you mean by two contexts? Is it what I've been referring to as the immediate amount vs recurring charge?
vestal goblet
Right, so an example would be a user changing their subscription halfway through their billing period, without any modifications to the plan interval.
They pay a prorated amount immediately which reflects their unused time on their old items and the remaining time on their new items. This is referred to as the immediate payment here: https://stripe.com/docs/billing/subscriptions/upgrade-downgrade#immediate-payment but I'd imagine the "upfront" amount on the quote response is synonymous.
Then, the recurring charge amount is just how much they'll get charged at the start of their next billing cycle on the new plan.
So our users would see something like: "You'll pay <immediate_amount> immediately, and starting <end of billing cycle> you'll be charged <recurring charge>.
The way we do this right now roughly follows the last paragraph here: https://stripe.com/docs/api/invoices/upcoming#upcoming_invoice
where we look at proration line items and only consider those with start dates equal to the proration date. But this is where we run into a bunch of edge-cases, e.g. sometimes the items are meant to be included but the start date is off by 1 second, sometimes the discount_amounts are already accounted for in the amounts while other times they're not. So this is where having it broken down already like on the sample quote object would be really nice for us.
rugged kelp
👋 Just hopping in for @thick notch
You can accomplish this if you do two requests to retrieve the upcoming invoice - the first would be the one to generate the immediate amount with all the prorations, and then you can make another request with subscription_proration_behavior: none to not generate any prorations. This second request will send back the upcoming invoice that will be generated after the next billing cycle
vestal goblet
Right, that makes sense 😄. It's mainly the first request for the immediate prorated amount that is challenging for us, as it also includes upcoming items that don't apply to the immediate amount, and has the aforementioned inconsistencies.
What I'm getting from this is that maybe I should make a feature request for quotes to work with plan changes 😄
rugged kelp
Do you have the request ID you're making to get the immediate invoice? Just want to see what you're passing in
vestal goblet
Yep, one second please
Here's an example from test-mode req_oj7tzxWa9INx8T
We don't really bother with the 2nd request as we generally know the plan prices already if there's no proration happening
rugged kelp
Is your goal to immediately for the changes immediately?
If so, you should make sure to pass in subscription_proration_behavior: always_invoice with your request
vestal goblet
Yeah thanks for pointing that out, it's something we've assumed but at least I only realized recently that we don't actually always invoice immediately 😅.
rugged kelp
Yeah, when you don't pass in always_invoice , the next invoice to be generated will have both the proration line items and the line items from a regular cycle.
vestal goblet
Oh interesting! Thanks for the pointer! I'll try things out and compare behaviour, thanks for all the help 😄