What is ABAXUS

ABAXUS is a self-hosted usage-based billing engine. Understand what it does, what it doesn't do, and where it fits in your stack.

What ABAXUS Is

ABAXUS is a self-hosted usage-based billing engine. You deploy it inside your own Kubernetes cluster, connect it to your PostgreSQL database, and configure your payment provider credentials. Once running, it exposes a REST API that your product services call to record usage, query entitlements, and issue invoices.

The key word is self-hosted. ABAXUS is not a SaaS platform you subscribe to. It’s software you operate. Your billing data — usage events, customer records, pricing configurations, invoices — lives in your database, inside your infrastructure, subject to your data residency and compliance requirements. This matters for companies in regulated industries and for any team that has made a commitment to customers about where their data lives.

What ABAXUS Does

ABAXUS handles the metering-to-invoice pipeline:

  1. Receives usage events from your product. Every API call, compute minute, active seat, or gigabyte transferred can be recorded as an event.
  2. Meters them by aggregating raw events into usage totals according to the metric definitions you configure (sum, count, max, unique count, and more).
  3. Applies pricing rules from your price plans — per-unit, tiered, volume, package, or flat fee — to produce a monetary amount.
  4. Generates invoices with full line-item breakdowns showing exactly how usage was calculated and priced.
  5. Collects payment by creating a Stripe PaymentIntent or Adyen payment against the customer’s saved payment method.

All five steps are exposed as API endpoints, giving you full control over when and how billing runs. You can trigger invoice generation on a schedule, on demand, or as part of a customer-facing billing portal.

What ABAXUS Does Not Do

Understanding the scope boundaries is as important as understanding the feature set:

  • Authentication: ABAXUS does not manage your user accounts or API key issuance for your customers. It has its own API key system (publishable pk_... and secret sk_... keys) for calling the ABAXUS API itself, but your product’s auth layer is separate.
  • Subscription front-ends: ABAXUS has no hosted checkout page, pricing table, or customer portal UI. You build those in your product using the ABAXUS API as the backend.
  • Dunning: Automated retry logic for failed payments is not yet included. You can handle retries by calling POST /v1/invoices/:id/charge again, but automated dunning sequences are on the roadmap.
  • Tax calculation: ABAXUS calculates usage-based charges but does not compute sales tax, VAT, or GST. Integrate with a tax provider (Stripe Tax, Avalara, TaxJar) and pass the resulting tax amount alongside the invoice if needed.
  • Email delivery: ABAXUS can trigger a POST /v1/invoices/:id/send-email event, but the actual email transport is your responsibility. Hook the event to your own email infrastructure.

Where ABAXUS Fits in Your Stack

ABAXUS sits between your product (which generates usage) and your payment provider (which collects money):

Your Product Services
        │
        │  POST /v1/events  (usage signals)
        ▼
    ABAXUS API
        │
        │  PaymentIntent / charge
        ▼
  Stripe or Adyen

Your product calls ABAXUS to record events and query entitlements on the hot path. ABAXUS calls Stripe or Adyen when you trigger a charge. Nothing else crosses the boundary.

The Core Data Model

Six objects make up the ABAXUS data model. Understanding how they relate is the foundation for everything else:

  • Metrics define what to measure and how to aggregate it. A metric named api_calls might aggregate by sum; a metric named active_seats might aggregate by last (most recent value in the period).
  • Price Plans define how to charge for measured usage. A plan contains one or more charges, each referencing a metric and a pricing model (per-unit, tiered, etc.). Plans are versioned and immutable once published.
  • Customers represent the entities you bill. Each customer has a stable ID you define (usually matching your own user or organization ID) and one or more payment methods attached.
  • Subscriptions bind a customer to a specific version of a price plan. The subscription records the exact plan version at the time of creation, so future plan changes don’t affect existing billing periods.
  • Events are the raw usage signals your product emits. Each event references a metric key, a customer ID, a value, and a timestamp. Events are idempotent — submitting the same event twice has no effect.
  • Invoices are the output of the billing cycle. ABAXUS calculates the charges based on events in the billing period, applies the price plan rules, and produces an invoice with line items, subtotals, and a total amount.

Entitlements as a Separate Concern

Usage-based billing and feature access control are related but distinct concerns. ABAXUS handles both through the entitlements system, which lets you declare on each price plan what customers are allowed to do — not just what they pay for.

Entitlements are boolean flags (advanced_analytics: true), numeric limits (api_calls_per_month: 100000), or custom configuration values (model_tier: "gpt-4"). They’re resolved at runtime when your product calls GET /v1/entitlements/check, returning whether a given feature is granted or exceeded for a specific customer.

This separation lets you change pricing without changing access control logic, and enforce limits in your product code without duplicating plan knowledge across services.