#rodney_api

1 messages · Page 1 of 1 (latest)

eternal jettyBOT
#

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

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

teal sinew
#

I guess the only tricky part here is that we want the monthly allowance for Free and Basic tiers but do not want to allow any overage

#

Other small ask for this, in the fixed fee and overage model, is it possible to set a bundle price of, for example $0.50/1000 units as opposed to $0.0005/1 unit, or is the default behavior of the bundle pricing to just do that math anyway (e.g. I use 200/1000 units in a bundle, so I am charged $0.10 for the 200 units)

native oracle
#

hey 👋 looking into this now!

teal sinew
native oracle
#

yep! i have to admit i haven't experimented much with transform_quantity but it should do exactly what you're suggesting if, for example, you pass in transform_quantity={"divide_by": 1000, "round": "up"},

#

i'm also a little unfamiliar with some of the advanced usage based pricing concepts but i'm working with one of my colleagues who is a little more familiar with them.

#

for now i do think the way you've described you're considering setting this up might be the best option, but i'm currently poking around to see if i can think of something better.

#

just to make sure i understand your original question, are you wondering if Stripe can manage tracking the usage for the "free" and "basic" products?

#

so that you're tracking usage consistently between all of the different pricing models?

teal sinew
#

Yeah exactly, i'd love to avoid application logic along the lines of "if this is a free or basic tier, post usage to internal db, if it's a higher tier send a meter usage event to Stripe"

#

and just have everything go through a meter usage event

#

a separate process will handle the question of "does this user have enough allowed usage for this request" so we don't need to worry about stripe handling the case of "requested 100 units on Free tier, but only 20 units remaining" etc.

native oracle
#

ok, so i think in that case you will need to track usage on your end. technically you can meter the usage on the free and basic tiers, but your application will still need to know when they've hit their cap so you can stop them from going over

#

so in short your application will be more reliable at stopping them from going over if it's all just tracked internally

teal sinew
#

Thanks for taking the time to look into this! Yeah I kind of figured that was the direction it would end up going, I think we've experienced the eventually consistent behavior of the meter events before and realized it's not a great system for doing things like usage checking

#

But it's vastly better than the legacy usage-based system haha. Appreciate it as always!