#Dan-upcoming-invoice

1 messages · Page 1 of 1 (latest)

winter finch
#

Hey! Do you have an example request ID I can look at?

jade brook
#

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

half gate
#

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.

jade brook
#

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.

half gate
#

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?

jade brook
#

both period start and end seem to be set to the time of the request

half gate
#

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.

jade brook
#

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.

half gate
#

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.

jade brook
#

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

half gate
#

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.

jade brook
#

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

half gate
#

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.

jade brook
#

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

half gate
#

Sounds great!