Building a School Fees and SME Payment System in Tanzania

Walk into almost any Tanzanian school, SACCO, or landlord's office, and you will find the same problem: collecting payments from many people, matching each payment to the right account, and keeping track of who has paid and who has not.

Before digital systems, this was manual. A parent brings cash to the school bursar. The bursar writes a receipt. The receipt goes into a drawer. At the end of the term, someone reconciles a stack of receipts against a list of students. Payments get lost, records conflict, and everyone argues.

Mobile money changed the collection part. Parents can pay from their phone. But without a system to match payments to students, the reconciliation problem actually gets worse: now you have money arriving from unknown phone numbers with no clear link to which student the payment is for.

The solution is a reference-based payment system. Each student gets a unique reference number (often their student ID or admission number). When a parent pays, they include this reference. The system receives the payment, reads the reference, and credits the right student's account. No manual matching. No lost receipts.

The same pattern works for SACCOs (member numbers), landlords (unit numbers), utility providers (account numbers), and any organization collecting recurring payments from a known set of customers.

A reference-based payment system has five components:

1. Customer/Account Database

A table of customers (students, tenants, members) with their unique reference numbers, expected payment amounts, and payment history. For a school: student name, admission number, class, fee amount, amount paid, balance remaining.

2. Reference Generation

Each customer gets a unique reference that is easy to type on a phone. Keep references short (6 to 10 characters), numeric only (letters are harder on a phone keypad), and unique within your system. The reference should not encode sensitive information (no birthdates or phone numbers).

3. Payment Collection

Three collection methods, depending on your setup:

• Paybill/USSD: The customer dials a USSD code or goes to their mobile money menu, selects "Pay Bill" or "Lipa Kwa Simu," enters your business number, enters the reference, and enters the amount. This works across all three providers.
• Web/app checkout: A web page where the customer enters their reference and phone number. Your system sends a push payment request (STK push or equivalent) to their phone. This uses the same aggregator integration described in our website payment guide.
• Both: Most systems support both USSD-initiated and web-initiated payments.

4. Callback Processing and Reference Matching

When a payment arrives (via callback from the aggregator or telco), your system extracts the reference from the callback payload, looks it up in your database, and credits the associated account. If the reference is invalid (typo, non-existent), flag the payment for manual review.

5. Reporting and Reconciliation

A dashboard showing: total collected, per-account balances, unpaid accounts, payment history, and daily/weekly/monthly summaries. This is what the school bursar, SACCO treasurer, or landlord actually looks at.

Reference matching sounds simple but has edge cases that trip up many implementations:

Typos. A parent enters "12345" instead of "12346." The payment arrives with the wrong reference. Your system either credits the wrong student or flags the payment as unmatched. Neither outcome is good.

Mitigations:

• Use check digits (like the last digit of a credit card number). If the reference fails the check digit validation, it is a typo. Flag it immediately rather than crediting the wrong account.
• Keep references short. Shorter references have fewer opportunities for typos.
• If a payment arrives with an unmatched reference, do not silently drop it. Flag it for manual review and notify your admin.

Partial payments. A parent cannot afford the full TZS 500,000 school fee and sends TZS 200,000 instead. Your system needs to handle partial payments gracefully: credit TZS 200,000 to the student's account and show a remaining balance of TZS 300,000.

Overpayments. A parent sends TZS 550,000 for a TZS 500,000 fee. Your system should credit the full amount and either carry the balance forward to the next term or flag it for a refund.

Multiple payments against one reference. A parent might pay in installments: TZS 200,000 today, TZS 150,000 next week, TZS 150,000 the week after. Your system must accumulate these correctly.

Payments from different providers. A parent might pay part from M-Pesa and part from Tigo Pesa. Both should credit the same student account, matched by reference, regardless of the provider.

For a school or SACCO, rejecting payments from one mobile money provider is not an option. Parents use whichever provider they have. Your system must accept M-Pesa, Tigo Pesa, and Airtel Money.

The aggregator approach is especially valuable here. With Selcom, Azampay, or Pesapal, you get one paybill number (or equivalent) that works across all three providers. Parents dial the same code or enter the same business number regardless of their provider. The aggregator routes the payment and sends you a normalized callback.

With direct telco integration, you would need three separate paybill numbers and three separate integrations. Parents would need to know which number to use based on their provider. This is confusing for users and more work for developers.

For USSD-initiated payments, the aggregator handles the routing transparently. The parent goes to their mobile money menu, selects "Pay Bill," enters your business number, enters the reference, and pays. Whether they are on Vodacom, Tigo, or Airtel, the experience is the same.

For web-initiated payments, the same aggregator API described in our website payment guide handles all three providers. The parent enters their reference and phone number, and the system sends a push notification to their phone.

The payment system is only as useful as its reporting. The people managing school fees or SACCO contributions need clear answers to basic questions:

• Who has paid? A list of all accounts with payment status: fully paid, partially paid, or unpaid.
• How much has been collected? Total amount received today, this week, this month, this term/year.
• Who still owes money? A list of accounts with outstanding balances, sorted by amount owed. This is the list the bursar sends home with students or uses for follow-up.
• What is the payment history for a specific account? When did each payment arrive, from which phone number, via which provider, for how much?
• Are there unmatched payments? Payments that arrived with invalid references and need manual attention.

The dashboard should be accessible from a browser (React frontend) and, if possible, from a mobile phone. School bursars in Tanzania do not always have access to a desktop computer. A mobile-responsive dashboard or even a simple SMS-based query system can be more practical than a desktop-only application.

Export to CSV or Excel is essential. Many schools and organizations still need to print reports or share them with administrators who are not comfortable with a digital dashboard.

A school fees or SME payment system combines three skill sets: full-stack web development, mobile money integration, and basic reporting/analytics.

The development path:

1. Learn mobile money integration. McTaba's M-Pesa Integration for Developers (KES 9,999 / ~TZS 200,000) teaches the request-callback pattern, webhook handling, and payment processing that forms the foundation of any collection system.
2. Build full-stack skills. The Full-Stack Software + AI Engineering course (KES 120,000 / ~TZS 2,400,000) covers React (for the dashboard), Node.js (for the backend and callback handling), databases (for storing accounts and transactions), and authentication (for admin access).
3. Deploy. The Deployment: Going Live course (KES 4,999 / ~TZS 100,000) covers getting your system from localhost to a production server with a domain and SSL.

This type of system is also an excellent portfolio project. A working school fees collection system that integrates with mobile money, handles multi-rail payments, and produces meaningful reports demonstrates real-world developer skills that Tanzanian employers and clients care about.

The market for this kind of system in Tanzania is large and underserved. Thousands of schools, SACCOs, and landlords still manage payments manually or with basic spreadsheets. A developer who can build and sell this kind of system has a genuine business opportunity, not just a technical skill.