Payment API Gateway (v5.7.2)

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.

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
}

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.

PHP example

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' => 10,
  'client_id' => '254000000000',
  '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

The parameters below will be obtained by a status query

Depending on the type of request you may see the following code

You can see this parameter in the callback

Responses for confirmation requests have the same format as original operation responses.

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.

Response for callback

Payment gateway considers the Merchant system response as successful if HTTP 200 was received.

2290000000000 - This is the format of the phone number you have to send in the payment requests.

C2B for Provider_ids that do not require OTP or Redirect: 9210

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST C2B request) and set extra data depending on the provider_id:

3. Customer gets push from operator and confirm the operation
4. Merchant gets a callback (or requests the status) with the final state of the operation

B2C flow is the same for everyone, please specify the required extra parameters

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST B2C request) and set extra data depending on the provider_id:

3. Customer receives funds to their mobile number
4. Merchant gets a callback (or requests the status) with the final state of the operation

Benin limits

22600000000 - This is the format of the phone number you have to send in the payment requests.

C2B for Provider_ids that require a OTP: 9209

1. Customer create OTP code on ussd_code *144*4*6*montant#
2. Customer initiates the payment on Merchant side
3. Merchant sends request to the platform (POST C2B request) and set extra data depending on the provider_id:

Example Request:

  {
  "merchant_id": "your merchant id",
  "customer_id": "2250705145655",
  "order_id": "test_161225_01_1",
  "amount": "1100",
  "currency": "XOF",
  "country": "BF",
  "callback_url": "your callback url",
  "provider_id": "9209",
  "signature": "1c594d338bc3f413bd61cb97d697e98ad5772071da533",
  "extra": {
    "otp": "5647"
  },
  }

4. Operator debits funds from customer mobile number
5. Merchant gets a callback (or requests the status) with the final state of the operation

B2C flow is the same for everyone, please specify the required extra parameters

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST B2C request) and set extra data depending on the provider_id:

3. Customer receives funds to their mobile number
4. Merchant gets a callback (or requests the status) with the final state of the operation

Burkina Faso limits

Note: for 9209 deposits and withdrawals are made in multiples of 5.

237000000000 - This is the format of the phone number you have to send in the payment requests.

C2B for Provider_ids that do not require OTP or Redirect: 802, 803, 702, 703, 9131

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST C2B request) and set extra data depending on the provider_id:

3. Customer gets push from operator and confirm the operation
4. Merchant gets a callback (or requests the status) with the final state of the operation

C2B for Provider_ids redirecting to Provider payment pages: 9062, 9063

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST C2B request) and set extra data depending on the provider_id:

3. Merchant gets the status of the operation and extra data customer_redirect
   Example of a user redirect link:

"extra": 
{
"customer_redirect": "https://checkout.provider.com/202511131111MqKRft39377/pay"
}, 

4. Merchant redirect Customer to provider page
5. Customer confirms the payment on the provider page
6. Merchant gets a callback (or requests the status) with the final state of the operation

B2C flow is the same for everyone, please specify the required extra parameters

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST B2C request) and set extra data depending on the provider_id:

3. Customer receives funds to their mobile number
4. Merchant gets a callback (or requests the status) with the final state of the operation

Cameroon limits

The flow is standard, no need to pass extra parameters

DR Congo limits

For 9227

C2B

1. Customer initiates the payment on Merchant side where customer_id is Wave GMB account number and sets extra data customer_name and customer_email
2. Merchant sends request to the platform (POST status) and get redirect_url (in the parameter extra->customer_redirect in the response)
3. Merchant redirect Customer to provider payment page
4. Customer submit form on provider payment page and confirm the operation
5. Merchant gets a callback (or requests the status) with the final stCate of the operation

B2C

1. Customer initiates the payment on Merchant side where customer_id is Wave GMB account number and sets extra data customer_name
2. Merchant sends request to the platform (POST payment_b2c)
3. Customer receives funds to their Wave GMB account
4. Merchant gets a callback (or requests the status) with the final state of the operation

