MENU
Orb is a billing platform for software companies using usage-based, seat-based, and hybrid pricing. It receives product events, converts those events into billable metrics, applies contract and pricing rules, and generates customer invoices.
This scope is relevant to AI companies because model calls, tokens, tool executions, workflows, and outcomes create variable costs that do not always align with conventional per-seat subscriptions. The number of software companies using consumption-based pricing models more than doubled between 2015 and 2024 as providers connected charges more closely to product activity.
Billing represents only one part of the commercial system required by autonomous agents. A company may also need to give an agent controlled purchasing authority, verify payment before an API runs, meter individual requests, enforce access, and settle machine-initiated transactions.
Key Takeaways
Orb is a billing platform for software products using variable usage and contract structures. It receives product activity, defines billable metrics over those events, connects customers to pricing plans, and calculates invoice amounts.
Orb documents the following billing configurations:
Orb is not an AI-agent framework or an autonomous payment network. It does not build the underlying product or determine which customer actions should be monetized.
The company implementing Orb defines the events, metrics, plans, customers, contracts, and billing rules. Orb applies those configurations when calculating the amount assigned to each customer.
Orb’s documented implementation process consists of five main stages:
A basic test configuration may require less work than a production migration. Enterprise contracts, historical data, accounting integrations, customer hierarchies, tax systems, and revenue-recognition requirements can increase implementation scope.
Orb receives raw product activity through its API and supported data-ingestion methods.
An event may represent:
Each event contains a customer identifier, event type, timestamp, and any properties required for later calculation.
The quality of the resulting invoice depends on the data supplied by the product. Missing customer identifiers, duplicate events, inaccurate timestamps, or incomplete usage quantities can affect the calculated amount.
Product teams therefore need to define event schemas, retry behavior, idempotency rules, and validation requirements before treating usage records as financial data.
A billable metric converts raw events into the quantity used for pricing.
An AI service could define metrics for:
Orb defines metrics as queries over stored event data. A metric may count events, sum a numeric property, identify unique values, or apply filters and grouping rules.
This separation means metric definitions can be changed without necessarily resending the same historical event data. The result still depends on whether the original event schema contains the information required by the new definition.
Orb connects billable metrics to configured prices.
A plan may contain:
Orb records pricing configurations as versioned objects. When a company changes its pricing, the system records which version applies to each customer and billing period.
Orb also documents pricing simulations that apply proposed changes to historical usage data. The resulting forecast depends on the completeness of the usage records and whether past customer behavior represents future activity.
Pricing simulations should therefore be treated as modeled estimates rather than guaranteed revenue outcomes.
A customer subscription connects a customer record to a pricing plan and billing schedule.
Enterprise agreements may include:
Orb records subscription and pricing timelines so invoice calculations reflect the terms assigned to a particular period.
The system can recalculate an earlier billing period when events arrive late or pricing data is corrected. Companies should test how those changes flow into invoices, accounting records, revenue recognition, and customer communications.
A corrected billing calculation does not automatically resolve the operational effects of an invoice that has already been issued, paid, disputed, or recorded in another finance system.
Orb calculates invoices using:
The resulting invoice contains line items based on the configured rules.
Orb can generate invoice data and connect billing records with payment, accounting, tax, and customer-management systems. The invoice calculation remains separate from the underlying payment processor unless the company configures an associated payment-collection workflow.
This distinction matters for AI products. An invoice records what the customer owes. It does not necessarily authorize an autonomous buyer to spend or determine whether a paid API should execute the next request.
Orb documents prepaid credits and enterprise commitments.
Credits may represent:
As customer activity is recorded, configured prices reduce the applicable balance.
A credit model requires the provider to define:
Orb applies the configured billing rule. The product team remains responsible for defining the commercial meaning of each credit and enforcing any product-access restrictions attached to the balance.
Orb describes its architecture as query-based billing.
Raw usage events are stored, while metric definitions, pricing versions, and subscription timelines determine how those events are interpreted for a particular invoice.
When an invoice is generated, Orb queries the relevant records and calculates the result from the active configuration.
The model includes:
This architecture is intended to handle billing corrections and historical recalculation. It does not independently provide payment authorization before an autonomous agent consumes a service.
The distinction is important when every request creates an immediate model, data, or compute cost. Recalculating an invoice later does not prevent an unauthorized or unfunded request from running in the first place.
Orb’s public pricing page lists three product tiers:
The page does not display fixed monthly or annual prices for those tiers. Prospective customers are directed to contact the company for commercial terms.
Published feature categories include event ingestion, custom metrics, usage alerts, hybrid billing, versioned pricing, invoicing, tax integrations, customer hierarchies, data synchronization, and finance-system integrations.
A commercial evaluation should request details on:
The total cost may also include separate payment-processing, tax, accounting, data-warehouse, or revenue-recognition services used alongside Orb.
Orb is intended for software companies that convert product usage into recurring or usage-based invoices.
Documented use cases include:
The platform’s role begins with product events and extends through pricing and invoicing workflows.
That scope differs from an autonomous agent-payment flow in which a buyer receives machine-readable payment requirements, presents authorization, pays within a delegated budget, and obtains access before a service performs work.
AI companies should separate billing requirements from transaction requirements before selecting infrastructure.
Retrospective billing records usage during a billing period and invoices the customer afterward.
Request-level payment requires the buyer to prove payment or entitlement before the workload runs.
Request-level payment may be required when:
A usage-billing platform calculates charges from recorded activity. A payment-enforcement layer determines whether the service should execute.
Traditional billing systems organize activity around customer, subscription, and contract records.
Autonomous commerce may instead involve:
These transactions require machine-readable payment requirements and scoped spending authority. They may occur without a user opening a hosted checkout page for each purchase.
Metering determines how much activity occurred and what it should cost.
Settlement moves value from the buyer to the seller.
A complete autonomous transaction may require:
A billing platform may cover the pricing and invoice portions. Agentic commerce requires the wider transaction lifecycle.
Nevermined provides a getting started overview for adding payments, pricing, access control, and settlement to AI agents and paid services.
The platform connects autonomous purchasing, paid access, usage metering, pricing, and settlement through one agent-focused transaction flow.
This scope lets an AI service charge for work while giving buyer agents controlled authority to pay for it.
Nevermined applies a Nevermined payments overview across supported card and payment-provider flows.
A card owner can define spending boundaries through the card delegation solution, including:
The agent receives scoped payment capability rather than the original card number. Charges outside the delegation rules are rejected, and the owner can revoke authority before the assigned budget expires.
This lets an organization fund an agent without giving it unrestricted access to a payment method.
The x402 facilitator overview describes Nevermined’s enforcement and settlement engine for HTTP-native payments.
When an agent calls a paid endpoint, the service returns payment requirements. The agent supplies authorization, and Nevermined verifies the permission before the workload runs.
The service can reject unpaid requests before model inference, tool execution, or data delivery creates cost.
Once the request completes, the applicable payment or credits are settled. Payment becomes part of the same lifecycle as access and execution rather than a separate invoice generated later.
Nevermined documents multiple payment models for APIs, agents, tools, and protected resources.
Available structures include:
Dynamic pricing can account for token count, request complexity, operation type, or another builder-defined metric.
Pricing therefore determines both the amount charged and whether the caller receives access.
The Nevermined x402 guide covers payment authorization and settlement for machine-readable HTTP transactions.
A payment token can encode the relevant plan, agent, permission, amount, and settlement information. The receiving service verifies the authorization before fulfilling the request.
This structure ties the commercial rule to the machine interaction that creates the usage.
It also removes the need for every API provider to build an independent authorization and payment-verification gateway.
Builders can use the agent-to-agent monetization solution for APIs, datasets, MCP tools, agents, and other protected services.
The implementation includes:
Other agents can purchase access and request work programmatically.
This supports commerce between software services rather than limiting payment to a conventional SaaS provider and customer account.
The Nevermined MCP integration adds payment validation to MCP tools, resources, and prompts.
An MCP handler can:
MCP defines how agents discover and invoke tools. Nevermined adds the commercial layer that determines who can call them, what each request costs, and how payment is enforced.
The AI agents observability documentation covers incoming requests, credit redemption, caller identity, plan balances, settlements, and revenue.
Each interaction can be associated with:
This gives operators a direct view of usage and settled revenue instead of relying only on monthly invoice totals.
The transaction record also supports investigation when a payment, entitlement, or workload result is disputed.
The five-minute setup guide covers registration, payment-plan creation, request validation, workload execution, and settlement.
Nevermined provides TypeScript and Python SDKs, REST APIs, CLI tooling, and framework integrations.
The implementation can protect an agent API, MCP tool, dataset, or another paid resource.
Valory reported reducing payment and billing infrastructure deployment for the Olas AI agent marketplace from six weeks to six hours. That result is customer-specific rather than a guaranteed implementation time.
Nevermined documents its security and compliance controls for agent payments and delegated spending.
Its security program includes:
These controls apply directly to agent payment activity rather than only to invoice generation.
The Nevermined pricing plans charge 1% to 2% of settled transaction volume.
There are no setup fees or minimums. A free personal account supports up to 20 agents and 10 payment plans.
Optional organization plans add dashboards, payment widgets, customer management, activity streams, and larger agent and plan limits.
Processor or network charges may still apply depending on the rail used for settlement.
Usage-based billing calculates charges from measurable product activity such as requests, tokens, compute time, workflows, or completed tasks. The provider defines the metric and applies a price to the recorded quantity. This model may generate an invoice after usage or reduce a prepaid credit balance. Nevermined extends usage pricing into request-level access and settlement when payment must be confirmed before work begins.
Billing calculates the amount a customer owes under a pricing plan. Agent payment gives autonomous software the authority to purchase a service and transfers value to the seller. Payment may need to occur before an API, tool, or agent completes the requested task. Nevermined connects authorization, access, metering, and settlement within the same transaction lifecycle.
Autonomous agents can issue repeated requests, select paid services, and continue operating without a person approving each transaction. Spending limits restrict the amount, duration, transaction count, and credential associated with that authority. These controls reduce exposure when an agent behaves unexpectedly or a key is compromised. Nevermined applies the limits directly through revocable payment delegations.
An MCP tool can require valid payment or credits before executing a method. The server checks the caller’s entitlement, applies the configured cost, and deducts credits after a successful call. Dynamic pricing can also vary the charge according to workload complexity or token consumption. Nevermined provides payment-protected MCP integrations for these request-level workflows.
An AI payment system should record the buyer agent, seller, authorization, pricing rule, request, usage amount, outcome, settlement, and receipt. It should also preserve revocation and error events so disputed activity can be reconstructed. These records differ from an invoice total because they describe each machine transaction. Nevermined connects agent identity, payment plans, usage, and settlement within one audit trail.
See Nevermined
in Action
Real-time payments, flexible pricing, and outcome-based monetization—all in one platform.
