Before you integrate

Are you ready to integrate?

Every DiGii API scope assumes you have a matching product on your side. A payments scope needs a checkout. An SMS scope needs credits and a sender ID. A schools scope needs actual schools using your platform. Use this page to self-check what your team must have built before we can enable each rail for you.

How access works

Three checkpoints, then you are live

Step 01

You build your side

Wallet, product, checkout, sender ID, biller UX. Whatever the rail below asks for.

Step 02

We enable the scope

Our team ticks the scopes on your partner record after a short review. No code change on your side.

Step 03

You call the API

Endpoints start responding for those scopes only. Everything else still returns 403 until you are ready for it.

Rails

What each scope needs from you

Pick the rails you actually want. You do not need to be ready for all of them, just the ones you are integrating. Missing prerequisites are the single biggest reason partner conversations stall, so it pays to be honest with yourself here.

Rail 01

Accept payments and refunds

Collect mobile money and bank payments from your customers into your DiGii wallet, refund them, and read your balance and transaction history.

Scopes
payments.collectpayments.refundbalance.readtransactions.read
What you must have built
  • A product or checkout where your users are already paying you (or willing to).
  • A server that can call our REST API with an HMAC signature on every request.
  • A publicly reachable HTTPS webhook endpoint that returns 2xx within 10 seconds.
  • Storage for our payment references so you can reconcile against your own orders.
Rail 02

Send payouts to users, staff, or vendors

Pay any DiGii user, MoMo number (MTN or Airtel), or Ugandan bank account from your partner wallet. Suitable for payroll, marketplace disbursements, refunds outside the original rail, or supplier settlements.

Scopes
payouts.send
What you must have built
  • A funded partner wallet with us. You cannot send what you have not pre-loaded.
  • Recipient-collection UX on your side (phone, name, and account details where relevant).
  • The same server + HMAC + webhook setup as Rail 01.
  • A clear internal approval flow. Payouts are irreversible once the provider confirms.
Rail 03

Bills, airtime, data, and tax

Let your users pay UEDCL, NWSC, URA, NSSF, and buy MTN or Airtel airtime and data bundles directly from inside your product. Fees are transparent and configured per biller on our side.

Scopes
billers.readbillers.validatebills.payairtime.buydata.buytax.pay
What you must have built
  • You are already offering these services to your users (school portal, telco reseller, tax filing tool, employer platform, etc.).
  • A funded partner wallet or a per-customer wallet model that we can debit from.
  • UX to collect the biller-specific details (meter number, NIN, TIN, phone, bundle size).
  • Legal clearance to be a bill-payment agent, if your regulator requires one.

Note. The partner-pool path is provisioned per partner and requires a call with our team before we flip it on. School-wallet variants (like QM) are already live.

Rail 04

Transactional SMS

Send OTPs, receipts, alerts, and reminders to Ugandan mobile numbers on your own sender ID. Read your SMS credit balance and per-minute limits. Buy top-ups from your wallet.

Scopes
sms.sendsms.balancesms.adjust
What you must have built
  • A registered sender ID (alphanumeric, 3 to 11 characters) approved with Africa's Talking or a Ugandan telco. We can register on your behalf, but the paperwork sits with you.
  • Pre-loaded SMS credits on your partner account. We do not extend SMS on credit.
  • A message-template inventory that respects Uganda spam rules (transactional only, no marketing without opt-in).
  • Rate-limit awareness. We cap per-partner throughput to protect telco relationships.
Rail 05

Partner-of-record for schools

Register the schools you already work with onto DiGii, receive a per-school API key, and then call our school-wallet, fees, and SMS-credit endpoints on their behalf. This is how QM Finance integrates today.

Scopes
schools.provision
What you must have built
  • You are a school management platform (fees, attendance, results, communication) with a real customer base.
  • A bursar or head-teacher onboarding flow inside your own product so schools consent to the DiGii link.
  • Ability to sync school metadata (name, location, contact) to us and keep it fresh.
  • A commercial agreement with us. This rail is not self-serve.

Note. Bespoke. Book a call before you build anything against these endpoints.

Next step

Come to us when the checkboxes are green

If everything on your target rail is in place, sign up for sandbox keys and email us. If you are still building, the fastest path is to keep building. We onboard faster with partners who already have their side working.