Security and enterprise identity

Merchant access requires a current session and active membership in that exact organization. Financial roles are explicit grants. Program managers do not acquire payout approval through a UI role. Affiliates are authorized by their own enrollment, never by a merchant layout's active organization.

SSO and SCIM

Enterprise identity configuration requires an active Enterprise subscription, an owner/admin account, MFA verified on the current session within the last five minutes. Enrollment or a trusted-device cookie alone is insufficient: successful native TOTP/OTP/backup-code verification writes a server-only proof tied to that session. Register SAML or OIDC through Better Auth and prove the provider domain. OIDC uses PKCE. SAML requires response correlation and timestamps, rejects unsolicited IdP-initiated responses and deprecated algorithms. Provider trust cannot be changed while paired to provisioning or enforced for the organization.

Run a verified SSO sign-in before enforcement. Configure a separate owner with MFA as the recovery account. A provider ID in user input does not mark a session authenticated by that provider.

Pair SCIM to the exact verified provider and organization. Generate managed credentials in the security screen; the plaintext is shown once, while the database stores its hash. SCIM resources live at /api/auth/scim/v2. The supported capability documents come from the installed Better Auth plugin. Map groups to explicit program, payout or analyst roles. Empty mappings grant no product access.

Disabling a directory user invalidates the tenant access check immediately, including an existing session. Better Auth also revokes global sessions when all directory identity sources become inactive; other organization memberships and the global user remain intact and can be used after reauthentication. Rotation permits bounded overlap; revoke the old credential after the identity provider switches.

Secrets and request protection

• Provider credentials, payout destinations and webhook bodies use AES-GCM with tenant/environment AAD.
• Keep the encryption key in a managed secret store and back it up independently of database snapshots.
• API keys store hashes, scopes, revocation and expiry. Browser clients never receive provider secrets.
• Financial writes require idempotency keys, role checks and recent authentication.
• Browser mutations validate Origin; server integrations authenticate API keys or provider signatures.
• Auth uses persisted rate limits. Control-plane IP buckets use Vercel's overwritten ingress header; a self-hosted proxy must strip and set that header, never forward a client-supplied value unchanged.
• Internal click batches use timestamp, nonce and HMAC; replay nonces are recorded durably.
• Logs include request/trace IDs and status, excluding raw provider payloads and credentials.

Financial retention

The runtime cannot update or delete ledger entries. Refunds and corrections append balancing entries. Closing a merchant or user must preserve financial evidence; direct organization deletion is blocked. Payout exports are immutable and fingerprinted. A refund after export requires transfer reconciliation; a refund after confirmed payment carries a negative balance for later offset.

The database enforces tenant/environment policies; application tests also attempt cross-tenant access with the non-owner runtime role. A database owner connection is reserved for migrations and recovery.