Implement usage billing
you can reconcile
The difficult part of metered billing is not displaying a unit price. It is proving that each invoice reflects the right customer's consumption, once, at the agreed rate.
14-day free trial · No credit card required
Write the rule before the integration
Agree what counts as consumption. For an API product, decide whether you charge for attempted requests, successful responses or completed jobs. Define whether internal requests, retries, cached results and customer cancellations count.
Write down the unit, included allowance, overage rate and billing period. A quantity called “storage” is ambiguous unless you specify a measurement such as GB consumed at a sampling point or GB-month. Choose a definition the customer can understand and your application can reproduce.
Keep this commercial definition separate from implementation details. The usage-based billing product page explains the available meter and allowance model; this checklist concerns the data you send and the tests you run.
Map your account to the order and meter
Keep a durable relationship between your application's account and the BillingServ customer and order. Confirm that the API key owns the order and that the metric name matches a meter configured on its package.
The usage event reference documents the request fields and response. Do not infer usage from a customer's email address or send the same aggregate to multiple active orders. Record the returned reference and the request correlation information needed for investigation.
Keep API credentials server-side. If you show usage in your customer interface, use an authenticated server-side request and expose only the account's authorised data.
Check below, at and above the allowance
| Total units in the period | Allowance | Rate above allowance | Expected usage charge |
|---|---|---|---|
| 90 | 100 | £0.05/unit | £0.00 |
| 100 | 100 | £0.05/unit | £0.00 |
| 105 | 100 | £0.05/unit | £0.25 |
| 120 | 100 | £0.05/unit | £1.00 |
Run these as independent test cases or reset the test data through an approved process. Do not submit all four totals as incremental usage events: that would represent a different quantity. Test small fractional prices and confirm rounding at the invoice boundary.
A timeout does not mean the event was rejected
Your sender should distinguish validation errors, rate limits and uncertain network outcomes. A timeout can occur after a request was accepted. Do not blindly resend billable usage without understanding the endpoint's duplicate-handling contract.
Keep a local event ledger with a stable source identifier, order mapping, quantity, send status and returned result. Confirm which operations support an idempotency key in the current API documentation. Do not assume that putting an identifier in arbitrary payload metadata makes the endpoint idempotent.
Plan how the team will investigate late events, cancelled orders, plan changes and a billing-period rollover. If the documented endpoint cannot express an adjustment you need, agree the supported process before launch rather than inventing a negative-usage workaround.
Compare application totals with billing totals
- Compare source events, accepted quantities and unbilled usage by order and metric.
- Explain every missing, rejected or potentially duplicate event.
- Verify included units and charged overage separately.
- Check the recurring fee and usage charge together on a representative invoice.
- Test the next billing period and any package changes you offer.
The usage demo is useful for understanding the workflow, not a substitute for testing your production integration. For the wider product setup, see SaaS billing and subscription management.
Test your usage model before launch
Try BillingServ with your products, customers and payment workflow.
No credit card required.