#yume_metered-changes

1 messages · Page 1 of 1 (latest)

pure rainBOT
#

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

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

rugged flint
#

yume_metered-changes

#

@turbid condor it's hard to say just looking at your code. The best option is to test in Test mode or a Sandbox and check the resulting Invoice(s) and confirm it matches what you want

I don't really get why you are cancelling the Subscription entirely either though, this doesn't make sense

turbid condor
#

Thank you for the quick response!
I tried the testing and did find that when user switches from metered plan to another plan right after the usage record is created, then the last usage is not billed anymore. I guess there is no better way to reflect though? (I could not find many examples/doc switching between fixed tier and metered plans)

I don't really get why you are cancelling the Subscription entirely either though, this doesn't make sense
Thank you for pointing out this, I added this because at some point I got error could not switch between metered based and fixed price plans, but it seems with current implementation, there is no error anymore so you are right I don' need this now!

rugged flint
#

when user switches from metered plan to another plan right after the usage record is created
Are you using the UsageRecords API or the Meter + MeterEvents APIs?

turbid condor
#

I am using meter events api:

stripe.billing.meterEvents.create(
{
event_name: meterEventName,
payload: {
stripe_customer_id: stripeCustomerId,
value: usageQuantity,
{
idempotencyKey: idempotencyKey,
}
);

pure rainBOT
brisk moon
#

Hi taking over here. Give me a bit to catch up

#

I tried the testing and did find that when user switches from metered plan to another plan right after the usage record is created, then the last usage is not billed anymore
Can you share the subscription id where you tested this so I can take a look at the implementation?

#

But seeing an example of what you're doing specifically would help

turbid condor
#

I am on sandbox mode for testing now and the subscription id I am using now is:sub_1SUthjQxnKawkD8KTayveBF1.

So when I switched from metered to fixed, when I tied to send 3 meter events as the image, which should get 90 usage in total should be charging 0.27 + fixed plan when switched is 10.27 but I only see invoices as 10.18.

For billing mode, I think I did not set it so it means as default, it is set as the flexible? ( I think I saw it somewehre in dashboard as flexible but forgot where I saw it...)

image.png image.png
#

I am also deleting the current items when switching not sure if it's related to losing the latest usage (but if I don't delete, I cannot switch because of error: You cannot change the usage type of the price attached to your subscription item...)

which means I am doint this:
const prorationBehavior = isSwitchingFromMeteredToFixed
? 'always_invoice' // Metered → Fixed: Invoice metered usage immediately
: 'none';
const updatedSubscription = await stripe.subscriptions.update(
subscriptionId,
{
items: [
{
id: subscriptionData.items.data[0].id,
deleted: true, // Delete old item
},
{
price: newPriceId,
quantity: newPriceId === METERED_PRICE_ID ? undefined : 1,
},
],
proration_behavior: prorationBehavior,
billing_cycle_anchor: 'now',
}
);

brisk moon
#

It's because you set proration behavior to none

#

See that link I sent before

#

You are using flexible but you need to not set proration behavior to none

# 
create_prorations: an invoice item is created for unbilled usage when removing a usage-based subscription item.
always_invoice: an invoice item for unbilled usage is created and immediately invoiced.
none: no invoice item is created.```
turbid condor
#

When I am switching from metered to fixed, I am setting behavior to always_invoice.

I am only setting behavior to None when I switch from fixed plan to mmetered usage

#

If I wait enough time, I can get the correct invoice, but my concern is if a user switch immediately after a usage created, that usage migh losing which occured when I am testing...
(for fixed -> metered plan switching, I don't need invoice so I set as None)

So I am wondering if there is any good way to make sure all usage is invoiced, even though the user switches immediately.

brisk moon
#

that usage migh losing which occured when I am testing...
Hmm can you share the request id of the usage reported?

#

So I can look at the timestamps here

#

If you reported usage first and passed proration behavior as always_invoice when subsequently deleting the metered price, a separate invoice should have been created for the usage

pure rainBOT
turbid condor
#

I just retried the testing again, and req_eSRps0zr3uZxnQ was not invcluded in the invoice when switch the plan...
(I tried 4 create_usage_record but only included 3)

lyric vigil
#

👋 Hi, codename_duchess had to take off and i'll be taking over the thread. just getting caught up.

#

can you point me to the invoice that was missing the meter event?

#

upcoming_in_1SUvqdQxnKawkD8K6OFUQLVY ?

turbid condor
#

Yeah the ID is: in_1SUvqtQxnKawkD8KYgbe0jh3

lyric vigil
#

Hrm, yeah so it looks because metered events are processed asynchronously, there can be up to a few minutes delay before they would be available for the next invoice. Which is why an invoice created 10 seconds after a meter_event was fired might not have that event available.

turbid condor
#

Hi! Thank you for the response!
So it means we have to accept that that portion is not charged or it might be charged/billed in the future?

lyric vigil
#

Might make the most sense to introduce a a short delay before creating the new invoice, are you currently using the billing portal to allow customers to change plans?

pure rainBOT
turbid condor
#

No, We have a button to switch between the fixed price plan and the metered plan on our frontend.
So do you mean when I switch the plan we cannot use 'always_invoice'?
Also, maybe it' s fine if we cannot charge when switching the plan since it will be charged in the new plan, but will this happne if the user cancel on the Stripe portal for metered plan?

#

(By the way the billing portal is not supporting switching between fixed plan and the metered plan(the check box is not working for the metered usage price)

limpid oriole
#

Hi there,
I took over for my colleague who had to step away.
You should be able to use 'always_invoice', but the problem is, that billing meter events are processed async. So it might happen that the meter event hasn't been process when the invoice gets finalized.

turbid condor
#

Hi thank you for the suggestion! I checked it and says set 1 hour as default.
But why then I still get wrong invoices immediately?
-> We might be fine with this when switching if not possible, but want to make sure the cancellation on Stripe Portal will charge correctly if the user cancels immediately after a usage report is created.

I tried canceling on portal and the same thing happens when cancels immediately after a usage report is created....

image.png
limpid oriole
#

Still looking into this...

#

One question though, was that the first invoice for that subscription?

turbid condor
#

No I have tested a lot so this is not the first invoice for this subscription

#

Oh I just realized that the invoices created when canceling via portal is still a draft, maybe it will be fixed when finalizing?(though now the bill is wrong...)

limpid oriole
turbid condor
limpid oriole
turbid condor
#

Okay. Thank you for sharing. I think we will accept that there are circumstances that which the invoice is not correct when switching between plans.

Finalizes the invoice immediately when collection_method is set to charge_automatically, or one hour later when it’s set to send_invoice.
Maybe if I change to 2 hours it might be helpful.. I think I will try testing this too.

I just want to confirm one last thing that will this happen when a first-time subscription is canceled in the customer portal?

limpid oriole
#

You should be able to define a grace period like 2 hours, or 1 day (whatever works best for you) when collection method is set to "send_invoice". For testing purposes, you can also try to update the collection method back to charge automatically right before the end of the grace period and see what happens.

turbid condor
#

I will try testing them to see if they can resolve our problems.

Thank you very much to you and all others who helped me today.

limpid oriole
#

No worries. We are always happy to help where we can.