Authentication and tokens

Access tokens

Customer registration and login return a bearer token. Send it in the Authorization header, never in the query string or request body. Treat it as an active secret: do not log the complete value, include it in error reports, or forward it to analytics platforms.

Customer and business context

Customer registration currently creates the customer and an initial YER primary wallet. Business employee login requires email or phone plus password and either business_id or business_number. The server returns user and business context, while abilities are derived from the employee’s roles. A successful login does not imply permission for every endpoint; each operation may require a narrower capability.

Server and client separation

Server-to-server integrations store credentials in a secret manager and inject them only at request time. A mobile application must not contain a broad business credential. Route sensitive operations through your backend or use a dedicated flow provisioned by LuxPay.

Failure and renewal

A 401 response means the credential is missing or invalid. A 403 response means the identity is recognized but its scope does not permit the operation. Clear a confirmed invalid token and avoid unbounded authentication retries. The current public contract does not expose a token refresh endpoint, so token lifetime and revocation policy must be obtained as part of integration provisioning rather than guessed in the client.

Read Production security before storing credentials.