Usage billing
Meter every call. Bill every period.
Record usage as it happens and let the period bill itself, against the same wallet authorization that carries the rest of the subscription.
Start meteringSandbox keys and test chains. The same code moves to live.
sub_4Kd9
Metered · monthly on Base
Included in Pro Plan
1,000,000
38.41 USDC
Billable this period
1,284,922
Usage records posted
Meter it, watch it, and bill it on one rail.
app.reclack.com/usage
Records posted this period
- api_requests48,21022:07:41.102
- api_requests51,88422:07:44.310
- seats1422:08:02.771
- compute_minutes1,20422:08:19.446
- api_requests46,00322:08:51.015
Each write carries an idempotency key. Posting the same record twice counts it once.
What you get
Metered billing without the spreadsheet
Metered or fixed
A price is billed either way, so a plan can move between the two without a migration.
Exact arithmetic
Usage totals and amounts are integers end to end. No floating point ever touches money.
Idempotent writes
Retry a usage record safely. The same key records it once.
One authorization
A variable amount still collects against the limit the customer approved.
Period invoices
Each period produces a real invoice with a PDF, not a surprise charge.
Sandbox first
Run a full metered period on test chains before a real customer is billed.
Your application
The period, event by event
Metering is a loop between your product and your billing. Both ends should know where it is.
$ reclack logs tail --events --format=json
- 22:07:41.102 POST usage.recorded 201 142ms 284,922 billable requests
- 22:07:41.884 POST invoice.opened 200 96ms INV-00219 · 38.41 USDC
- 22:07:44.310 POST payment.confirmed 200 118ms 0x2e2d…f306 on Base
- 22:07:44.907 POST invoice.paid 500 2004ms Receipt emailed
- 22:07:46.915 POST subscription.renewed 200 134ms Next period open
Reclack-Signature: t=1792447200,v1=5d41402abc4b2a76b9719d911017c592
$
Signed and retried
Each delivery carries a signature and a timestamp, with up to six attempts if your endpoint is down.
Safe to replay
Usage writes take an idempotency key, so recovering from an outage cannot double-bill a customer.
Or read it back
The subscription carries its running total, its allowance and everything collected so far.
In detail
Everything metering has to get right
Usage billing goes wrong in arithmetic and in double counting. These are the parts that stop both.
Recording usage
- Posted through the API as your product produces it
- Idempotency keys so a retry cannot double-count
- Attached to the subscription being metered
- Recorded continuously or batched on your own schedule
Pricing a meter
- An included allowance, then a rate beyond it
- Rates priced in USDC and held in atomic units
- Fixed and metered plans against the same catalog
- Several prices against one product
Closing a period
- Billed in arrears on what was recorded
- A real invoice with a PDF per period
- The usage figure shown beside the amount
- One invoice per period, enforced in the database
Collection
- Charged against the authorization already signed
- Never more than the approval allows
- Followed to a confirmed state before being marked paid
- Retried on a spaced schedule when the customer can fix it
Arithmetic
- Money held in integer atomic units throughout
- No floating point anywhere near a charged amount
- Rounding decided once, at the point the invoice is written
- The same figure on the invoice, the receipt and the chain
Visibility
- Running totals in the dashboard
- The same figures in the customer portal
- usage.recorded and invoice.opened events
- Sandbox meters on test chains
Rules
How a metered amount is arrived at
A bill your customer cannot check is a bill they will argue with. Every figure here has a stated origin.
Integers, always
Amounts live in atomic units from the meter to the chain. Floating point never touches money that will be charged.
Counted once
Usage records take an idempotency key, so a network retry on your side cannot bill your customer twice.
Capped by the customer
A metered period is still bounded by the approval they signed. Usage cannot quietly exceed what they agreed to.
Shown before it is charged
The running total is visible to you and to them while the period is open, not revealed in an invoice at the end.
Explained on the invoice
The bill carries the usage figure that produced it, so a question about the amount has an answer on the document.
One rail
Metered plans use the same invoices, retries, receipts and events as fixed ones. There is no second system to learn.
Illustrations on this page use sample data.
Questions
Before you meter
- When is usage billed?
- In arrears. The window is the period that has already elapsed, so a metered customer is charged for what they used rather than for what they might.
- What if usage exceeds the approval?
- The charge is clamped to the cap the customer authorized onchain. The merchant is paid the most the authorization allows rather than the collection failing outright, and the shortfall stays visible on the invoice.
- Can we post usage once at the end?
- Yes. Post as it happens or send one rollup when the period closes; the idempotency key means a retried rollup records once.
- Is agent spending supported?
- Not yet. Usage billing is live today; agent spending and automatic swaps are planned, and the site says so wherever they appear.
The rest of the stack
Bill consumption, not estimates
Meter in your product, collect in USDC, settle to your own address.