Payment Providers in Uganda

Customer approval comes before a paid order

MTN Uganda's Open API overview distinguishes RequestToPay collections from Transfer disbursements. The developer documentation explains the customer-facing sequence: the merchant sends a request, the customer approves or rejects it on their own device, and the transaction reaches a final result. An initial acceptance of the request does not establish that the customer has paid. MTN Uganda Open API overview, MTN Request to Pay use case

For an online shop, this creates a practical test. Keep the order waiting while authorization is incomplete. Show the customer what action remains, and ask the PSP how your system obtains the final result if its notification is missing. Dispatch decisions should use verified payment evidence linked to the order. A customer returning to the checkout screen is not sufficient evidence by itself.

Set up the business account for the intended job

MTN's Uganda collections description places receipts in a collection account before bank liquidation and describes a merchant-initiated liquidation process. Its Uganda disbursement description separately specifies an allocated account funded by purchasing e-money. The latter describes bulk payments to registered MTN Mobile Money recipients. These are published product procedures on a portal labelled as a test environment; confirm the current production arrangement before relying on them. Uganda collections procedures, Uganda disbursement procedures

Ask which account your proposed PSP will open or configure, which operations it permits and who controls outgoing instructions. Establish whether collected value can fund payouts, whether another balance needs funding, and how any internal movement appears in statements. Receiving customer money does not establish that a particular supplier payment or refund has been enabled.

Airtel Uganda's formal-merchant guidance illustrates another onboarding boundary: it lists business registration, trading and tax documents among the requirements. Use the provider's current checklist for your company structure; an existing personal wallet does not answer the business-onboarding question. Airtel Money Pay merchant FAQs

Test one Kampala order through its exceptions

Consider a hypothetical Kampala homewares shop selling an order for 90,000 UGX. This is an operating exercise, not a customer case or a quoted tariff.

First, the customer receives a payment request but the shop has no final result. Staff should investigate that request before creating another charge or assuming that money needs refunding. Ask the PSP to show how the original request, customer response and account entry can be matched.

Next, suppose the payment is confirmed, but a 30,000 UGX item becomes unavailable and the shop agrees to return that amount. The goods retained total 60,000 UGX, before any fees considered separately. Qualify the refund process: whether partial refunds are supported, who authorizes them, which balance is debited and what links the return to the original payment. Do not assume an ordinary outgoing transfer has the same controls as a refund.

Finally, suppose the shop sends collected funds to its bank, but the transfer has an unclear outcome. Airtel Uganda's merchant FAQ tells merchants to provide the transaction ID, amount and date when self-liquidation fails or the bank credit is missing. This gives the comparison a concrete investigation test. Airtel's self-liquidation guidance, question 21

Before repeating the transfer, establish whether it completed, remains unresolved or has failed. If funds must return to the merchant balance, request the return reference and evidence that the amount is usable again. A failure label alone should not be treated as proof of restored funds. The shop needs separate evidence for the customer's purchase, the agreed refund and its own bank transfer.

Compare the evidence each provider will supply

Request charges, limits and settlement terms for each operation. MTN Uganda's payment-system rules tie participant transactions to contractual scope; they do not make every published capability available under every agreement. Identify the exact wallet or bank destination and payment purpose. Do not infer cross-network support or overseas-merchant eligibility from a familiar brand. MTN Uganda payment-system rules

Turn the requirements into a PSP shortlist

Share your company jurisdiction, business activity, customer locations, expected UGX volumes, usual and largest payment, refund needs and settlement account with PayStar Discovery. The team can help structure a focused shortlist and the questions to qualify each option. You choose and contract directly with the PSP; the PSP approves the business, processes payments and performs settlement under that agreement.

Want information about these Uganda payment options for free? Contact Anastasia through PayStar Discovery. Free information does not include integration, processing or approval, or make the whole Discovery service free. Availability and eligibility are confirmed separately.

PayStar’s role

PayStar provides information and technical services. PayStar is not a bank or PSP, does not arrange payment acceptance or settlement in its own name, does not receive or hold customer or merchant funds, and does not settle those funds. Payment services are provided by the selected provider under a direct agreement with the merchant. PayStar’s API, routing and monitoring operate within the agreed technical role.