Gambia limits

2250000000000 - This is the format of the phone number you have to send in the payment requests.

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 806:

C2B

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST payment_c2b) and set extra data a. customer_name b. customer_email
3. Platform returns a synchronous response with initial status In Progress
4. Customer initiates a USSD request (#144*82#) on the operator’s side to generate an OTP
5. Customer follows the USSD instructions to complete the payment
6. Merchant sends a status request and set extra data -> OTP
7. Merchant gets a callback (or requests the status) with the final state of the operation

Example of a status request:

  {
  "merchant_id":"cdeffe6210c7fdc7402c13b215455bd8ddec02da0c",
  "order_id":"55584tty848rt",
  "customer_id":"2250768000000",
  "extra":{
    "otp":"7374"
  },
  "signature":"d7d6d76bd12bfd24dytu6u6c803be455d81cfe792f00cd8892c26ce7cf5a05beebb9c80843e"
  }

C2B for Provider_ids that do not require OTP or Redirect: 9196, 9198, 2430, 2303, 2305, 2333, 2335, 699, 804, 805:

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST C2B request) and set extra data depending on the provider_id:

3. Customer gets push from operator and confirm the operation
4. Merchant gets a callback (or requests the status) with the final state of the operation

C2B for Provider_ids that require a OTP: 9197

1. Customer create OTP code on ussd_code #144*82#
2. Customer initiates the payment on Merchant side
3. Merchant sends request to the platform (POST C2B request) and set extra data depending on the provider_id:

Example Request:

  {
  "merchant_id": "your merchant id",
  "customer_id": "2250705145655",
  "order_id": "test_161225_01_1",
  "amount": "1100",
  "currency": "XOF",
  "country": "BF",
  "callback_url": "your callback url",
  "provider_id": "9197",
  "signature": "1c594d338bc3f413bd61cb97d697e98ad5772071da533",
  "extra": {
    "otp": "5647"
  },
  }

4. Operator debits funds from customer mobile number
5. Merchant gets a callback (or requests the status) with the final state of the operation

C2B for Provider_ids redirecting to Provider payment pages: 9199, 2431, 2336

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST C2B request) and set extra data depending on the provider_id:

3. Merchant gets the status of the operation and extra data customer_redirect
   Example of a user redirect link:

"extra": 
{
"customer_redirect": "https://checkout.provider.com/202511131111MqKRft39377/pay"
}, 

4. Merchant redirect Customer to provider page
5. Customer confirms the payment on the provider page
6. Merchant gets a callback (or requests the status) with the final state of the operation

C2B for Provider_ids that require redirecting and OTP: 2304, 2306, 2334

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST C2B request) and set extra data depending on the provider_id:

3. Merchant gets the status of the operation and extra data customer_redirect
   Example of a user redirect link:

"extra": 
{
"customer_redirect": "https://checkout.provider.com/202511131111MqKRft39377/pay"
}, 

4. Merchant redirect Customer to provider page
5. Customer gets SMS\WhatApp message with OTP
6. Customer confirm the operation by OTP on the page
7. Customer gets push from operator and confirm the operation
8. Merchant gets a callback (or requests the status) with the final state of the operation

B2C flow is the same for everyone, please specify the required extra parameters

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST B2C request) and set extra data depending on the provider_id:

3. Customer receives funds to their mobile number
4. Merchant gets a callback (or requests the status) with the final state of the operation

Ivory Coast limits

Note: for 9196, 9197, 9198, 9199 deposits and withdrawals are made in multiples of 5.

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.

Malawi limits

0000000000 - This is the format of the phone number you have to send in the payment requests.

C2B for Provider_ids redirecting to Provider payment pages: 9015

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST C2B request) and set extra data depending on the provider_id:

3. Merchant gets the status of the operation and extra data customer_redirect
   Example of a user redirect link:

"extra": 
{
"customer_redirect": "https://checkout.provider.com/202511131111MqKRft39377/pay"
}, 

