#worming_proration-coupons
cobalt lakeBOT
👋 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/1423351626919313418
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- worming_best-practices, 14 hours ago, 4 messages
wild willow
Do you have an example of an API request that resulted in this behavior?
Can you share an API request ID? It will start with req_
Here's how you can find a request ID: https://support.stripe.com/questions/finding-the-id-for-an-api-request
blazing vortex
can you tell me if using the .Net SDK InvoiceService.Upcoming generates a request?
req_sXlFwmpYjzajzV
i just saw it
wild willow
the Upcoming Invoices API has been deprecated for a few versions now. The Preview Invoice API is the preferred API: https://docs.stripe.com/api/invoices/create_preview
This is because the Upcoming Invoice API doesn't create an object so I don't have anything I can see.
blazing vortex
we have the same behavior from the dashboard or calling the upcoming endpoint
wild willow
Can you share the Subscription ID that you are generating this invoice for?
blazing vortex
sub_1SCwipLN0iJa18Ze164c07P8
wild willow
Taking a look at the sub
This is the expected behavior when you combine discounts with proration and the classic billing mode (which is the only one for your API version)
We discuss this a little here: https://docs.stripe.com/billing/subscriptions/prorations#prorations-and-discounts
blazing vortex
Could it be that when using a coupon at subscription creation, and then applying another coupon during an update, Stripe is applying the original coupon to the proration credits and the new coupon only to the added items?
Is there anything to do to avoid getting negative amounts? or should i remove the option to use a coupon on that flow?
wild willow
It's much easier to debug this with the Preview Invoice API because it creates an object that can be more easily reviewed.
But I think, since you are stuck using the classic billing mode, that not allowing the stacking of coupons would make sense
blazing vortex
Is there anything to do to avoid getting negative amounts? or should we completely remove the option to use a coupon on that flow to avoid it?
cobalt lakeBOT
hexed ruin
worming_proration-coupons
Are you sure the math isn't correct? I wonder if you're maybe mixing up what is show in the API about the discount from what is really calculated
blazing vortex
im going to send you an screenshot of the upcoming invoice that i get when i update the sub from the dashboard
hexed ruin
A screenshot won't really help I think. This is unfortunately really subtle and it would really help to get real exact objects and the exact JSON/relevant parts in the API
You don't need the upcoming Invoice for this. You can update the Subscription for real and see what the resulting Invoice is
blazing vortex
ok
in_1SDqBVLN0iJa18Zefe4ZgEer
that is the invoice that was generated
As you can see, the discount coupon used in the update is only being applied to the items I’m adding.
The replaced items are not getting the discount, which results in a negative total.
What makes me wonder is that the proration items seem to still have the original coupon from when the subscription was created, which actually makes sense.
the sub was created using a 99% discount, and the update used different coupon (99.9%)
hexed ruin
I don't think that's correct looking at it. The proration line items do have the discount bundled into it right?
Unused time on Phone System: On-Hold Messaging + Music (up to 10 Phone Lines) (with 99.0% off) after 02 Oct 2025
1
-$0.14
it says this, it has the 99% off included
blazing vortex
That is the percentage discount used when the subscription was originally created (a 99% coupon). During the update, a different coupon was applied, with a 99.9% discount.
hexed ruin
Sorry I know this can be super annoying to debug/grasp. It's so subtle and the way we bundled the coupon in during proration is quite particular and hard to notice.
That is the percentage discount used when the subscription was originally created (a 99% coupon).
yes that is completely expected!
So I think we've narrowed down the confusion. You expect the new Coupon to apply, but that's not how we do the proration/math. We look at refunding the credit based on how much they originally paid
blazing vortex
Correct. What I want is for the update coupon to apply to the subtotal, regardless of which items are included.
hexed ruin
Gotcha. That's just impossible
I don't fully get why you would want that. If someone paid you $100 on October 1st and then you decide to change their Subscription today and add a Coupon, the Coupon shouldn't apply to the credit your are refunding them since they paid you $100 already
so the new Coupon only applies to the new amounts that are owed for the new Price/quantity, not the what was paid before if that makes sense
blazing vortex
Let’s say I have a customer who originally purchased a subscription using a discount we provided. Now I want to give the customer a discount on a subscription upgrade. This could generate a negative invoice, which would create a positive balance for the customer — but that’s not what we want. Our intention is just to give the discount on the upgrade, and in the worst-case scenario, the invoice should be $0, not negative.
hexed ruin
Yeah but in many cases that wouldn't make sense financially. Imagine someone pays you $100/seat for 10 seats so they paid $1000 on October 1st. Then they realize they made a mistake and they really just wanted 1 seat, they did a typo and you're going to downgrade their Subscription and offer a 50% discount as a show of good will.
You don't want them to pay $0 or $50. You need to refund them the $1000 they mistakenly paid too
So really proration takes into account what was paid and if a coupon was used it uses that original coupon
The end state you are looking for is not possible, partly because it almost always leads to real financial loss for the end customer which then leads to confusion or disputes
blazing vortex
That makes sense in the downgrade scenario you described. However, in our system we do not allow downgrades, only upgrades. The only case we need to handle is applying a discount to an upgrade, and in that scenario we just want the coupon to apply to the subtotal of the upgrade. In the worst case the invoice should be $0, but never negative.
hexed ruin
Yeah I get your point but it wouldn't work as an API design since we have no way to know that is your consideration, and it's highly likely you will hit corner cases in the future where someone overpaid upfront and absolutely wants a refund for it
Sadly what you are trying to do is not really supported unless you actively disable proration and calculate how much to bill them for the upgrade yourself
blazing vortex
Ok, I guess the safest approach is to disable coupons when prorations are involved, so we avoid negative invoices and unexpected credits
at least for now... later we can decide to generate a one-time invoice for the upgrade
hexed ruin
👍