Loading page
Sign-in UI
Each environment serves registration, e-mail verification, sign-in, password reset and logout screens. Upload your logo, pick your colours, turn on languages, replace the wording and set the password rules in the console; your application starts a standard authorization code flow and never handles a password. Turn on passkeys under Multi-Factor Authentication and users can sign in without a password.
Status
No planned items are listed for this page.
Deliberately left out of this product. These items are not planned.
Flow
Build the authorization URL from the discovery document with the console's client ID, a registered redirect URL and a PKCE challenge. The sign-in service renders the sign-in screen with a registration link.
New users register and must verify their e-mail before a token is accepted. Existing users sign in with e-mail and password, or use the forgot-password link.
Your callback exchanges the code with the PKCE verifier. No client secret exists, and the access token is what you present to the Paycux API.
Boundaries
The hosted screens are the sign-in service's own pages, isolated per environment. You change how they look and read; the flows themselves stay the same everywhere.
Security
The client the sign-in service provisions is deliberately narrow, so a misconfigured application cannot widen it.
Screens
All of these exist on every ready sign-in service today, in your colours, languages and wording.
HTTP
Everything your application needs is in the console and the sign-in service's discovery document. There is no SDK.
1curl "https://api.paycux.com/v1/environments/<environment id>/auth?projectId=<project id>" \2 --cookie "__Host-paycux_session=<session cookie>"34HTTP 2005{6 "setup": {7 "displayName": "Example App",8 "redirectUris": ["https://app.example.com/auth/callback"],9 "logoutRedirectUris": ["https://app.example.com/"],10 "status": "ready",11 "issuer": "https://<identity host>/realms/pcx-<uuid>",12 "clientId": "<client id>",13 "discoveryUrl": "https://<identity host>/realms/pcx-<uuid>/.well-known/openid-configuration",14 "realmId": "<sign-in service id>",15 "lastErrorCode": null16 }17}18# The full object also carries workspaceId, projectId, environmentId,19# providerRealmName, checkoutReturnUrls, revision and appliedRevision.
Transparent pricing
Included in every workspace plan. Limits (projects, provider connections, members, usage events) are listed on the pricing page.
Questions
Logo and colours, yes: upload the logo and pick the colours on the environment's Sign-in screens tab; they apply to every screen once Paycux has applied them. The screens stay on the identity host; custom domains are not included.
Yes. Turn on any of 40 languages and pick the default; visitors switch on the screen, and you can replace the wording per language.
No. The screens are hosted and reached by redirect; embeddable widgets are not included.
E-mail and password, with mandatory e-mail verification and password reset, plus the social sign-in providers you add under User Management, and passkeys once you turn them on under Multi-Factor Authentication. E-mail magic links are not included.
Yes, in environments named development or preview: http loopback redirect and logout URLs are accepted there. Every other environment requires exact HTTPS URLs.
From the sign-in service's own e-mail delivery, which the Paycux operator configures. Until it is configured the environment's setup stays failed and no user can verify an account.
The dashboard signs its members in through a sign-in service of the same kind, with the same registration, verification and reset screens. Customer sign-in services are separate and isolated per environment.
Keep exploring
Create a workspace, configure an environment's Authentication tab and start the authorization code flow against the issuer it reports.