#mark-a_api

1 messages Β· Page 1 of 1 (latest)

crisp shoalBOT
#

πŸ‘‹ 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.

vernal jungle
#

Hi there

#

Give me a few minutes to catch up

fading mango
#

Thank you

vernal jungle
#

So just to be clear, your goal is to preview the upcoming Invoice for sub_1R6RrMAUoPbSaQbfHnNyqWD5?

fading mango
#

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.

vernal jungle
#

Okay, so discounts and prorations get tricky

fading mango
#

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.

vernal jungle
#

Out of curiosity, do you also use Subscription Schedules outside of the billing migration?

fading mango
#

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

vernal jungle
fading mango
#

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.

vernal jungle
#

I think it might be but give me a few more minutes

fading mango
#

Thank you

vernal jungle
#

I think this likely has to do with not overly discounting for a period

#

Let me step through this

fading mango
#

ok

#

Here's how this usually works, and is what we're trying to achieve (probably already obvious, but working example):

vernal jungle
#

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.

fading mango
#

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)

vernal jungle
#

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)?

fading mango
#

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.

vernal jungle
fading mango
#

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.)

vernal jungle
#

Do you have the ID of the Subscription from the last screenshot above?

fading mango
#

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)

vernal jungle
fading mango
#

looking/digesting

vernal jungle
fading mango
#

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)

vernal jungle
#

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)

fading mango
#

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.

crisp shoalBOT
fading mango
#

(and the screenshot just above was from upcoming invoice)

gritty elm
#

πŸ‘‹ Taking over this thread, catching up now

fading mango
#

Hi, OK. You're the 5th on this item since yesterday.

gritty elm
#

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?

fading mango
#

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)

gritty elm
#

Thanks for confirming! Checking the invoices shared

gritty elm
#

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
#

The timestamp are all in UTC

fading mango
#

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.

gritty elm
#

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?

crisp shoalBOT
#

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.
fading mango
#

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.

gritty elm
#

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

fading mango
#

OK, thank you. I'll create a write-up at the link.