paybondpaybond
Sign in

Console sign-in and workspace access

Who should use the console sign-in page, how it differs from signup, and what each plan should expect after login.

Console sign-in and workspace access

Paybond's /console/login page is for existing workspaces. If a tenant realm has already been created and activated, its operators sign in there with tenant credentials.

Use /console/login when the user already belongs to a Paybond workspace on any of these plans:

PlanShould use /console/login?What to expect after login
FreeYesExisting workspace owners and invited operators can sign in, but private dashboards and paid plan controls stay gated.
StarterYesSign in for private operator dashboards and tenant operations.
TeamYesSign in for private dashboards, disputes, audit exports, and ongoing operator workflows.
BusinessYesSign in for production console access, billing, SSO/RBAC setup where configured, and managed policy workflows.
EnterpriseYesSign in for the contracted tenant rollout after the workspace is provisioned through sales-led onboarding.

Use signup instead when

  • the buyer does not have a workspace yet
  • the buyer is choosing a self-serve plan for the first time
  • the buyer needs a new tenant realm to be provisioned

That means the split is straightforward:

  • /signup is for creating a workspace
  • /console/login is for entering an existing workspace

UI handling

  • Public header Sign in goes to /console/login.
  • Landing-page "operator console" CTA should go to sign-in, not straight to a protected console route.
  • If a user is bounced out of a protected /console/* route, the app should preserve the requested destination and return them there after successful login.
  • Login page copy should explain that sign-in is for existing workspaces across Free, Starter, Team, Business, and Enterprise.

Backend wiring

The sign-in path is already connected end to end:

  1. The login form posts credentials to the Next.js server action in apps/admin/app/console/login/actions.ts.
  2. That server action calls the Go gateway POST /v1/auth/login.
  3. The gateway validates the user, resolves the tenant grant, and returns an access token plus refresh token.
  4. The admin app stores those tokens in httpOnly cookies.
  5. Protected /console/* routes use refresh-on-demand middleware and server-side gatewayFetch(...) calls to keep requests authenticated.
  6. The Go gateway remains the authority for principal resolution and billing state.
  7. Harbor (Rust) receives tenant-scoped Bearer credentials minted by the gateway for runtime enforcement.

Plan and role boundaries

Signing in does not guarantee every console section is visible. After authentication:

  • RBAC determines which routes the principal may open.
  • plan features determine which private surfaces are enabled
  • gateway and Harbor still enforce tenant scope and commercial limits on every protected call

So the rule is:

  • all existing plans can sign in
  • only entitled roles and enabled plan features can use specific console surfaces