Getting Started
Payouts, also sometimes called Disbursements, are outbound fund transfers from your merchant account to supported mobile money channels or bank accounts.
The API supports funds payout/disbursement via a number of methods e.g. Mobile Money, Bank Transfer and many other methods will be supported along the way. The API enables you to send payments via a simple, secure process that requires only the bank/phone information of the recipients. This section will describe the process flows for every available payment method. However, every payout will follow the steps described below, in the order of occurrence.
Prerequisites
Before payouts can start,
The merchant needs to have an approved merchant account on the live platform. This is only achieved after the go-live requirements are met (being on sandbox and clearing the UAT tests).
The payment channels/options required by the merchant need to be configured on the designated merchant account. The support teams will be available to assist with this.
The merchant is expected to have configured the payout notification URL as well as the payout verification URL on the merchant account profile. The notification URL will receive webhook/callback requests when the payout is successful/failed. The verification URL on the other hand allows our platform to do a "handshake" with the merchant's platform to verify the authenticity of the request as described in step 2 below.
The merchant needs to avail the funds for payout. This can be achieved by requesting transfer of funds collected or deposited prior as described in the Availing Payout Funds section.
Step 1: Payout API Request
The merchant will form the payout request payload (based on the selected payment method) and send it to the API for processing. If there are any errors with the parameters, these would be communicated immediately in the response otherwise the API would respond with an acknowledgement. Take the following the mobile money request and a sample acknowledgement.
However, should this process fail in any way even after the acknowledgement e.g. if the merchant is making too many requests to the same phone number, the following failure callback will be sent to the payout callback URL.
Step 2: Payout Verification Request
For every payout request sent to the API, a request will be made to the merchant platform via the configured payout verification URL. This is one of the platform's security measures and the purpose of the request is to ensure the merchant platform (database) is "aware" of the transaction. The merchant simply needs to ensure that the configured URL is operational. When a request is sent to it, query your records to confirm that the reference is among your records and in the status/state to be processed. If this is true, respond with a simple HTTP code 200 strictly, which to the API will be translated as permission to process the transaction. Any other response will be regarded "denial" and the API will not move ahead with the processing.
A sample verification request could be like the following. The GET request will have a single query parameter reference
that holds the value of the merchant reference sent in the payout request prior. The example below assumes that the merchant_reference
in the request was MCTREFDWWJTDYTEAHEQP.
If the response to that request is HTTP code 200, the API will proceed to queue the transaction for processing and after processing, a notification will be sent to the payout notification URL to communicate the final status of the transaction as described in step 3
Step 3: Final Status Notification
This is the notification that communicates the very final status of the transaction, and this would mark the close of the transaction process. Sample completed and failed transaction callbacks/notifications shared below.
Cross-currency Transfers
If the request currency is different e.g. USD from the payment provider currency (transaction currency) e.g. UGX, the API will convert the USD to UGX and your UGX balance will be debited with the converted amount. More details here.
Last updated