#rad_api

1 messages ¡ Page 1 of 1 (latest)

undone moonBOT
#

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

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

warm rampart
#

Hi, let me help you with this.

proper wadi
#

hello, awesome!

warm rampart
#

So you're expecting credit amounts to decrease as you report usage?

proper wadi
#

exactly

#

my understanding was, the ledger amount will decrease after the invoice is finalised, but the "available credits" amount will decrease per event received

warm rampart
#

Credits only apply to payments, not usage, therefore it only applies when the next Invoice is created.

#

You can use this feature to give your users, for example, X units for a fixed price, compared to if they paid for usage normally.

#

I.e. it allows you to sell units in bulk

proper wadi
#

What should I use to support this scenario, e.g Customer pre-pays $10. Then, every time an action is triggered, it sends the usage event that adds usage with the unit price on it. And that depletes the credit up to the point they've used all the credits and can't use the service anymore?

#

I wouldn't want to implement credit tracking solution on our side, the part I miss is the real time evaluation on available credits

warm rampart
#

Credit usage is something you should track on your side, as it doesn't directly relate to payments.

proper wadi
#

Thanks!

Assuming this scenario, let's say I add the usage-based credits via one-time invoices as recommended. Then I'm sending the metered events that will reduce the credit on invoice finalisation.

If I need to store the usage and credit amount on our side, how does this compare with just one-time payments for credits that are reflected only on our side, and then, instead of sending metered events, I need to deplete the credit held on our side or block the access if credits are 0.
That would take out the metered usage events completely out of the equation, and my impression was that these metered events are exactly to support this case?

warm rampart
#

Yes, if you only allow the customers to use their purchased-in-bulk credits, you don't need Meters API.
Meters API is for when the amount to pay is calculated based on the usage.

proper wadi
#

So the Meters API can't work as pre paid usage solution, is that correct?

#

Because I want to calculate the amount to pay based on usage, that part is correct. But I want to check if that amount doesn't exceed the available pre-paid credits when the next usage is triggered.

warm rampart
#

I don't quite understand. You want the customer to pay a fixed amount or a variable amount?

proper wadi
#

I want pre-paid solution. Let's say one SMS costs $0.10. The customer has paid the amount they wanted, let's say $1 and received that as Credit that will be consumed by metered usage. So they should be able to send 10 SMS for $0.10 each. I wanted to check available credits before triggering SMS send, and if the credit is used, stop SMS send action.

#

Because meter events don't affect the credit real time, theoretically they could pre-pay just for $1, but send unlimited amount of messages, resulting in invoice to be paid minus the credit depleted. (-$1)

warm rampart
#

Okay, that's not usage-based billing.
You just create an Invoice for an amount, and then track credits on your side.
Because in your case the amount is based on the prior customer choice. In usage-based billing the amount is based on the usage.

undone moonBOT