#shanu_meter-credit-grants
sudden flumeBOT
👋 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/1374045714052677643
📝 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.
- shanu_api, 3 days ago, 6 messages
vivid ice
Hi there. Can you please help me? We are looking to implement this using Stripe. we have very large scale and expect high volumes.
We want everything to be stored via Stripe, and only cached on our side. We want to make full use of Stripe's webhooks system and stripe APIs to implement this.
autumn portal
Hi there 👋 have you already looked through our guides for this new feature that are linked to from the blog you shared; do you have questions about the content provided in those? Or have you already started testing and are running into a problem?
https://docs.stripe.com/billing/subscriptions/usage-based/billing-credits#credit-grant-eligibility
https://docs.stripe.com/billing/subscriptions/usage-based/billing-credits/implementation-guide
vivid ice
yes, we implemented both of these.
I am not able to figure out the reason of why meters are even required. I have a gap in my logical understanding.
since meters are only usage based, how can I top up "500 goodies per month" and "1800 goodies per month" in Goodies meter
and then how can I tell Stripe to first consume these "goodies" first every month. Only when these "goodies" are consumed, they should block the user and consume one-time bought "goodies" which have a longer expiry time say of a year.
So, there is a priority order in consumption of "goodies".
autumn portal
Credit Grants work by granting customers access to a certain amount of usage, so it has to be aligned with features that can be used to track that usage. The feature was built to work with Meter Events as the way of tracking usage, which is why Meters have to be used here.
Did you not see these being consumed in your testing? Did you play around with the priority parameter at all when creating the grants if so?
https://docs.stripe.com/api/billing/credit-grant/create#create_billing_credit_grant-priority
sudden flumeBOT
vivid ice
Yes, we tried this already. This works on credit grants only.
The problem, Toby, is the following:
- Problem 1: we want priority order on meters. Is that possible?
- Problem 2: how to add top-ups to meters? We want to add "500" goodies every month on subscription renewal. (Assume we have a metered product live on Stripe which is bound to "goodies")
I have this product live in sandbox for example.
random herald
Hi 👋
I'm stepping in as my colleague needs to go soon.
Problem 1: we want priority order on meters. Is that possible?
Can you decribe what you mean by this in terms of Stripe behaviors?
Problem 2: how to add top-ups to meters? We want to add "500" goodies every month on subscription renewal. (Assume we have a metered product live on Stripe which is bound to "goodies")
Wouldn't creating monthly credit grants address this? It is something you would have to schedule on your end but that isn't very hard.
vivid ice
let me send you an example from another product to help you understand this quickly. What our pricing system would look like.
Please clikc on pricing in the header.
Manus is a popular agent which allows a "credit" based pricing. They are giving 3900 credits per month in the "Plus" plan. The credits is their logic. Apart from that, after doing an Agent task, if you consume those 3900 credits, you can buy more credits in the month. Kind of like "add-on credits".
These 3900 credits are valid for 1 month and then refresh again the next month. The unused ones expire within the month.
These "add-on credits" are valid for 1 year
I am aiming to mimic this entire exact system
random herald
Okay and what about Billing credits does not allow you to replicate this functionality?
vivid ice
How can I build this kind of pricing system on stripe? That is the help needed if you can give directions.
Billing credits are only on actual $ values, right?
they cannot be associated with a non-monetory logic like "credits"?
random herald
Currently they are only monetary, yes.
vivid ice
how do I link both of them together then?
random herald
What do you mean, "link both of them together"?
vivid ice
how can I top up 3900 credits per month? In which object on Stripe do I store this and track it?
also, when I want to give say 750 add-on credits for 50$, which object do I store it in?
random herald
You would need to determine what the monetary value of those credits are and apply the correct billing credit
Your price per "credits" would need to reflect this
vivid ice
so, do I need to create a separate product (metered type) on Stripe for this? Would this be required?
and should I append it to a monthly subscription then?
or not required?
random herald
You can only use credit grants with metered prices, as my colleague has already explained.
I recommend creating multiple product/price pairs for the different types or values of these credits and applying whichever makes sense in your situation.
Adding metered prices to monthly subscriptions would allow you to automatically bill your customers on a regular cadence.
vivid ice
so, in our requirements, similar to manus: we want to stop the user from doing a task as soon as 3900 credits become 0.
The user is not shown the dollar value, but the 3900 value in the frontend.
The question is:
Option1: Do we require to send meter events and see this 3900 reduce to say, 3200, 2500, 1700, 1500, 500 .... 0 over time in the backend?
Option 2: Or we just track if those credits grants in dollars worth 3900 become zero in the backend?
random herald
You would send meter events to track the burn down of the credit grants. The metered Price object would convert the number of credits consumed into a monetary value wichi is how the monetary amount of the credit gets consumed.
I stronly recommend you build a very basic simulation of this. Just a few functions to create a mereted Price & Subscription for a Customer, add a Credit Grant, and then generate Meter events.
I think this whole process will make much more sense once you can see the API responses and webhook events for yourself.
vivid ice
yes, I did that already. I have it ready in my sandbox everything 🙂
Maybe, I am struggling with the logical understanding part of how this works.
So, 2-3 final basic questions. Sorry for bugging so much.
Question 1: Is meter object, according to you, credits (those "3900 Credits" one) then? Or it is Credit Grants?
random herald
Sorry that wording doesn't make sense.
The Meter object tracks usage, by recording the Meter Events and assigning that usage to a specific Price
Subscriptions link the Price to a Customer
Credit Grants are for specific Meter usage for a specific Customer
vivid ice
Okay. Let me rephrase. Please let me try one more time.
Assume a subscription renews on 19th May for a customer.
In that customer's account, would we add a new Credit Grant (in dollar value) every month? Can you confirm that?
random herald
Yes, you would add a new credit grant each month yourself. I recommend configuring your webhook listener to respond to invoice.paid webhook events to trigger this action.
vivid ice
okay, great. This part is clear now to me. Now coming to the second question which is where I am stuck.
In that user's UI,
- On 18th May, I want to show he has, say, 50 credits left
- On 19th May, I want to show he has (50 + 3900) credits left = 3950.
How can I show this particular part, considering I don't want to store anything on our DB and let Stripe track the credit consumption?
Is this part possible or not?
random herald
So you can check the credit grant balance when your customer visits your site and do whatever conversion you set up to go from the monetary value to the number of credits. On May 18 they have 50 credits left because they haven't used up all their monthly credits.
Then, when your webhook triggers adding a new credit grant, you check the customers balance and report on the higher amount
vivid ice
ah. Got it. Got it.
So, the last logical question to confirm:
Every time a metered event is done to Credits meter, internally it uses the Stripe product (metered one) to understand the conversion rate? And then deducts from Credit grant?
Is this the logic?
random herald
Correct. The Metered Price object converts the usage you report with the Meter Event into a monetary value and that value is deducated from the Credit Grant.
vivid ice
Got it. Fully understood.
Now, one more question. In the documentation, there are 2 types of Credit grant:
- Prepaid (with lower priority)
- Add-on (with higher priority)
When we do the Add-on, I understand credit grants with higher priority are attached to the customer.
When the meter events come, the conversion will happen based on Price object and stripe automatically deducts credit grants of the prepaid first? We don't have to do anything on our end or do we have more control here?
random herald
That is where you can manually add the priority parameter to change the priority of which credits get consumed first
If you want that level of control
For instance, if you wanted the Prepaid to have higher priority you could create the grant with priority: 10 and create the Add-on credit grant with a priority: 20. This would make the Prepaid grants the first to get consumed.
vivid ice
understood. Now, I am able to understand the data models to render the UI.
One final question. In our UI, since we are showing the credits left in user's account separately for:
- prepaid
- Add-on
This means we need separate credit balance left for each of the credit_grants. Is there any specific API to do that?
I understand credit_balance shows the entire summary.
random herald
Unfortuantely, that is something you would need to track outside of the Stripe APIs
vivid ice
got it. and credit_balance is updated real time as soon as meter event comes?
or only at the end of the month when invoice is run?
random herald
That is something I recommend you test.
vivid ice
Got it. Can you please keep this thread active for some time and not close it?
I will check sandbox in the meanwhile
random herald
We close threads due to inactivity and we do not re-open them. However, you can ask a new question about how credit balances are consumed and we will be happy to answer.
vivid ice
just 2 mins. Almost done.
I have created a video on the question. It is only showing up for me in the upcoming invoice: https://www.loom.com/share/836ba7a088a54df39d3dbd432a538e54
So, to understand what is a particular user's credit balance, is the only way the upcoming invoice section? Or is there a better way to get this?
random herald
Sorry I can't review a video (there are too many active threads). Can you explain, step by step what you are doing and what you see?
vivid ice
Sure. Here are the steps:
- I go to the customer subscription
- click on triple dots and do "View my upcoming invoice"
- on opening this, I see the following shown below. This is the only place I can see the future "credit grants" that will be applied for the user on say, 19th June.
random herald
You can can also query meter usage summaries but then you have to calculate the monetary amount yourself.
sudden flumeBOT