Register

Credit Wallet API

Payout funds directly to customized wallets in your books.

How does it work?

The Credit Wallet API allows clients pay funds only into customized wallets they generated. This API works as an intrabank transfer service, thus 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 backend by the bank, and mapped to the clients access key.

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

  3. The client initiates 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 transfer request.

  6. Client receives a notification of transaction status.

Go Live

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. Client initiates request for payout to destinationAccountNumber, specifying amount and custom transactionReference and narration (set useCustomNarration as true).

  2. 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 using its 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 status are PENDING, SUCCESSFUL or FAILED.

Authentication Model

Request Model

  1. The bank makes this request to the client to authorize this transaction request.

  2. Authorization callbackURL is profiled by the bank, and mapped to the clients access key.

  3. Bank makes authentication request to client by passing the securityInfo and custom transactionReference specified in the payout request.

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

  5. This endpoint should not take any header 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.