Billing — how this works

In the app: /settings/billing

How it works

Usage (sends/enrichments/renders/seats) is METERED against the tenant's plan (src/lib/billing/plans.ts) — a small, hand-curated catalog, never a database table. Only SENDS are actually ENFORCED: the outbox's existing throttle chokepoint (dispatch()/reserveSlot(), unchanged since INFRA-04) now reserves against the tenant's plan-driven daily cap instead of a hardcoded constant, so a tenant at its send cap throttles exactly the way an exhausted resource cap always has — a 'throttled' outcome, not an error, and the message stays queued for the next day. Enrichments/renders/seats are DISPLAY-ONLY today: there is no reservation chokepoint on those fires yet. Payment history and today/MTD totals reuse the Revenue page's own paymentsRepo.ts unchanged — this page's ONLY addition is reading it through a tenant-scoped client. Stripe Checkout/portal links stay behind CALLHQ_BILLING_LIVE (default off) — a founder's box-env flip (§B), never a code change.

Data source

src/lib/billing/{plans,usage}.ts (the catalog + meters) and src/lib/revenue/paymentsRepo.ts (payment history, unchanged, reused).

Troubleshooting

Usage looks stuck at zero right after a send? Counters reset at 00:00 UTC and only count TODAY's activity, not all-time. Sends throttling unexpectedly? Check the plan badge at the top — a tenant defaults to "starter" (5 sends/day) unless its Tenant.plan row says otherwise; the founder org is on "scale" (10,000/day).

Who can see this: admin