#Dan-upcoming-invoice
1 messages · Page 1 of 1 (latest)
I'll generate one now and find the ID.
If it helps, this is snippets from the UI with this
This should be the correct ID req_JHShAEEwOMu6m4
Thank you, I'm pulling that up on our end.
It looks like subscription_proration_behavior was set to none in that request, which would disable the proration calculations.
I've tried various variations, without setting that field it's the same result req_82cd5BREbUB8uR
The UI examples also have "prorate changes" checked.
I'm making a fairly large assumption that the next invoice preview in the UI is coming from the same API, so I apologise if that is incorrect. But given the UI had the same behaviour I'm experiencing in the API, it feels like that change of billing cycle means this is expected, I'm just hoping there's a way around that I can't find in the documentation.
We're not as familiar with the dashboard UI in this forum as we mostly focus on API integrations, so I'm not 100% certain on that.
I'm still looking at details but here is what I think is happening. Changing the billing frequency of a subscription results in an immediate invoice, but that since this subscription is in a trial period that invoice will be a zero-dollar-invoice. I think another invoice will be generated when the trial ends.
Within the response that you received for req_82cd5BREbUB8uR, what was the period_end value?
I just ran though a test in my account, and since the subscription is still in the trial period it's expected that the next invoice will be a zero-dollar invoice (because it's during a trial). That invoice will immediately resolve, and then another invoice will be scheduled to trigger when the trial period ends and charge the full price of the subscription.
Ok, I guess my confusion is coming from the inconsistency then. As it's only the change in billing cycle with the issue (example request just changing the product) req_MJnzc6GGH7p6bd
Is there any way at all for me to generate that preview? If not I'll go down the route of manual calculation during a trial.
That happens because changing the billing frequency causes the billing_cycle_anchor to shift which results in an immediate invoice, whereas generating an invoice for other changes is optional and not the default behavior.
https://stripe.com/docs/billing/subscriptions/upgrade-downgrade#immediate-payment
https://stripe.com/docs/billing/subscriptions/billing-cycle#prorations
The tricky part is that the invoice preview is generating correctly, the next invoice will be $0, but what you actually want is the second upcoming invoice which there isn't a way to retrieve.
When you make the request to retrieve the upcoming invoice, can you set the subscription_proration_date parameter to a value that is 1 second later than the current trial_end value on the subscription? This will simulate the change occurring after the trial period ends and I believe that will behave closer to what you're looking for.
Doesn't seem to have any impact, generates the same sort of preview and returns now as the subscription proration date on the response. req_l1wy46egATdQlF
Running some tests on my end.
Thanks for your patience! When I retrieved the upcoming invoice with subscription_trial_end=now (while upgrading from monthly to yearly) the returned amount_due was equal to the price of my yearly subscription, because it's simulating the invoice generation that'll occur when the trial period ends.
No problem, thanks for taking such a detailed look at it, I'll give that a try
That looks to be exactly what I needed, thank you
Happy to help, I'd recommend testing it with scenarios where the billing cycle anchor isn't changing (such as changing quantities) to make sure it doesn't throw those off. You may need two separate preview requests depending on whether the subscription has a trial.
yeah definitely, for now I've just wrote a quick test which is checking if the subscription is trialing, and only setting that field if it's in a trial
Sounds great!