Billing bypass (internal)

This is an internal article for super-admins. The billing bypass flag lets you grant access to an account without an active paid subscription. Use it for incident credits, partner accounts, internal test accounts, and time-limited goodwill credits.

The flag lives on account_billing.billing_bypass and has three values. Every write goes through one server action and creates an audit-log row. There is no UI for account members.

The three modes

null (normal). No bypass. Entitlements come from the active plan and any purchased add-ons. Past-due and unpaid accounts go read-only after the 7-day grace window. This is the default for every account.

core. All CORE content features are on for free. OPTIONAL features (jobs, references, posts, gallery) stay off. Integrations are not auto-granted; you can flip individual providers on through integrations.enabled as a manual grant. Use this for partner accounts or long-term goodwill where you want the base product available without comping integration add-ons.

all. Everything is on. All content features, all integrations, pricing is ignored. Use this for internal test accounts, incident credits during outages, and short-term concessions where you don't want to think about which features the customer needs.

How to set the flag

The only write surface is the setBillingBypass server action, callable from the super-admin panel. It requires three inputs: the target accountId, the bypassMode (null, core, or all), and a reason string. The reason is required and cannot be empty.

The action runs the mode change and the audit-log insert in the same transaction. If the audit insert fails, the bypass change is rolled back.

Audit log

Every write to billing_bypass inserts a row into billing_bypass_audit_log. The row captures the actor (super-admin user id), the target account id, the previous mode, the new mode, the reason text, and the timestamp.

Treat the reason field as a working note for the next person who looks at the account. Write the ticket number, the customer name, or the incident reference. "Test" is not a useful reason. "INC-2026-04-12 Stripe outage credit, expires 2026-05-12" is.

The audit table is append-only. Do not edit or delete rows. If you reverse a bypass, set the mode back to null with a fresh reason and the new row records the reversal.

When to use which mode

Outage credit for a paying customer: set all for the credit window, then revert to null once their subscription is healthy again.

Long-running partner or pilot account that uses the base product only: set core and grant the specific integrations they need through the integrations table.

Internal account used by the team for QA or demos: set all once at setup and leave it.

Revoking a bypass: set the mode to null. The next entitlements read falls back to whatever Stripe says the subscription is doing.

Related

• Plan & Billing (the customer-facing billing article)
• Account deletion (the bypass flag does not survive account deletion; the cascade clears it)