Download OpenAPI specification:
This API is part of the our ecosystem. It allows you to make payments, find out the status of transactions and much more. Here you will find the latest documentation on setting up your solution.
Merchant’s request and callback have to be signed to verify sent data. To generate the signature all sent parameters from the payload are included in the order they were sent. The parameter signature should be excluded, of course, and added to the payload after generating.
Note: to generate a correct signature you need a secretKey received with other credentials.
function calculateSignature(array $data, string $secretKey, string $currentParamPrefix = '', int $depth = 16, int $currentRecursionLevel = 0 ): string
{
if ($currentRecursionLevel >= $depth) {
throw new Exception('Recursion level exceeded');
}
$stringForSignature = '';
foreach ($data as $key => $value) {
if (is_array($value)) {
$stringForSignature .= calculateSignature(
$value,
$secretKey,
"$currentParamPrefix$key.",
$depth,
$currentRecursionLevel + 1
);
} else if ($key !== 'signature') {
$stringForSignature .= "$currentParamPrefix$key" . $value;
}
}
if ($currentRecursionLevel == 0) {
return strtolower(hash_hmac('sha512', $stringForSignature, $secretKey));
} else {
return $StringForSignature;
}
}
$postData = [
'merchant_id' => 'fffed61be9780b97c5e4c65e4e07bb6b',
'provider_id' => 14,
'client_id' => '080000000',
'country' => 'BI',
'order_id' => 'order_3444298767545',
'amount' => 1000,
'currency' => 'BIF',
'callback_url' => 'https://my.callback.url'
];
$secretKey = "cf11635572c1e8d77297207152dc0791ad91f22b32d23c758ce3ba2637202ad8f7290ba41f2243cccf32edde1dfb8bf0f5dea62525309e293b3adb2c76eed6a5";
$signature = calculateSignature($postData, $secretKey);
$postData['signature'] = $signature;
Examples in other languages are available on request
| Code | Name | Description |
|---|---|---|
| -1 | undefined | Operation status is undefined (for example in an error situation) |
| 0 | initiated | Operation is initiated |
| 1 | in progress | Operation is in progress |
| 2 | success | Operation is successful |
| 3 | failed | Operation is failed |
| 4 | cancelled | Operation is cancelled |
| 5 | cancelled partially | Operation is cancelled partially (this status is related to POS payments) |
| 6 | in_transit | Operation is in transition (for example for withdrawal operation it means that cash was held but wasn’t received by the customer, this status also is related to POS payments) |
Depending on the type of request you may see the following code
| Code | Operation |
|---|---|
| 16 | payment_b2c |
| 17 | payment_c2b |
| Code | Note |
|---|---|
| USD | Non-betting merchants only |
| BIF | Burundi, betting and non-betting merchants |
Responses for confirmation requests have the same format as original operation responses.
C2b transaction status is sent via callback because it needs a confirmation by client done asynchronously. Usually the callback should be sent in 2-3 minutes maximum. In case of missing callback there is a way to get the transaction status using API method status. It needs the order ID as an parameter and returns a status of the performed transaction.
Payment gateway considers the Merchant system response as successful if HTTP 200 was received.
| Provider ID | Provider Name | Notes |
|---|---|---|
| 14 | Simulator | For testing purposes |
During tests runs, using 14 provider ID (simulator) the callback is not returned and the transaction remains in the "in progress" status and if successful you will see in the response
{
"order_id": "54321",
"transaction_id": "12345",
"transaction_ref": "",
"status": 1,
"result": {
"code": 0,
"message": "OK"
},
"provider_result": {
"code": -8888,
"message": "Good"
},
"service_id": 1,
"service_version": "1.03/1.14|1.0/1.26|1.0/1.0|1.01/1.01|1.01/1.01||1.01/1.27",
"service_date_time": "2023-05-15 10:00:00.000000",
"confirm_type": 0
}
| Provider ID | Provider Name | Notes |
|---|---|---|
| 358 | Lumicash |
25700000000 - This is the format of the phone number you have to send in the payment requests.
Client-Side Transaction Flow
After a transaction request is initiated, the following process occurs on the client side. Once the transaction is created, the customer receives an SMS notification requesting transaction approval.
Example notification: You received a request of approval at 10:00 10/10/2025 for cash-out 1,000 FBu from TikMoney Burundi, code: 101010. Fee: 0 FBu. This request will expire in 4 minutes. Please dial *163# and choose option 2 to approve it by entering the PIN code TransCode: 23145678945000 Thank you!
The user needs to perform actions from SMS
| c2b minimum | b2c minimum | Maximum transaction limit |
|---|---|---|
| BIF 1000 | BIF 2000 | BIF 1000000 |
| public_id required | string Example: f54ec96649be11ebb3780242ac130002 Merchant public ID |
Parameters to initiate a customer to the merchant payment
| merchant_id required | string (merchantIdDef) Unique Merchant ID received during the merchant registration |
| customer_id required | string (customerIdDef) Customer ID (usually mobile phone number of the customer) |
| order_id required | string (orderIdDef) The unique value is generated by the transaction initiator for each Operation. Max length is 128 symbols. Allowed symbols: [a-z], [A-Z], [0-9], “_” (underscore character), “-” (hyphen), “:” (colon), “.” (dot). For example, GUID or TIMESTAMP can be used as an order_id. This parameter provides API idempotency. It means that requests with identical nonce from the same transaction initiator will have identical responses and The corresponding operation won’t be repeated. |
| amount required | string Amount to pay, should be in format with two digits after point |
| currency required | string (currencyDef) Currency code in ISO 4217 format from the list of availabe currencies |
| country | string (countryDef) Country code in ISO 3166-1 alpha-2 format as defined in the payment providers. |
| callback_url | string URL to notify the merchant via callback. Recommended |
| provider_id required | integer (providerDef) Provider ID. Can be one of the option from this list. |
| signature required | string (signatureDef) Merchant’s request and callback have to be signed to verify sent data. To generate the signature all sent parameters are included in the order they were sent. The parameter signature should be excluded, of course. Example can be found here |
{- "merchant_id": "e0fecd91fcb24f348048193b3fb34875ba3722b4",
- "customer_id": "0900000001",
- "order_id": "16280954971628095497",
- "amount": "100.00",
- "currency": "BIF",
- "country": "BI",
- "provider_id": 14,
- "signature": "d7d6d76b0e22c6f9d369fa6c24f107053d12bfd24d3b154f2deb6676bf179c123134e1f20879c803be455d81cfe792f00cd8892c26ce7cf5a05beebb9c80843e"
}{- "order_id": "16280954971628095497",
- "transaction_id": "732007046722",
- "transaction_ref": "MP.33234.342.CP33",
- "status": 1,
- "result": {
- "code": 0,
- "message": "OK"
}, - "provider_result": {
- "code": 0,
- "message": "OK"
}, - "service_id": 1,
- "service_version": 11.1,
- "service_date_time": "2020-11-25 10:08:32.832969"
}{- "merchant_id": "e0fecd91fcb24f348048193b3fb34875ba3722b4",
- "operation_type": 17,
- "customer_id": "0900000001",
- "amount": 100,
- "order_id": "16280954971628095497",
- "transaction_id": "1234567",
- "transaction_ref": "QR555RQ",
- "status": 2,
- "provider_id": 14,
- "destination_id": "",
- "result": {
- "code": 0,
- "message": "OK"
}, - "provider_result": {
- "code": 0,
- "message": "OK"
}, - "service_id": 1,
- "service_version": "1.03/1.0|1.0/1.26|1.0/1.0|1.01/1.0|1.01/1.0||1.01/1.27",
- "service_date_time": "2020-11-25 10:08:32.832969",
- "signature": "d7d6d76b0e22c6f9d369fa6c24f107053d12bfd24d3b154f2deb6676bf179c123134e1f20879c803be455d81cfe792f00cd8892c26ce7cf5a05beebb9c80843e"
}Cashless payment from the merchant to the customer. If the confirm_type response parameter is a non-zero merchant, send the second payment_b2c request with confirmation data according to the section Confirmation Types.
| public_id required | string Example: f54ec96649be11ebb3780242ac130002 Merchant public ID |
Parameters to initiate the merchant to the customer payment
| merchant_id required | string (merchantIdDef) Unique Merchant ID received during the merchant registration |
| customer_id required | string (customerIdDef) Customer ID (usually mobile phone number of the customer) |
| order_id required | string (orderIdDef) The unique value is generated by the transaction initiator for each Operation. Max length is 128 symbols. Allowed symbols: [a-z], [A-Z], [0-9], “_” (underscore character), “-” (hyphen), “:” (colon), “.” (dot). For example, GUID or TIMESTAMP can be used as an order_id. This parameter provides API idempotency. It means that requests with identical nonce from the same transaction initiator will have identical responses and The corresponding operation won’t be repeated. |
| amount required | string Amount to pay, with two digits after point |
| currency required | string (currencyDef) Currency code in ISO 4217 format from the list of availabe currencies |
| country | string (countryDef) Country code in ISO 3166-1 alpha-2 format as defined in the payment providers. |
| callback_url | string URL to notify the merchant via callback |
| provider_id required | integer (providerDef) Provider ID. Can be one of the option from this list. |
| signature required | string (signatureDef) Merchant’s request and callback have to be signed to verify sent data. To generate the signature all sent parameters are included in the order they were sent. The parameter signature should be excluded, of course. Example can be found here |
{- "merchant_id": "e0fecd91fcb24f348048193b3fb34875ba3722b4",
- "customer_id": "0900000001",
- "order_id": "16280954971628095497",
- "amount": "100.00",
- "currency": "BIF",
- "country": "BI",
- "provider_id": 14,
- "signature": "d7d6d76b0e22c6f9d369fa6c24f107053d12bfd24d3b154f2deb6676bf179c123134e1f20879c803be455d81cfe792f00cd8892c26ce7cf5a05beebb9c80843e"
}{- "order_id": "16280954971628095497",
- "transaction_id": "732007046722",
- "transaction_ref": "MP.33234.342.CP33",
- "status": 1,
- "result": {
- "code": 0,
- "message": "OK"
}, - "provider_result": {
- "code": 0,
- "message": "OK"
}, - "service_id": 1,
- "service_version": 11.1,
- "service_date_time": "2020-11-25 10:08:32.832969"
}| public_id required | string Example: f54ec96649be11ebb3780242ac130002 Merchant public ID |
Get the status of the performed transaction
| merchant_id required | string (merchantIdDef) Unique Merchant ID received during the merchant registration |
| order_id required | string (orderIdDef) The unique value is generated by the transaction initiator for each Operation. Max length is 128 symbols. Allowed symbols: [a-z], [A-Z], [0-9], “_” (underscore character), “-” (hyphen), “:” (colon), “.” (dot). For example, GUID or TIMESTAMP can be used as an order_id. This parameter provides API idempotency. It means that requests with identical nonce from the same transaction initiator will have identical responses and The corresponding operation won’t be repeated. |
| signature required | string (signatureDef) Merchant’s request and callback have to be signed to verify sent data. To generate the signature all sent parameters are included in the order they were sent. The parameter signature should be excluded, of course. Example can be found here |
{- "merchant_id": "e0fecd91fcb24f348048193b3fb34875ba3722b4",
- "order_id": "16280954971628095497",
- "signature": "d7d6d76b0e22c6f9d369fa6c24f107053d12bfd24d3b154f2deb6676bf179c123134e1f20879c803be455d81cfe792f00cd8892c26ce7cf5a05beebb9c80843e"
}{- "order_id": "16280954971628095497",
- "transaction_id": "532007056722",
- "transaction_ref": "",
- "status": 1,
- "result": {
- "code": 0,
- "message": "OK"
}, - "provider_result": {
- "code": 0,
- "message": "OK",
- "customer_message": "Complete the payment by following the instructions received by USSD"
}, - "service_id": 11,
- "service_version": 11.1,
- "service_date_time": "2020-11-25 10:08:32.832969",
- "confirm_type": 0
}