#rgrau_unexpected

1 messages ยท Page 1 of 1 (latest)

fallen torrentBOT
#

๐Ÿ‘‹ 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/1488576196139811029

๐Ÿ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

vivid pivot
#

Hi there. Can you provide an example Subscription id (sub_123) that illustrates what your'e doing now?

wary thicket
#

hi! sure : sub_1TH3UjK2yjOku12MlgWLdsrM

#

"pending invoice invoice on" dates for the end of every month, and the it gets issued if there are changes on the non-metered line item, but there's one line item which is metered that doesn't get cleaned off in the monthly invoices. (IIUC)

#

(and doesn't trigger a monthly invoice either, ofc)

vivid pivot
#

So you want to, on the same Subscription, collect an annual payment, and then collect monthly payments on a usage basis, right?

wary thicket
#

yeah. We do this already for an item of the subscription, and wanted to use the same technique to collect the usage of the other item.

vivid pivot
#

okay I think I see here. You're incrementing the quantity of the Subscription Item and expecting that to get picked up as a pending Invoice Item.

There are at least two ways you could do this: the one that is the correct version of what you're trying now would be to create Invoice items passing in the subscription parameter

#

I think that should work, though I wonder if you'll get some conflict betwen the monthly Invoice cadence for pending items and the annual price, but I think this will likely work

#

The second way would be to add a usage-based Price and report usage using Billing Meters and then let Stripe bill monthly for the usage automatically

wary thicket
#

You're incrementing the quantity of the Subscription Item and expecting that to get picked up as a pending Invoice Item.
That's what we're doing for price price_1TA7dDK2yjOku12MO9Q0LNFn and it's working fine. when incrementing quantity, the invoice gets generated.

The problem is with price_1TBcEjK2yjOku12MpG6rDi32, which is the case for your "second way". we reported usage for 1,232 using billing meters, but stripe doesn't surface that into the monthly invoice. We would like to leverage the stripe's capability for summing usage-based metrics. Option 1 may work, but there's always risk of messing up with prorations and get only part of the amount in the final invoice.

You think option 2 should work? Could we take a look at that price_1TBcEjK2yjOku12MpG6rDi32 and figure out why it doesn't trigger the invoice? (feel free to advance the simulation clock)

vivid pivot
#

oh I can't advance your test clocks from my end

#

but I'll have a look

#

price_1TBcEjK2yjOku12MpG6rDi32 is backdoored into being a yearly price

#

the interval is month but the interval count is 12, so you will get an Invoice for the metered price once every 12 months

wary thicket
#

as we are comming from an old stripe version (before flexible billing) all prices are annual, but we used to use the pending_invoice_item_interval to get yearly subscriptions with monthly invoices.

Now we upgraded, so we may be able to mix periods, but it's not really what we want, because in case we have some tiers, the counts should be aggregated per year, not per month (or, pay one base fee per year, not per month). the monthly invoices should be only for our customers to not end up owing us too much.

I'm sorry it might be confusing but it's our real use case

vivid pivot
#

okay, I am confused.

So you want an Invoice each month, but you don't want for the metered Price to be a monthly price for the usage? What I was suggesting was having an annual licensed price and a monthly metered price on the same subscription

wary thicket
#

before flexible billing, all prices in a sub had to have the same billing_cycle_month, so that's why, if you had a yearly subscription, everything had to be yearly. But there was this option, using pending_invoice_item_interval to generate monthly invoices along the way with the partial consumptions. in fact, it worked perfectly. ๐Ÿ‘

Now we're trying to add a new price to the subscription, which is also yearly, and I was expecting that the partial consumptions would be factored into those pending_invoice_item_interval invoices, but they are not. That was the original reason of asking around here

#

From what you're saying, I gather that this usecase is not supported really, and that the option is, to go with mixed intervals and have some yearly and some monthly in the same subscription? That involves quite a few changes on our end, and I'd rather not do it if I can avoid, because there are compatibility changes with cancel_at_period_end (that we're using too, hehh)

vivid pivot
#

So it would take me some time to dig into exactly what is causing the difference in behavior, which is fine, but if moving from classic > flexible billing mode caused the undesirable change in behavior, I have to ask is there a reason you need flexible billing mode?

#

You can still use classic billing mode on newer API versions if you like

wary thicket
#

mm.. that's a good question. when we upgraded stripe api version we got the flexible billing mode as default, so it wasn't a consious decision really.
we noticed the undesired behaviour when we added our first usage-metered price into the mix. When moving to flexible, the non-usageBasedPrices worked fine. So it's not sure that this case ever worked. (usage-based price quantities triggering the "pending_items_invoice" and/or being added in the "pending_items_invoice"

I can try classic and if that works, we can kick the can down the road a bit more, but the ideal would be that usage-based price quantities would appear in "Pending Invoice Items" as the other items we have.

vivid pivot
#

I'm testing now but I think mixed intervals is the way to do this on flexible mode

#

I also don't get the metered usage getting picked up on a monthly basis using classic billing mode. I appreciate that this chat has been running for a while but it would be helpful to see an example of a Subscription that does what you want it to do because I wonder if this is actually an API version difference in pending invoice item behavior

wary thicket
#

in that same subscription, I'm going to change the quantity of the price price_1TA7dDK2yjOku12MO9Q0LNFn to 42, with "Bill for prorated change amount -> on next invoice after update". Then, I'll kick the test-clock a month, and we should see a new invoice generated , with that proration

#

done. that sub has now a new invoice, issued on Aug 30

#

with the "pending_items" generateed by that update-quantity to 42

vivid pivot
#

Ah I see, you're just updating the quantity of the Subscription Item directly. I thought from some of your earlier comments that you had Subscriptions where you were using a metered Price and reporting usage and that usage was getting picked up on a monthly basis by pending_invoice_item_interval

wary thicket
#

nop, the ones that are updated directly do work, the ones that go thru usage-meter dont ... ๐Ÿคท . sorry if I was not clear,... :/

vivid pivot
#

No problem; its complicated

#

Yeah I think your options are: 1) doing the thing that you are doing that gets the result you want 2) use mixed intervals and billing meters

wary thicket
#

wdym with 1) ? what I'm currently doing doesn't work for usage-metered prices. I think at this point the only thing that would work is 2).... or, you meant something else with 1)? the other option of manually sending one-off line items so that the pending_invoice_item_interval triggers might work too, but it involves doing all the counting myself..

#

anyway, I think I have a general idea here....from what I understand the "usage-metered prices" are not going to work in combination with pending_invoice_item_interval, and it's not an implementation issue, but seems to be something that stripe doesn't do. The meters do not trigger a pending_invoice.

The alternatives are either go manual and send invoiceitems before the pending_interval, or use flexible billing