Amnen Pay apps (customer, agent, merchant)
Native and web apps use the same APIs as the website. Log the user in, then send the short-lived access token on every request. Never put a secret API key inside the mobile app binary.
# 1) Login (OTP or password — same as the website)
curl -X POST https://api.amnenpay.com/api/v1/auth/login \
-H "Content-Type: application/json" \
-d '{"phone":"+46700000000","otp":"123456"}'
# 2) Call any app API with that JWT
curl https://api.amnenpay.com/api/v1/user/balance \
-H "Authorization: Bearer ACCESS_TOKEN"
# Full list: GET https://api.amnenpay.com/api/v1/docs/appsContract reference: API Style Guide
API keys
Send your secret key in the Authorization: ApiKey … header or X-API-Key. Keys are stored hashed with a visible prefix for identification.
| Key prefix | Purpose |
|---|---|
ampk_test_… | Merchant API key (sandbox/test). Hashed at rest; rotate and revoke via the dashboard. Synthetic example only. |
ampk_… | Merchant API key (live). Server-side only. Never expose in a browser or mobile app. |
Bearer JWT | Short-lived HS256 access token from login/refresh. Not a password grant on API services. |
Authenticated request
curl https://sandbox.amnenpay.com/v1/wallets \ -H "Authorization: Bearer sk_test_51H8xExampleSandboxKeyOnly"
Bearer tokens (dashboard sessions)
Interactive apps exchange credentials at POST /auth/login for a short-lived access token and a refresh token. Send the access token as Authorization: Bearer <accessToken> and refresh it at POST /auth/refresh before it expires.
Security rules
- Secret keys are shown once at creation — store them in a secrets manager, never in source control.
- Never ship a secret key to a browser, mobile app, or public repository.
- Rotate keys regularly and immediately revoke any key you suspect is leaked.
- Sandbox and production keys are fully isolated — sandbox never touches real money.