Domains
How Domains works in Paycux, what it is for, and the smallest setup that gets it running.
Organizations
An organization is the tenant boundary in Paycux. Connections, directories, roles and audit log streams all hang off an organization, and a user reaches your application through a membership in one.
Create an organization per customer, not per environment. The same organization exists in staging and production with separate configuration.
Email validation
Email validation is handled by Domains 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.
Allowing any 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.
Implement profile validation
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.
Custom ACS domains
Custom ACS domains applies specifically to Domains. 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.