#Gyan - metered billing

1 messages · Page 1 of 1 (latest)

neat pivot
#

Hi there. When you update a subscription, the default behavior is to prorate. An endpoint I recommend playing around with in test mode is this upcoming invoice endpoint: https://stripe.com/docs/api/invoices/upcoming. This allows you to preview what a change on the subscription would do for the next invoice

flint ledge
#

okay, so using aggregate_usage=sum is correct in this use case?

neat pivot
#

To clarify, you just want to upgrade the subscription with a different price that specifies aggregate_usage?

flint ledge
#

No, not that. I just want to update the quantity specified in the subscription i created before. Am not sure what parameters should i pass

#

Should i go with default parameters?
action: increment
aggregate_usage=sum

neat pivot
#

Neither of those are parameters on the update subscription endpoint

#

1st one is on creating a usage record

#

2nd one is on creating a price

#

If you already have a price and just want to update subscription quantity, you pass the new quantity

#

I feel like i might be misunderstanding what you're asking here though

#

Updating the subscription might not be what you actually want to do here

flint ledge
#

I tried to just update the quantity, i am getting the below error:
{
"error": {
"message": "You cannot set the quantity for metered plans.",
"param": "quantity",
"type": "invalid_request_error"
}
}

flint ledge
# neat pivot Updating the subscription might not be what you actually want to do here

okay, I see. The use case is simple, I have a metered pricing and a subscription created with qty=0.
Now, I want to keep adding units to the quantity throughout the billing period, and also want to make sure the billing is pro-rated as per the timestamp when they were added.
And lastly, at the end of the billing cycle, customer should be billed accordingly.

neat pivot
#

Oh ok. Just curious, what's your use-case for using metered?

#

What are you measuring

flint ledge
#

We have organizations who subscribe to the pricing models, and once they are subscribed, they can start adding members.
So, depending on how many members were added and when they were added, we want to do calculate how much they need to pay.

For example in a monthly billing cycle:
Unit price set as (u)

Day 1:
number of members = 10
total charge = 10 x u

