#the_gaijo
rose aurora
By doing this, I can't find an easy way to return the amount due today, as the new invoice, in some way doesn't take into account whether the previous invoice was paid or not.
Can you explain more about the specific issue here?
I don't really understand what you're trying to get vs hat you're actually getting
bleak hare
The amount due today I am getting from the API response doesn't take into consideration of the invoice paid before the proration request. So I am getting the full value in amount_due and 0 for amount_paid
rose aurora
Can you share an example request you're making and the response body you get?
bleak hare
I would expect that the amount paid takes into consideration the invoice paid before the proration request, so the customer knows exactly the remainder they will need to pay, like it is shown in the customer portal proration flow
rose aurora
Yes, assuming you don't disable proration the updated subscription invoice should credit the previous paid quantity amount and prorate the charge for the new quantity
bleak hare
rose aurora
ok and what part of this is not what you expect?
bleak hare
ops sorry I forgot to include the rest, this is just the lines
I expect amount_paid to be different than 0
because the subscription_id I passed (sub_1NJNx2KVm4WHjNVwD76Gi5ui) was paid in full in the past, before I made the request to preview the upcoming invoice to see what the proration would look like
rose aurora
Sure, and that appears to be getting credited in the first line with:
Unused time on 5 × Product One
and a negative (credit) amount
then the other line is the prorated 7x
amount paid is not what you think --- its the amount paid for this invoice, which will always be zero for upcoming invoice, they're not real invoices
its not a reflection of the credit for prorated periods
bleak hare
but even doing the math with the negative amounts, the result is vastly different than what I see in the customer portal flow
rose aurora
Can you say more? Do you have an example from that?
bleak hare
10,302.19 - 7,358.71 = 2,943.48 is not 3,245.15 that I see when I do the same operation trough the customer portal flow (3,245.15)
I understand that the proration is calculated to the second, but the difference between 2,943.48 and 3,245.15 is way more than what a few seconds may do
I am not sure what the customer portal flow API request looks like, but mine is above
rose aurora
There must be other differences then, such as the specific proration date used
bleak hare
that's what I am saying, I am using the timestamp for now and I go through both flow one after the other, I don't think there is a > 300 dollar difference for a few seconds difference
so basically I am asking in the customer portal flow, how is that "amount due today" number achieved? Is it just the subtraction between the remaining time amount and the negative amount? The numbers are not adding up for me
rose aurora
I'm suggesting perhaps its more than a few seconds, like that the start of the day?
1687392000
rose aurora
so basically I am asking in the customer portal flow, how is that "amount due to...
I'm not sure -- you'd need to ask our support team about that.
bleak hare
I am confident I am using the current UNIX timestamp
rose aurora
Sure, but I'm saying I don't know what the portal uses
bleak hare
is there a way to know without reaching to customer support? They redirected me here
rose aurora
They shouldn't have -- sorry to hear that
Can you share a test mode portal session url with me, and tell me what options to choose to see what you describe?
bleak hare
sorry I misexplained this, I meant for dev questions, so not related to stuff like billing or errors, they redirected me here, if you think I should reach back to them I can
upper oasisBOT
bleak hare
the link should be the final page, so no need to choose any option
rose aurora
spark ginkgo
That link does take me specifically to the confirm page for an update. Do you want to have the update already confirmed when you link them?
rose aurora
The difference appears to be the tax amount
2943.45 is the difference you're seeing via upcoming invoice
plus or minus a little bit for timing, as you noted
bleak hare
I don't want to link them to this page, just replicate the same behavior
oh, nice, yes, the tax amount difference would make sense
I am confused because for each line item amount and amount_excluding tax is the same
spark ginkgo
I'm seeing different amounts between them. Is this when you retrieve the invoice via the API?
bleak hare
yes, see the message above #1121505542616129617 message
spark ginkgo
I wonder if this is a issue specifically with the upcoming invoice call
I assume that those amounts differed when you tested with an actual invoice?
bleak hare
I haven't really tested this with an actual invoice, but I can if it can be useful
I think there's either a bug or I am misinterpreting the response, because amount and amount_excluding_tax the same, but the tax_amounts is a non empty list for all entries
spark ginkgo
Yeah those should be different. I think you are expecting the right behavior. This definitely seems to be how it works on other test invoices on your account: https://dashboard.stripe.com/test/invoices/in_1NJNx2KVm4WHjNVw898JENpa
bleak hare
so is it a bug on Stripe's end? Is there a way I can report it?
spark ginkgo
From my testing I think it is a bug specifically in the upcoming invoice endpoint. I can report it for a fix
bleak hare
ok, thank you! Is there a way I can track this, or I can be notified for this, so I can come back to work on this once it is addressed?
spark ginkgo
Yeah you can write an email in to our support team and then DM me your email address so I can grab the email that you sent to support https://support.stripe.com/?contact=true
Doesn't need to be too in depth of a summary as I have this context. Maybe just show the upcoming invoice code you have and the response and mention that you talked to Pompey on Discord
upper oasisBOT
bleak hare
Sorry, I couldn't send you a DM
weary minnow
cc @spark ginkgo ^