Payment by Reference
Legacy Version
This section documents the legacy version of the IZI Pay Reference Payments & GPO API. It is intended for merchants and integrations that have not yet migrated to the latest API version. Existing implementations can continue using this version while planning their migration path to the current API platform.
The API uses predictable URLs, accepts JSON payloads, returns JSON responses, and follows standard HTTP status codes for success and error handling.
Environments
We provide two environments to support your development workflow:
- Production:
https://pay.izipay.ao - Sandbox:
https://pay-sandbox.izipay.ao
Return Codes
Field validation occurs before the requested resource is processed.
2xx- success.4xx- validation/authorization/request error.5xx- internal IZI Pay platform error.
| Code | Status | Definition |
|---|---|---|
| 200 | OK | The requested resource was successfully processed and returned. |
| 201 | Created | Resource created successfully; a Location header should be present indicating the URI of the new resource. |
| 204 | No Content | Resource successfully updated or deleted. |
| 400 | Bad Request | The request could not be parsed. Please check the syntax of the submitted data. |
| 401 | Unauthorized | Client is disabled, the signature is incorrect, or it was not provided properly. |
| 402 | Payment Required | Signature is correct, but the account has been blocked due to non-payment. |
| 403 | Forbidden | A connection was attempted without encryption (use HTTPS), or access to a resource was attempted without the required permissions. |
| 404 | Not Found | The requested resource/endpoint was not found, or the submitted format is not accepted. |
| 422 | Unprocessable Entity | The request was received but contains invalid parameters or business rule violations (see the errors attribute). |
| 429 | Too Many Requests | Request rate limit reached. Check the Retry-After header. |
| 500 | Internal Server Error | A failure occurred in the IZI Pay API. |
Query endpoint responses
Query endpoints (GET) may return 200 OK even when there are no results; in that case, the response body returns an empty array/object.
HMAC Authentication
Overview
Authentication is performed via an HMAC signature in the Authorization header.
- Security scheme:
apiKey - Header:
Authorization - Required transport:
HTTPS
For each application (App), the following credentials are provided:
AppId(client id)AppSecret(client secret)
Never expose the AppSecret in client-side code or public repositories.
How to Create the Signature
Build the MAC string in the following format:
AppId + HTTP_METHOD + URI + TIMESTAMP_UNIX + NONCE + BASE64_MD5_PAYLOAD
Then:
- Generate
HMAC-SHA256using theAppSecret. - Encode the result in Base64.
- Assemble the header as follows:
ApiKey AppId:hash:nonce:timestamp