How usage-based billing works (and when it beats a flat subscription)

Usage-based billing means the invoice follows what a customer actually consumed: minutes transcribed, API requests served, gigabytes stored. It replaces the guesswork of picking a tier up front with a bill that grows and shrinks with real use.

The three ideas

A meter is the thing you count (ai_minutes). An event is one measurement of it (4.5 minutes, for customer X, at 14:02). A price turns a cycle's total into rupees — per unit, in tiers, graduated, or by volume — often with a free allowance first.

A Kathmandu example

Himalayan AI charges रू 1.00 per minute for the first 1,000 minutes a month, रू 0.80 up to 5,000, and रू 0.60 after that, with the first 200 minutes free. A customer who used 2,160 minutes in Kartik owes रू 800 + रू 928 = रू 1,728 before VAT. Tola Pay does this arithmetic when the cycle closes and puts the line on the invoice next to the base plan.

Why retries matter

Services retry. If your worker sends the same event twice, you must not bill twice. Tola Pay uses transaction_id as the idempotency key: send the same ID again and the API answers 202 with status duplicate and counts nothing. That one field is what makes usage billing safe to run from real infrastructure.

When a flat plan is still better

If your cost per customer barely changes with use, a flat subscription is simpler to sell and forecast. Many Nepali SaaS teams land on a hybrid: a base plan for predictability plus one or two meters for the parts that genuinely scale.