#stellar-Invoices

1 messages · Page 1 of 1 (latest)

muted silo
#

Hi there, how can I help?

iron urchin
#

sorry i'll connect back in a few minutes

iron urchin
#

hello

#

a few days ago i was talking to u about this

#

i get different lines in invoice from retrieveUpcoming and on the actual invoice genereated when paid

#

i tried what u suggested to filter invoiceLines by type == 'invoiceitem'

#

it works ok when updating quantities but when price need to be changed it doesn't

#

what am i doing wrong? please help

muted silo
iron urchin
#

when prices are updated = req_f6ClSX5SGwgMUk

#

when quantites are updated =
req_T6MOqwG1WJzs88

iron urchin
iron urchin
muted silo
#

OK, I can't see the response because the GET response are not cached, can you tell me the expected value vs the value you received?

iron urchin
#

and please remember its not just total that's different, invoice lines too do not match the actual invoice generated

muted silo
#

req_f6ClSX5SGwgMUk is updating price whereas req_T6MOqwG1WJzs88 is updating quantity, and you are saying the request that updating quality is working as expected?

iron urchin
#

no, request updating price works as expected

muted silo
#

OK, so I see the amount for price is 50, and you are changing the quantity from 2 to 3

iron urchin
#

yes

muted silo
#

OK, are there any discounts applied? how should 3 x 5000 ends up to be 4900 ?

iron urchin
#

proration?

#

increasing quantity from 2 to 3 means 5000 more

muted silo
#

Again, I can't view the response because it's a GET request

#

or perhaps is there a invoice object that I can take look?

iron urchin
muted silo
#

Thanks for the info, the amount looks OK to me

  • -9983 for Unused time on 2 × Basic - LO Seat after 07 Mar 2022"
  • 14974 for Remaining time on 3 × Basic - LO Seat after 07 Mar 2022
  • 15000 3 × Basic - LO Seat (at $50.00 / month)

The total is 19991

iron urchin
#

with these invoice lines yes the total is correct

#

this is what i want

muted silo
#

OK, this invoice is generated because you are updating the subscription by setting "billing_cycle_anchor": "now"

iron urchin
#

ok i'll try without it

muted silo
#

@iron urchin My shrift is over and my colleague has joined this thread to continue help you

#

If your issue can't be resolved today, please contact Stripe Support and tell them you have reached out to us previously, and they will escalate the issue to us https://support.stripe.com/contact

Stripe: Help & Support

Find help and support for Stripe. Our support center provides answers on all types of situations, including account information, charges and refunds, and subscriptions information. Get your questions answered and find international support for Stripe.

iron urchin
#

here is the upcomingInvoice object when updating quantity from 3 to 4

📎 message.txt
zealous mantle
#

Hi! I'm taking over Jack Tan.

#

Can you clarify what is the issue with the invoice that you just shared? What were you expecting to see instead?

iron urchin
iron urchin
#

they both have different invoice lines and thus different total

zealous mantle
#

Can you share: the request ID for the upcomingInvoice, and the actual invoice ID?

iron urchin
#

upcomingInvoice: req_Q2TJuV8Jk6iVqm

zealous mantle
iron urchin
#

actual invoice: in_1KadNcSAuIq5vjOhlHKHR8rc

#

please note i created a new request with same parameters except subscription_proration_date

zealous mantle
#

Thanks! Give me a few minutes to look into this.

zealous mantle
#

Sorry for the delay. What you see is expected:

  • When you get the upcoming invoice, it is just that, a preview of the next invoice. That means it contains both the proration items for the change you make, and also the amount for the next month.
  • If you then go and make the actual update using proration_behavior: "always_invoice" to charge the proration now, that generates an invoice for only the proration, so it’s not identical to the preview (since it’s not the invoice for the next month, exactly).
  • If you only want to see the proration total (to show the customer “here’s what you will pay today when we do the update”), you have to inspect the lines of the upcoming invoice and only sum up the ones that are marked proration:true.
iron urchin
#

okay

#

i'll try that

#

thanks

iron urchin
#

if i update the price then proration won't b true for those items, so this doesn't solve my issue

#

if i filter by proration:true, then the total would be negative amount

naive wasp
#

I see, and why is that a problem? It's possible that the proration is negative yes, and invoices can be negative as well.

#

if the change to the subscription is such that there is a large negative proration, the invoice can be negative, in which case the invoice will get marked as paid automatically and the negative amount is added to the customer's balance as a credit that will be applied against future invoices.

iron urchin
#

but that's not the case here, look at the second invoiceLine its amount is 180000

naive wasp
#

yep but that's the amount for the next period.

#

it's not the proration

#

if you were to preview this via invoices/upcoming, then do the Subscription update with payment_behavior:always_invoice, what gets generated is an invoice with only the proration items

