M-Pesa Fee Collection Automation for Kenyan Schools
Almost every Kenyan school already collects fees by M-Pesa. The part that eats a bursar's week isn't the payment itself -- it's proving, line by line, that every shilling on the Paybill statement actually made it into a student's account. Here's where that manual process breaks down, and how EduCore automates it instead.
Where the paper trail falls apart
A typical week: parents pay into the school's Paybill from dozens of different phone numbers, a bursar downloads the Safaricom statement, and then goes searching -- one M-Pesa code at a time -- to confirm each payment landed against the right student. Money that doesn't match anything sits in limbo. A receipt typed in wrong sends a real payment to the wrong account, and nobody notices until a parent disputes their balance at the end of term.
None of this is an M-Pesa problem -- Safaricom's side works exactly as designed. It's a reconciliation problem: turning a flat list of transactions into a confirmed, per-student balance, without a person cross-checking every line by hand.
Reconciliation built in, not bolted on
A real STK push, confirmed automatically
A parent pays through the familiar M-Pesa PIN prompt. Safaricom's callback confirms it directly -- no manual entry -- and the same charge can't be pushed or confirmed twice.
Statement matching, not manual searching
Paste or upload the Paybill statement and every "paid in" line is matched against recorded payments by receipt number -- matched, amount-mismatch, or not-in-system, at a glance instead of one code at a time.
Auto-allocated straight to the invoice
Invoices exist before the payment does -- even for a new admission -- so a confirmed M-Pesa payment applies immediately. No unallocated-payment limbo waiting on a bursar to match it.
Credentials encrypted, endpoints locked down
Paybill/Till credentials are encrypted via Supabase Vault, and only Safaricom's own webhook can confirm a payment -- the endpoint can't be called directly to forge one.
Money nobody recognizes doesn't get invented an owner
A statement line with no matching payment is flagged as "not in system" -- it is never guessed into a student's account automatically. The bursar records it through the same Record Payment flow used for any other payment, prefilled with the receipt number and amount already pulled from the statement, so confirming it is a click, not a re-typing exercise.
This is one part of EduCore's fee management system -- fee structures, invoicing, and per-student balances, reconciled directly against real M-Pesa payments instead of a spreadsheet.
Frequently asked questions
Does a parent need the EduCore app to pay fees by M-Pesa?
No. Payment is a standard M-Pesa STK push -- the parent gets the familiar PIN prompt on their phone. EduCore triggers it and confirms it automatically once Safaricom's callback lands; nothing extra to install.
What happens if a parent pays through the school's Paybill directly, not through the app?
It still gets accounted for. The Finance team can paste or upload the Paybill statement, and every line is automatically matched against payments already in the system by M-Pesa receipt number -- so a direct Paybill payment doesn't require re-typing it in by hand.
Can a payment get applied to the wrong student, or double-counted?
Each STK push is tied to a specific request with double-dispatch prevention, so the same charge can't be pushed twice. Reconciliation matches by the M-Pesa receipt number, which is unique per transaction, so a statement line can only match one recorded payment.
Does this work for admission payments before a student has a full fee account set up?
Yes. The invoice is created as soon as the admissions wizard's Finance step loads the applicable charges, so a confirmed M-Pesa payment applies straight to it instead of sitting as an unallocated payment waiting on a bursar to match it later.
Are M-Pesa API credentials safe if a school's account is compromised?
Paybill/Till credentials are encrypted at rest via Supabase Vault, not stored as plaintext, and the callback/confirm endpoints only accept calls authenticated as Safaricom's own webhook -- a payment can't be forged by calling the endpoint directly.
What if the statement shows money the system doesn't know about?
That line is flagged as "not in system" rather than silently ignored or auto-created. The bursar records it through the normal Record Payment flow, prefilled with the receipt number and amount from the statement, so nothing gets added to a student's account without someone confirming it.
See fee reconciliation running your school's own numbers.
A demo is built around your school's actual fee structure -- not a generic product tour.