API Revenue OS / Platform — deploy next to Kong, WSO2, or Apigee; not a gateway replacement.
Revenue built in — not bolted on
Financial correctness is infrastructure — not an integration between your gateway and someone else's billing SaaS.
API Revenue OS — not an API gateway
Finno is not a typical API gateway. It is the API Revenue OS you deploy alongside your existing ESB or gateway — unifying metering, billing, and double-entry accounting on the consumption path.
Instead of Kafka + Stripe + custom billing + a reconciliation team (while keeping your gateway), one revenue platform on your own infrastructure.
Every API request is charged and recorded before the response returns — revenue you can explain, not reconstruct.
What revenue infrastructure gives you
Executives don't buy API gateways. They buy control over revenue, trust, and accountability.
Immediate revenue
When value is delivered, usage is metered and charged — not queued for a billing job tonight. Every request becomes recorded revenue before the response returns.
Explainable by design
Every charge traces to a request. Finance gets audit-ready reports — without rebuilding from logs.
Durable at scale
Raft-replicated charges, sub-250 µs overhead, and 10k–50k req/s per cluster. Revenue infrastructure that scales — not another reconciliation bottleneck.
Every digital action creates value.
- Every unit of value deserves accountability.
- Every request should be measured, authorized, charged, and recorded the moment it happens.
We believe revenue should never depend on reconciliation jobs, missing events, or delayed accounting. Finno exists to make digital commerce trustworthy by design — not just billing. Not just accounting. The revenue infrastructure for the API economy.
Read our storyCatch revenue leaks before the next invoice
Finno doesn't just charge requests — 23 background checks continuously scan your ledger, payments, settlements, usage rollups, and gateway telemetry. Every finding ships with evidence, money at risk, and a recommended next step — not a vague alert.
Zero hot-path overhead
The gateway emits facts; detection runs in the dashboard API against Postgres and gateway /stats. Request overhead stays under 250 µs.
23 checks: 17 deterministic + 6 statistical
From ledger balance to settlement failures, usage-rollup drift, overdue invoices, error floods, and survival mode — transparent rules first; statistical detectors calibrate in shadow before they alert.
Actionable findings, not log lines
Each item includes severity, money at risk, auditable evidence, an owner role (engineering / finance / SRE), and a concrete next step. Episodes stay open until acknowledged or resolved.
How it works
Gateway records facts
Every request, payment, ledger posting, and /stats signal lands in the Postgres mirror and gateway telemetry.
Background detectors run
A periodic loop in the dashboard API scans existing data with SQL and gateway fan-out — never touching the proxy hot path.
The anomalies board fills up
Admins see open items ranked by money at risk, acknowledge or resolve them, and get notified via email, Telegram, or other channels.
What we watch
Ledger & settlement integrity
- Debits = credits on every journal entry
- Settlement failures after a request was served
- Billable calls with zero provider (wholesale) cost
- Folded usage vs. raw facts — rollup discrepancy with diagnosed cause
- Missing CSV exports for audit and disputes
Collections & leakage
- Stuck pending requests missing from reports
- Repeated payment failures and overdue invoices
- Postpaid credit exposure nearing limits
- Sharp traffic drop-off from active customers
Gateway & upstream health
- Insufficient-balance (402) and throttle (429) spikes
- Upstream provider errors and timeouts
- Survival mode under host pressure
- IP-ban surges and monthly invoke-plan limits
Abuse & broken integrations
- Error floods from a single source IP
- Coordinated attack patterns in active IP bans
Detect, alert, and investigate — without touching the hot path
Anomaly detection finds integrity breaks and revenue leakage on your platform. The abuse investigation board rolls signals into reviewable episodes. Notification channels push critical findings to Slack, email, Telegram, WhatsApp, or your webhook — in the language you choose.
Anomaly board
23 background checks on ledger, payments, settlements, gateway telemetry, and usage rollups. Each finding: severity, money at risk, evidence, owner, next step.
Revenue abuse investigation
Nearline rules and anomaly signals roll into scored cases with an audit trail. Review, override, and escalate — enforcement stays off the request path until you enable it.
Alert channels
Configure webhooks, Slack, SMTP email, Telegram, and WhatsApp. Revenue anomaly and abuse alerts dispatch with cooldowns and a delivery log.
Stay up when upstream quotas run out or the host is under pressure
Two different kinds of failover: Raft keeps the cluster durable; service failover spills traffic to ordered fallback upstreams when a provider's shared quota is exhausted — consumer billed at the facing price, provider settled for what actually delivered. Survival Mode sheds load by value before the host collapses.
Service failover
Ordered fallback targets when service-wide concurrency or daily/monthly budget is exhausted. Backend-only services stay out of the consumer catalog but serve as spill targets.
Survival Mode
Host CPU/RAM vitals drive escalating protection: stop parking at Elevated, value-aware shedding at Critical/Lifeboat. Recovery is automatic — every mitigation is a pure function of the current level.
Gateway telemetry
Per-node /stats and /metrics fan out to the admin Gateway page — request rates, latency percentiles, Raft health, survival level, settlement failures.
Everything included — because fragmentation is the enemy
One system replaces the gateway + events + billing + accounting stack.
Quota + prepaid + postpaid
Three funding models on one API key with automatic fallback.
Graduated & volume pricing
Tiered packages that reward high-volume customers.
Margin visibility
Upstream costs vs. consumer charges — per service, per period.
Request transforms
Path rewriting, headers, and jq transforms compiled to bytecode.
Three dashboards
Admin, consumer self-service, and provider settlement views.
Global payments
Stripe plus extensible IPG with webhook-verified fulfillment.
Revenue anomaly detection
23 background checks on ledger, payments, rollups, and gateway telemetry — ranked by money at risk, with evidence and next steps.
Revenue abuse investigation
Signals from anomalies and nearline rules roll into scored cases with evidence and an audit trail.
Service failover
Spill to fallback upstreams when provider quota is exhausted — same consumer price, correct provider settlement.
Uninvoiced exposure
Admin overview shows gross revenue and profit not yet on an invoice — finance sees exposure before the billing run.
Integration clients
HMAC-signed machine credentials for ERP and partners — same routes as the panel, default-deny scopes, optional virtual services.
Corrective adjustments
Maker/checker balance corrections for consumers and providers — goodwill, SLA, rate fixes, opening balances, dispute outcomes.
Billing disputes
Claim-file reconciliation that places every micro of difference in a named bucket, then settles through maker/checker adjustments.
Invoice, expose, and explain — from the same ledger
Range-based batch invoicing, printable invoice PDFs, uninvoiced revenue and profit on the admin overview, financial reports from a normalized ledger projection — plus corrective adjustments and billing disputes on the same books.
- Uninvoiced exposure Gross revenue plus postpaid charges not yet on an invoice; profit-at-risk when provider costs are tracked.
- Range invoice issuance Pick a period end in your timezone; cursor-based billing never double-counts.
- Invoice PDF + CSV Customer-facing PDF and audit CSV exports from the admin grid.
- Corrective adjustments (maker/checker) Signed consumer and provider balance corrections; dispute outcomes release through the same rails.
- Billing disputes Cases on invoices, settlements, or periods; claim-file upload; line-level reconciliation with an explicit residual.
- Supervisor role Read-only operators scoped to assigned services; provider keys scrubbed at the API layer.
- Proactive consumer alerts Email/SMS when wallet balance or credit usage crosses configured bands.
Connect systems, correct balances, close disputes
Three cold-path capabilities: machine credentials for ERP and partner systems, maker/checker corrective adjustments, and claim-file billing disputes — without touching the metering hot path.
Integration clients
HMAC-signed credentials for the dashboard API, default-deny scopes, and virtual services for work that happens outside Finno — no sharing of an operator’s browser session.
Corrective adjustments
Goodwill credits, SLA refunds, rate corrections, and opening balances. One operator proposes; a different one approves — separately for consumers and providers.
Billing disputes
Consumers or providers open a case, upload a claim CSV, and Finno places every micro of difference in a named bucket. Resolution settles through the same maker/checker adjustment rails.
Onboard services in minutes, not sprints
- Step-by-step service guide in the admin dashboard
- Import from cURL/Postman for fast service setup
- Integration clients with HMAC-signed access for ERP, CRM, and partners
- Virtual services to meter work delivered outside Finno
- Admin analytics with period comparison and local timezone
- mTLS client certificates with application-layer pinning (Sovereign tier)
Traditional competitors by category
Comparison table
| Capability | Typical stack Kong + Metronome + Stripe + custom ledger | Finno |
|---|---|---|
| Architecture | Separate gateway, events, billing, accounting | Proxy + ledger in one system |
| When revenue is recorded | Hours or days later | Before the response returns |
| Nightly reconciliation | Required | Not needed |
| Double-entry accounting | Custom build or export | Six built-in accounts |
| Reserve funds before upstream | Rarely | Always |
| Billing gap | Yes | No |
| Lost billing events | Possible | Prevented |
| Self-hosted / air-gapped | Limited | Full support |
| Audit-ready financial reports | Separate integration | Built in |
| Revenue anomaly detection | Separate monitoring / manual reports | 23 built-in background checks |
| Machine integration clients | Scripts sharing operator sessions | HMAC credentials with scoped reach |
| Corrective adjustments | Spreadsheets / side ledger | Maker/checker on the real books |
| Billing disputes | Tickets and manual matching | Claim file + full difference decomposition |
Finno's key differentiators
Proxy + ledger in one system
Competitors: Gateway → Events → Billing → Accounting. Finno: Reserve → Upstream → Finalize — no gap, no reconciliation, no lost events.
Built-in double-entry accounting
Most competitors track balances. Finno maintains six accounts — Float, Receivable, Wallet, Owed, Deferred Revenue, Revenue — audit-ready from day one.
Real-time spend authorization
Funds are reserved and credit verified before upstream runs. The financial exposure of post-billing systems disappears.
Self-hosted & government-ready
On-premise, air-gapped, and national operators — where SaaS competitors cannot go.
Built-in revenue anomaly detection
23 background checks on ledger, payments, rollups, and gateway telemetry — from accounting integrity to settlement failures and overdue invoices. Every finding ships with evidence and a recommended action, with zero hot-path overhead.
Integrations, adjustments & disputes
Machine credentials for ERP, maker/checker corrective adjustments, and claim-file billing disputes — on the same books, not a side spreadsheet.
The hidden competitor: your internal team
The biggest competitor is engineering teams building Kafka + Stripe + custom billing + a reconciliation team — while keeping Kong or WSO2 for traffic. Finno replaces the monetization stack, not your gateway.
Stop building monetization infrastructure. Deploy Finno next to your gateway.
Deploy once. Charge forever.
Stop paying for three vendors and one reconciliation team.