#

so here it would be a negative invoice

#

this is what @zealous mantle was describing. the upcoming invoice is not just the proration , it's just the next invoice, which is <amount for the upcoming period> + <any proration>. If you do the Subscription update with payment_behavior:always_invoice then you are only charging for the proration component, not the other line item, hence why you'd filter from the preview as described.

iron urchin
naive wasp
#

would they?

iron urchin
#

that is y whis is an issue for me, upcomingInvoice is different than the actual invoice

#

look i just want to show the user if they update there subscription how much they r going to pay

naive wasp
#

yep, and we described how to do that(get the upcoming invoice and filter it to just the proration items).

naive wasp
iron urchin
#

this is my subscription update call

Screenshot_from_2022-03-07_17-04-23.png
#

this is for retriveing upcoming invoice with same updates

Screenshot_from_2022-03-07_17-05-28.png
#

anything wrong here?

naive wasp
#

nope, all looks normal

iron urchin
#

again i pass same parameters to both call

naive wasp
#

well, not really?

#

did you read what I wrote?

#

the upcoming invoice includes the underlying subscription item

#

the invoice you create by updating the subscription does not , it only contains the proration items

#

you can not call the upcoming invoice endpoint in a way that gives you an identical invoice

#

the only options is what what we said, inspect the lines of the upcoming invoice and sum the proration items, since those are what will be in the actual invoice generated.

iron urchin
#

sorry! i'm still not getting it

iron urchin
naive wasp
#

yes. The invoice created by your first screenshot(calling stripe.subscriptions.update with proration_behavior:"always_invoice")

iron urchin
#

ok please bear with me

#

i have a user with monthly price subscription

#

now changing to yearly price

#

now if the subscription is updated too with yearly prices

#

this is the invoice generated: in_1Kaf5tSAuIq5vjOhKfT52R2c

#

everything is correct?

iron urchin
#

?

naive wasp
#

will look in a second, I need to help other people as well

iron urchin
#

sure

naive wasp
#

does it look correct to you?

iron urchin
#

i meant everything is as u would expect?

naive wasp
#

seems like it!

#

so you did "billing_cycle_anchor": "now" to force the subscription to cycle

#

I suppose that's one option! it makes the upcoming invoice match the generated invoice, if that is really what you want. Just make sure you understand what that means(you changed it so now this subscription will recur at this time every year instead of the previous time it was set to), it might not matter in your use case, in which case, totally fine.

iron urchin
#

ok so now as u guys said, to show the preview to user i would filter the invoiceLines in upcomingInvoice by proration = true

#

doing so would result in different total than what the user would actually pay

#

i don't want that to happen

naive wasp
#

like you have changed the question now

#

now you are using billing_cycle_anchor": "now" to force the subscription to cycle, which means the invoice generated charges for proration, plus the upcoming period

#

which is the same as the upcoming invoice endpoint. But earlier, you were not doing that, so the invoice generated was only for proration, which is why we said you'd want to only look at the proration parts of the upcoming invoice preview. Let me know if anything is unclear, seems everything is good now.

iron urchin
#

not quite 😬

#

this is one scenario

#

in another case where price does not change but the quantity changes

#

let me give u an example

#

and when the subscription is updated
this is the invoice: in_1KaffTSAuIq5vjOh38XS9yxx

#

now the invoices r not similar as in the price change case

naive wasp
#

can you explain to me what's different exactly to save me time?

iron urchin
#

an extra invoice item on upcomingInvoice

naive wasp
#

what's the description of that item?

iron urchin
#

"Remaining time on 6 × Basic - LO Seat after 07 Mar 2022",

naive wasp
#

do you have the request ID req_xxx of the call where you called v1/invoice/upcoming?

iron urchin
#

req_d5EpudlnWi5xvl

naive wasp
#

hmm ok, that's what I thought, it's just weird that was 40 minutes ago

#

so I don't think it's useful to look at that, since you have changed that subscription multiple times between that preview and creating in_1KaffTSAuIq5vjOh38XS9yxx right? so the state of the subscription is different

#

better to do a fresh test!

iron urchin
#

quantity chanes from 1 to 2

#

upcoming invoice

#

request:
req_nhLLWAPFkPTRZC

#

and the paid invoice: in_1Kafv3SAuIq5vjOhg96CCf8R

#

difference,
one extra invoice item: "Remaining time on 2 × Basic - LO Seat after 07 Mar 2022"

naive wasp
#

yeah because the calls are not quite equivalent I think. It's to do with passing proration_date on the preview but billing_cycle_anchor on the actual update.

#

but I don't 100% understand it either. I have to run soon so my colleague might look with a fresh pair of eyes.

iron urchin
#

i have been stuck on this for few days now, can't figure out what to do