Single Sign-On

Introduction

Single Sign-On is part of the Paycux platform. This page explains what it does, when to reach for it, and the smallest working setup you can ship.

Everything below applies to both environments. Build and test in staging, then promote the same configuration to production without changing your code — only the API key and client ID differ.

Getting started

Getting started applies specifically to Single Sign-On. It behaves the same in both environments, and the values it depends on are visible in the dashboard for the environment you have selected.

If the behaviour you see does not match this description, check which environment your API key belongs to before anything else — a staging key against production data is the most common cause.

Enable SSO

Enable SSO is handled by Single Sign-On rather than by your application code. Paycux exposes it through the same API surface as the rest of the platform, so the client you already configured needs no additional setup.

Configuration lives in the dashboard and is versioned per environment. Change it in staging, confirm the behaviour, then apply the same change to production.

Test with the Test Identity Provider

Verify the setup end to end before you hand it to a customer. Run the flow from a private browser window so no existing session masks a broken step.

1. 1Open the connection in the dashboard and confirm its status reads Active.
2. 2Start the flow from your application, not from the provider, so the redirect URI is exercised.
3. 3Sign in as a test user and confirm the profile arrives with an email address.
4. 4Check the connection's event list — a successful sign-in appears within a few seconds.

Service provider-initiated SSO

Service provider-initiated SSO is handled by Single Sign-On rather than by your application code. Paycux exposes it through the same API surface as the rest of the platform, so the client you already configured needs no additional setup.

Configuration lives in the dashboard and is versioned per environment. Change it in staging, confirm the behaviour, then apply the same change to production.

Identity provider-initiated SSO

A user record holds the identity Paycux resolved for the person: email, name, verification state, and the identities they have linked. It is the object your application should key on.

Users are unique by email within a project. When the same person arrives through a second provider, Paycux links the identity to the existing user rather than creating a duplicate.

Guest email domain

Verify a domain before you let it drive access. Paycux issues a TXT record; once it resolves, the organization owns that domain and users arriving with a matching email address are routed to its connection.

Verification is re-checked periodically. If the record is removed, the domain returns to unverified and routing stops — it does not silently keep working.

Error response

If something does not work, check these first — they cover the large majority of failed setups:

• The values were pasted into the wrong environment. Staging and production hold separate configuration.
• A trailing slash or stray whitespace in the ACS URL or redirect URI. Both are matched exactly.
• The connection is saved but not activated. An inactive connection returns connection_inactive.
• Attribute names differ from what the mapping expects, so the user is created without an email address.

Every failed authentication is recorded with a reason on the connection's page in the dashboard. Start there before reading application logs.