How it works
Your app sends usage events, such as 1,200 tokens or one API call, to a meter. At the end of the period the billing system sums the events for each customer, applies the price and any tiers or discounts, and creates an invoice that is charged to a card on file or sent for payment.
The trade-off is risk and accuracy. Usage events must be reliable, because a lost event is lost revenue and a duplicated one is an overcharge. And because service is delivered before payment, a declined card at the end of the month leaves you with an unpaid bill for costs you already incurred, such as model inference.
Example
A customer makes 180,000 API calls in March at $0.002 per call. On April 1 they are invoiced 180,000 × $0.002 = $360. If their card declines, you have already paid your upstream provider for those 180,000 calls and now have to collect $360 through retries and dunning emails.
Metered billing in Cred
cred.diy is prepaid rather than metered: customers buy credits first and each use is deducted immediately, so a balance can never be consumed without having been paid for. Subscriptions add a credit allowance after each paid invoice rather than billing usage in arrears.
Managing Credits docsQuestions
- When is metered billing a better fit than prepaid credits?
- Metered billing suits larger customers with contracts and procurement processes who expect an invoice, and products where usage is hard to predict in advance. Prepaid suits self-serve buyers and products with real per-use costs.
- Can I combine metered billing with credits?
- Yes. A common pattern is prepaid credits for normal use and metered overage once the balance is exhausted, though that brings back the collection risk prepaid was meant to remove.
