Lib Lite tokens

List and generate Lib Lite tokens — the API key your mobile app passes to the In-App Payments SDK.

Lib Lite tokens are the API keys your mobile apps pass to the In-App Payments SDK on every payment invocation. Each merchant can have multiple active tokens — typically one per app build, environment, or distribution channel.

For the SDK side of the integration, see In-App Payments overview.


Endpoints

MethodPathPurposeAllowed callers
GET/restful/merchant/libLite/listTokens/{merchantId}List every token on a merchantPSP, Acquirer
POST/restful/merchant/libLite/generateTokenGenerate a new tokenPSP, Acquirer

Merchant must be in ACTIVE state.


List tokens

Returns every Lib Lite token configured for the merchant — active and historical.

Request:

curl -X GET https://qa.scantopay.io/portal/restful/merchant/libLite/listTokens/25 \
  -u 'PSP_42:yourPspApiPassword'

Response:

[
  {
    "merchantId": 25,
    "token": "A1B2C3D4E5F6A7B8A1B2C3D4E5F6A7B8",
    "status": "ACTIVE"
  },
  {
    "merchantId": 25,
    "token": "F1E2D3C4B5A69788F1E2D3C4B5A69788",
    "status": "DISABLED"
  }
]

Response fields:

FieldDescription
merchantIdMerchant the token belongs to
tokenThe 32-char uppercase hex token (16 random bytes, base16-encoded)
statusACTIVE or DISABLED

DISABLED tokens are rejected by the SDK with INVALID_API_KEY_PARAMETER — they're kept in the list for audit purposes only.

📘

The list endpoint returns the full token value — unlike the merchant API password, Lib Lite tokens are queryable after creation. They're treated as long-lived per-app credentials, not single-display secrets.


Generate a new token

Creates a fresh ACTIVE token on the merchant. The merchant can have as many active tokens as it needs — generation doesn't disable existing tokens.

Request:

curl -X POST https://qa.scantopay.io/portal/restful/merchant/libLite/generateToken \
  -u 'PSP_42:yourPspApiPassword' \
  -H 'Content-Type: application/json' \
  -d '{ "merchantId": 25 }'

Request fields:

FieldRequiredDescription
merchantIdyesMerchant to generate the token for

Response:

The same shape as List tokens — the full list of tokens (active and disabled), with the new token included.

[
  {
    "merchantId": 25,
    "token": "9B8A7C6D5E4F3210FEDCBA9876543210",
    "status": "ACTIVE"
  },
  {
    "merchantId": 25,
    "token": "A1B2C3D4E5F6A7B8A1B2C3D4E5F6A7B8",
    "status": "ACTIVE"
  }
]

Common errors

HTTPBodyCause
400"Merchant not in 'ACTIVE' state"Merchant must be active
400"Invalid 'merchantId'"Ownership check failed
401(empty)ROLE_REMOTE not granted, or caller-prefix not allowed

Multiple tokens — when and why

Use multiple tokens to separate concerns at the app / environment level:

ScenarioToken strategy
One app, sandbox + productionTwo tokens — one for TEST environment, one for LIVE (each issued per environment)
Multiple app builds with the same merchantOne token per build / channel — easier to track usage and revoke selectively
White-label deploymentsOne token per white-label partner
Internal testing app + customer-facing appSeparate tokens so internal usage doesn't skew customer analytics

There's no hard cap on the number of tokens per merchant, but in practice 5-10 is plenty for most setups.


Disabling a token

The Portal API doesn't expose a disable endpoint. To disable a token:

  • Portal UI: log in → email dropdown → Lib Lite Tokens → set the token's status to DISABLED
  • Or contact [email protected] for bulk disable / cleanup

Once disabled, the token immediately stops authenticating SDK calls — apps using it will receive INVALID_API_KEY_PARAMETER errors. Coordinate the disable with an app release that swaps in a new token.


What's next