What is UnitPay?
UnitPay is the billing engine for products that charge in dollars, in credits, or in both. Most billing tools pick a side. Usage-meters (Orb, Metronome) are built to turn usage into a dollar invoice at the end of the month. Credit and entitlement tools are built to hand out balances and gate access. Real products need both — a plan price and a credit allowance, a prepaid balance and a dollar overage — and end up stitching two systems together. UnitPay is one system where both are first-class. You model what you sell once. Usage flows in once. From there it either becomes a dollar invoice you collect on, or deducts credits from a balance — often both, in the same plan. Same objects, same API, same dashboard.The two paths
Everything in UnitPay comes down to how value moves out after a customer uses your product:| Dollar billing | Credit billing | |
|---|---|---|
| When you charge | At invoice time — usage adds up, you bill later | At usage time — credits come off a balance instantly |
| The result | An invoice, collected by card or on NET terms | A balance that goes down and refills or tops up |
| Feels like | A monthly bill | A prepaid wallet or an allowance |
| Classic for | API metering, enterprise contracts | AI products, packs, plan allowances |
What you can build
These aren’t hypothetical models — they’re how products you already know bill their customers. Each one maps cleanly onto UnitPay:Lovable
A monthly credit allowance plus daily free credits, burned per message. Pure credit billing with recurring and drip grants.
Anthropic API
A prepaid balance burned down per token. Both paths at once — metered usage drawn from a prepaid balance, with dollar overage.
ChatGPT
Flat tiers — Free, Plus, Pro — with usage caps. Dollar subscription plus entitlement gating, no metering.
Claude.ai
Flat Pro and Max subscriptions. The simplest dollar billing case — a recurring price and access.
Numbers and exact tiers for these products change over time. UnitPay docs model the shape of each pricing pattern, not their live prices — the shape is what’s stable and what you’ll reuse.
Why use UnitPay?
Billing starts as one checkout and balloons in complexity as you scale. The list below is the work you’d otherwise build and maintain yourself — across both billing paths:| Area | What you’d build |
|---|---|
| Subscriptions | Checkout, proration, upgrades, downgrades, add-ons, trials. |
| Credit ledgers | Real-time deduction, recurring and one-time grants, rollovers, expiry, FIFO priority, concurrency. |
| Invoicing | Usage aggregation, line items, NET terms, dunning, collection, multi-PSP. |
| Entitlements | Feature gating per plan, boolean and metered features, seat allowances. |
| Controls | Spend caps, auto top-ups, overage handling, usage alerts. |
| Pricing changes | Versioning, grandfathering, migrations, backwards compatibility. |
| Enterprise | Contracts, rate overrides, minimum spend, custom invoice schedules. |
How is this different?
Usage-meters are built for post-hoc invoicing: you send events, they generate a dollar invoice at period end, and your app still owns access control and balances. Entitlement tools own balances and gating but don’t run real billing and collection. UnitPay does both as one system of record. Query it inline for a customer’s plan, entitlements, and balances; track usage once and have it land as an invoice line or a credit deduction. Because UnitPay owns the state, proration, failed payments, rollovers, and concurrency are handled for you. Pricing changes become configuration, not code. UnitPay connects to your payment processor (Stripe, Razorpay) for moving money — your customers and payment details stay in your own processor account.Next steps
How it works
The one model behind both billing paths, and the objects you’ll use.
Get started
Model a plan, grant credits or set a price, and see it work end to end.