#mark-a_api
1 messages Β· Page 1 of 1 (latest)
π 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/1354223359696568340
π 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.
- mark-a_api, 23 minutes ago, 19 messages
- mark-a_api, 18 hours ago, 67 messages
Thank you
So just to be clear, your goal is to preview the upcoming Invoice for sub_1R6RrMAUoPbSaQbfHnNyqWD5?
Yes, with a quantity increase, prorations, keeping the current subscription discount.
Currently the discount only seems to be applying in this case to one half of the proration.
Okay, so discounts and prorations get tricky
Totally. We've been using them for more than a year, but this is the first time with CSV migrated subscriptions, which this one is. Though, there have been other changes in our code base that may have affected this too, so it's not totally clear.
Out of curiosity, do you also use Subscription Schedules outside of the billing migration?
we don't, other than these new imports DO, but seems that these subscriptions at this point should just be live regular subscriptions.
It seems like these subscriptions all have associated schedules on the imports until they go live, but then seems like the schedules (I hope) simply go away.
And these that we're testing are all past the go live date
That depends on the Schedule's end_behavior. In this case, the Schedule was created with end_behavior: 'release' which means the Schedule will end (but the Subscription will remain) at the end of the phase. The phase won't end until March 2026
Do you think that's in play here? I don't see an option to control the end_behavior in the CSV import docs. One item of worry those is this, in those same docs, which doesn't make a lot of sense, and I don't think I've seen evidence (since the discounts are remaining on the subscriptions during all this):
And again, at this point, I can't even tell if these being imports are part of the issue. On a second quantity/proration update for these, it works as expected, but the first attempt on one of these after import and go-live seems to lose the discount on half of the calc.
I think it might be but give me a few more minutes
Thank you
I think this likely has to do with not overly discounting for a period
Let me step through this
ok
Here's how this usually works, and is what we're trying to achieve (probably already obvious, but working example):
I think there are a few things at play. The Billing Migration created Schedule sub_sched_1R6QoSAUoPbSaQbfRr5UJP7l. As part of that request, there's some initial_billing_cycle_anchor property that was set to a future date (1744783683, or April 15, 2025). Additionally, proration_behavior was set to none so no Invoice was created when the Subscription was automatically created.
Correct, all intentional, and actually mentioned in the coupon screenshot above as part of the docs.
These migrated subscriptions are paid through the future billing anchor.
So there shouldn't be invoices until the upcoming billing anchor
(they're being converted from an alternate internal billing system for some subscriptions)
That unused time on ... line in the upcoming Invoice preview is the credit for March 25 - April 15. I understand there's no discount on this proration but do you actually want to apply a credit here or just make the Subscription update and have those changes in place for April 15 (when the first Invoice is cut on Stripe)?
The proration behavior is set to always invoice. And even though this customer won't have an initial invoice until next month, if they add users, we want to generate a new invoice before the billing anchor for the new quantity.
And in some of our test cases where we have a 60% discount and billing anchor closer to a year in the future, without the discount on the proration line, the amount due on these is a negative number. Really bad.
...as almost a year of non-discounted amount gets factored into that line missing the discount.
Where in that case, we would expect almost a year of new quantity actually due.
Taking a step back, I think you can still use the preview an upcoming Invoice endpoint but, since a Schedule is involved (due to the migration), you should use schedule and schedule_details instead: https://docs.stripe.com/api/invoices/create_preview#create_create_preview-schedule_details
OK, I'll take a look. You think we can manipulate all we need that way?
And that it will be correct?
and/or... is there any way to convert this out of a schedule when they go live?
(so they behave "normally")
And again, if we do a second quantity increase on these right after the first, they work.
(that last screenshot above is one of those - no schedule manipulation and no date advances, etc.)
Do you have the ID of the Subscription from the last screenshot above?
I think so, one moment please
sub_1R6RryAUoPbSaQbfIeqLoQjw / cus_S0RMz03O1ZF9Bl. Two invoices in short order. First has the fail, second was fine.
One possible factor here... I believe as part of maybe the first update or maybe even a manual subscription update, the coupon now seems to be associated with subscription line item instead of at subscription level.
(though I can't say for sure we're doing that in this use case path, but I do have some code that does make that change in some cases. May need to epxlore, but when creating the imports, coupon can only be applied as subscription level from what I've seen)
Hm, I'm looking at these two requests:
https://dashboard.stripe.com/test/logs/req_DkpyAnZ1qA47A6 - the top-level discount hash was not null
https://dashboard.stripe.com/test/logs/req_X3noYJ80qTCpnN - the top-level discount was removed, and discounts were added to the SubscriptionItem that's being edited
looking/digesting
Actually, I think we should be looking at:
https://dashboard.stripe.com/test/logs/req_JBuyWYu5aOwfZy
and
https://dashboard.stripe.com/test/logs/req_DkpyAnZ1qA47A6
ok, checking, yeah, the second link above didn't work
The requst posts in those last two appear to be identical
And I'm not seeing what you mention.
(or not understanding)
I'm looking at the latest_invoice : in_1R6ZtXAUoPbSaQbfR2zMWwI3 (only one of the proration items has the discount) and in_1R6aMMAUoPbSaQbfMZsvLj3G (both proration items have the discount)
And may be related to this, which has been intentional:
OK, yes, those two invoices are the right samples before/after, but I don't see that I'm doing anything differently.
(and the screenshot just above was from upcoming invoice)
π Taking over this thread, catching up now
Hi, OK. You're the 5th on this item since yesterday.
Just to ensure that I'm on the right track - Am I right to understand you would like to preview the subscription, such that the quantity, proration and discounts remain. However, you're observing difference due to discounts when attempting to preview the subscription?
Yes, basically, and that on first preview and quantity increase (update after preview), the discount that exists on the subscription is not applied to one of the proration items. But on a second quantity preview and subscription update, the discount is applied to both. And this may be affected by these being CSV imported subscriptions, which is new to us. All of our "legacy" subscriptions (thousands) behave "normally" when previewing/updating.
And as noted above from roadrunner_stripe, this is a good example, back to back in short order on the same subscription: in_1R6ZtXAUoPbSaQbfR2zMWwI3 (only one of the proration items has the discount) and in_1R6aMMAUoPbSaQbfMZsvLj3G (both proration items have the discount)
Thanks for confirming! Checking the invoices shared
Let me put the subscription changes in timeline, so that it'll be easier to explain:
- [2025-03-25 07:25:55] Subscription created using migration import - no invoice was created
- [2025-03-25 16:00:02] req_JBuyWYu5aOwfZy was sent by your system to update the quantity to 2 from 1, which resulted in in_1R6ZtXAUoPbSaQbfR2zMWwI3 created -
- At this point, no prior invoice was created which the unused items are considered not discounted > that's why the unused time item is not discounted
- With this request, this quantity change picked up the discounts for the new invoice > that's why the remaining time time has discount
- [2025-03-25 16:29:49] req_DkpyAnZ1qA47A6 was sent by your system to update to quantity to 3, which resulted in in_1R6aMMAUoPbSaQbfMZsvLj3G
- The previous invoice has discounts, so the discounts was applied for the unused time item
- For remaining time items, it will pick up the discounts from the subscription itself
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
The timestamp are all in UTC
Thanks, reading...
OK, I understand what you're saying, but not sure it makes sense. There's a discount on the subscriptions. I've not seen docs saying a discount is based on a previous invoice. Any docs I can read that support/explain that more?
And even more importantly... what's a work-around for this on the first invoice, if any?
And I can't imagine that we're the first to deal with this, when importing existing subscriptions form another system. We expect those to show as paid and active, with a billing anchor in the future. If there's a discount on the account and they need a quantity increase now, how does one apply that? We can't wait until their first subscriptoin invoice is generated, up to a year in the future.
This is likely the edge case. I don't have a solution off the top of my mind. Could you writing in with the link I'll be sending to you shortly, so that we can check with the relevant team and get back to you?
Hello @fading mango, we have sent you a direct message, please check it at https://discord.com/channels/@me/1354261752375677089
- πThe message has instructions on how to open a direct support case with our Developer Support team, in order to help you more effectively.
Sure, but was certainly hoping to have this resolved in short order. It's holding up a production release that was scheduled for last THU and been battlign this for days.
Sorry to hear your experiences. This is likely the expected behavior, but we'll follow up with you to check whether there is any workaround to this
OK, thank you. I'll create a write-up at the link.