Authentication
The Merchant API is backend-only. Call it only from trusted server-side systems, and never expose your credentials in browser code, frontend bundles, or client-side storage.
Authentication model
Merchant API requests use an API key plus Basic Authentication, both handled on the backend. The Authorization header holds the word Basic, a space, then a base64-encoded username:password string.
Keep credentials on the backend
Use Merchant API credentials for server-to-server work: creating and retrieving payments, refunds and preauthorisations, customer management, Hosted Checkout sessions, token and proxy operations, and diagnostics.
Never expose them in browser JavaScript, frontend env files, mobile app bundles, client-side storage, screenshots, or logs a user could see. The safe pattern:
- The frontend calls your backend.
- Your backend authenticates to the Merchant API.
- Your backend returns only the minimum data the frontend needs.
This applies to Hosted Checkout too. Even though the frontend launches the modal, your backend still generates the session, holds the credentials, and validates the result. The browser only ever sees launch-safe values.
Environment separation
Don't mix test, UAT, and production credentials. Configure base URLs, API keys, usernames/passwords, merchant codes, and callback URLs per environment, and store all of it in environment variables or a secret manager rather than in source control.
Operational hygiene
- Limit who can access production credentials.
- Rotate credentials through a controlled process.
- Redact sensitive values in logs and support tooling.
Related pages
Summary
Authenticate with an API key and Basic Auth, keep credentials on the backend, and never mix environments.