4. Merchant redirect Customer to provider page
5. Customer confirms the payment on the provider page
6. Merchant gets a callback (or requests the status) with the final state of the operation

B2C flow is the same for everyone, please specify the required extra parameters

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST B2C request) and set extra data depending on the provider_id:

3. Customer receives funds to their mobile number
4. Merchant gets a callback (or requests the status) with the final state of the operation

Marocco limits

Bank Transfer / Pay Attitude / OPay / Palmpay / Card payment C2B (deposit) scenario:

• Customer initiates the payment via Bank Transfer/Pay Attitude/OPay/Palmpay/Card method on the Merchant’s side.
• Merchant requests Customer’s Name, Email and Amount. This step is optional, as this data may be stored in the merchant's system
• Merchant initialises the payment, redirecting the Customer to the Payment Page. Redirect url and other details are described on the Payment Page section.
• Customer is requested to specify required data for the payment: Name, Email, Amount.
• Customer receives the Merchant’s Bank Account details / In case of payment by card, enter its data
• Customer opens his Bank Application and makes the transfer to the corresponding account (not relevant for card payments)
• Merchant receives the notification, that initiated payment is processed successfully and shows to the Customer a success message.

OPay payment B2C (withdrawal) scenario:

• Customer initiates the payment on Merchant side
• Merchant sends request to the platform (POST payment_b2c) and set extra data of his Pay Attitude / OPay / Palmpay bank account
  • customer_name
  • customer_email
• Customer receives funds to his bank account in Pay Attitude / OPay / Palmpay
• Merchant gets a callback (or requests the status) with the final state of the operation

Bank Transfer B2C (withdrawal) scenario:

• Customer initiates the payment via Bank Transfer method on the Merchant’s side.
• Merchant receives the list of available banks and its codes via get banks API Method
• Customer selects on the Merchant’s side the Bank and specifies his recipient’s bank account.
• Merchant sends a B2C request to the system. Format is described on the API Methods page. In the "extra" merchant specifies the bank code (parameter bank_code) and customer name (parameter customer_name). In the "customer_id" merchant specifies the bank account.

B2C Bank Transfer request example:

{
  "merchant_id":"e0fecd91fcb24f348048193b3fb34875ba3722b4",
  "order_id":"0900000001",
  "customer_id":"16280954971628095497",
  "amount":"100.00",
  "currency":"NGN",
  "provider_id":5026,
  "extra":{
    "customer_name":"Name Lastname",
    "customer_email": "Name@domen.com",
    "bank_code":"000001"
  },
  "signature":"d7d6d76b0e22c6f9d369fa6c24f107053d12bfd24d3b154f2deb6676bf179c123134e1f20879c803be455d81cfe792f00cd8892c26ce7cf5a05beebb9c80843e"
}

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_name": "Test Ltd / Test Limited",
    "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

For 9230

C2B:

• Customer initiates the payment on Merchant side where customer_id must be a Opay account number and set extra data
  • customer_name
  • customer_email
• Merchant sends request to the platform (POST payment_c2b)
• Merchant sends status request (POST status) and gets extra parameter customer_redirect
• Merchant redirects the customer to the link from the customer_redirect parameter
• On the provider's page, the customer is presented with temporary bank account details
• Customer makes a bank transfer to the provided details
• Merchant gets a callback with the final state of the operation once the funds are received

B2C:

• Customer initiates the payment on Merchant side where customer_id must be a Opay account number and set extra data
  • customer_name
  • customer_email
  • customer_phone
• Merchant sends request to the platform (POST payment_b2c)
• Customer receives funds to his OPay wallet.
• Merchant gets a callback with the final state of the operation.

For 9231:

C2B

1. Customer initiates the payment on Merchant side and set extra data:

• customer_email
• customer_name

2. Merchant sends request to the platform (POST payment_c2b)
3. Merchant sends status request (POST status) and gets extra data from status response:

• account_number
• bank_code
• bank_name

