What Neruba ships
Neruba Billing Engine puts access, ingest, billing runs, balances, payments, and operator tooling in one shipped surface so teams can inspect concrete capability coverage instead of translating claims.
Projects, tenants, and API keys define clean boundaries.
Usage intake stays traceable and replay-safe.
Schedulers and billing jobs produce repeatable outcomes.
Credits, payments, and operator tools close the loop.
Use capabilities when the review needs shipped product proof
Use this page when the review needs shipped surfaces: projects, keys, ingest, billing runs, wallets, payments, and operator workflows. It is the fastest product-detail route.
- You need feature-level proof that the product already covers the workflows your rollout depends on.
- Engineering, finance, and support want to inspect different surfaces without translating a generic product story.
- You are trying to decide whether to go deeper into architecture, operations, or implementation next.
- 1Use the overview and capability proof section to confirm the product areas that matter to your team are already shipped.
- 2Scan the capability cards in the same order buyers usually inspect the product surface.
- 3Use the next-step panel when the review turns from feature fit into rollout, architecture, or runtime questions.
Open architecture when the question becomes how those capabilities are partitioned and kept explainable under retries and support work.
Open operations when the review shifts from product surface to scheduler behavior, recovery, and deployment posture.
Open the rollout model when the team is already planning migration, validation, and cutover.
What the product surface lets teams configure, run, and support
From project-scoped API keys to usage ingest, billing runs, wallets, credits, payment flows, and admin actions, this is the product surface that matters once billing is live.
Tenancy, roles, memberships, and API-key issuance define the operating boundary.
Usage intake, pricing logic, and billing runs stay deterministic under retries.
Credits, balances, transactions, and operator actions stay visible after go-live.
See the shipped surface in the order real buying teams usually inspect it
The goal is not to show more tiles. It is to help engineering, finance, support, and product teams see how project boundaries, ingest paths, billing runs, money state, and operator actions connect before rollout risk becomes a debate instead of a review.
Project access, ingest, billing runs, money state, and support actions now read as one connected product loop instead of six unrelated feature buckets.
Engineering can spot retry and scheduler depth, finance can see the money controls, and support can see what happens after launch without translating the page for one another.
Replay safety, ledgered adjustments, project-scoped keys, and operator tooling stay visible enough to assess whether the product can replace fragile side systems.
Project access, idempotent ingest, scheduler locks, and migration discipline decide whether the implementation looks credible.
Wallets, credits, disputes, audit trails, and corrective actions decide whether the money model stays explainable.
The full surface shows whether one system can replace brittle add-ons without hiding rollout risk.
The surfaces teams usually review once billing starts carrying real operational risk
Memberships, invites, and API keys give teams a clear tenant boundary from the start.
Retry-safe ingest protects against duplicate charges from clients, queues, and relays.
Runs, locks, reruns, and sweeps make the operating model more believable.
Credits, adjustments, disputes, and admin actions remain explainable for humans.
Projects, tenants, and API keys
Separate customer environments cleanly with project-scoped access, tenant boundaries, invites, membership controls, and API-key flows.
Usage ingest with replay safety
Ingest single-event usage, batch usage, and charge traffic with idempotency protection so retries, queue redelivery, and client timeouts do not double-apply charges.
Billing runs and scheduler flows
Run billing through scheduled scans, lock coordination, reconciliation, recovery, and consistency sweeps instead of relying on one fragile happy path.
Wallets, credits, and ledgered money movement
Support prepaid and adjustment-heavy models with wallet balances, ledgered transactions, manual corrections, and credit-pack workflows.
Payments and secure Stripe flows
Handle checkout, secure Stripe webhook processing, replay-safe event storage, refunds, disputes, and payment-side support flows without turning the billing core opaque.
Admin, support, and operator surfaces
Expose the product to operators through admin endpoints, billing health reads, audit logs, replay tooling, and corrective workflows that stay explainable.
Capability depth is what turns a polished product story into a credible rollout conversation
Serious billing evaluations start once teams move past feature names and ask how the system behaves under retries, late events, disputes, migrations, and support intervention. These are the product surfaces that answer those questions without hand-waving.
Go deeper into architecture and operations when your engineering team wants dependency boundaries, failure modes, reruns, and deployment behavior explained.
Open Implementation when your team wants event design, rollout sequencing, deployment posture, and cutover planning spelled out.
Open Solutions when you want the product translated into usage billing, migration, hybrid pricing, or enterprise deployment scenarios.
Once product fit is clear, move into the rollout questions that shape launch
Bring your provider stack, pricing model, deployment posture, integration constraints, and support edge cases so the discussion moves from generic feature shopping into a real implementation plan.
Tenancy, roles, memberships, and API-key issuance define the operating boundary.
Usage intake, pricing logic, and billing runs stay deterministic under retries.
Credits, balances, transactions, and operator actions stay visible after go-live.