Applications
Register applications, manage their API credentials, and override the gateway for testing.
Applications are the tenants of the service. Registering one provisions its identity, settings, and the credentials it uses to call the API.
Register an app
POST /admin/apps (requires app:manage) creates the app and two credential
pairs — TEST and LIVE. The raw key and secret of each are returned once
in the registration response; relay them to the integrating team securely.
| Setting | Meaning |
|---|---|
name | Display name. |
webhookUrl | Where signed webhooks are delivered. |
refundApprovalThresholdMinor | Operator refunds above this are parked for approval. |
receiptsEnabled | Whether settled payments expose a receipt. |
minAmountMinor / maxAmountMinor | Optional per-payment bounds. |
Update settings later with PATCH /admin/apps/{id}/settings.
Manage credentials
List an app's credentials with GET /admin/apps/{id}/credentials. Each row shows
its mode, status, and expiresAt — secrets are never shown again after
creation.
- Rotate —
POST /admin/apps/{id}/credentials/rotateissues a new credential and puts the old one into a grace window (both work until it expires). Use this for routine rotation or to replace a lost secret without downtime. - Revoke —
POST /admin/apps/{id}/credentials/{credentialId}/revokedisables a credential immediately.
See Authentication for the integrator's side of rotation.
Rotation and revocation are sensitive actions: they require step-up re-auth and are recorded in the audit log.
Gateway override
For testing, an operator can point an app's mode at a specific gateway configuration:
PUT /admin/apps/{id}/gateway-override— set the override.DELETE /admin/apps/{id}/gateway-override/{mode}— clear it.
This is how you exercise sandbox vs. specific store credentials without changing the app. Like credential changes, it requires step-up re-auth and is audited.