Download OpenAPI specification:Download
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' => 'KE',
'order_id' => 'order_3444298767545',
'amount' => 1000,
'currency' => 'KES',
'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) |
Only this parameter determines the status of the transaction
Depending on the type of request you may see the following code
| Code | Operation |
|---|---|
| 16 | payment_b2c |
| 17 | payment_c2b |
| Code | Name | Locations |
|---|---|---|
| BIF | Burundian franc | Burundi |
| CDF | Congolese Franc | CONGO (THE DEMOCRATIC REPUBLIC OF THE) |
| GHS | Ghanaian cedi | Ghana |
| KES | Kenyan shilling | the Republic of Kenya |
| MWK | Malawian kwacha | Malawi |
| NGN | Naira | Nigeria |
| RWF | Rwandan franc | Rwanda |
| TZS | Tanzanian shilling | Tanzania |
| UGX | Ugandan shilling | Uganda |
| XAF | CFA franc BEAC | Cameroon, Central African Republic, Republic of the Congo, Chad, Equatorial Guinea, Gabon |
| XOF | CFA franc BCEAO | Benin, Burkina Faso, Ivory Coast, Guinea-Bissau, Mali, Niger, Senegal, Togo |
| ZAR | South African rand | Eswatini, Lesotho, Namibia, South Africa |
| ZMW | Zambian Kwacha | Zambia |
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 |
|---|---|---|
| 2302 | Lumicash |
25700000000 - This is the format of the phone number you have to send in the payment requests.
| c2b minimum | b2c minimum | Maximum transaction limit |
|---|---|---|
| BIF 1000 | BIF 2000 | BIF 1000000 |
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 Bitlipa Burundi, code: 101010. Fee: 0 FBu. This request will expire in 4 minutes. Please dial *163# and choose option 2 to approve it. TransCode: 23145678945000 Thank you.
The user needs to perform actions from SMS
| Provider ID | Provider Name |
|---|---|
| 189 | Orange |
| 190 | Mobicash |
22600000000 - This is the format of the phone number you have to send in the payment requests.
For C2B payments you should send a customer email in the payment requests. Parameters extra->customer_email. Please see the example in the API Methods section.
For B2C payments you should send a customer full name in the payment requests. Parameter extra->customer_name. Please see the example in the API Methods section.
| c2b minimum | b2c minimum | Maximum transaction limit |
|---|---|---|
| XOF 5.00 | XOF 1.00 | XOF 550000.00 |
| Provider ID | Provider Name | Notes |
|---|---|---|
| 191 | Orange | Check provider id with your manager |
| 192 | MTN | Check provider id with your manager |
| 658 | MNT | Check provider id with your manager |
| 659 | Orange | Check provider id with your manager |
237000000000 - This is the format of the phone number you have to send in the payment requests.
For 191, 192: For C2B payments you should send a customer email in the payment requests. Parameters extra->customer_email. Please see the example in the API Methods section.
For 658, 659: For C2B payments you should send a customer full name in the payment requests. Parameters extra->customer_name. Please see the example in the API Methods section.
For B2C payments you should send a customer full name in the payment requests. Parameter extra->customer_name. Please see the example in the API Methods section.
| c2b minimum | b2c minimum | Maximum transaction limit |
|---|---|---|
| XAF 5.00 | XAF 1.00 | XAF 550000.00 |
| Provider ID | Provider Name | Notes |
|---|---|---|
| 2079 | Orange | Client's phone should start from 0: 0800000000 |
| 2078 | Airtel | Client's phone shouldn't start from 0: 999000000 |
| 2080 | Africel | Client's phone should start from 0: 0900000000 |
| c2b minimum | b2c minimum | Maximum transaction limit |
|---|---|---|
| CDF 100 | CDF 100 | CDF 1500000 |
The flow is standard, no need to pass extra parameters.
| Provider ID | Provider Name |
|---|---|
| 193 | Orange |
| 194 | MTN |
| 195 | Moov |
| 736 | Wave |
2250000000000 - This is the format of the phone number you have to send in the payment requests.
For C2B payments you should send a customer full name and customer email in the payment requests. Parameters extra->customer_name and extra->customer_email. Please see the example in the API Methods section.
Current methods have additional instructions for C2B payments for the Customers during the payment. To make it successful you should display these instructions to the Customers after the payment initiated. The flow is this:
1. You call the standard C2B request payment_c2b and get the response (example in the API Methods section).
2. After successful response of accepting the transaction into processing (status:1), you call the status method.
3. You can get the link in the parameter extra->customer_redirect in the response of the status method. After receiving the link, you should redirect the customer to this page to confirm the transaction using OTP code
For B2C payments you should send a customer full name in the payment requests. Parameter extra->customer_name. Please see the example in the API Methods section.
| c2b minimum | b2c minimum | Maximum transaction limit |
|---|---|---|
| XOF 5.00 | XOF 1.00 | XOF 550000.00 |
| Provider ID | Provider Name |
|---|---|
| 196, 2062 | AirtelTigo |
| 197, 2063 | MTN |
| 198, 2064 | Vodafone |
233000000000 - This is the format of the phone number you have to send in the payment requests.
For C2B payments you should send a customer full name and customer email in the payment requests. Parameters extra->customer_name and extra->customer_email. Please see the example in the API Methods section.
You can get the link in the parameter extra->customer_redirect in the response of the status method. After receiving the link, you should redirect the customer to this page to confirm the transaction using OTP code.
For B2C payments you should send a customer full name in the payment requests. Parameter extra->customer_name. Please see the example in the API Methods section.
| c2b minimum | b2c minimum | Maximum transaction limit |
|---|---|---|
| GHS 1.00 | GHS 10.00 | GHS 5000.00 |
| Provider ID | Provider Name | Notes |
|---|---|---|
| 660 | MTN |
22400000000 - This is the format of the phone number you have to send in the payment requests (country code is not required).
For C2B payments you should send a customer full name in the payment requests. Parameters extra->customer_name. Please see the example in the API Methods section.
For B2C payments you should send a customer full name in the payment requests. Parameter extra->customer_name. Please see the example in the API Methods section.
| c2b minimum | b2c minimum | Maximum transaction limit |
|---|---|---|
| GNF 1000.00 | GNF 1000.00 | GNF 10000000.00 |
| Provider ID | Provider Name | Notes |
|---|---|---|
| 199, 347, 2012 | MPESA | Check provider id with your manager |
254000000000 - This is the format of the phone number you have to send in the payment requests.
For C2B payments you should send a customer full name and customer email in the payment requests. Parameters extra->customer_name and extra->customer_email. Please see the example in the API Methods section.
For B2C payments you should send a customer full name in the payment requests. Parameter extra->customer_name. Please see the example in the API Methods section.
For B2C payments provider 199 you should send a customer document type and document number in the payment requests. Parameters extra->customer_doc_type and extra->customer_doc_number. The customer_doc_type parameter can have one of the following values: * intl_passport - for International Passport * driving_license - for Driving License * national_id - for National ID
| c2b minimum | b2c minimum | Maximum transaction limit |
|---|---|---|
| KES 1.00 | KES 500.00 | KES 150000.00 |
| Provider ID | Provider Name | Notes |
|---|---|---|
| 2157 | Airtel | |
| 2158 | TNM |
265000000000 - This is the format of the phone number you have to send in the payment requests.
For C2B payments, the flow is standard, no need to pass extra parameters For B2C payments, you should send a customer full name in the payment requests. Parameter extra->customer_name. Please see the example in the API Methods section.
| c2b minimum | b2c minimum | Maximum transaction limit |
|---|---|---|
| MWK 50.00 | MWK 50.00 | MWK 750000.00 |
| Provider ID | Provider Name | Notes |
|---|---|---|
| 661 | Orange |
22300000000 - This is the format of the phone number you have to send in the payment requests.
For C2B payments you should send a customer full name in the payment requests. Parameters extra->customer_name. Please see the example in the API Methods section.
For B2C payments you should send a customer full name in the payment requests. Parameter extra->customer_name. Please see the example in the API Methods section.
| c2b minimum | b2c minimum | Maximum transaction limit |
|---|---|---|
| XOF 200.00 | XOF 1000.00 | XOF 1500000.00 |
| Provider ID | Provider Name |
|---|---|
| 5008 | BankTransfer |
| 5010 | Palmpay |
| 5011 | Pay Attitude |
Bank Transfer / Pay Attitude / OPay / Palmpay payment C2B (deposit) scenario:
C2B query url parameters:
| Name | Is required | Value | Description |
|---|---|---|---|
| merchant_id | required | Unique Merchant ID received during the merchant registration | |
| customer_id | required | ||
| order_id | required | 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. | |
| country | required | NG | Country code in ISO 3166-1 alpha-2 format |
| currency | required | NGN | Currency code in ISO 4217 format from the list of availabe currencies |
| provider_id | required | Provider identifier | |
| operation | required | c2b | Operation type |
| type | required | bank_transfer | Provider type |
| callback_url | not required | URL to notify the merchant via callback. Callback structure you may see in C2B API Method. | |
| not required | Customer email | ||
| name | not required | Customer full name | |
| amount | not required | Amount to pay | |
| signature | required | 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 below |
Pay Attitude / OPay / Palmpay payment B2C (withdrawal) scenario:
Bank Transfer B2C (withdrawal) scenario:
B2C Bank Transfer request example:
{
"merchant_id":"e0fecd91fcb24f348048193b3fb34875ba3722b4",
"order_id":"0900000001",
"customer_id":"16280954971628095497",
"amount":"100",
"currency":"NGN",
"provider_id":5008,
"extra":{
"customer_name":"Name Lastname"
"bank_code":"000001"
},
"signature":"d7d6d76b0e22c6f9d369fa6c24f107053d12bfd24d3b154f2deb6676bf179c123134e1f20879c803be455d81cfe792f00cd8892c26ce7cf5a05beebb9c80843e"
}
| c2b minimum | b2c minimum | Maximum transaction limit |
|---|---|---|
| NGN 100.00 | NGN 100.00 | NGN 400000.00 |
For 5008 provider_id, there is an alternative way to make a c2b transaction request - directly through the API
{
"merchant_id":"e0fecd91fcb24f348048193b3fb34875ba3722b4",
"order_id":"0900000001",
"customer_id":"0000000000",
"amount":"100.00",
"currency":"NGN",
"provider_id":5008,
"extra": {
"customer_email": "[email protected]"
},
"signature":"d7d6d76b0e22c6f9d369fa6c24f107053d12bdgjkdgrjrdig445579c123134e1f20879c803be455d81cfe792f00cd8892c26ce7cf5a05beebb9c80843e"
}
In the synchronized response, you will get the bank payment details that need to be share to the user. This is listed in the "extra" part
{
"order_id": "90900000001",
"transaction_id": "",
"transaction_ref": "",
"status": 1,
"result": {
"code": 0,
"message": "OK"
},
"provider_result": {
"code": -8888,
"message": ""
},
"service_id": 1,
"service_version": "1.03/1.14|1.0/2.0|1.0/1.0|1.01/1.0|1.01/2.0||1.02/1.27",
"service_date_time": "2024-04-20 01:08:42.797957",
"extra": {
"transfer_amount": 100,
"account_number": "4000000000",
"bank_name": "Premium Trust Bank"
},
"confirm_type": 0
}
For other provider_id in the case of bank transfers, a payment page implementation is required
| Provider ID | Provider Name |
|---|---|
| 200 | Airtel |
| 201 | MTN |
250700000000 - This is the format of the phone number you have to send in the payment requests.
For C2B payments you should send a customer full name and customer email in the payment requests. Parameters extra->customer_name and extra->customer_email. Please see the example in the API Methods section.
Current methods have additional instructions for C2B payments for the Customers during the payment. To make it successful you should display these instructions to the Customers after the payment initiated. The flow is this:
1. You call the standard C2B request payment_c2b and get the response (example in the API Methods section).
2. After successful response of accepting the transaction into processing (status:1), you call the status method.
3. You can get the link in the parameter extra->customer_redirect in the response of the status method. After receiving the link, you should redirect the customer to this page to confirm the transaction using OTP code
For B2C payments you should send a customer full name in the payment requests. Parameter extra->customer_name. Please see the example in the API Methods section.
| c2b minimum | b2c minimum | Maximum transaction limit |
|---|---|---|
| RWF 300.00 | RWF 300.00 | No Limit |
| Provider ID | Provider Name |
|---|---|
| 202 | Orange |
| 203 | Wave |
| 204 | Free money |
| 205 | E-money |
221700000000 - This is the format of the phone number you have to send in the payment requests.
For C2B payments you should send a customer full name and customer email in the payment requests. Parameters extra->customer_name and extra->customer_email. Please see the example in the API Methods section.
Current methods have additional instructions for C2B payments for the Customers during the payment. To make it successful you should display these instructions to the Customers after the payment initiated. The flow is this:
1. You call the standard C2B request payment_c2b and get the response (example in the API Methods section).
2. After successful response of accepting the transaction into processing (status:1), you call the status method.
3. You can get the link in the parameter extra->customer_redirect in the response of the status method. After receiving the link, you should redirect the customer to this page to confirm the transaction using OTP code
For B2C payments you should send a customer full name in the payment requests. Parameter extra->customer_name. Please see the example in the API Methods section.
| c2b minimum | b2c minimum | Maximum transaction limit |
|---|---|---|
| XOF 100.00 | XOF 100.00 | No Limit |
| Provider ID | Provider Name |
|---|---|
| 5012 | BankTransfer |
Bank Transfer C2B (deposit) scenario:
Bank Transfer B2C (withdrawal) scenario:
B2C Bank Transfer C2B (deposit) request example:
{
"merchant_id":"e0fecd91fcb24f348048193b3fb34875ba3722b4",
"order_id":"0900000001",
"customer_id":"0000000000",
"amount":"100",
"currency":"ZAR",
"provider_id":5012,
"extra":{
"customer_email": "[email protected]"
},
"signature":"d7d6d76b0e22c6f9d369fa6c24f107053d12bfd24d3b154f2deb6676bf179c123134e1f20879c803be455d81cfe792f00cd8892c26ce7cf5a05beebb9c80843e"
}
B2C Bank Transfer B2C (withdrawal) request example:
{
"merchant_id":"e0fecd91fcb24f348048193b3fb34875ba3722b4",
"order_id":"0900000001",
"customer_id":"16280954971628095497",
"amount":"100",
"currency":"ZAR",
"provider_id":5012,
"extra":{
"bank_code":"FNB",
"customer_name":"Name Lastname",
"customer_email":"[email protected]",
"customer_phone":"0123456789",
"customer_address":"Customer Address"
},
"signature":"d7d6d76b0e22c6f9d369fa6c24f107053d12bfd24d3b154f2deb6676bf179c123134e1f20879c803be455d81cfe792f00cd8892c26ce7cf5a05beebb9c80843e"
}
| c2b minimum | b2c minimum | Maximum transaction limit |
|---|---|---|
| ZAR 5.00 | ZAR 5.00 |
| Provider ID | Provider Name | Notes |
|---|---|---|
| 2007, 117, 206 | Airtel | Check provider id with your manager |
| 2008, 119, 207 | HaloPesa | Check provider id with your manager |
| 2009, 126, 209 | Vodafone | Check provider id with your manager |
| 2010, 118, 208 | Tigo | Check provider id with your manager |
255000000000 - This is the format of the phone number you have to send in the payment requests.
For C2B payments, you should send a customer full name and customer email in the payment requests. Parameters extra->customer_name and extra->customer_email. Please see the example in the API Methods section.
For B2C payments you should send a customer full name in the payment requests. Parameter extra->customer_name. Please see the example in the API Methods section.
For B2C payments providers 206, 207, 208, 209 you should send a customer document type and document number in the payment requests. Parameters extra->customer_doc_type and extra->customer_doc_number. The customer_doc_type parameter can have one of the following values: * intl_passport - for International Passport * driving_license - for Driving License * national_id - for National ID
| c2b minimum | b2c minimum | Maximum transaction limit |
|---|---|---|
| TZS 100.00 | TZS 1000.00 | TZS 50000000.00 |
| Provider ID | Provider Name | Notes |
|---|---|---|
| 2005, 210 | Airtel | Check provider id with your manager |
| 2006, 211 | MTN | Check provider id with your manager |
256709000000 - This is the format of the phone number you have to send in the payment requests.
For C2B payments you should send a customer full name and customer email in the payment requests. Parameters extra->customer_name and extra->customer_email. Please see the example in the API Methods section.
Current methods have additional instructions for C2B payments for the Customers during the payment. To make it successful you should display these instructions to the Customers after the payment initiated. The flow is this:
1. You call the standard C2B request payment_c2b and get the response (example in the API Methods section).
2. After successful response of accepting the transaction into processing (status:1), you call the status method.
3. You can get the link in the parameter extra->customer_redirect in the response of the status method. After receiving the link, you should redirect the customer to this page to confirm the transaction using OTP code
For B2C payments you should send a customer full name in the payment requests. Parameter extra->customer_name. Please see the example in the API Methods section.
| c2b minimum | b2c minimum | Maximum transaction limit |
|---|---|---|
| UGX 1000.00 | UGX 2000.00 | UGX 4000000.00 |
| Provider ID | Provider Name | Notes |
|---|---|---|
| 2159, 2376 | Airtel | |
| 2160, 2377 | MTN | |
| 2161, 2378 | ZAMTEL |
260976000000 - This is the format of the phone number you have to send in the payment requests.
For C2B payments, the flow is standard, no need to pass extra parameters For B2C payments, the flow is standard, no need to pass extra parameters
For payments, the flow is standard, no need to pass extra parameters
| c2b minimum | b2c minimum | Maximum transaction limit |
|---|---|---|
| ZMW 1.00 | ZMW 1.00 | ZMW 5000.00 |
| Provider ID | Provider Name |
|---|---|
| 355 | TMoney |
22890000000 - This is the format of the phone number you have to send in the payment requests.
The flow is standard, no need to pass extra parameters.
| c2b minimum | b2c minimum | Maximum transaction limit |
|---|---|---|
| XOF 200.00 | XOF 500.00 | XOF 200 000.00 |
Payment Page allows to avoid the user interface and payment forms developing on the merchant’s side for each payment method. The Merchant only needs to redirect the Customer to the payment page at [this link], where they can enter their specific data for the selected payment method. The payment page can be opened in a pop-up window, an iframe or a separate browser tab.
Merchant needs to append some required parameters to the query url, and some optional ones. The optional parameters allow merchant to pre-fill some data in the url, or let the customer enter it on the payment page themselves.
URL example with the pre-filled customer’s data https://hpp.bitlipa.net/example.php
After the redirect merchant needs to request the status of the initiated payment and also wait the callback with the final status. Status request and callbacks formats are described on the API Methods page.
Signature generating for the redirect URL example:
function calculateSignature($data, $secret)
{
$signed = '';
foreach ($data as $key => $value)
{
$signed .= $key.$value;
}
return strtolower(hash_hmac('sha512', $signed, $secret));
}
$data = [
'merchant_id' => 'fffed61be9780b97c5e4c65e4e07bb6b',
'order_id' => 'order_3444298767545',
'country' => 'NGA',
'currency' => 'NGN',
'provider_id' => 5008,
'operation' => 'c2b',
'type' => 'bank_transfer',
'callback_url' => 'https://my.callback.url'
];
$secretKey = "cf11635572c1e8d77297207152dc0791ad91f22b32d23c758ce3ba2637202ad8f7290ba41f2243cccf32edde1dfb8bf0f5dea62525309e293b3adb2c76eed6a5";
$signature = calculateSignature($data, $secretKey);
echo $signature;
// signature: 9826c5e89ff6386e7bbb5263a4fbd41ed35eb2fc7c58650be487db14f066b0a650b1980762575ad296b0cbac1745f6a5faeb64cacd2756ccff95b52ba08259d7
// result query: https://hpp.bitlipa.net/?merchant_id=fffed61be9780b97c5e4c65e4e07bb6b&order_id=order_3444298767545&country=NGA¤cy=NGN&provider_id=5008&operation=c2b&type=bank_transfer&callback_url=https://my.callback.url&signature=9826c5e89ff6386e7bbb5263a4fbd41ed35eb2fc7c58650be487db14f066b0a650b1980762575ad296b0cbac1745f6a5faeb64cacd2756ccff95b52ba08259d7
This payment page https://hpp.bitlipa.net/example.php is only a test example, it should be implemented on the merchant side with only the data that the user must enter. For example, it can only be email, name and amount.
If the data is entered incompletely or incorrectly, the user will see the form:
After entering all the data correctly, the request will be sent to the system, and the user will be redirected to the web-page, where it is necessary to get bank details for payment
| 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 | |
| callback_url | string URL to notify the merchant via callback. Recommended |
| provider_id required | |
object Extra parameters | |
| 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": "CDF",
- "country": "KE",
- "provider_id": 14,
- "extra": {
- "customer_name": "Name Surname"
}, - "signature": "d7d6d76b0e22c6f9d369fa6c24f107053d12bfd24d3b154f2deb6676bf179c123134e1f20879c803be455d81cfe792f00cd8892c26ce7cf5a05beebb9c80843e"
}{- "order_id": "16280954971628095497",
- "transaction_id": "732007046722",
- "transaction_ref": "MP.33234.342.CP33",
- "status": 2,
- "result": {
- "code": 0,
- "message": "OK"
}, - "service_id": 1,
- "service_version": 11.1,
- "service_date_time": "2020-11-25 10:08:32.832969"
}{- "transaction_id": "1234567",
- "order_id": "16280954971628095497",
- "status": 2,
- "service_id": 12345,
- "service_version": "5.2.0",
- "service_date_time": "2020-11-25 10:08:32.832969",
- "result": {
- "code": 0,
- "message": "OK"
}, - "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 | |
| callback_url | string URL to notify the merchant via callback |
| provider_id required | |
object Extra parameters | |
| 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": "CDF",
- "country": "KE",
- "provider_id": 14,
- "extra": {
- "customer_name": "Name Surname"
}, - "signature": "d7d6d76b0e22c6f9d369fa6c24f107053d12bfd24d3b154f2deb6676bf179c123134e1f20879c803be455d81cfe792f00cd8892c26ce7cf5a05beebb9c80843e"
}{- "order_id": "16280954971628095497",
- "transaction_id": "732007046722",
- "transaction_ref": "MP.33234.342.CP33",
- "status": 2,
- "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": 2,
- "result": {
- "code": 0,
- "message": "OK"
}, - "extra": {
- "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
}| public_id required | string Example: f54ec96649be11ebb3780242ac130002 Merchant public ID |
Get available banks
| merchant_id required | string (merchantIdDef) Unique Merchant ID received during the merchant registration |
| provider_id required | |
| 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",
- "provider_id": 14,
- "signature": "d7d6d76b0e22c6f9d369fa6c24f107053d12bfd24d3b154f2deb6676bf179c123134e1f20879c803be455d81cfe792f00cd8892c26ce7cf5a05beebb9c80843e"
}{- "banks": [
- {
- "code": "000001",
- "name": "OK"
}
], - "result": {
- "code": 0,
- "message": "OK"
}
}