Kawu's parent app and student smart-card: the data path

Roughly sixty-two thousand parents send their kids upkeep through Kawu — per The Observer's late-2024 write-up — and a student tops up at the canteen with a smart card while the parent watches the balance fall on a phone in Kampala or the diaspora. That is the shape a third party would integrate against: a parent-side wallet with kids attached to it, per-child withdraw limits, a notification feed that fires on every swipe, and a ledger of school-canteen spend posted out of the Interswitch-routed point-of-sale leg.

What integrators usually want from Kawu is dull and useful: a feed of where the upkeep money went, a way to read or set a child's spending cap, and a webhook so a downstream system sees a swipe within seconds. None of that needs a heroic protocol exercise — it is a tight set of authenticated endpoints behind the parent's login, plus the notification stream the parent already gets on the phone.

What Kawu holds for one family

Each row below names a surface a parent already touches inside the app. The mapping is what we'd ship in the spec, not a guess.

Authorized routes into Kawu's back-end

Three routes apply for an app shaped like this. The one we'd lead with is the first; the others backstop it.

1. Authorized interface integration of the parent app

The parent app is the natural seat for a third party. A consenting parent gives scope; we map the device-bound login, the bearer-token refresh, the children-list endpoint, per-child wallet, limits, and ledger, and we wrap them as a clean HTTP surface in front. Effort: the bulk of a one-to-two-week cycle. Durability: tied to the parent app's release cadence — we re-validate when the build changes. Setup the studio does: onboarding with the parent account holder, NDA where the data is sensitive, a test account for the build to run against.

2. User-consented credential access via a hosted session

For workflows where a parent wants a one-shot pull — say, an export of the last term's canteen spend for a fee subsidy or stipend program — we run the read inside a session the parent has consented to, never a long-lived credential cache. Effort: light. Use: narrow but real. This is the route a school welfare office tends to ask for.

3. USSD channel as fallback

Kawu's own product page lists USSD as a parent channel — there are families on feature phones, or with the app offloaded. The USSD code-paths cover top-up, balance, and limit changes; the data is thinner than the app surface but still genuine. We document the codes in the spec so an integrator with low-bandwidth coverage has somewhere to fall back to.

For most integrations the spine is route one. Routes two and three sit alongside it for the workflows they actually serve.

A working request shape against the parent app

Illustrative — exact field names and host are pinned to the build during the engagement, not asserted here as flat fact. The shape is what you'd see after device-bound parent login, list of children, then per-child wallet and ledger.

# 1) Parent sign-in. Device id is pinned on first launch and replayed
#    on every call; the build wires that pinning so the server accepts us.
POST /v1/auth/login HTTP/1.1
Host: api.kawu.ug
Content-Type: application/json
{
  "msisdn":   "+2567XXXXXXXX",
  "pin":      "...",
  "device_id":"<uuid pinned on first launch>"
}

200 OK
{
  "access_token":"eyJ...",
  "refresh_token":"...",
  "expires_in": 1800,
  "parent_id":  "p_8a31..."
}

# 2) The children attached to this parent — one or many.
GET /v1/parents/p_8a31.../students
Authorization: Bearer eyJ...

200 OK
{
  "students":[
    {"student_id":"s_111","name":"Aine N.","smart_card_id":"KW-77...","school_code":"SCH012"},
    {"student_id":"s_222","name":"Pius N.","smart_card_id":"KW-78...","school_code":"SCH012"}
  ]
}

# 3) Per-child wallet, current daily limit, and recent ledger.
GET /v1/students/s_111/wallet?from=2026-04-19&to=2026-05-19
Authorization: Bearer eyJ...

200 OK
{
  "balance_ugx": 84500,
  "daily_limit_ugx": 7000,
  "ledger":[
    {"ts":"2026-05-18T12:14:02+03:00","kind":"canteen_purchase","amount_ugx":2500,"agent":"AG-CT-04"},
    {"ts":"2026-05-18T10:02:55+03:00","kind":"cash_out",        "amount_ugx":3000,"agent":"AG-MT-02"},
    {"ts":"2026-05-17T16:48:10+03:00","kind":"top_up",          "amount_ugx":50000,"source":"mtn_momo"}
  ]
}

