01
Usage outgrew the rating engine
Minutes, messages and fax pages rate cleanly. The inference, the API call and the machine hour billed to that same customer never reach the engine — and those are the lines they now question.
Usage billing for vCons · voice, messaging, fax · release 0.1
Bill anything
expressible
as a vCon.
A call. A message. Three pages of fax. Then the AI inference and the machine hour that landed on the same customer. Send us the vCon; we work out who owes for it, price it, charge it, and hand back a signed receipt you can put in front of that customer six months later.
voice minute/message delivered/fax page/ai inference/door entry/forklift runtime/document analysis/data egress/sensor hour/
One vCon in, one priced charge out.
Illustrative data
What happened
What we work out
What lands on the bill
Charged
POSTED · 1 CHARGE
Revenue escaped the rating engine.
02
Every vendor invents a log
Each new usage source arrives with its own CSV, webhook or database view. Integration cost scales with vendor count, and none of it is signed.
03
Record and charge diverge
Evidence of what happened lives in one system, the charge in another. Six months later nobody can reconstruct the decision that produced the amount.
Six stages. The order is load-bearing.
Canonicalize before hashing. Resolve identity before pricing. Freeze pricing before authorizing. Authorize before accounting.
The format doesn't care what the event was.
Voice, messaging and fax are where vCons already live, and where we start. The same envelope carries anything else whose usage reduces to a quantity or a session — the gateway treats them identically.
| Event | Source | Unit | Qty | Rate code | Mode |
|---|
Billing Handles
A handle is whatever your source can actually assert: a fob ID, an agent name, an extension, a vehicle tag. It is not an account number, and it should not have to be.
Resolution walks a time-bound graph from that handle to the account that pays. Every edge carries a validity window, so a fob reassigned in March still charges the tenant who held it in February.
cst234_fob:F0B-8842 └─ fob → asset valid 2026-01-04 → open └─ asset → site valid 2025-11-20 → open └─ site → account valid 2025-11-20 → open → Customer 234 / Account 1000456
Resolved at event time, not submission time. The path is stored with the operation and replayed on dispute.
Rules that hold when things go wrong.
Billing systems are judged on their failure modes. These are ours, stated before you ask.
A charge isn't revenue until it's collected.
Rating an event is the first step. What follows is the part nobody demos: tax, invoice, collection, and the retry schedule that decides whether the money actually arrives. It is already there, because the charge lands in a billing platform rather than a spreadsheet.
Taxation
Tax decided at rating time
Jurisdiction, tax code and rate are resolved when the charge is priced — not bolted on at invoice time. The decision is stored with the operation, so a question from a tax authority six months later replays like any other dispute.
Invoicing
Invoices a customer can actually read
Charges roll up on your billing cycle into invoices that itemise what happened — the call, the message, the fax page, the inference — with every line traceable back to the signed record that produced it.
Collections
Money moves without chasing it
Payment methods on file are charged automatically on the cycle. Failures retry on a schedule you set and escalate through dunning, so a declined card becomes a resolved payment instead of a write-off nobody noticed.
Payment providers
Settled through the rails you already use
Twenty-eight gateways, plus Bitcoin. Capability differs by gateway: cards on most, e-check and ACH on several, and tokenised credentials where the provider supports them — so card numbers stay with the provider rather than being re-keyed into the billing system. Adding or switching a provider doesn't change how usage reaches us.
Credit control
Limits that hold under load
Prepaid balances, postpaid credit limits and thresholds are enforced at authorization — which is exactly why a charge is reserved before it is posted. A low balance notifies. An exceeded limit denies, before commit.
Recurring & usage
Subscriptions and usage on one bill
Monthly plans, commitments, minimums and one-off fees sit on the same invoice as the usage we rate. Your customer gets one bill; you get one revenue picture instead of two systems to reconcile.
Settlement · 28 providers, plus Bitcoin
Stripe / PayPal / Authorize.Net / Worldpay / Chase / CyberSource / Fiserv / Worldline / Moneris / Skrill / Cielo
Full list — Authorize.Net · Bambora (Worldline) · Chase (Paymentech) · Cielo · CyberSource · CM (Docdata) · Fiserv (First Data) · GlobalCollect (Worldline) · Ingenico (Worldline) · Moneris · Netaxept · NetaxeptBBS · Nets · Payarena · PayflowPro · Windcave (PaymentExpress) · PayNearMe · PayPal · Plug'n Pay · ProxyPay3 · Remita · SecureHosting · SecurePay · Skrill · Stripe · Thunes · VCS · Worldpay (FIS)
Not every gateway does everything. Card, e-check and ACH, and token-based payment support vary between them — we'll tell you which of these covers your mix before you commit to one.
Bitcoin is settled too — a customer can pay an invoice in coin and it reconciles against the same balance as everything else.
Rating is the part vCon Ledger adds. Everything downstream — tax tables, invoice runs, collection schedules, dunning rules — belongs to the billing platform the charge is posted into, and at release 0.1 is configured with you during the design-partner engagement rather than self-serve.
You send vCons. We do the billing.
One endpoint. No middleware to run, no shadow ledger to reconcile. Your rate plans stay yours — we price against them and give the charge back to you with the evidence attached.
- Input
- vCon core draft-03, signed
- Interface
- HTTPS, one submit call
- Output
- Priced charge + receipt vCon
- Pricing
- Your rate plans, unchanged
- Retention
- Replayable operation record
Build status · release 0.1
Mechanism
One vCon in. An Access-Request out to authorize against the balance, then an Accounting-Stop carrying the actual units when the charge commits. Authorize-then-commit, over RADIUS — the protocol your switch already speaks, pointed at events that never came from a switch.
Everyone else speaks RADIUS inward, from network gear. We speak it outward, from arbitrary events: a door, an inference, a fax page, a forklift hour. Your engine doesn't need to know the difference.
Straight answer on maturity: session-style authorization and a timed accounting stop work today. Quantity-mode authorization — the path most non-voice events depend on — runs the same route but is not yet returning a live grant. That makes it the architecture, not a shipped capability, and this paragraph changes the day it is.
We're looking for four design partners.
Release 0.1 is a working prototype, not a product you can buy yet. We're starting with the operators and platforms already producing vCons for voice, messaging and fax. Partners run it against a sandbox with their own rate plans, and their usage source is what we build an adapter for first.
Tell us what you'd send us.
We read every one of these. The useful ones tell us what produces your usage today — a softswitch, a messaging gateway, a fax server, something stranger — and what you currently do to turn it into a charge.
Submissions go to the vCon Ledger team. We use what you send to reply and to plan adapter work; we don't sell it or pass it on. See the Privacy Policy.