Opening proof path
SIRJ is loading the workspace, connector, or public page with the same proof path intact: ad spend, lead, booked job, invoice, paid.
See how SIRJ handles signup trials, account-scoped billing, checkout, billing portal access, client workspace limits, feature gates, and cancellation states.
Buyer questions
Pricing tells the buyer which plan to choose. Billing clarity tells them what happens after they choose it.
Signup creates account, user, workspace, session, and subscription records. New accounts receive a trialing subscription with a trial end timestamp, so the workspace can start setup before the buyer completes long-form procurement.
The buyer gets a real workspace path after signup, not a dead-end lead form. Trial state is explicit and can be audited instead of living in vague sales copy.
Follow the proof pathSIRJ subscriptions are account-scoped. Client workspaces belong under the account, while billing actions, checkout, and billing portal access are handled for the account rather than for one individual client record.
Agencies can evaluate plan fit around their portfolio instead of worrying that each client workspace will secretly become a separate subscription.
Follow the proof pathPlan-limit checks run before a new client workspace or limited integration is saved. When a limit is reached, the runtime returns a billing-forward message rather than creating an over-limit workspace and surprising the buyer later.
The product should fail before commitment, not after the agency has promised a client that reporting is ready.
Follow the proof pathCheckout creates a subscription-mode billing session, while the billing portal lets owners manage the customer account. Canceled subscriptions and expired trials block continued use with a clear prompt to choose a plan in Billing.
The buyer sees a normal SaaS billing path: subscribe through checkout, manage through the portal, and avoid hidden retention calls or silent access failures.
Follow the proof pathBilling map
The map below connects signup, trial state, checkout, portal access, workspace limits, feature gates, and blocked subscription states to buyer-visible outcomes.
Plan mechanics
This table translates billing behavior into plain-language expectations: trial, checkout, portal, limits, features, and blocked states.
| Rule | User sees | Runtime source |
|---|---|---|
| Trial creation | A newly created account can enter the workspace with a trialing subscription and a visible trial end state. | Signup provisions a trial subscription and stores trialEndsAt using the configured trial length. |
| Account-scoped subscription | One account owns the subscription while client workspaces sit underneath that account for reporting and access. | Subscription records carry accountId and do not carry clientId, keeping billing separate from individual client data scope. |
| Checkout session | Owners can start a subscription checkout session for a selected tier, with success and cancel paths returning to the app. | Billing checkout uses subscription mode and account metadata before returning a hosted checkout URL. |
| Billing portal | Owners with a Stripe customer can open the billing portal to manage payment method, subscription state, and account billing. | Portal requests require the account subscription's customer id and a return URL, then create a billing portal session. |
| Client workspace limit | The product blocks new client workspace creation when the active account has reached the current plan's workspace limit. | Client creation counts existing workspaces, reads the subscription, and runs assertClientLimit before saving the new workspace. |
| Feature gate | Some features require higher-plan access and return a Billing-forward message when the active subscription does not include them. | The tier feature matrix gates features such as weekly insight emails and keeps raw tier values stable for runtime checks. |
| Expired trial or canceled subscription | A canceled subscription or expired trial stops continued use with a clear message that the account needs to choose a plan in Billing. | subscriptionUsability returns blocked reasons for missing, canceled, or expired-trial subscriptions before protected work continues. |
Billing workflow
The billing path should preserve buyer intent, create an explicit subscription state, enforce limits before writes, and give owners a portal for account management.
| Step | Commercial role | User-visible proof |
|---|---|---|
| Preserve plan intent | Signup reads selected plan context from the pricing path, keeps that intent through account creation, and sends plan-driven buyers toward billing setup after the session is created. | A buyer who clicks a plan does not lose the commercial context after the account is created. |
| Create the trial subscription | The auth runtime provisions a subscription for the new account, marks it trialing, and stores a trial end timestamp based on the configured trial length. | The workspace can start onboarding while the commercial state remains explicit and time-bounded. |
| Start checkout when the buyer is ready | Checkout requests are owner-only, subscription-mode Stripe sessions with account metadata and app return URLs for success or cancellation. | The buyer gets a normal hosted checkout path instead of a hidden manual billing process. |
| Enforce limits before writes | Workspace and integration limits are checked before creating additional client workspaces or limited integrations, so the data layer does not drift beyond the paid account state. | A plan-limit message appears before over-limit work is created, which keeps expansion conversations clean. |
| Manage billing through the portal | Owners can open the billing portal from an account subscription with a Stripe customer id and return to the dashboard billing view afterward. | Cancellation and payment management live in the product billing path instead of requiring a retention conversation. |
Proof standards
These gates keep billing permissioned, account-scoped, explicit about limits, and clear when trial or subscription state blocks continued use.
Runtime billing routes check permissions before creating checkout or portal sessions.
Subscription records are account-scoped and client workspaces remain separate from the billing record.
Workspace and integration limits are enforced before records are saved, so buyers see the plan boundary before another client promise is created.
Subscription usability returns missing, canceled, or expired-trial reasons with Billing-forward messages.
FAQ
Clear answers reduce friction without discounting the product or hiding the commercial path.
Yes. New accounts receive a trialing subscription with a trial end timestamp so setup can begin while the billing state remains explicit.
No. SIRJ billing is account-scoped. Client workspaces belong under the account, and plan limits determine how many workspaces the account can manage.
The runtime blocks the new workspace before it is saved and returns a plan-limit message, so the account can upgrade before promising another client a dashboard.
Yes. Owners can use checkout to subscribe and the billing portal to manage account billing when a Stripe customer is attached to the subscription.
Ready when the numbers need to hold up
Compare the public plans, then create the workspace with the plan context preserved into billing and setup.