# 4) A push notification, mirrored as a webhook on the integrator side.
POST https://customer.example/kawu/hook
X-Kawu-Signature: sha256=...
{
  "event_id":"evt_2f...","ts":"2026-05-19T11:42:10+03:00",
  "student_id":"s_111","kind":"canteen_purchase","amount_ugx":1500,
  "limit_remaining_ugx":4500
}

Errors line up the way the parent app already surfaces them — bad PIN, locked card, limit-exceeded — and we propagate them as discrete error codes rather than collapsing to a generic 400. Token refresh is the only retry the client ever needs.

What lands on disk at the end of the build

• An OpenAPI 3 spec for the surfaces above, written against the actual responses observed during the engagement, not a generic stub.
• Runnable source for the key endpoints in both Python (requests / httpx) and Node.js, with the device-binding and token refresh implemented.
• A protocol-and-auth-flow note covering the parent login, the bearer/refresh chain, the notification subscription, and the small surprises (signed device id, agent-role codes in the ledger).
• A webhook bridge for the real-time notification stream, so the integrator's server sees swipes within seconds rather than polling the ledger.
• Automated tests against a test parent account: balance read, limit read and update, ledger replay, webhook signature verification.
• Interface documentation in English, plus a compliance note covering data minimization, retention, and the consent record kept against each parent on whose behalf the integration runs.

Planning notes specific to Kawu

Four things shape the build for this app — they are not gates the customer has to clear, they are details the studio handles.

• Multiple children per parent is the common case, not an edge case. We model children as an array on the parent and run balance, limit and ledger queries per child. The "happy path" of one student is just N = 1 of the same code path.
• The student spend itself doesn't ride the parent app's main HTTPS calls — it goes through the Interswitch-routed POS leg. What the integration reads is the settled ledger entry that lands back in the parent view, plus the notification that fires on the swipe. We design around that two-track shape so a missing notification never silently hides a real spend, and a webhook is reconciled against the ledger nightly.
• The withdraw-notification stream is opt-out on the parent side. A parent who has muted push in the app still has the underlying events on the server; we wire the mirror against the server stream, with consent, so a downstream system isn't blind because the parent silenced their phone at night.
• Front-end builds drift. The parent app is on a real release schedule, and field names move. The engagement bakes a re-validation routine into the maintenance window — a short suite that probes the device-bound login and the per-child wallet shape, run on a cron, with a notification when a response shape moves so we patch before users notice.

Authority and consent in the Ugandan setting

Two regimes do real work here. The first is monetary: Kawu's payments back-end is operated through Interswitch under the Bank of Uganda's National Payments Systems Act, which is the licensing instrument for payment service operators in the country — Kawu's own HiPipo profile calls Interswitch a Bank of Uganda-licensed financial technology partner. Card-rail authorization and the canteen POS leg sit on that side of the house.

The second is personal data: parent identifiers, child names, school codes, balances and ledgers are personal data under Uganda's Data Protection and Privacy Act, 2019, supervised by the Personal Data Protection Office (PDPO) under NITA-U. The Act gives the parent and, where applicable, the student data-subject rights — access, correction, deletion in defined cases — and requires entities collecting or processing personal data to register with NITA-U. The dependable basis for the integration is the parent's explicit consent at onboarding, recorded, scoped to the specific data domains the build needs, and revocable; we keep a consent log per integration with the timestamp, scope, and revocation state. Where a child's data is in scope the consent is given by the parent as the data-subject's guardian, narrowly framed, and not used for anything else.

Operationally that means authorized, logged, data-minimized access. NDA where the third party prefers one. No long-lived credential cache; tokens refresh inside the agreed scope and die when the parent revokes.

Where these notes came from

Worked from Kawu's own product copy on Google Play and the company website, cross-checked against two Ugandan press profiles and HiPipo's fintech write-up; regulatory framing drawn from NITA-U's posting of the Data Protection and Privacy Act, 2019. Where a number (active users, school count) shows up, it's attributed to the source and not asserted independently.

