Charge anything. See everything.
Any pricing model you can describe. Every charge, retry and cent accounted for — through the processor you already use.
Early access · every workspace starts in test mode — no processor or card required
Overview
Test environment · no production data or money
| Invoice | Customer | Amount | Status |
|---|---|---|---|
| inv_8fa21c | Northwind Trading 3rd attempt · stripe | $4,820.00 | recovered |
| inv_71b0e4 | Corvus Analytics next in 3d · adyen | $1,240.00 | retrying |
| inv_5c93aa | Meridian Health 1st attempt · stripe | $18,600.00 | paid |
| inv_2ad7f1 | Ashgrove Labs ACH · settling | $960.00 | pending |
| inv_44e0b8 | Pallas Robotics hard decline · 04 | $7,315.00 | failed |
Bill an agent product
Tokens, credits, per-action. Input and output priced apart, per model.
See every attempt
Full charge and retry history per invoice. The trail is the record.
Keep your processor
Your merchant agreement. Your rates. Your vault. No re-tokenising.
Bring the processor you already have a merchant agreement with
Your processor should be a choice, not a dependency.
Most billing platforms quietly become the payment layer too. Separate the decision from the execution and it stays yours.
Billing decides. Payments execute.
Split them and either can change without a migration.
A decline is a routing problem.
One vault means every retry hits the same wall.
Scope not taken is scope not audited.
References only. No card data, no PCI.
01Agent & token billing
Know which model is losing you money
Price input and output separately, per model, at sub-cent precision. Provider cost rates against the same cells — so margin is per model, not a blended average hiding the loss-maker.
See the billing engineai_tokens · rate card
| Model | Type | Price | Provider cost | Margin |
|---|---|---|---|---|
| gpt-4.1 | input | $3.00 | $1.50 | 50% |
| gpt-4.1 | output | $15.00 | $7.50 | 50% |
| opus-4.8 | input | $3.00 | $5.00 | −67% |
| opus-4.8 | output | $15.00 | $25.00 | −67% |
| (catch-all) | — | $4.00 | untracked | 0% |
02Billing engine
Meter, rate, invoice, recognise
Usage becomes tiers, tiers become invoices, invoices become collectable. One workflow.
Every pricing model03Dunning engine
From brittle to unmissable
A durable workflow, not a cron job. Next Tuesday's retry still fires after a deploy, a restart, or an outage.
How the engine worksinv_8fa21c · Northwind Trading
$4,820.0004Connector framework
One port, every processor
The engine never branches on a vendor name. Cross-processor retry is a routing decision.
Read about the seam// One port. Every processor implements it — pre-built or your own. // The engine never branches on "if stripe". type Connector interface { Name() string Charge(ctx, Instruction) (Result, error) Refund(ctx, RefundRequest) (Result, error) } // An Instruction carries PSP-minted references only. Never a PAN. type Instruction struct { CustomerRef string // cus_… minted by the merchant's PSP MethodRef string // pm_… minted by the merchant's PSP AmountMinor int64 // integer minor units — no floats, ever Currency string } // Cross-PSP retry is just a different connector name on a later attempt. registry.Register("stripe", stripe.New(creds)) registry.Register("adyen", adyen.New(creds)) registry.Register("acme", yourOwnConnector)
05The boundary
Out of the money path
We see references, never card numbers. Funds settle straight from your PSP to your bank.
Talk through your setupEvery model, one engine.
Combine them in one plan. Simulate a change against a customer's real history — or usage that doesn't exist yet — before you ship it.
Built like money software.
Durable by construction
The attempt history is the audit trail.
Integer money math
Minor units end to end. No floats.
amountMinor int64 = 88000 // $880.00 USD, exact // never: // amount float64 = 880.00
Test and live, truly apart
A rehearsal can't be mistaken for production.