> ## Documentation Index
> Fetch the complete documentation index at: https://docs.useunitpay.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Welcome to UnitPay
> The billing engine for dollars and credits — both first-class, same platform, same API.
## 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 |
You don't choose one for your whole business. You choose per plan, and you can use both at once.
## 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:
A monthly credit allowance plus daily free credits, burned per message. Pure **credit billing** with recurring and drip grants.
A prepaid balance burned down per token. **Both paths at once** — metered usage drawn from a prepaid balance, with dollar overage.
Flat tiers — Free, Plus, Pro — with usage caps. **Dollar subscription** plus entitlement gating, no metering.
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. |
You can build all of this twice — once for dollars, once for credits — or model it once in UnitPay.
## 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
The one model behind both billing paths, and the objects you'll use.
Model a plan, grant credits or set a price, and see it work end to end.