Every organisation is on exactly one plan — Free, Pro or Enterprise — and the plan is the only thing that decides what it may do. Nothing in TRUSTIVAN checks a plan’s name directly; every check asks the entitlement resolver a question (“does this tenant have webhooks?”, “how many more assets may it add?”) and the resolver answers from the plan, the subscription’s standing, and any per-tenant exception on record. See backend/internal/entitlement if you want the code this page describes. Exact seat counts, scan allowances and feature lists live on the pricing page rather than here, because that page is checked against the migrations that seed them on every build — a number transcribed a second time here would drift the first time either one changed and nobody remembered the other copy existed.

​
Two kinds of limit

  • Stocks — assets, seats, API keys, webhook endpoints, policies, agents and other non-human identities. A ceiling on how many exist right now. Deleting one frees the room immediately.
  • Flows — scans per month is the one flow limit today. A ceiling on consumption within the current billing period; deleting a scan that already ran does not give the allowance back, because the CPU, the egress and the vulnerability-database read already happened.
A few numbers on the pricing page are policies rather than either — retention windows and the minimum interval between scheduled scans — and are never metered, because nothing accumulates against a rule.

​
What happens at the ceiling

Every metered action is checked at the service layer, before the write, and a refusal is 402 Payment Required, not 403: a wrong credential cannot fix it, and only a plan change can. The response names what was refused, where you stand against it, and — when a self-serve plan would fix it — which one:
Scanning itself is never gated. If the entitlement layer were ever misconfigured or unreachable, a scan runs rather than being refused — a security product that stops scanning because of a billing fault is a worse outcome than an unmetered scan. Your own usage against every metered limit is on the dashboard’s Plan and usage page, and at GET /api/v1/billing/entitlements.

​
The lifecycle

Signing up puts an organisation on Free, active, with no trial to expire — a trial of a plan with nothing to trial granted nothing and used to render as “Trial · 7 days left” and then as cancelled, which was a defect, not a feature. From there:
  • Upgrading or downgrading goes through Manage billing and a hosted checkout, on a deployment that sells self-serve. Nothing in the dashboard writes a plan directly — a plan changes only when the payment provider reports it, over a channel whose signature is verified first.
  • Cancelling keeps you entitled through the period you already paid for, then falls back to Free. Your data is never deleted by a plan lapsing.
  • A failed payment does not withdraw anything immediately. TRUSTIVAN carries a past-due subscription at its plan for a grace period before falling back to Free, because a card that expired on a Friday should not stop a security product from scanning over the weekend.
  • Reactivating is the same checkout as upgrading: buy the plan again and your entitlements resume.
Every one of those transitions is written once — the state a webhook or a reconciliation reports and nothing else — and appears in the organisation’s audit log as a subscription.changed entry, so “what did this account’s plan actually do, and when” is answerable without a support escalation to a payment dashboard.

​
What this deployment can charge you

TRUSTIVAN’s payment integration is a small, provider-neutral interface (internal/commerce.Provider): create a customer, start a checkout, open a portal, report a subscription’s state, cancel it, and verify a webhook. Two implementations exist — a Stripe adapter, and a manual provider that sells nothing and answers every checkout request honestly with “this deployment does not sell subscriptions; your plan is set by agreement.” If Manage billing or Upgrade is missing or answers that way, this deployment has no payment provider configured. That is a normal, supported, permanent state for a self-hosted install or a contract-invoiced enterprise — plans are still enforced exactly as described above, assigned by an operator or a signed agreement instead of a card. It is never a broken checkout form; if a deployment cannot sell you a plan, it says so rather than pretending. Invoices, receipts and payment-method management live entirely at the payment provider, opened from Manage billing — TRUSTIVAN stores no card data and reimplements none of a billing system’s own surface.

​
What TRUSTIVAN does not claim

Trial terms, taxes, currency, proration and regional pricing are the payment provider’s, not stated here. TRUSTIVAN does not hold a SOC 2 report or any other third-party certification; see Security and trust for what is and is not independently verified today.