paybondpaybond
Sign in

Console sign-in and workspace access

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

Use /console/login when you already have access to a Paybond workspace. It is the sign-in entry point for workspace owners and invited operators across every plan.

If the workspace does not exist yet, start with signup instead.

Which plans use sign-in

Existing members of these plans sign in through /console/login:

PlanCan existing members sign in?What to expect after login
Free DeveloperYesExisting workspace owners and invited operators can access the sandbox-only workspace they already created.
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 after the workspace is provisioned.

Sign-in vs. signup

Use /console/login when:

  • the user already belongs to a provisioned workspace
  • the user was invited into an existing tenant
  • the user is returning to the console, onboarding flow, or operator workspace

Use another entry point when:

  • /signup is needed to create a new Free Developer, Starter, Team, or Business workspace
  • /contact/sales is needed before Enterprise provisioning exists

The rule is simple:

  • /signup creates a workspace
  • /console/login opens an existing workspace

Session and access model

The console keeps authentication and tenant scope on the server side. After a user signs in, Paybond establishes the session, resolves the workspace and role set, and applies those permissions to subsequent console requests.

Workspace SSO

Business and Enterprise workspaces can use workspace SSO where the plan and tenant configuration enable it. Free Developer, Starter, and Team workspaces use Paybond-native sign-in and cannot configure tenant IdP federation. The login page keeps the operator-facing flow protocol-neutral: users enter the workspace realm, and Gateway starts the configured OIDC or SAML flow for that realm.

Tenant admins manage SSO from /console/configuration/identity/sso.

For OIDC:

  • configure the IdP issuer URL, client ID, and client secret
  • register /v1/auth/sso/callback as the redirect URI
  • request openid email profile

For SAML:

  • configure the tenant with the IdP metadata URL
  • import Paybond SP metadata from /v1/auth/sso/metadata, or configure the ACS URL /v1/auth/sso/callback manually
  • use the Paybond SP entity ID shown in the SSO setup page
  • send a stable subject plus an email assertion for first login

In both protocols, Gateway stores single-use state before handoff and resolves tenant scope from that state and the configured realm after callback. SSO setup remains tenant-admin gated because it can change which external identities receive workspace access.

After sign-in

Signing in does not mean every console surface becomes available immediately. 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.

In practice:

  • All existing plans can sign in.
  • Only entitled roles and enabled plan features can use specific console surfaces.