Launch Checklist
How Launch Checklist works in Paycux, what it is for, and the smallest setup that gets it running.
Implement complementary enterprise features
Implement complementary enterprise features is handled by Launch Checklist 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.
Before you start
Before you start, make sure you have the following in place:
- A Paycux account with access to the project you are configuring.
- An API key for the environment you are working in. Staging keys start with
sk_test_; production keys start withsk_live_. - Admin access on the system you are connecting, so you can create the application and read its metadata.
- A redirect URI registered in the Paycux dashboard under Developer → Redirects.
Create an IP Allowlist
Create an IP Allowlist is handled by Launch Checklist 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.
Go-live checklist
Go-live checklist is handled by Launch Checklist 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.
Frequently asked questions
Frequently asked questions is handled by Launch Checklist 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.
Can we add SSO authentication for a current user in an application?
Every API request is authenticated with a bearer token in the Authorization header. Keys are scoped to a single environment and are shown once at creation — store them in a secret manager, not in source control.
1curl -X GET 'https://api.paycux.com/v1/organizations' \2 -H 'Authorization: Bearer $PAYCUX_API_KEY'
How does Paycux manage user attributes from an identity provider?
Paycux normalizes incoming attributes into a fixed profile shape, so your application reads the same fields no matter which provider the user came from.
| Paycux field | Typical source |
|---|---|
| NameID, email, or mail | |
| first_name | givenName or first_name |
| last_name | surname, sn, or last_name |
| idp_id | The provider's stable user identifier |
Anything the provider sends beyond these fields is kept verbatim under raw_attributes, so you can map custom claims without waiting on us.
Is the user attribute mapping configurable in Paycux?
Is the user attribute mapping configurable in Paycux? is configured per environment in the dashboard, so staging and production can differ while your application code stays identical.
Changes take effect on the next request. There is no deploy step and no cache to clear.