4. Merchant displays this bank details to the Customer
5. Customer makes a manual bank transfer to the provided account
6. Merchant gets a callback (or requests the status) with the final state of the operation

B2C

1. Customer initiates the withdrawal on Merchant side
2. Merchant receives the list of available banks and its codes via get banks API Method
3. Customer selects on the Merchant’s side the Bank and specifies their recipient’s bank account
4. Merchant sends request to the platform (POST payment_b2c) where customer_id is customer bank account number and sets extra data

• bank_code got from get banks API Method
• customer_name
• customer_email
• customer_phone

5. Platform transfers funds to the Customer's bank account
6. Merchant gets a callback from the platform with the final state of the operation

For 706, 9122:

C2B

1. Customer initiates the payment on Merchant side and set extra data customer_email
2. Merchant sends request to the platform (POST payment_c2b)
3. Merchant sends status request (POST status) and gets extra data customer_redirect
4. Merchant redirects the customer to the page from the customer_redirect url
5. Customer makes a payment on the page
6. Merchant gets a callback (or requests the status) with the final state of the operation

B2C

1. Customer initiates the withdrawal on Merchant side.
2. Merchant receives the list of available banks and its codes via get banks API Method
3. Customer selects on the Merchant’s side the Bank and specifies his recipient’s bank account
4. Merchant sends request to the platform (POST payment_b2c) where customer_id is customer bank account number and sets extra data

• bank_code got from get banks API Method response
• customer_email

5. Platform transfers funds to the Customer's bank account
6. Merchant gets a callback from the platform with the final state of the operation

For 707, 9123:

C2B

1. Customer initiates the payment on Merchant side and set extra data a. customer_name b. customer_email
2. Merchant sends request to the platform (POST payment_c2b)
3. Merchant sends status request (POST status)
4. Merchant gets a redirect_url in the status response
5. Merchant redirects Customer to provider payment page
6. Customer makes a payment on the page
7. Merchant gets a callback with the final state of the operation

For 9143:

C2B

1. Customer initiates the payment on Merchant side and set extra data customer_email and customer_name
2. Merchant sends request to the platform (POST payment_c2b)
3. Platform returns a extra object in the API response with account_number, bank_name, in status response
4. Merchant displays this bank details to the Customer
5. Merchant gets a callback from the platform with the final state of the operation

B2C

1. Customer initiates the withdrawal on Merchant side
2. Merchant sends request to the platform (POST payment_b2c) and sets extra data "bank_code"
3. Merchant gets a callback from the platform with the final state of the operation

Nigeria limits

22898200000 - This is the format of the phone number you have to send in the payment requests.

For 873:

C2B

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST payment_c2b) and set extra data:

• customer_name
• customer_email
• return_url
• customer_id
• ip_adress
• customer_state
• customer_zip
• customer_city

4. Merchant gets customer_redirect
5. Merchant redirects a customer to provider payment page
6. Customer makes a payment on the page
7. Merchant gets a сallback with the final state of the operation

B2C

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST payment_b2c) and set extra data:

• customer_name
• customer_email
• customer_doc_number
• return_url

3. Customer receives funds to their mobile number
4. Merchant gets a callback with the final state of the operation

For 424, 425, 426

C2B

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST payment_c2b) with parameters extra->customer_name and extra->return_url
3. Merchant gets the status of the operation (POST status) and gets extra parameters from the response extra->customer_redirect
4. Merchant redirects the customer to the page from the customer_redirect url
5. Customer submit form on provider payment page
6. Customer gets push from operator and confirm the operation
7. Merchant gets a callback (or requests the status) with the final state of the operation

B2C

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST payment_b2c)
3. Customer receives funds to his mobile number
4. Merchant gets a callback (or requests the status) with the final state of the operation

Egypt limits

221000000000 - This is the format of the phone number you have to send in the payment requests.

For 9203

C2B:

