Work/Payments/Built for a client
CRSS Collections
Pay school fees from any phone and see where the money is.
LiveLive on production payment keys.
Web
The problem
“We queue at the bank, and nobody can tell which payment is whose.”
A secondary school with several campuses collects fees by bank deposit, transfer and cash at the bursary. Transfers carry unclear narrations, so accountants match payments to students by hand. Parents are unsure whether a payment arrived and have no proof. A deposit to the wrong campus is hard to correct. Ordinary payment pages send everything to one bank account, so campuses wait for transfers and cannot tell which payment is theirs. The school's central office has no quick, auditable view of what has been collected.
Who had it
- ParentsPay from a phone, for several children at once, and get proof of payment.
- Campus accountantsMatch each payment to a student and follow the money to their bank.
- School administrationOne auditable picture of collections across campuses.
- Fikazon operations teamApprove payouts and resolve refunds and mistakes safely.
What the answer had to survive
- Parents have no account and may pay from any phone.
- Mistakes such as wrong campus or overpayment must be fixable.
- A campus must never see another campus's payments.
- Payment confirmations from the provider can arrive late or never.
- Every kobo must be accounted for and checked.
What we built
A short payment page, held funds, daily campus payouts and a self-checking ledger.
Parents pay on a three-step page with no sign-up, for up to ten children in one transaction. The server sets the amount, so the browser cannot change it. Each payment is held for 72 hours, so mistakes can be reported before money moves. Each morning, payments past their hold are gathered into one payout per campus, approved by the platform team and sent to that campus's bank account with a statement. Every movement is recorded in a double-entry ledger that checks itself each night. Payments never depend on a provider message arriving.
What it does
Paying as a parent
- Three-step payment pageDetails and campus, then students and fees, then review and pay. It works on any phone, with no account.
- Several children, one paymentUp to ten children in one transaction, each with class, term and amount, and one receipt.
- Server-set amountsThe server issues the quote. A quote that changed since the parent saw it is refused.
- Instant numbered receiptA PDF receipt appears at once, is emailed, and is copied to the campus bursary.
Campus bursary
- Verify each studentCheck payments against school records one by one or in bulk, with search by name, class and arm.
- Where the money isA dashboard shows money held, available, in payout and paid out.
- Daily payout statementsEach payout lists every payment, with a PDF or CSV statement matching the bank narration.
- Problem reportsRaise a report on any payment and follow its status through to the outcome.
Money controls
- 72-hour custody holdPayments are held before payout, so a wrong campus or overpayment can be reported first.
- Approved payoutsPlatform staff approve each batch after the portal re-checks the total and the live balance.
- Refunds and correctionsRefund, move to the right campus, correct student details or dismiss, each with an updated receipt.
- Nightly ledger checkDebits must equal credits and each campus's balance must match its payments. Drift raises an alert.
Safety and records
- Campus wallsEach campus sees only its own data, enforced in the data layer and not only on screen.
- Signed receipt linksReceipt and report pages use signed, expiring links, so a guessed number shows nothing.
- Audit logPlatform staff changes are recorded, and bank-account changes alert every platform admin.
Built-in help
- Help centreSearchable articles with screenshots, and a Help button that opens the article for the current page.
- PDF guideA printable guide produced from the same articles, so the two stay in step.
- Ask the teamA form that emails the platform team, with replies going to the bursary.
A day with it
- 1
Open the page
The parent opens the payment page on a phone, with no sign-up, and enters their details and campus.
- 2
Add each child
For each child they add name, class, term, what is being paid for and the amount.
- 3
Review the slip
The slip shows fees, the processing fee and the total in figures and words. The parent confirms the campus.
- 4
Pay
Payment is made on Paystack's secure page by card, bank transfer, USSD or bank app.
- 5
Receive the receipt
A numbered receipt appears with a PDF and arrives by email, copied to the campus bursary.
- 6
Payout to campus
After the hold, the payment joins that campus's daily payout. A problem can be reported from the receipt.
How it works inside
Parents use public payment pages and campus staff use an admin area. One application records every payment in a double-entry ledger. Paystack takes the payment and later pays each campus's bank. Background jobs release holds, check open payments and prepare payouts.
Cut the network to see what this system does without it.This one lives on the internet, so it waits, like any website. Its staying power is on our side: backups, health checks and tested recovery.
On the device
- Public payment pagesQuote, checkout and receipt for parents on a phone.
- Admin areaCampus staff verify students; platform staff approve payouts.
Our cloud
- Fees applicationFees, payments, custody holds, payouts and refunds.
- Double-entry ledgerBalanced postings, checked every night.
- Scheduled jobsRelease holds, recheck payments, prepare payouts.
- Payments databaseMoney stored as whole kobo.
Outside services
- PaystackTakes payments and sends transfers and refunds.
- Email serviceReceipts, statements and bounce reports.
- Campus bank accountsReceive the daily payout.
Every part and every link, as text
- Public payment pages — Quote, checkout and receipt for parents on a phone. (on the device)
- Admin area — Campus staff verify students; platform staff approve payouts. (on the device)
- Fees application — Fees, payments, custody holds, payouts and refunds. (our cloud)
- Double-entry ledger — Balanced postings, checked every night. (our cloud)
- Scheduled jobs — Release holds, recheck payments, prepare payouts. (our cloud)
- Payments database — Money stored as whole kobo. (our cloud)
- Paystack — Takes payments and sends transfers and refunds. (outside services)
- Email service — Receipts, statements and bounce reports. (outside services)
- Campus bank accounts — Receive the daily payout. (outside services)
- Public payment pages → Fees application: Quote, then checkout (needs internet)
- Fees application → Paystack: Start payment, verify (needs internet)
- Public payment pages → Paystack: Parent pays (needs internet)
- Fees application → Double-entry ledger: Balanced postings (works offline)
- Double-entry ledger → Payments database: Entries, nightly check (works offline)
- Scheduled jobs → Fees application: Holds, rechecks, payouts (works offline)
- Admin area → Fees application: Verify, approve, resolve (needs internet)
- Fees application → Paystack: Transfer to campus (needs internet)
- Paystack → Campus bank accounts: Daily payout (needs internet)
- Fees application → Email service: Receipts and statements (needs internet)
The hard parts
Money as whole numbers, and a ledger that audits itself
- The situation
- A fees portal that holds money must never lose, double-count or invent a kobo. Fractional arithmetic and notifications that arrive twice are the usual causes.
- What we did
- All money is stored in whole kobo. Every movement posts a balanced entry with a unique key, so a repeated message cannot post twice. A job checks every night that debits equal credits and each campus balance matches its payments.
- The lesson
- The payment system proves its own books are right every night.
A 72-hour hold and approved daily payouts
- The situation
- Paying a campus the moment a parent pays turns mistakes such as a wrong campus, overpayment or duplicate into clawbacks.
- What we did
- Payments are held for 72 hours, then pooled into one payout per campus each morning. The platform admin sees the batch total and live balance before approving. A problem report freezes a payment out of payouts.
- The lesson
- Mistakes are corrected while the money is still in custody.
Designing for a message that may never arrive
- The situation
- Payment providers send confirmation messages that can be late or lost. In the first test payment, the message never arrived at all.
- What we did
- The portal never waits for it. It verifies the payment when the parent returns, rechecks open payments every 10 minutes, and reconciles payouts and refunds hourly.
- The lesson
- Provider plumbing can fail and the money still ends up in the right place.
Campus walls enforced in the data layer
- The situation
- Several campuses share one system. An accountant at one must never see another's payments, even by guessing an ID or tampering with a bulk request.
- What we did
- Campus limits are applied by query scopes on the data models, not only in the screens. Tests try guessed receipt numbers, another campus's lines in a bulk verify, exports and direct IDs.
- The lesson
- Another campus's data does not exist from a campus admin's point of view.
The stack
- Backend
- PHP 8.3LaravelPaystack API
- Apps
- Blade pagesAlpine.jsTailwind CSS
- Data
- MySQL 8RedisDouble-entry ledger
- Infrastructure
- Cloud serverNginxCloudflare
- Services
- PaystackAmazon SES
- Testing
- PestPHPUnitLocal payment simulator
How it came together
- 1A written specificationThe project started from a written specification and mockups.
- 2The whole payment pathThe fee calculator, checkout, ledger, receipts, payouts and admin area were built.
- 3A dedicated serverA dedicated server was set up, HTTPS issued and Cloudflare placed in front.
- 4A first payment, balancedThe first test payment completed, the receipt was issued, and the ledger balanced.
- 5Production keysProduction payment keys were added, and email was authenticated and sending.
- 6Guides for the accountantsA help centre, a 36-page guide for campus accountants and a training video script were written.