• Google Play — Kawu -Send & Manage Upkeep (com.kawu.ug)
• The Observer — "Kawu helping parents to remotely manage children's pocket money"
• HiPipo — "Kawu is digitizing pocket money", #40Days40FinTechs S5 D40, Sept 2024
• NITA-U — Data Protection and Privacy Act, No. 9 of 2019 (PDF)

Notes by the OpenBanking Studio integration desk · May 2026.

Where Kawu sits in Uganda's student-money stack

Plain context, not a ranking. These names come up in the same conversation a school or a parent-facing fintech has when scoping where money for students lives.

• DesisPay — Ugandan school payments and student-wallet platform with a physical card used at canteens; the closest functional peer.
• SchoolPay (Service Cops) — universal school-fees payments and school-ERP rails covering thousands of Ugandan schools; integrates with banks and mobile money rather than carrying a per-student spend card.
• Kawallet — smart-school platform marketed in the same parent-and-student wallet niche.
• Xente — Ugandan payments and business spend-management platform, useful when the school itself is the merchant of record.
• MTN MoMo (Uganda) — the dominant mobile-money wallet a parent funds Kawu from; relevant any time the funding leg of upkeep is in scope.
• Airtel Money Uganda — the second mobile-money funding rail parents top up from.
• Pesapal — East-African payment gateway covering Uganda, often paired with school-fees collection flows.
• Flutterwave (Tuition) — pan-African payments stack with a tuition product the same school finance offices look at.

Questions integrators tend to ask about Kawu

Can we see what a Kawu student actually spent in the school canteen, line by line?

Yes. Per-card spend posts to the parent-side ledger as discrete events — timestamp, amount in UGX, agent code at the canteen — once the Interswitch-routed POS leg settles. We pull those events per child, not as one aggregated total, so reconciliation works the same way a parent sees it.

Does Kawu push real-time withdraw alerts that a third-party server can ingest?

Kawu's own product copy describes real-time withdraw notifications to the parent (with an opt-out). The integration mirrors that same stream into a server-side webhook scoped to the parent's consent, so a downstream system sees the swipe even when the parent has muted the in-app push.

Where does Kawu sit under Ugandan financial regulation?

Kawu rides the rails of an Interswitch payments back-end licensed by Bank of Uganda under the National Payments Systems Act, per Kawu's HiPipo and Observer profiles. Personal-data handling falls under the Data Protection and Privacy Act 2019, supervised by the Personal Data Protection Office under NITA-U.

A parent has three kids on Kawu — does the integration cope with that?

That is the common shape, not the edge case. The parent account exposes a list of students, each with its own smart-card id, daily limit, and ledger. The integration treats children as an array on the parent and queries balance / limit / spend per child, so a parent with one student and a parent with four use the same code path.

Pricing is small and stated up front. Source-code delivery starts at $300 — runnable source for the parent-login, per-child wallet, limits, ledger and webhook surfaces, plus the OpenAPI spec, the protocol report, tests, and the interface documentation — and you pay after delivery once a test parent account you provide passes the suite. The pay-per-call hosted option has no upfront fee: you call our endpoints against the same surfaces and pay only for what you call. A normal cycle is one to two weeks from agreed scope to handover. Tell us the parent-account scope you'd like covered at /contact.html and we will quote it before any work starts.

Kawu in brief

Name: Kawu -Send & Manage Upkeep · Package: com.kawu.ug (per Google Play) · iOS bundle: id1639007286 (per Apple App Store). Operator: Kawu Smart Mobile Money Services Ltd. Market: Uganda. Launch: 2022, per HiPipo's profile. Reported scale (Sept 2024, per The Observer / HiPipo): around 62,000 active customers across roughly 70 schools — not independently audited here. Surfaces: Android, iOS, USSD; physical Kawu Smart Card on the student side, processed via Interswitch. Origin of the name: a Ugandan student slang for being broke, often the colloquial nickname for the kawunga-and-beans phase of the term — Kawu's own founders use that framing publicly.

Interface evidence

App screenshots used as on-page references — click to enlarge. Screens originate from the Google Play listing for com.kawu.ug.