Most billing platforms force a product decision early: prepaid or postpaid, subscription or pay-as-you-go, self-serve or enterprise. Pick one model, ship it, and bolt on exceptions later — separate Stripe products, manual credits, sales-ops spreadsheets.
Real platforms do not look like that.
Your hobbyist developers want a wallet and a credit card top-up. Your growth-stage teams want predictable monthly quota. Your enterprise accounts want net-60 invoicing with a negotiated credit line — and they still burst over quota during launch week.
Finno treats these not as competing “plans” but as funding sources on one account, resolved automatically on every request with a single API key.
The three funding sources
1. Quota subscriptions
A consumer buys a fixed allocation — API calls, tokens, bytes, or milliseconds — for a billing period. Each served request decrements the remaining quota for the enrolled plan.
Best for: Standard, team, and enterprise tiers where buyers want predictable spend caps.
Behavior: When quota is exhausted, Finno does not stop the world. It falls through to the next funding source in your precedence ladder (wallet, then credit) — or returns 402 if nothing remains.
2. Prepaid wallets
Consumers deposit funds (via Stripe Checkout, local IPG, or admin adjustment). Each request debits the wallet in real time after metering.
Best for: Developers experimenting, pay-as-you-go buyers, markets where invoices are friction.
Behavior: Top-ups commit through the same ledger as usage. A confirmed deposit is visible to the hot path immediately after reconcile — no “balance updates hourly” disclaimer.
3. Postpaid credit
Consumers spend against a configurable credit limit. At period end, Finno generates an invoice for the outstanding receivable balance.
Best for: Enterprise accounts with procurement workflows, net-30/60 terms, and established credit relationships.
Behavior: Reserve checks wallet first, then available credit headroom. Receivable posts to the double-entry ledger as usage accrues — finance sees exposure before the invoice is sent.
One key, one integration, automatic fallback
Here is a realistic month for a single consumer on one API key:
| Week | What happens | Funding used |
|---|---|---|
| 1 | Within Pro plan — 500k tokens/month | Quota |
| 2 | Launch spike exhausts quota | Wallet (auto top-up via Stripe) |
| 3 | Wallet depleted mid-demo; credit limit allows finish | Postpaid credit |
| 4 | Finance receives invoice; consumer pays via dashboard | Repay clears receivable |
The developer never changed API keys. Your sales team never filed a “billing exception” ticket. Finno walked the ladder:
quota (subscription) → wallet (prepaid) → credit (postpaid) → 402Precedence is configurable per product — but the resolution is always server-side, deterministic, and replicated through Raft so every node agrees on the funding decision.
Pricing models stack on top
Funding answers where money comes from. Pricing answers how much each unit costs.
On the same account, Finno supports:
- Flat per-unit — $0.002 per call, regardless of volume.
- Graduated tiers — first 1M tokens at one rate, next 4M at another.
- Volume tiers — unit price changes based on total period usage.
Pricing runs at Finalize time using period-to-date usage counters — so a graduated tier crossing mid-request is handled correctly with integer micros, not spreadsheet approximations.
A consumer can be on a quota subscription and a graduated token package and draw overages from wallet — because funding and metering are separate concerns wired together in one command flow.
Why competitors make you choose
| Platform | Typical limitation |
|---|---|
| Kong / AWS APIM / Apigee | Quota enforcement only — no monetary billing |
| Stripe Billing | Subscription or metered — not both natively on one key with wallet fallback |
| Lago / Metronome / Orb | Strong metering — but async events reintroduce the billing gap; no native proxy |
| Zuplo | Gateway + Stripe — no unified ledger or simultaneous funding ladder |
Finno’s differentiation is not “we support three pricing pages.” It is that all three funding sources share one ledger, one reserve/finalize flow, and one invariant — checked before the response returns.
What you configure vs what consumers experience
You configure:
- Plan definitions (quota, period, price)
- Wallet top-up providers and minimum balances
- Credit limits and invoice terms
- Funding precedence and overage policy
Consumers experience:
- One API key
- Immediate
402when truly out of funds - A self-service dashboard showing quota remaining, wallet balance, and open invoices
- No billing SDK in their application code
They should not need to know whether this request drew from March quota or yesterday’s Stripe top-up. That is infrastructure — not their problem.
When to use which model
| Persona | Start with | Expand to |
|---|---|---|
| Indie developer | Prepaid wallet | Quota plan when they upgrade |
| Growth team | Quota subscription | Wallet for overages |
| Enterprise | Postpaid credit | Quota caps for departmental budgets |
| Marketplace / reseller | All three | Provider settlement from the same ledger |
The point is not to pick one row. It is to grow across rows without replatforming billing.
Three billing models on one API key is not a marketing checkbox. It is a funding ladder implemented in the same state machine that proxies your API — so every customer type shares one integration, one ledger, and one source of truth.