Collecting fees
Bill a term’s fees and take payment.
A virtual account per student
A dedicated account number that reconciles itself and accepts instalments.
Splitting fees to third parties
Pay suppliers, transport and exam bodies directly out of one fee.
Course subscriptions
Recurring access for EdTech platforms.
Collecting fees
What you’re building: A portal where a parent or student signs in, sees what is owed, and pays — with the school management system updated automatically.The flow
1
Raise the fee notice
Send an invoice per student, itemised by fee type — tuition, uniform, transport, trips — each line carrying its own tax rate. SeerBit emails it and assigns an invoice number.Billing a whole class or cohort at once? Use bulk invoicing to send the run in a single request.
2
Take the payment
The invoice carries its own payment link. If you would rather families pay inside your portal, create the transaction there with Standard Checkout instead.
3
Update the fee record
Confirm with a webhook or by verifying the payment, then mark the fee paid against the student.
Decisions specific to education
- Put the student identifier in the reference. A scheme like
FEE-STD00291-TERM2-2026means reconciliation is a string parse, not a lookup. Keep it unique per attempt. - One invoice, many fee types. Because
taxis set per line item, a single invoice can carry zero-rated tuition alongside taxable uniform and transport charges. You do not need separate invoices per fee type. - Ad-hoc charges don’t need an invoice. A trip, a resit fee, a replacement ID card — a payment link shared in a class group is faster than raising a document.
- A fee that covers other parties should be split at payment time rather than paid out later — see splitting fees to third parties.
What to watch
orderNo is your lookup key. Invoices can be retrieved by invoice number, order number or customer email — set orderNo to something meaningful from your school system and you get a free reconciliation path.
Guardians pay from their own accounts. The name on the payment often won’t match the student’s. Never reconcile on payer name.
A virtual account per student
What you’re building: Every student has their own bank account number to pay into. Money arriving is attributed to that student automatically, in any amount, at any time — so instalments work by default and nobody matches a bank statement by hand. This is the single highest-leverage thing an institution can do with SeerBit. A virtual account is a real account number reserved against one student, and it solves three problems at once:The flow
1
Reserve an account per student
Create a virtual account against each student, using your own student identifier as the
reference. You get back a bank account number.2
Give the number to the family
Show it on the portal and on fee notices. It does not change, so families can save it as a beneficiary and pay from any banking app.
3
Credit the student as money arrives
Each transfer fires a webhook. Add the amount to that student’s balance and compare the running total against the term’s fees.
Decisions specific to education
- There is no instalment API — and you do not need one. You track the running total against the term’s fees yourself; the dedicated account is what makes that safe, because every credit is already attributed to the right student.
- Make the
referenceyour student ID. It is how you retrieve and delete the account later, and how you attribute inbound payments. - The account outlives the term. Reserve once at enrolment, not once per term, and the family keeps paying to the same number year after year.
- Decide your part-payment policy in code. SeerBit reports what arrived; whether a pupil with 60% paid may sit an exam is your rule, not a payment one.
What to watch
Payments arrive unannounced. A parent can transfer at 2am on a Sunday. Rely on webhooks rather than polling, and make your handler idempotent — a repeated event must not double-credit a student. Virtual account credits shareeventType: "transaction" with ordinary payments. Branch on the presence of creditAccountNumber, not on the event type alone.
Splitting fees to third parties
What you’re building: One fee paid by one family, arriving already divided between the school and everyone else it is owed to — the uniform supplier, the transport operator, the exam body, the PTA levy. Without this, the school collects the whole amount, holds other people’s money, and pays it out later by hand. Split settlement settles each party directly as part of the original payment.The flow
1
Register each party once
Create a sub-account for every recipient — the uniform supplier, the transport operator, the exam body. Each gets a
subAccountCode.2
Decide how the fee divides
Either configure a split rule on the dashboard and reference it by
splitCode, or define the division inline per transaction with a splits object. See split settlement.3
Take the payment as normal
Add the split to your existing Standard Checkout request. Nothing else about the payment changes.
Decisions specific to education
FLATfits fees better thanPERCENTAGE. A uniform costs a fixed amount regardless of what else is on the invoice, so a fixed split matches how fees are actually priced. UsePERCENTAGEfor revenue shares — an EdTech platform taking a cut of tutor earnings.- Split inline when the composition varies per student. Two pupils in the same class can owe different combinations — one takes the bus, one doesn’t. A
splitsobject per transaction handles that; a fixedsplitCodedoes not. - Decide who bears the transaction fee.
transactionFeenominates which party absorbs it —PARENT_ACCOUNTkeeps it with the school,PROPORTIONATEshares it across recipients. For a supplier expecting an exact invoice amount, do not make them the bearer. - Register the recipient before you reference it. A split naming a
subAccountCodethat does not exist will fail — so onboarding a new transport operator is a prerequisite, not a same-day change.
Why this matters here
Marketplace-shaped platforms — an EdTech site paying tutors, or a portal serving many schools — use the same mechanism to take commission and settle the rest.
Course subscriptions
What you’re building: An EdTech platform charging monthly or annual access, renewing without the learner re-entering card details.The flow
1
Take the first payment with tokenisation
Charge the learner through Standard Checkout with
tokenize: true. Card details are entered in SeerBit’s form, so no PCI DSS certification is required.2
Retrieve the authorization code
Query the payment to get the
authorizationCode. Store it against the learner. This stands in for the card.3
Renew on schedule
For fixed cycles, define a plan with subscriptions and let SeerBit charge automatically. To control timing yourself, charge the stored code with card tokenisation.
Decisions specific to education
- Recurring charges are card-only. Transfer, USSD and mobile money cannot be auto-renewed, so offer a card at signup even if your checkout supports everything else.
- Academic terms are not calendar months. If access should end at the end of term, a fixed monthly plan will over-bill — use tokenisation and charge on your own academic calendar instead.
- Handle the failed renewal gracefully. Pause access rather than deleting progress, and give a grace period; a learner mid-course is worth more than one month’s fee.
Peak registration windows
Education traffic is spiky in a way retail is not — a fee deadline or an exam registration opening concentrates months of volume into hours.- Never poll for status during a peak. Use webhooks so load does not scale with your polling frequency.
- Make references idempotent. A parent refreshing a slow page must not create a second charge — a reused
paymentReferenceis rejected, which is the behaviour you want. - Offer non-card methods. Transfer and USSD hold up when card rails are congested, and reach guardians without cards.
Candidates paying from other countries
Exam and professional bodies often collect from across the region. Enable the payment methods that are normal in each market rather than expecting an international card, and check the supported currencies before you price in one.Before you go live
Test the fee flow end to end
Test cards, and how test and live modes differ.
Go live
KYC, swapping keys, and re-pointing webhooks.
Virtual accounts are per-mode. Accounts created with test keys only work in test mode — you will reserve them again against live keys before term starts.