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
| Method | Path | Purpose | Allowed callers |
|---|---|---|---|
| GET | /restful/merchant/libLite/listTokens/{merchantId} | List every token on a merchant | PSP, Acquirer |
| POST | /restful/merchant/libLite/generateToken | Generate a new token | PSP, 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:
| Field | Description |
|---|---|
merchantId | Merchant the token belongs to |
token | The 32-char uppercase hex token (16 random bytes, base16-encoded) |
status | ACTIVE 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:
| Field | Required | Description |
|---|---|---|
merchantId | yes | Merchant 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
| HTTP | Body | Cause |
|---|---|---|
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:
| Scenario | Token strategy |
|---|---|
| One app, sandbox + production | Two tokens — one for TEST environment, one for LIVE (each issued per environment) |
| Multiple app builds with the same merchant | One token per build / channel — easier to track usage and revoke selectively |
| White-label deployments | One token per white-label partner |
| Internal testing app + customer-facing app | Separate 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
- Use the token in the SDK → In-App Payments overview
- Android-specific integration → Android — Payments
- iOS-specific integration → iOS — Payments
- SDK error reference → Android errors / iOS errors
- Cross-cutting rules → Business rules
Updated about 23 hours ago
