---
title: "Stripe Billing"
description: "Public usage ladder, grandfathered design-partner meters, startup subscriptions, payment readiness, and reviewed usage invoices."
---
The design-partner offer is **$1,500 USD per startup per month**, plus usage from the first dispatched call. Your linked development, staging, and production workspaces share one subscription. Adding a teammate does not add a seat fee.
## Rates
Obol publishes two usage schedules. They are not a volume discount of each other (ADR-0060). The public ladder is the quote. The assisted first-five partners are billed on a grandfathered Team schedule — the meters this page and the shipped biller implement.
### Public ladder
The public quote, per 1,000 dispatched calls. This is what the marketing site states, and what hosted Pro meters at public launch.
| Dimension | Per 1,000 calls | Per call |
|---|---:|---:|
| Read-only tool/API calls | $0.30 | $0.0003 |
| Idempotent write calls | $1.00 | $0.001 |
| Destructive tool calls | $3.00 | $0.003 |
| LLM requests | $0.10 | $0.0001 |
### Design-partner meters
The grandfathered Team schedule for the assisted rollout. Control's `PLAN_RATES` and the Stripe catalog charge these amounts today. They are **not** a discount from the public ladder.
| Dimension | Per 1,000 calls | Per call |
|---|---:|---:|
| Read-only tool/API calls | $1 | $0.001 |
| Idempotent write calls | $3 | $0.003 |
| Destructive tool calls | $10 | $0.01 |
| LLM requests | $1 | $0.001 |
Usage is billed in arrears using per-call decimal rates, without rounding up to blocks of 1,000. For example, on the design-partner meters, 100,000 LLM requests, 100,000 reads, 10,000 writes, and 1,000 destructive calls cost $240 in usage. A renewal with that usage is $1,740 before configured taxes. The invoice is not capped at $2,000.
You bring your own provider credentials and pay providers directly. Token counts and **Vendor cost estimates** in your workspace are informational; editing those estimates never changes these Obol rates. Obol does not charge a percentage of payment volume or act as a merchant of record.
## What counts as a call
One logical request becomes billable when upstream dispatch starts. A vendor error after dispatch still counts. Obol's internal retries, provider fallbacks, approval resumes, and receipt revisions do not add another fee for the same logical request.
Policy denials and failures before dispatch are free. Discovery, dashboard management requests, and verification probes are not separately billable. Tool categories come from the reviewed tool definition captured at dispatch time, not from a caller's labels or later catalog changes.
Billing records dispatch. It does not certify that a tool achieved its intended effect. A receipt still states its evidence class; federated routes do not gain native, gateway-observed outcome evidence through billing.
## Enroll and activate
Design partners receive founder-approved assisted onboarding. There is no public trial or unapproved self-serve Checkout.
Open **Settings → Billing** or continue onboarding. The owner of the designated billing workspace manages payment for the linked startup.
Checkout collects a card and billing address. It creates one monthly subscription with the base price and four metered prices. Obol activates execution after the control plane confirms the initial payment; returning from Checkout alone does not activate it.
Choose models, tools, or both. Connect your provider, publish policy, create a virtual key with a budget, and make a successful dispatched call. Onboarding resumes from recorded state. Inviting teammates is optional.
The startup's billing workspace owners can see aggregate rates, linked workspaces, billable counts, and invoices. Membership in another linked workspace alone does not reveal startup-wide finances. Other members retain their workspace's [Usage view](/billing/usage).
New workspaces in an enrolled organization inherit its payer without granting access to other workspaces. Enrollment does not bill historical traffic. Existing unenrolled and self-hosted workspaces retain their existing behavior.
## Renewal and payment recovery
A confirmed failed renewal starts a fixed seven-day grace period. At the deadline, new execution is blocked while in-flight calls finish and the dashboard, audit, and receipts remain available. Use the Stripe-hosted payment portal in Billing to update payment details.
Payment recovery restores billing readiness, but cannot remove a manual workspace freeze. A Stripe outage or an Obol reconciliation failure alone does not suspend an active partner. Cancellation takes effect at the end of the paid period; the final invoice collects accrued usage without starting another base subscription period.
## How usage reaches Stripe
The gateway emits an immediate dispatch fact separately from completion usage. Control stores the dispatch source and allocates one immutable charge per workspace, request kind, and logical call identity. The allocation pins the customer, meter, price version, amount, and dispatch timestamp. Completion metadata can recover the same fact without charging it twice.
Each allocation reports one unit to its matching sum meter. Stripe receives a stable identifier, event name, customer ID, value, and original dispatch timestamp. It receives no tool arguments, vendor credentials, receipt bodies, token counts, or vendor cost estimates.
Delivery uses durable claims, fenced leases, and bounded retries. Ambiguous requests stop before the remote idempotency window expires; they require reconciliation. Known ingestion gaps pause delivery. A successful meter request acknowledges receipt, while Stripe aggregates asynchronously.
## Usage invoices require review
Before activating a paid partner, control persists Stripe subscription collection behavior `keep_as_draft` with no resume deadline. Every subsequent usage-bearing invoice is held in draft with automatic advancement disabled, including during a control outage. Control compares local allocations and delivery status with Stripe's meter summaries, invoice quantities, and rounded amounts. Disagreement, missing data, or ambiguous delivery keeps the invoice on hold.
For this assisted rollout, even matching observed totals require operator review and explicit payment of the individual invoice in Stripe; the subscription-wide draft setting stays in place. Stripe meter summaries require minute-aligned windows, so an invoice period with other second boundaries also remains under review. The gateway's asynchronous queue can lose events before Redis; matching two downstream totals cannot prove that no earlier event was lost. Initial base-only payment collects normally. See [Metering](/billing/metering) for the transport boundary.
Billing distinguishes **complete**, **delayed**, **gap**, and **reconciliation required** projections. Here, complete means the observed projection has no known gap or outstanding delivery problem; it is not a guarantee of invoice-complete ingress.
## Deployment
The control API and worker use Obol's platform Stripe secret and the billing webhook signing secret. These are distinct from customers' vaulted Stripe connector credentials and never reach the gateway or dashboard configuration.
The repository's `infra/scripts/stripe_billing_catalog.py` prints the reviewed catalog by default and provisions only an authenticated sandbox with `--apply`. It verifies existing immutable prices and meter semantics before reuse. Runtime configuration includes one base price, four metered prices, meter IDs, event names, and separate `STRIPE_BILLING_WEBHOOK_SECRET` and `STRIPE_BILLING_METER_WEBHOOK_SECRET` values for lifecycle and thin meter-error endpoints. Automatic tax defaults to false until the account's tax setup is configured.
Legacy tool-only deliveries remain separate. Enrollment never releases historical waiting rows into the new design-partner meters. The implementation lives in `apps/control/app/services/billing/`; the legacy pipeline remains in `stripe_meter.py`.