Skip to content

Customer onboarding creates the regulated user identity for the whitelabel card issuing program. Your integration can use partner API key registration for a backend-driven flow, or the email and wallet registration routes when the customer authenticates directly in your app.

Partner API key flow

For server-side partner-controlled onboarding, register the customer with:

curl -X POST "https://issuing-stage.xmoney.com/v1/auth/register/partner" \
  -H "Content-Type: application/json" \
  -H "x-partner-api-key: YOUR_PARTNER_API_KEY" \
  -d '{
    "email": "customer@example.com",
    "walletAddress": "erd1examplewallet"
  }'

The response returns the customer identifier. Use it to obtain customer tokens:

curl -X POST "https://issuing-stage.xmoney.com/v1/auth/login/partner" \
  -H "Content-Type: application/json" \
  -H "x-partner-api-key: YOUR_PARTNER_API_KEY" \
  -d '{
    "customerId": "cust_01JQX0FAY4JPEHG5EPEJ0R3XEQ"
  }'

Use the returned access token as a bearer token for KYC, accounts, cards, topups, and transactions.

Email and wallet flows

The API also supports customer-facing email/password and wallet-based registration and login:

  • POST /v1/auth/register/email
  • POST /v1/auth/register/email/verify
  • POST /v1/auth/register/wallet/challenge
  • POST /v1/auth/register/wallet
  • POST /v1/auth/register/wallet/verify
  • POST /v1/auth/login/email
  • POST /v1/auth/login/wallet/challenge
  • POST /v1/auth/login/wallet
  • POST /v1/auth/2fa/send
  • POST /v1/auth/2fa/verify
  • POST /v1/auth/refresh

Use these routes when your product requires the customer to authenticate directly with credentials, wallet signatures, OTP, or 2FA.

Email registration passwords must include at least 8 characters with lowercase, uppercase, number, and symbol characters.

Token usage

All customer-scoped issuing routes use:

Authorization: Bearer CUSTOMER_ACCESS_TOKEN

Refresh expired access tokens with POST /v1/auth/refresh, using the refresh token as the bearer token. If the refresh token expires, start a new login flow.

If a login flow requires 2FA, use the returned session token as the bearer token for POST /v1/auth/2fa/send and POST /v1/auth/2fa/verify.