#mark-a_api
merry gardenBOT
👋 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/1353855845334650912
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
misty needle
Here's what I couldn't paste. Also have the whole preview invoice.
The import seems fine and displays as expected. Next invoice will be due at billing cycle anchor of March 17, 2026.
Now the customer wants to add an additional user (annual subscription quantity increase) from 1 user to 2 users as of today March 24, 2025 which we expect to prorate, and since there's the better part of a year remaining, expect this new user add should be equal to almost the full rate of an additional user. However, the proration preview invoice (set to always_invoice) is showing as:
"amount_due": 0,
"subscription_proration_date": 1742852184,
"subtotal": -8240,
"subtotal_excluding_tax": -8240,
"tax": -515,
"test_clock": null,
"threshold_reason": null,
"total": -8755,
"total_discount_amounts": [
{
"amount": 0,
"discount": "di_1R4YUMAUoPbSaQbfZJ4vWwCe"
}
],
"total_excluding_tax": -8240,
Options passed to the preview calc:
invoiceSubscriptionItemOptions.Quantity = 2
InvoiceSubscriptionItemDiscountOptions = 40% coupon (ID LEuP5LiF)
SubscriptionProrationBehavior = "always_invoice"
Help please.
gentle grotto
hello! currently reading and digesting your question, but in the meantime i wanted to ask if you've tried using test clocks to see what the proration actually ends up looking like?
misty needle
I've pushed a couple of these through to invoice creation and yeah, the first one I tested created a negative amount invoice, probably in line with what we're seeing above.
gentle grotto
mind sharing one of those as an example if you have it handy? it's a little harder to parse preview invoices for me so a case where the actual invoice was generated would be a little easier 😅
misty needle
Sure, what would you like me to paste?
gentle grotto
you're using subscription schedules right? just the schedule ID is fine
misty needle
well, this are import complete, and we're not manipulating any schedules after the import is complete. They're live subscriptions as this point.
gentle grotto
gotcha. a subscription ID is also good
misty needle
getting
sub_1R4YTvAUoPbSaQbffZxsWK8E This one had a subscription anchor date 96 days away so a bit different than above. It created the negative invoice. I then manually set the suscription quantity back to 1 for more testing.
gentle grotto
ok cool! fyi i'm juggling a few threads so it might take me a bit to look into it.
misty needle
OK, sure, Hopefully we can resolve before you're done today as this is holding up a release.
gentle grotto
for that last example, is this the invoice where you're seeing the proration that looks weird?
in_1R6GUNAUoPbSaQbf4sCu4Pul i see a line item for 64.51 and then another proration for -80.64
misty needle
Yes, same invoice
And I would definitely expect a postive amount due, as we're adding a new subscription quantity for 96 days, at 300 per year (though there is a large discount on this one too)
gentle grotto
ok i'm seeing one suspicious thing in the params you're sending, let me run a quick test to sanity check if that could be related...
misty needle
Thanks
gentle grotto
ok nope, i was on the wrong track there. but i think i might know what's going on, let me run another test
misty needle
OK, super. Thank you.
gentle grotto
ok, i think i'm done testing. let me sanity check a few things.
appreciate your patience 🙏
misty needle
ok, and my co-worker just ran a test. With the discount still showed issue, and we removed the discount and did another proration preview, which looked as we would expect with a positive amount.
So, seems like it's related to the discounts, which I kind of wondered might be the issue, but certainly not clear why. Seeems like it should work.
gentle grotto
yeah, i think the issue here is that your discount is -60%, which applies to both products.
let me make sure my math is mathing
misty needle
OK. great. So maybe we need to remove the discount on the proration preview call, and let it use the discount already applied to the subscription? But what if we wanted a new/different discount?
(included in the proration preview)
gentle grotto
ok yeah, that's definitely the issue. so basically since they're already part way through the subscription, and the discount applies to both "quantities" of the item, we're essentially charging them for 40% of the remaining time on the new "quantity" and refunding them 60% of the used up time on the old one
as for different ways to approach this, lemme noodle on that for a bit
misty needle
ok cool. That's helpful, but still not clear how to resolve. Thanks.
And to clarify, in most cases (maybe all of these) we will want to maintain the existing discount.
gentle grotto
ok, so one thing we're running into is that subscriptions only allow one instance of a price. so when you try to add a second "quantity" of the price, you have to discount both of them. another thing you would run into if you tried to call the API differently is that we only allow one instance of a price in each line of the subscription items, so we can't make 2 items that each have the same price and discount them differently.
one potential solution is to just make a second price, and apply separate discounts to each one
misty needle
oh that sounds ugly. But really we're just trying to change quantity on an existing price that has a discount. We've been doing this for probably the better part of a year but this is the first time we've worked with migration imports, and it SEEMS like this is different, unless we've not been noticing previously but nobody has complained. So we incrementing quantity. Original quantity had a discount and proration on an additional quantity has the same discount. It doesn't seem contradictory to any of the API docs or even your comment above.
We're just saying, add a "user" in this case. Keep the discounts as is. Calculate and charge the proration.
gentle grotto
ok yeah the importer is also throwing me off a little too. our team doesn't really support it so i think that's adding a bit of confusion on my part 😅 let me run another test that i think simulates the importer process
misty needle
OK great. And to even break down the use case more: Customer has a subscription. Subscription has a discount. Customer has 1 user on their subscription. Add one more user, keep the discount and prorate accordingly (though I think you get that already).
gentle grotto
ok yep, i just ran that test and it looks like it behaved the way you are expecting it to. let me run through the differences between your example subscription and mine
misty needle
ok
merry gardenBOT
misty needle
One of our team members just brought this up from a live PROD account. A one user add that maintains the discount and appears to have charged appropriately as expected:
(and that one is pre-import... No CSV migration import was done on that subscription, and it's the way these have worked in the past for us)
gentle grotto
fyi i need to run but sam is taking over the thread - i've given them a rundown of what i've found so far
misty needle
OK, thanks so much for your help thus far. I'm still hoping to resolve this today.
gentle grotto
yep, happy to help! this is a tricky one, but you're in good hands 🙂
misty needle
Awesome. Thanks. Standing by...
gentle grotto
one other thing that i want to throw out before signing off, have you tried just leaving the discount in place at the subscription level when you update the subscription? rather than including it in the line items as you're doing right now
misty needle
I actually just compiled the app that way but have not tested. I'll do that now and throw that out here as I get results.
Worried about the discount not being maintained, etc.
in_1R6LG5AUoPbSaQbfmjuhmRe6 ran through the preview and the invoice. It charged a postive value as expected. Still not sure all the numbers are right, but initially looks like it may be OK, and I do still see the discount on the subscription. Here's what we show our customers during the preview, which matches the invoice:
So all I did in this case was remove the discount from the preview request, and then followed through with the purchase.
Perhaps this is the resolution here, though we'll have to test our previous subscriptions to see if they're still OK
...and the subscription ID for that test above: sub_1R4YUMAUoPbSaQbfB4b3GgrA
pulsar flicker
Hi! Taking over from my colleague! Just catching up. Thanks!
misty needle
Thanks Sam.
pulsar flicker
Looks like you came to some resolution. Let me know if you have further questions.
misty needle
Well, not sure if you might know for sure, but we're kind of just guessing at this point. Seems to work, but I'm hoping this change won't break our previous "normal" subscriptions during quantity updates, which historically have worked I believe (screenshot about 30 minutes ago above).
We'll test, but it's still kind of inconclusive as to what's happened different now on these imported/migrated accounts (if that's even part of this).
pulsar flicker
Can I confirm if the discount should be applied to just the first "quantity" and subsequent "quantities" will not be discounted?
misty needle
We're not working with two separate quantities. This is a proration calc which Stripe always breaks into two separate line items on thees invoices. All we're passing is the quantity change to apply to the current subscription item. Single value, quantity.
Though if you mean subsequent as in the future, then in that case, yes, there may be additional future quantity changes similar to the one we're currently making. But we've not discussed that here at all, and I don't think really applies to this context probably. All we're doing is making a quantity change. We're not entering any line items as part of the call.
Nor are we sending different "quantities" with the request. It's just a single subscription item and we're saying increase the quatitiy from A to B.
...and maintain any current discount during the proration.
And how/why Stripe applies discounts each auto-generated proration line item isn't clear here (kind of the question), or why it's not working in these new use cases (imported/migrated subscriptions) but has previously for us (earlier sample above).
misty needle
OK, I believe I've found the issue(s) and have made corrections that we're testing. You can close this out now. I'll start a new chat if there are additional issues. We appreciate the help.