Skip to main content
Usage-based billing charges a customer for a measured quantity. That quantity can be tokens, requests, compute time, or a product-specific action. Token billing is one form of usage-based billing, not a synonym for it. The model works when you can explain the unit to the customer and measure it consistently. Use this page to understand the billing flow before choosing a destination or implementing metering. The pricing-model comparison helps you decide whether usage should be the entire price or part of a subscription with an allowance.

​
Metering lifecycle

The flow begins when your app makes a model call for an authenticated customer. The inference provider returns usage, and the Narev SDK can capture that usage through middleware. Customer Tagging connects the generation to the user or tenant who should receive the charge. Obtain that identity from trusted app state so a client cannot assign its usage to a different customer. Next, the integration resolves cost or prepares usage quantities for the destination. A token count and a dollar cost are different units. With a cost-based meter, the event can carry a normalized cost amount; with an itemized meter, the destination receives quantities that its configured rates price. The Narev Cloud billing integration overview links to the supported setup paths. The billing provider then aggregates accepted events according to your meter and customer contract. Receiving an event does not by itself create a bill: the customer must have the relevant product or subscription, the event must match the meter, and the meter’s unit and price must agree. Your app also needs a policy for allowances, credits, refunds, and failed tasks when those are part of the offer.

​
Keep units and customer identity consistent

For a cost-based example, one USD equals one billion nanos. If a destination sends cost in nanos, a dollar-valued meter would be wrong by a factor of one billion. Dollars and cents differ by a factor of 100. Confirm the event payload, aggregation, and product price together before accepting the first charge. A stable customer identifier matters just as much as the numeric unit. In the Polar integration, the configured userId tag maps to the customer’s externalId. The chatbot guide walks through verifying that relationship. A correctly priced event assigned to the wrong customer is still a billing failure. Keep provider cost separate from the amount you sell. A $0.002 inference cost may contribute to a larger customer charge or fall inside a subscription allowance. Metering gives you the evidence to implement that policy; it does not ensure margin or enforce an app spending limit by itself.

​
Verify the complete flow

Start in the billing provider’s test environment. Create a test customer, make one model request, and inspect the captured usage and resulting destination event. Confirm the customer ID and unit conversion, then check that the meter aggregate changes by the expected amount. Finally, inspect the test bill or charge preview under the configured product. Repeat with multiple requests, a completed stream, and the failure or retry paths your app supports. An inference retry may incur new provider cost, while redelivering the same billing event should not create an accidental duplicate charge. Check how the destination handles duplicate events and preserve event identifiers where your integration requires them. Reconcile app records against accepted destination events over a closed reporting window. Investigate missing usage, customer mapping failures, duplicate deliveries, and unit mismatches before relying on invoice totals. For historical observations without costs, Langfuse backfilling repairs estimates; it is a separate operation from sending customer billing events.