#lennard.

1 messages ยท Page 1 of 1 (latest)

violet oarBOT
rose oasis
#

Hi ๐Ÿ‘‹

What do you mean "trigger a new metered billing"?

dry quarry
#

Do I just store cus_OYhHfYSIEWoiIB

rose oasis
#

That does not make sense

dry quarry
#

eg. they make a new request, add one to their billing

dry quarry
rose oasis
#

Gotcha, okay

#

So you have created a Subscripiton for this customer with a usage based price?

dry quarry
#

Right, I will share it

#

Sorry @rose oasis, wrong image. This is the actual one.

rose oasis
#

Okay I didn't need to see it, just that you have created this beforehand

dry quarry
#

Yes and the test sub is on that pricing

#

Would I save any more info other than price id and customer id on the db?

rose oasis
#

So, you remember that recurring billing pricing model I sent you?

#

All the information is there

dry quarry
#

Thanks

#

So the only 2 things I need to store in the user object, is the customer id and subscription id?

rose oasis
#

No, that is not what that document says

#

The code snippet for reporting usage records clearly shows you need the Subscription Item ID

rose oasis
#

What do you mean, talking generally? I thought we were discussing specific API actions and how to achieve your desired behavior

rose oasis
#

But in general, you can choose to store only the customer and subscription IDs, and you can look up the other related information through the API.

But you would likely want to keep either the Subscription Item ID or at least the Price ID that corresponds to the usage-based price so you know which subscription item ID to use when you create the usage records

#

So I would recommend you think through how you are going to write your integration. How it is going to track your customers usage and report that to Stripe. Figure out what information you will need to store locally to make that work based on your own logic and the parameter required to make the necessary Stripe API calls.