Reaching Kawu's wallet, card limits and withdrawal events

Every Kawu card carries three things worth reading: a server-side balance, a withdrawal ceiling the parent sets, and a stream of withdrawal events that a parent sees almost as they happen. That event stream is the interesting part. When a student taps the card at a school vendor, the platform fires a notification to the funding parent — opt-out, but on by default — and the same moment is what most integrators actually want to capture. Per its Play Store and company materials, Kawu has run since 2021 and describes serving tens of thousands of students across dozens of Ugandan schools; treat those counts as the vendor's own figures rather than independently verified.

For a third party — a school finance office, a sponsor program, a savings or ledger product — the goal is to mirror those card movements into your own system as they land, and to read balances and limits on demand. The route below leads with that real-time event capture, with a transaction read behind it so nothing is lost when a parent has muted alerts.

What Kawu stores per card and wallet

Getting to the data: the routes that fit Kawu

1. Authorized interface integration of the app's traffic

We observe how the Kawu client authenticates and which calls return the balance, the transaction list, and the card-control object, then rebuild those calls as a clean client. Reachable: balances, withdrawal history, limits, top-up confirmations. Effort is moderate and front-loaded into the mapping phase. Durability is good for a stable consumer app, and we re-check the auth and payload shape if the app ships a breaking update. Access to a live or consenting account is arranged with you at the start of the build.

2. User-consented account access

A funding parent (or the student account holder) consents to let their card data be read on their behalf. This is the strongest legal footing for a read in Uganda and the natural fit when the integration serves the cardholder — a sponsor dashboard, a savings nudge, a school finance view. We capture and store the consent record as part of the work.

3. Native confirmation channel as a fallback

Where the cleanest path to a movement is the notification or SMS the platform already sends, we treat that as a signal source and reconcile it against the transaction read so the picture stays whole.

For most briefs, the first route carries the integration and the second supplies the authorization underneath it. We would put the live event capture on the interface client and lean on consented access to make that read defensible — that pairing is what we would actually build first.

What lands in your repo

Code that runs is the headline. A typical Kawu drop:

• A runnable client in Python or Node for the balance, transaction, and card-control surfaces, with auth handled.
• A webhook receiver that normalizes Kawu's withdrawal and low-balance events into your own event shape, ready to point at your queue or database.
• A small test harness running against recorded fixtures, so a change in Kawu's payloads shows up as a failed assertion when we re-run it.
• A batch backfill script for pulling historical transactions per card on first sync.
• An OpenAPI description of the rebuilt surfaces, and an auth-flow report covering the login and token chain.
• Interface documentation and short data-retention guidance for the card data you hold.

The first three are where the value sits for an ingestion team; the spec and the auth report come along so the work is auditable later.

A withdrawal-event handler, sketched

Illustrative only — field names get confirmed during the build against the live payloads, not assumed. The shape below is the normalized event we would emit from a Kawu withdrawal, plus a balance read:

// Normalize an inbound Kawu card event into your ledger shape
function onCardEvent(raw) {
  const e = {
    cardId:    raw.card_ref,
    studentId: raw.student_ref,
    kind:      raw.event === "purchase" ? "spend" : raw.event, // spend | topup | limit_block
    amountUGX: raw.amount,           // UGX, minor units normalized during mapping
    balanceAfterUGX: raw.balance,
    school:    raw.merchant_school || null,
    occurredAt: raw.ts
  };
  if (e.kind === "limit_block") {
    // a blocked tap: policy event, not an empty wallet
    flagPolicyHit(e.cardId, e.amountUGX);
  }
  return postToLedger(e);   // de-duplicated on raw.event_id
}

// On-demand read of a single card
GET /kawu/cards/{cardId}
-> { balanceUGX, withdrawalLimitUGX, lowBalanceAt, lastEventAt }

Two things this captures that a generic stub would miss: a blocked tap is its own event kind, distinct from a zero balance, and the amount is reconciled in UGX minor units rather than taken at face value.

Authorization under Uganda's payment rules

Kawu sits inside Uganda's payments perimeter. The National Payment Systems Act, 2020 sets the framework, and the Bank of Uganda is the regulator for payment service providers and electronic-money issuers — the Act also lets the central bank run a regulatory sandbox for new entrants. What that means for an integration is simple in practice: the read rests on the account holder's authorization, captured and logged before data moves, and the data we touch is kept to what the use case needs. There is no separate open-banking mandate in Uganda compelling a data feed, so consent and authorized interface work — not a statutory API right — are the dependable basis. Where a client needs paperwork, we work under NDA and keep a consent and access log.

