The tuition collection playbook

Students mostly manage to pay. What creates the queue is proving they paid: a slip, a counter, a person checking, and a registration system that only learns about it when somebody types it in.

Removing the human from that loop is the whole project. Everything else is detail.

Point a webhook at your student information system. When a payment clears, the callback carries the amount and the reference, and your system flips the student to eligible without anyone touching it.

Build this against the sandbox before registration week, and test the failure cases: the duplicate callback, the partial payment, the payment against a reference that does not exist.

Two patterns cover almost everything. A student paying in parts needs a running balance against one reference. A sponsor paying for several students needs each payment to carry the student it belongs to, which usually means one link per student even when one person is paying them all.

Decide your eligibility rule explicitly: fully paid, or a minimum percentage. Write it down before the system enforces it, because whatever you build will be applied to every student without sympathy.

For each payment: who paid, for whom, how much, on which method, at what time, and against which reference. That is what an auditor asks for, and it is what an export should contain without post-processing.

Keep failures too. A reconciliation that only shows successes cannot explain a student who says they paid.