#smock - prorate upcoming invoice
1 messages · Page 1 of 1 (latest)
smock - prorate upcoming invoice
For reference we are using the .NET stripe lib for our integration, so at first I thought it might be a serialization issue
but if I manually call stripe for an upcoming invoice with the query string
I get the same results, hopefully I am not just making a dumb mistake
Okay so you want to simulate the proration if the customer did not have the discount?
yeh
Can you share the the request ID for this request?
Here's how you can find a request ID: https://support.stripe.com/questions/finding-the-id-for-an-api-request
This will be a GET request so you may need to turn off the default filters
yep sure, might just need a min sorry
That's okay
ok sorry it was req_sZvJBFu1V49cV7
made a fresh customer as I had been playing with the previous sub for a little bit so wanted to make sure it was not something I had done previously
ah ok yeh I can see the coupon is not showing up there
Yes, I'm not seeing the coupon: "" parameter in that request
wait sorry, I didnt refresh properly, it should be req_1EAacWC1ZqVbAd
but the total for that invoice is $21.79, when what we are after would be an invoice for $1.00
(additional units are $1 and this was pro-rated right when the sub began)
but the total for that invoice is $21.79, when what we are after would be an invoice for $1.00
Sorry that sentence was not clear to me. Did the invoice object returned include the coupon discount or not?
ok so, TBH I am not sure because whether I pass a blank coupon or not doesnt seem to make a difference so I am not sure what is or is not meant to be there. In both instances it seems to not include any discount information
it might pay to take a step back to what my original question was yesterday
Could you restate it. There are multiple people asking questions right now
sure yep
discord is giving me grief, sorry I know there is a lot of stuff going on in there
so my original question/problem was
"I was wondering I could get some help with some unexpected behavior when prorating a subscription upgrade after a one-off discount has been applied to a customer (the remaining time on the sub uses the discounted amount, so the first prorated upgrade charges the customer a lot more than I would expect, not sure if there is a way around this)."
and then I had a follow up example of :
*"so first this is the "normal" scenario, the subscription has not been discounted; the base price is $21 and additional units cost $1
sub_1LpibiAlWOZ9EtFQVDFSJ4zC
so in this case we did a prorated upgrade right at the start of the and it charged the customer $1 as expected (for both the first and second invoice)
and this is the "problem" scenario
same sub and pricing, but this time when the customer purchased the subscription, they had a one-off discount of 99% applied, and the second invoice charges them $21.79 after a prorated upgrade, because the time remaining is only counted as $0.21, we would expect it to also charge $1
sub_1LpJCKAlWOZ9EtFQgEaDFusw
so invoice in_1LpJDwAlWOZ9EtFQxliqJUJG specifically is what I am having trouble with"*
so yeh it basically comes down to that invoice, in_1LpJDwAlWOZ9EtFQxliqJUJG, where the customer is charged $21.79 for adding 1 unit to the quantity of their sub
the advice was to use a empty coupon to simulate an invoice
and then manually raise with that amount
but doing that seems to just give me the same amount as when I dont send a coupon at all
I don't see any discounts associated with this invoice. Am I missing something?
ok so for subscription sub_1LpJCKAlWOZ9EtFQgEaDFusw, customer cus_MYQ1Apk2KA4sad, they buy a sub with a 99% discount, and then add 1 unit to the sub
that invoice doesnt have a discount, but we dont want them to be charged $21.79 to add 1 unit
and it seems to charge them $21.79 because the remaining time on the sub is costed at $0.21
if they never had a discount on the original purchase, this would charge them $1, which is what we want
its just this scenario of doing a proration after a one-off discount that is confusing to us
because the customer basically has to end up "paying back" the discount to add 1 more unit
It's confusing me to. Okay I can see the applied discount on in_1LpJCKAlWOZ9EtFQnN2fPtYE that has a billing cycle from 10-04 to 11-04
And then it was updated here: https://dashboard.stripe.com/test/logs/req_8ePGMyfUcfwNMH
Which is how we got to the invoice for $22
yeh, I just dont get the $22 - $0.21 = $21.79 part
since they are only adding 1 to the quantity, we would only expect them to be charged $1
so dunno if there is something we are not doing properly with the upgrade request, or in this case we just need to do the calculation ourselves and raise a manual invoice
If you move from quantity 1 to 2, what we do is refund quantity 1 entirely for the remaining time and then charge quantity 2 entirely for the remaining time. Not a diff
if the coupon had duraction: 'once' then it applied originally not on the upgrade
yep sure
so I mean its sounding like we need to do this calc ourselves
though im not really expecting the discount to apply to the upgrade
as if you think about it as a customer who got offered a discount on their original purchase and also told that additional units are $1
that behavior would be surprising
I am not sure that you have to calculate it all yourself. It really depends what end result you're after. But here you gave a 99% off coupon with duration once, and so what it does is discount the invoice once. And when you changed the quantity the coupon isn't here anymore
ok yep, I guess that is more thinking about it is buying two separate things and being refunded for the unused part of one of them
which makes me think, is there a more appropriate pricing to use?
if we want to look it as more that, you got discounted on the base product, and adding to it costs X per unit (so if the base product gets discounted, it wont affect the invoice for add more units that way it does in the scenario above?)
ok, I will dig into that a bit
anyway, I think I have enough to go one with ATM, cos either we need to use diff pricing or raise manual invoices for this one case
thanks anyway, appreciate the patience from both of you
of course!
you're not the only person thrown off by this
there's a lot of upsides with our flows, but it can be baffling sometimes 😅
yep it can be a bit overwhelming with all the options, thanks for clearing things up for me, again really appreciated