#higher_invoice-preview
1 messages ¡ Page 1 of 1 (latest)
đ 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/1286014663179501653
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
From the data sent in the request we would have expected to see $400 as the upcoming invoice price, instead we saw $345 which doesn't make sense from our perspective
the endpoint was /v1/invoices/upcoming I believe
higher_invoice-preview
@terse olive can you share your exact code and what the exact issue is? If you just call the API and pass nothing then you'd get the real upcoming Invoice
subscription_id=subscription.id,
subscription_proration_behavior=self._stripe_service.DO_NOT_PRORATE,
upcoming_items=upcoming_items,
)```
upcoming items is defined here
# Swap the stripe price ID for the new plan's vendor (stripe) ID on the email subscription item, keep all
# other items the same
price = (
new_plan.vendor_id
if item.vendor_plan_id == previous_plan.vendor_id
else item.vendor_plan_id
)
upcoming_items.append(
{
"id": item.id,
"price": price,
}
)
why are you passing any upcoming items though?
Like what is your goal, what are you previewing?
we are previewing what their price would be if they upgrade one of their subscription items
Gotcha. Then there would be no proration. If the amount isn't what you'd expect you likely have an already pending InvoiceItem, some coupon or something else.
is there any way for us to diagnose what caused the difference in this case?
I have a specific subscription id that I'm investigating
What I recommend is: dump the raw JSON you get back to a file and then carefully read each element in the lines.data array to pinpoint what doesn't match your expectations
it's not an issue that i can reproduce here. do you have access to GET logs that occurred during Aug 5th 2024?
ah no sorry that's not something I have access to
is there anyone you can bring in that does have access?
No, we don't log anything like this so there's no one to pull in
We delete GETs after 30 days. And we never log the response of GET requests even before 30 days.
ah
Sadly debugging the upcoming Invoice can be quite tricky. And what I recommend is to store the raw JSON to pinpoint the issue