1. Customer initiates the payment on Merchant side (Customer have to get OTP: #144#391#)
2. Merchant sends request to the platform (POST payment_c2b) and set extra data
   • otp (with OTP code provided by customer on previous step).
3. Merchant sends status request (POST status) and gets extra data
   • customer_redirect
4. Merchant redirects the customer to the page from the customer_redirect url
5. Customer makes a payment on the page
6. Merchant gets a callback (or requests the status) with the final state of the operation

C2B for Provider_ids that do not require OTP or Redirect: 2398, 2399, 2400, 2354, 2356, 9204

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST C2B request) and set extra data depending on the provider_id:

3. Customer gets push from operator and confirm the operation
4. Merchant gets a callback (or requests the status) with the final state of the operation

C2B for Provider_ids redirecting to Provider payment pages: 2401, 2335, 9205

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST C2B request) and set extra data depending on the provider_id:

3. Merchant gets the status of the operation and extra data customer_redirect
   Example of a user redirect link:

"extra": 
{
"customer_redirect": "https://checkout.provider.com/202511131111MqKRft39377/pay"
}, 

4. Merchant redirect Customer to provider page
5. Customer confirms the payment on the provider page
6. Merchant gets a callback (or requests the status) with the final state of the operation

B2C flow is the same for everyone, please specify the required extra parameters

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST B2C request) and set extra data depending on the provider_id:

3. Customer receives funds to their mobile number
4. Merchant gets a callback (or requests the status) with the final state of the operation

Senegal limits

Note: for 9203, 9204, 9205 deposits and withdrawals are made in multiples of 5.

27000000000 - This is the format of the phone number you have to send in the payment requests.

South Africa limits

232000000000 - This is the format of the phone number you have to send in the payment requests.

Sierra Leone limits

250000000000 - 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 for Provider_ids that require redirecting and OTP: 2351, 2352

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST C2B request) and set extra data depending on the provider_id:

3. Merchant gets the status of the operation and extra data customer_redirect
   Example of a user redirect link:

"extra": 
{
"customer_redirect": "https://checkout.provider.com/202511131111MqKRft39377/pay"
}, 

4. Merchant redirect Customer to provider page
5. Customer gets SMS\WhatApp message with OTP
6. Customer confirm the operation by OTP on the page
7. Customer gets push from operator and confirm the operation
8. Merchant gets a callback (or requests the status) with the final state of the operation

B2C flow is the same for everyone, please specify the required extra parameters

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST B2C request) and set extra data depending on the provider_id:

3. Customer receives funds to their mobile number
4. Merchant gets a callback (or requests the status) with the final state of the operation

Rwanda limits

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.

C2B for Provider_ids that do not require OTP or Redirect: 2337, 2338, 2339, 2340, 2402, 2403, 2404, 2506, 2507, 2508, 2509

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST C2B request) and set extra data depending on the provider_id:

3. Customer gets push from operator and confirm the operation
4. Merchant gets a callback (or requests the status) with the final state of the operation

B2C flow is the same for everyone, please specify the required extra parameters

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST B2C request) and set extra data depending on the provider_id:

3. Customer receives funds to their mobile number
4. Merchant gets a callback (or requests the status) with the final state of the operation

For 2405 (only B2C):

You should set account number as customer_id and send customer full name and bank BIC("Bank Identifier Code", ask your bank) in the payment request. Parameters extra->customer_name and extra->bic. Please see the example in the API Methods section.

For B2C payments providers 2310, 2309, 2308, 2307:

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

Tanzania limits

228000000000 - This is the format of the phone number you have to send in the payment requests.

C2B for Provider_ids that do not require OTP or Redirect: 2357, 2358, 2359

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST C2B request) and set extra data depending on the provider_id:

3. Customer gets push from operator and confirm the operation
4. Merchant gets a callback (or requests the status) with the final state of the operation

B2C flow is the same for everyone, please specify the required extra parameters

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST B2C request) and set extra data depending on the provider_id:

3. Customer receives funds to their mobile number
4. Merchant gets a callback (or requests the status) with the final state of the operation

