A record of what's been paid and confirmed — without Notipa touching a card number or a bank transfer. Never payment processing, just a clearer paper trail.
Planned Not yet started — this page describes the intended design and build plan.
Overview
Extends fee notices — currently marked paid, owed, or waived by an admin — so a guardian can attach a
reference against a notice they've already paid outside the app: a bank transfer ID, mobile money
reference, or a photo of a receipt from paying at the school office. An admin then confirms or disputes
it. Notipa still never touches the payment itself — this is explicitly not a payments feature. It's a
paper-trail feature, and the distinction the features section already draws needs to hold here too.
How it will work
Guardian marks a notice as paid. Against an owed fee notice, a guardian can record "I've paid this" and optionally attach a reference number or a photo of a receipt.
Pending confirmation, not automatic. The status becomes "Paid — pending confirmation" until an admin reviews it — a guardian's claim alone doesn't close out the notice.
A review queue, not individual chasing. Admins see pending claims in one place, so confirming payments doesn't mean hunting through messages or a separate spreadsheet.
No payment gateway, ever. No card details, no bank integration, no money moving through Notipa — attachments and text only, the same file-attachment handling already used for homework.
Development plan
1Data model
Extend the fee notice status with a guardian-submitted claim: reference text, optional attachment, timestamp, pending admin review.
2Guardian UI
An "I've paid this" action on an owed fee notice, with an optional reference field and attachment upload.
3Admin UI
A review queue for pending claims on the existing fee notice roster, with confirm/reject actions.
4Testing
Tests confirming a guardian's claim never auto-closes a fee notice without admin confirmation.
A copy review pass to make sure the wording throughout stays unambiguous that this is a record, not a transaction — no risk of a guardian believing they've paid through the app itself.
Technical considerations
Deliberately stays on the "informational record" side of the line drawn on the landing page — this is not a step toward payment processing, and the UI copy needs to make that explicit everywhere it appears.
Reuses the file-attachment handling already built for homework, rather than a new upload path.
Serves schools where the actual payment method is bank transfer, mobile money, or cash at the office — common outside markets where card-based payment processors are the default — without them needing a separate spreadsheet to track who's paid.