#kaylee_unexpected

1 messages · Page 1 of 1 (latest)

gritty pewterBOT
#

👋 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/1427327674128531456

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

median ermine
visual thunder
#

It looks like you were planning on sending negative values.

median ermine
# visual thunder Hello 👋 So are you using the method described here to remove the previous val...

No i'm updating the meter with a negative value e.g. -100k before updating the subscription

                await stripeClient.billing.meterEvents.create({
                    event_name: 'geo_location',
                    payload: {
                        value: '-100000',
                        stripe_customer_id: subscription.stripeCustomerId,
                    },
                }),

await new Promise((resolve) => setTimeout(resolve, 60000));

            await stripeClient.subscriptions.update(
                subscription.stripeSubscriptionId,
                {
                    items: [
                        ...stripeSubscription.items.data.map((item) => ({
                            id: item.id,
                            deleted: true,
                        })),
                        ...lineItems.map((item) => ({
                            price: item.price,
                            quantity: item.quantity,
                        })),
                    ],
                    proration_behavior: 'none',
                    billing_cycle_anchor: 'now',
                }
            );

Update 2 (Usage limit reduction not applied)
req_cIWLp5uprZbNr9 - Update
req_4TdhE65tqjM12a, req_zUpKLRg6jBUG3A (meter events)

Update 1 (invoice with the expected amount)
req_OGjBl1xqnA591y - Update
req_kge69IaUurV5bs, req_6ZlL3xQgqlf2k1 (events)

visual thunder
#

Okay and what is the behavior you are expecting to see?

What are the values you expect and where are you seeing them?

median ermine
#

I was expecting for an invoice like in_1SHnblQl5o0oC79A9VmXFNLi where the metered events are reset to 0 when the user upgrades - to incentives upgrading but seems this approach has a race condition

visual thunder
#

Okay let me take this through one example at a time.

For req_cIWLp5uprZbNr9, you delete three Subscription Items and add three new ones including a metered price for price_1Rpm6XQl5o0oC79AWjtEq8Jh

#

This generates Invoice: in_1SHoDPQl5o0oC79ASQCIluvw where all the usage based prices I can see appear to have $0 amounts

#

Can you point to a specific line item on that Invoice that is charging your user more than you expected?

median ermine
#

the Geo-Location one

visual thunder
#

Well I think there may be a misunderstanding here. UBB bills in arrears. That is, at the end of the billing period. But licensed prices like the flat fee bill at the start of the billing period.

#

Oh wait now I see the Geolocation has usage up to Tier 2 (non-free) totalling $38

#

And you are saying that should have been reduced?

median ermine
median ermine
#

as the prices have different free limits

visual thunder
#

Right, so you've got 48,000 usage that is being billed when you issued a request to reduce the usage by 100,000 a couple minutes prior to making the update

median ermine
#

so if you're over the free plan usage limits you can upgrade to the pro p[lan and save money in theory

median ermine
visual thunder
#

Okay let me try testing this out so I can repro what you are experiencing

median ermine
#

Oki

visual thunder
#

Yikes our Test clocks are taking a long time to advance. My requests keep erroring because the test clock hasn't finished updating

median ermine
visual thunder
#

Yeah, sorry for the delay

median ermine
#

All good! ty for looking into this :D

visual thunder
#

Okay I was able to reproduce what you are seeing.

I created a Subscripton using a metered price, incremented that usage by 10K, advanced time (test clock) by 12 days, decremented the usage by 10K, and then updated my Subscription by setting billing_cycle_anchor="now".

The resulting Invoice still charged for the 10K usage.

median ermine
#

My proration_behavior is also set to none

visual thunder
#

Yes I did that too. I just didn't bother switching prices

gritty pewterBOT
median ermine
#

I suppose a quick solution for it could be running it in the background and setting a long delay between the two but that's not something fun for prod

visual thunder
#

Yeah, ideally you should have a solution that works synchronously with the API request so that, when you receive the successful response, you know you are good to go

median ermine
visual thunder
#

I noticed that the Subscription you are updating is using billing_mode: "flexible". This might be why the behavior doesn't match what our docs say here

#

I'm going to test again but specify billing_mode: {type: 'classic'}

#

Okay yes! That was it.

#

Billing mode: flexible introduces new proration calculation behaviors.

#

But, if you specify billing_mode: {type: 'classic'}, you get the old defaults. What this means is that you don't even need to decrement the Meter usage. Just specifying proration_behavior="none" is sufficient to ignore existing usage on the update request

median ermine
deft lion
#

Hi there, taking over for @visual thunder as they had to step away

median ermine
deft lion
#

Unfortunately there isn't a way to update a subscription to classic mode if it was created with flexible mode

#

Also flexible mode is the recommended approach going forward, so it makes sense to try and find a solution that works with flexible mode

#

I'm reading through the prior conversation to see if there are some recommendations that haven't been suggested yet

#

The things that cross my mind are

  • deleting and recreating the meter (but that is probably not ideal if the meter is used with other customers)
  • not trying to reset the meter, which results in a charge that you can refund/credit after the fact
  • maybe there's an event that triggers when your current async approach of resetting the meter resolves?
#

You can still create subscriptions with classic billing mode, so that would be a solution for new subscriptions going forward (you should test that out to make sure you're seeing the same result that @visual thunder got)

#

I'm going to try and recreate on my side as well

median ermine
#

I think i'll try keep flexible billing if thats the recommended approach for long term.

The meter is used with other customers so can't be deleted and I'm not sure about refunding and crediting customers after-the-fact in the long run.

The promise from resetting the meter resolves fast its just immediatly calling the update endpoint for a subscription fetches the old data not new one

#

so currently i just have a timeout between the two endpoints but i dont think thats ideal

#

as it may or may not be updated when subsription update is called

#

My current setup looks like this

await stripeClient.billing.meterEvents.create(...) 
await new Promise((resolve) => setTimeout(resolve, 60000)); // Even 1 min is a bit too short from my testing

await stripeClient.subscriptions.update(...)
deft lion
#

Yeah that's not ideal, it's a possible workaround but it will most likely be fragile in the long run

#

Let me consult with my colleagues to see if they have ideas on other approaches

deft lion
#

Spoke to a few of my colleagues, did not come up with a clean solution for this situation. Would you mind if I have a bot send you a DM so you can write this in to support and we can follow up to determine if there is a bug or feature we can add to handle this use case properly?

median ermine
#

Would this be sort of a bug thing as any meter events created within the last few mins of a billing period e.g. update or the period ends would be missed / not counted?

gritty pewterBOT
#

Hello @median ermine, we have sent you a direct message, please check it at https://discord.com/channels/@me/1394708318521528380

  • 🔗The message has instructions on how to open a direct support case with our Developer Support team, in order to help you more effectively.
deft lion
#

Sorry, when I said bug I meant that we can check if your situation is the expected behavior. Right now what it looks like is that we made the transition from billing_mode=classic to billing_mode=flexible, but now there isn't a clean way to reset the meter, which seems like an oversight for this type of use case

median ermine
#

Ahh ok :D

deft lion
#

Your case came through, I will communicate your situation to our team and we will follow up as soon as there is something to share!

median ermine