Build details we plan around

Specifics of this app that shape the work:

• The withdrawal limit is a ceiling, not a balance. We model it as a separate field so a blocked purchase reads as a policy hit rather than an exhausted card — the two have very different downstream meaning.
• Real-time alerts are opt-out per parent. We design the feed so that when a parent has silenced notifications, a scheduled transaction read fills the gap and the ledger stays complete.
• Card use is tied to vendors inside specific schools. Where the app exposes the school or merchant, we tag each event with it so multi-school reporting works without guesswork.
• Amounts are in Ugandan shillings. We pin currency and unit handling during mapping so totals reconcile against mobile-money top-ups exactly.

Access to a consenting account or a test card is arranged with you during onboarding; the build runs against that rather than against assumptions.

Working with us, and what it costs

A first integration against Kawu's card and wallet surfaces typically lands in one to two weeks. You can have the runnable source and its documentation handed over — that starts at $300, and you pay after delivery, once the code does what the brief said. Or skip hosting it yourself and call our endpoints instead, paying per call with nothing upfront. You give us the app name and what you need from its data; access, consent capture, and compliance steps are arranged with you as part of the engagement. To scope a Kawu build, tell us what you are trying to read and we will come back with the route and a timeline.

Where integrators put this

• A school finance office mirroring every card movement into its own accounting, so cash reconciles per student without manual entry.
• A sponsor or NGO program funding cards for many students and watching spend and balances from one dashboard.
• A savings or budgeting product that reads a student's withdrawal pattern (with consent) to nudge top-ups before the card runs dry.
• A parent-facing aggregator that folds the Kawu balance in beside mobile-money accounts in a single view.

Screens from the app

Sources and who checked them

Checked on 2026-06-07 against the app's own listings and Ugandan press: the Google Play listing and App Store listing for the feature set, The Observer for the model and reach figures, and the National Payment Systems Act, 2020 (ULII) for the regulatory frame. OpenFinance Lab · interface mapping, 2026-06-07.

Other Ugandan money apps in the same orbit

• SchoolPay — school-fees collection used widely across Ugandan schools; holds fee invoices and payment records.
• Xente — a wallet with payments, bills, cards and loans; transaction and card-spend history per user.
• Chipper Cash — peer-to-peer and cross-border transfers; balances and transfer ledgers.
• EasyPay — mobile wallet for sending money and paying bills; account and payment history.
• Flutterwave — payment infrastructure used for tuition and merchant flows; settlement and transaction records.
• PegPay — bill aggregation and collections; payment and biller records.
• Furaha — financial services including school-fees loans; loan and repayment data.
• MTN Mobile Money — Uganda's largest mobile-money wallet; balances and transaction statements.
• Airtel Money — mobile-money wallet; balances and transfer history.

Several of these end up in the same unified view as Kawu, which is where a normalized event and balance schema across them earns its keep.

Questions integrators ask about Kawu

Can Kawu's withdrawal notifications be turned into a webhook feed our system consumes?

That is usually the cleanest path. Kawu pushes a withdrawal alert to the parent at the moment a card is used, and the same event can be normalized and re-emitted to an endpoint you own. Because that alert is opt-out per parent, we pair it with a transaction read so the ledger stays complete even when a parent has silenced notifications.

Does the parent-set withdrawal limit come through in the data we would receive?

Yes. The limit is a per-card ceiling the parent configures, and it sits alongside the balance in the card object. We surface it as its own field, separate from the spendable balance, so a blocked purchase reads as a policy event rather than an empty wallet.

Which regulator covers a Kawu integration, and what does consent look like?

Kawu operates as a digital financial service under Uganda's National Payment Systems Act, 2020, with the Bank of Uganda as the payments regulator. The dependable basis for a read is the account holder's own authorization — the parent who funds the card, or the student account — captured and logged before any data moves.

We run on Node — what is in the first delivery for Kawu?

A working Node client for the balance and transaction surfaces, a small webhook receiver that normalizes withdrawal and low-balance events, the auth-flow notes for the login and token chain, and tests against recorded fixtures. First drop is one to two weeks.