Day 15:
new set of members were added (let's say 4)
total charge = 4 x 0.5 x u (pro-rated)

total charge at the end of the billing cycle =
10 x u + 4 x 0.5 x u

neat pivot
#

Oh ok I see. To be honest it sounds like metered billing might complicate this unnecessarily

#

Let me give you a recommendation. One moment

flint ledge
#

okay

neat pivot
#

Is each member a fixed price? (ignoring prorations)

flint ledge
#

yes, it's fixed

#

In above example , "u" is the price per member per month.

neat pivot
#

Ok so the best way to do this I think would be to create a normal (non-metered) subscription specifying a price (per member): https://stripe.com/docs/api/subscriptions/create#create_subscription-items-price. You can also specify the quantity of members you have: https://stripe.com/docs/api/subscriptions/create#create_subscription-items-quantity. Whenever you want to add a new member, all you would need to do is to update the subscription's quantity: https://stripe.com/docs/api/subscriptions/update#update_subscription-items-quantity. This, by default, creates a proration. You can also specify proration_behavior with this param: https://stripe.com/docs/api/subscriptions/update#update_subscription-proration_behavior. I also recommend reading this document to learn more about prorations: https://stripe.com/docs/billing/subscriptions/prorations

Prorations

Learn about prorations.

Stripe API reference – Update a subscription – curl

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

Stripe API reference – Create a subscription – curl

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

#

I think metered billing just adds complexity that isn't needed here

flint ledge
#

I chose metered billing only because the bill is always postpaid in this.
I have tried to create normal pricing, but in that case it charges the customer immediately after the subscription is created. Instead of waiting till the end of the billing cycle.

#

And, yes i agree updating the subscription is pretty straightforward with this approach and also includes prorations.

neat pivot
flint ledge
#

let me check.

#

I see, In this what is the default proration_behavior ?

neat pivot
#

Default is create_prorations

#

So it will prorate unless you set it to none

flint ledge
#

okay

#

but i guess if we provide a timestamp to billing_cycle_anchor it will just be fixed for one billing cycle. I want to set the bill generation to the last day of every billing cycle.

neat pivot
#

No it's fixed to that anchor for every month after that

#

Last day of the month is tricky since each month ends on a different day

#

We recommend fixing to the 1st of the next month to account for this

flint ledge
#

yes,

#

so to fix 1st of every month. What should be the value of billing_cycle_anchor?

neat pivot
#

You would choose a utc timestamp for the 1st of the coming month

flint ledge
#

okay, so if today i set value to epoch timestamp of September 12th, it will automatically start posting bills on 12th of every month from now on?

neat pivot
#

Correct

flint ledge
#

just making sure i understood correctly

neat pivot
#

You got it

flint ledge
#

okay thanks

neat pivot
#

No problem!

flint ledge
#

Let me try, can you give me 5-10 mins before you archive this chat?

neat pivot
#

Yes we usually give ~1 hour before archiving

flint ledge
#

Awesome. Thanks.

neat pivot
#

I have to head out soon, but my colleague @north swan can step in if you need further help

flint ledge
#

Got it!

#

Can we not create subscription with a given quantity?
when i am sending items[0][price] & quantity in the call, it is throwing below error:

{
"error": {
"message": "Received both items and quantity parameters. Please pass in only one.",
"type": "invalid_request_error"
}
}

neat pivot
#

Can you share the request id?

flint ledge
#

request id as in?

neat pivot
flint ledge
neat pivot
#

Ah quantity isn't in items

flint ledge
#

req_2PrcFdBljJAa2y

neat pivot
#

You quantity needs to be in items[0] see above

flint ledge
#

Ah.. i see

#

I was able to create the subscription successfully, everything looks fine except the description in the invoice where it says Sept 12 - Oct 12, instead of Aug 12 - Sept 12.

unknown.png
#

Is that correct?

north swan
#

ah, that section reflects the subscriptions upcoming/next invoice.

#

the finalized and paid invoice should be further down the page

flint ledge
#

Yes, found it. It shows paid which means anchor did not work? ideally it should not have charged until Sept 12th, right?

unknown.png
#

Here is the request Id : req_GpLCaWZXXMIHaP

#

@north swan

north swan
#

looking! it got a bit busy in here

flint ledge
#

oh.. okay. Take your time. Thank you

north swan
#

I believe you'll want to use billing_cycle_anchor in combination with trials if you want to delay the first charge

flint ledge
#

oh.. let me take a look. We already have trial period of 1 month in the beginning. But i want to make sure, the bill is always posted at the end of the billing cycle.

#

Since, we already have 1st month as trial period, We want Stripe to track the quantity for the second month and then Bill on the 1st day of third month. Which will effectively be for the usage of 2nd month.

#

I am not able to understand how can we achieve this here?

north swan
flint ledge
#

But if i schedule the subscription to a future date (ie. Sept 12) in my case, will i still be able to update the subscription quantity, even though it is not active yet?

flint ledge
#

I think unit pricing works for me, I just need to set the billing date to the 1st day of next billing cycle and still be able to update the quantity of the subscription in the current billing period.

jade jackal
#

👋 hopping in since @north swan needs to head out soon - give me a minute to catch up

flint ledge
jade jackal
#

Backing up for a bit - was there a particular reason you wanted to always bill at the end of the billing cycle? I agree with what was said earlier that metered billing doesn't exactly fit your use case because of the proration behavior you want

flint ledge
jade jackal
#

Yes, but even with that pricing model you could still pay up-front instead of at the end of the cycle - you'd have them pay up front for the 10 members, and when the 4 additional members are added they'd pay for those at that point in time

flint ledge
#

oh.. no i guess we don't want to keep charging them every time they add a new member. Because that can happen on daily basis.
We want to charge them at the end of the month, based on how many members were added and when they were added.

#

Does that make sense to you?

jade jackal
#

Yes, it makes sense - it's just not something you can easily model on our subscriptions so i'm just thinking through some options

flint ledge
#

Okay, If i go with your suggestion. Will i have to go with simple unit pricing and just update the subscription whenever new members are added? and the customer will be charged immediately for the new members?
Also, If any member leaves in between a billing cycle, how will the refund process work?

jade jackal
#

Yeah, if you go with my suggestion you'd do simple per-unit pricing and update the subscription when new members are added. Whether you invoice for those changes immediately is up to you - you can actually update the subscription and not charge for those changes until the END of the billing cycle (which I think is more in line with what you want)

flint ledge
#

Yes

#

and in the next billing cycle, will the customer be charged upfront for the number of members that were present at the end of the previous billing cycle?

jade jackal
#

correct

#

So it would be a bit of a blend - you'd charge up front for the # of members at the start of the billing cycle, but you'd wait to charge for all changes until the end /start of the NEXT cycle

#

Does that make sense?

flint ledge
#

Yes that works fine.
So, how does posting the charges to the end of the billing cycle works, in order to cater all the changes made during the billing cycle?

#

Will i have to call update-subscription with anchor or set the trial?

jade jackal
#

When you update the subscription all you need to do is make sure that you set proration_behavior: create_prorations (https://stripe.com/docs/api/subscriptions/update#update_subscription-proration_behavior). This will generate proration invoice items that account for the changes being made, and we'll automatically add them to the next subscription invoice

Stripe API reference – Update a subscription – curl

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

flint ledge
#

oh.. so it will directly add the charge to the next subscription invoice after making the adjustments?

#

Just** proration_behavior=create_prorations** parameter is enough to achieve this?

jade jackal
#

yup!

flint ledge
#

okay, let me try this quickly

jade jackal
#

👍

flint ledge
#

is proration_behavior=create_prorations a default behaviour in the subscriptions?

jade jackal
#

Yes, create_prorations is the default value for proration_behavior but I do want to clarify - this is something you need to be setting with EACH update request. It's not a sticky parameter that is persisted on the subscription