Togo limits

256709000000 - This is the format of the phone number you have to send in the payment requests.

C2B for Provider_ids that do not require OTP or Redirect: 808, 809

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST C2B request) and set extra data depending on the provider_id:

3. Customer gets push from operator and confirm the operation
4. Merchant gets a callback (or requests the status) with the final state of the operation

C2B for Provider_ids redirecting to Provider payment pages: 2105, 2106

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST C2B request) and set extra data depending on the provider_id:

3. Merchant gets the status of the operation and extra data customer_redirect
   Example of a user redirect link:

"extra": 
{
"customer_redirect": "https://checkout.provider.com/202511131111MqKRft39377/pay"
}, 

4. Merchant redirect Customer to provider page
5. Customer confirms the payment on the provider page
6. Merchant gets a callback (or requests the status) with the final state of the operation

B2C flow is the same for everyone, please specify the required extra parameters

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST B2C request) and set extra data depending on the provider_id:

3. Customer receives funds to their mobile number
4. Merchant gets a callback (or requests the status) with the final state of the operation

Uganda limits

260000000000 - This is the format of the phone number you have to send in the payment requests.

C2B for Provider_ids that do not require OTP or Redirect: 2370, 2371, 2372, 2119, 2118, 2332, 2504, 2505

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST C2B request) and set extra data depending on the provider_id:

3. Customer gets push from operator and confirm the operation
4. Merchant gets a callback (or requests the status) with the final state of the operation

B2C flow is the same for everyone, please specify the required extra parameters

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST B2C request) and set extra data depending on the provider_id:

3. Customer receives funds to their mobile number
4. Merchant gets a callback (or requests the status) with the final state of the operation

Zambia limits

254000000000 - This is the format of the phone number you have to send in the payment requests.

C2B for Provider_ids that do not require OTP or Redirect: 2390, 2391, 2392, 2393, 700, 701, 798, 9125

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST C2B request) and set extra data depending on the provider_id:

3. Customer gets push from operator and confirm the operation
4. Merchant gets a callback (or requests the status) with the final state of the operation

B2C flow is the same for everyone, please specify the required extra parameters

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST B2C request) and set extra data depending on the provider_id:

3. Customer receives funds to their mobile number
4. Merchant gets a callback (or requests the status) with the final state of the operation

Kenya limits

233000000000 - This is the format of the phone number you have to send in the payment requests.

C2B for Provider_ids that do not require OTP or Redirect: 704, 9127, 980, 981, 982, 9252, 9253, 9255, 2502, 2503

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST C2B request) and set extra data depending on the provider_id:

3. Customer gets push from operator and confirm the operation
4. Merchant gets a callback (or requests the status) with the final state of the operation

B2C flow is the same for everyone, please specify the required extra parameters

1. Customer initiates the payment on Merchant side
2. Merchant sends request to the platform (POST B2C request) and set extra data depending on the provider_id:

3. Customer receives funds to their mobile number
4. Merchant gets a callback (or requests the status) with the final state of the operation

For 9254:

B2C:

1. Customer initiates the payment on Merchant’s side
2. Merchant sends request to the platform (POST banks)
3. Merchant gets the list of available banks and its codes
4. Merchant sends request to the platform (POST payment_b2c) and set extra data:
   • customer_email
   • customer_name
   • bank_code
5. Customer receives funds to their bank account
6. Merchant gets a callback (or requests the status) with the final state of the operation

Example request:

  {
  "merchant_id": "cdeffe87da339a801a07cee670b40ff303b92065",
  "customer_id": "2030050920719", // Bank account number
  "order_id": "test_b2c_9254_gha_ghs_200126_01_1",
  "amount": "1",
  "currency": "GHS",
  "country": "GH",
  "provider_id": "9254",
  "callback_url": " ", // Your callback URL
  "extra": {
    "customer_name": "John Doe",
    "bank_code": "FBL"
  }
  }

Ghana limits