#elBR

1 messages · Page 1 of 1 (latest)

smoky trailBOT
errant nimbus
#

I see that some invoices total are 0.00 and I don't know why

#

I don't want that to happen

warped axle
errant nimbus
#

but why did it happen?

#

I don't want my customers to have a balance

#

it should remain always 0

warped axle
errant nimbus
#

I have a problem

#

And I do not agree the way Stripe calculates this

#

as you can see here, I have changed the quantity of the subscription from 5 to 6

#

and as you can see the total to be paid for that 1 item that I added is $44.93, where in fact the item costs just $30 and should be even smaller the total to consider the prorations

#

So as I understand, Stripe makes the difference with the 5 items that were applied a discount of $10 but is incorrect

#

the user should pay just for 1 item

#

please let we know about this behavior because is very risky for my app

last cloak
#

can you post the Invoice ID in_xxx your screenshot is from?

errant nimbus
#

in_1LrflgEMyoEBRsWZmA3SfFgg

#

as you can see the customer ends up to pay $47.98, whereas the item cost just $30 and considering the proratioins it would be just $29.98

last cloak
#

I don't think it works the way you think it should work. But I'll look in a while when I have a chance

errant nimbus
#

why it shouldn't. I just added one item that cost $30

#

please, this is very urgent

#

My customer expects that if he adds a new item, so he changes the quantity from 5 to 6, he will be charged for that 1 item he added that would be just $30

#

I don't see any reason why it should behave differently.

last cloak
#

because it's prorated by time.

errant nimbus
#

and because is prorated, the amount should be bigger?

#

in fact should be even cheaper than $30

last cloak
#

I'll look at your specific example in a little bit

errant nimbus
#

ok, please let me know

last cloak
errant nimbus
#

I got them from upcoming invoice of the subscription after you provide the new item quantity

#

you can check

#

the result is the same. I create the invoice items on my own because of I want to apply a coupon to just that invoice but does not have anything to do with the problem I face

#

so the prorations are calculated by upcoming invoice of subscription

#

from this

last cloak
#

ok

#

can you share the request ID req_xxx of one of the time you call the Upcoming endpoint, and the exact JSON response it sent back? I need to see specifically what update you're making and the response(we don't store GET responses so I can't see the response myself).

#

ultimately I don't really understand why you think it's wrong.

#

it's simply :
(7* 29.98) - (90% of (6*29.98))

#

it works out as more than 29.98 because the positive amount(the amount for 7 seats) is even more than the negative amount because the negative amount(the refund for 6 seats) also includes your 10% discount while the positive doesn't. i.e. instead of 7 - 6 , it's 7 - 5.4

#

other ways to get to "just 29.98" if that's what you want are (90% of (7* 29.98)) - (90% of (6*29.98)) (i.e. apply the coupon to both items). The problem here is arises from the weird things you're trying to do with the coupon I suppose, which I don't completely understand.

errant nimbus
#

In simple words I want that when I add the quantity by 1 I want to charge the amount for that one amount

#

prorated for the time it is being created

#

I am not interested in time not used for x and remaining time for x

#

As normally if I add a new item I expect to be charge for that one item. The customer don't want to know about the past seats

last cloak
#

then probably you would be better off disabling our proration and just calculating it yourself if you think that works better.

#

you can just do proration_behavior:"none" when updating the subscription and creating your own invoice item directly for 2998 with whatever description you like. Maybe that's a better option, since you can't change how our proration works, and it does work by crediting for unused time and debiting for remaining time.

errant nimbus
#

I am ok with that. I am not ok with the part that it also considers the coupon code applied and as a result I get a bigger amount

#

the previous 6 items, have been paid. I don't see any reason why they should affect the new item created

last cloak
#

it's again how our proration works. The customer didn't pay for 6 items, they paid for 90% of 6 items. So when calculate the proration, we take into account what they actually paid, and thus the line item is calculated inclusive of the discount.

errant nimbus
#

I thought maybe Stripe has any attribute for my case, that seems pretty reasonable

last cloak
#

it does not

#

like it is feedback I have heard before, but it's just how it works for now. We have some default behaviours in the product for how proration works(like it being inclusive of discounts in this case) and not really any configuration for now. We know it doesn't work for all businesses, it's a complex product and everyone has slightly different use cases

errant nimbus
#

if you go to a store and buy 5 items that cost $30 and you get $5 discount. Then if you add another item you expect to be charged more than $30 for that item? No. What have been paid have been paid. We should consider only the new item

#

I don't understand why this is not reasonable

last cloak
#

yep, there are different ways to look at this. The way our product team designed this years ago was based on looking at it in a different way than you do. I don't want to get into a debate with you, it doesn't change anything.