Register

Credit Wallet API

Payout funds directly to customized wallets in your books.

Test Destination Account - 0280100171

How does it work?

The Credit Wallet API allows clients to pay funds only into the customized wallets they generated. This API works as an intrabank transfer service; destination accounts can only belong to Wema Bank.

One use case for this API is the payment of winnings by Betting and Lottery agencies to their customers.

  1. The client is profiled with a payout account (sourceAccountNumber). This activity is done in the backend by the bank and mapped to the client's access key.

  2. The client makes an enquiry to ensure the destination wallet is mapped to its channel and also to confirm the beneficiary's details.

  3. The client initiates a payout request and gets a PENDING status.

  4. The callback is made to the client to authorize the transaction - debit to payout account and credit to destination wallet.

  5. The bank proceeds to fulfill the transfer request.

  6. Client receives a notification of transaction status.

Note: You will need to profile your Authentication Callback URL for this endpoint to avoid getting the authentication failed error while testing.

Step 1: Name Enquiry - Destination Wallet

Request URL

POST - {baseURL}/credit-wallet/api/Shared/AccountNameEnquiry/Wallet/{accountNumber}

Try it out !

  1. Client is required to pass a valid access value in the header of their request. This value would be provided by the bank.

  2. Client validates the destination account number using the request URL.

  3. A successful call to this endpoint would return the accountName of the beneficiary.

Step 2: Client Fund Wallet

Request URL

POST - {baseURL}/credit-wallet/api/IntraBankTransfer/FundWallet

Try it out !

  1. The client initiates a request for payout to destinationAccountNumber, specifying amount and custom transactionReference and narration (set useCustomNarration as true).

  2. The client is expected to pass a securityInfo. This should be an encrypted value whose signature is known only by the client. The client is the only one with the secret to decrypt its value. This value serves as the mandate for authorization of payout.

  3. The bank makes an authentication request to the client securityInfo to receive confirmation of the transaction. The client is expected to validate this authentication request for the transaction to be executed. Authentication request and response models can be seen below.

  4. The client gets a PENDING transaction status while the transaction is being executed.

  5. Client receives final transaction status via a callback URL.

Note: Transaction statuses are PENDING, SUCCESSFUL or FAILED.

Note: Your security information is unique to you and can be an alphanumeric string of any length. It helps secure your transactions and authenticate every transaction initiated by you, preventing unauthorized access by third parties.

Authentication Model

Request Model

  1. The bank asks the client to authorize this transaction.

  2. The authorization callback URL is profiled by the bank and mapped to the client's access key.

  3. The bank makes an authentication request to the client by passing the securityInfo and the custom transactionReference specifications in the payout request.

  4. Clients should ensure that the encryption used for the securityInfo parameter is highly secure, dynamic, and unique to each transaction request.

  5. This endpoint should not take any headers as it is generic to all clients using this service.

Expected Response Model

  1. Client responds with the transactionReference and authorized status of the authentication request.

  2. Authentication status

    • authorized = true; if securityInfo is valid

    • authorized = false; if securityInfo could not be validated.

The Callback Model

Clients are to build their callback following the specification below. Your callback URL would be profiled to your assigned channelId.