Skip to main content

Integrating the Kuda Business API

A practical integration overview for developers building with the Kuda Business API.

Written by Nosa O

The Kuda Business API lets approved businesses connect their own systems to Kuda Business for banking operations such as collections, transfers, bill payments, account information, and transaction status checks.

This guide gives you the recommended integration path before you start writing code.

What you can build

You can use the Kuda Business API to:

  • retrieve supported banks

  • validate account names before transfer

  • make single transfers

  • make bulk payments

  • create dynamic virtual accounts for collections

  • pay bills

  • retrieve balances, statements, and transaction history

  • receive transaction and bill notifications through webhooks

  • check the status of pending or uncertain transactions

Recommended integration order

Start with low-risk, read-only or validation calls before adding money movement.

  1. Generate your API key from the Kuda Business dashboard.

  2. Generate an access token.

  3. Configure the UAT environment first.

  4. Make a safe starter request with BANK_LIST.

  5. Add NAME_ENQUIRY to validate account details.

  6. Add the product-specific flow you need, such as transfers, bills, or dynamic accounts.

  7. Persist every requestRef you generate.

  8. Add status-query handling before retrying any uncertain transaction.

  9. Configure webhooks if your product needs asynchronous updates.

  10. Move to production only after UAT testing is complete.

Integration architecture

Keep your Kuda integration on your server. Do not call the Kuda Business API directly from browser or mobile frontend code.

Your app should look like this:

User interface -> Your backend -> Kuda Business API
                         |
                    Your database
              request refs, status, audit logs

Your backend should handle:

  • access token storage or token generation

  • Kuda request construction

  • request reference generation

  • response parsing

  • transaction status checks

  • webhook ingestion

  • retries and support logs

Safe starter calls

Use these calls first:

Operation

serviceType

Why it is useful

Bank list

BANK_LIST

Confirms base URL, token, and request envelope.

Name enquiry

NAME_ENQUIRY

Confirms account validation without moving money.

Balance

ADMIN_RETRIEVE_MAIN_ACCOUNT_BALANCE

Confirms account information access.

Money movement safety

For transfers, bulk payments, bill purchases, and dynamic account creation:

  • validate inputs before execution

  • show the user a preview before charging or transferring funds

  • generate a unique requestRef

  • store the request and response

  • require explicit confirmation in your product

  • check transaction status before retrying an ambiguous request

Do not build money movement as a one-click frontend-only action.

What to read next

Read these guides in order:

  1. Kuda Business API Request Format and Environments

  2. How to Authenticate Kuda Business API Requests

  3. Making a Transfer with the Kuda Business API

  4. Checking Transaction Status and Recovering Pending Payments

  5. Handling Kuda Business API Webhooks

If you are building collections, read Getting Paid with Dynamic Virtual Accounts before webhooks.

Common mistakes to avoid

  • Exposing API keys or access tokens in frontend code.

  • Using production before testing in UAT.

  • Reusing UAT bank codes in production.

  • Hardcoding bill item identifiers without refreshing the catalog.

  • Losing the original requestRef after submitting a transaction.

  • Retrying a transfer or bill payment before checking its final status.

  • Treating every successful HTTP response as final transaction success.

Need help?

If you need access to the API or need help validating your integration, contact Kuda Business support through the approved support channel for your business.

Did this answer your question?