Student Village — Case Study

Student Village — Bursary Management SystemBuilt by Monthos · Case Study

Industry

Education / Corporate Bursary & CSI Management

Product type

Multi-tenant SaaS · Custom web application

Market

South Africa, extensible to the broader SADC region

Built by

Monthos

Live domain

sv.co.za (production) · uat.sv.co.za (staging)

At a glance

Problem

Large South African corporates running bursary and CSI/L&D programmes had no single system to manage applications, approvals, disbursements, academic tracking, and regulatory reporting—typically relying on spreadsheets, e-mail chains, and manual finance processes.

Solution

A production-grade, multi-tenant bursary management platform that gives each corporate client its own branded portal, configurable workflows, role-based access, and automated payment and reporting pipelines.

Stack

Laravel 12 · PHP 8.2 · MySQL · AWS S3 · Peach Payments · Microsoft Azure AD (SAML 2.0) · Bref (serverless) · ClickATell SMS · AWS SNS · SFTP

Scope

Six confirmed enterprise clients including Vodacom, Nedbank, MultiChoice, Adapt IT, AECI, and 36ONE

Project impact

Monthos built a production-grade bursary platform that automates the full beneficiary lifecycle for large South African corporates—now running six enterprise clients on one codebase.

Every corporate gets its own branded, isolated portal. Configurable workflows, eligibility rules and email templates—without bespoke code per client.

Disbursement runs itself, safely. Nightly bank verification and scheduled Peach Payments payouts replace manual EFT, behind a mandatory five-step approval trail.

Funder reporting that maps to compliance. An automated 130-column export delivered to each corporate's SFTP, aligned to B-BBEE Skills Development and SETA categories.

The failure points are automated away. 20 scheduled jobs handle stale-application rejection, reminders, HR batch imports and year rollovers.

Who this is for: large corporates and funders running bursary, learnership or CSI/L&D programmes in South Africa and the broader SADC region.The challengeRunning a corporate bursary programme at scale is operationally intensive. The problems Monthos was asked to solve were concrete and recurring across every prospective client:

No single source of truth. Student applications, approval decisions, invoice records, and academic results lived in separate systems—or in no system at all.

Manual approval chains. Line Managers and L&D Managers were notified by e-mail and expected to reply; follow-up was manual and inconsistent, causing applications to lapse.

Disbursement risk. Paying students and suppliers required bank account validation and a multi-step authorisation trail. Without automation, errors were common and reconciliation was slow.

Academic monitoring gaps. Corporations had no systematic way to track whether bursars passed their subjects, triggering renewals or terminations appropriately.

Regulatory reporting burden. B-BBEE Skills Development and CSI reporting demands meant that funders needed structured, auditable data on every rand spent—segmented by NQF level, SETA category, qualification, race, gender, and accommodation type.

Multi-client complexity. Each corporate client has distinct eligibility rules, application windows, funding categories, branding, and e-mail templates. A single shared instance could not serve them without contaminating one another's data.

Employee record synchronisation. HR data in corporate systems (employee status, line manager assignments, cost centre clusters) needed to flow into the bursary platform automatically, not be re-keyed.

Our approachMonthos designed Student Village around four guiding principles:

Isolation by design. Every corporate client is a discrete tenant. Data, branding, budgets, funding categories, eligibility rules, application dates, e-mail templates, and user accounts are all scoped to the owning company. No client ever sees another client's beneficiaries or spend.

Configurable, not customised. Rather than shipping bespoke code per client, the platform exposes a rich administration layer—application form field toggles, custom questionnaires, per-company e-mail template overrides, configurable age and eligibility thresholds, disbursement fee settings, and per-company payment gateway keys. Clients configure; Monthos maintains one codebase.

Audit-ready by default. Every approval decision, status transition, disbursement, and document upload is captured in structured activity logs. Invoice approval follows a mandatory five-step workflow (submitted → line manager → operations → released → paid), with timestamps and actor identities at every step.

Automation reduces human error. Scheduled Artisan commands handle the tasks most likely to be missed under manual operation: auto-rejecting stale applications, reminding managers of pending queues, verifying bank accounts, releasing payments to the Peach Payments gateway, and importing HR batch files from SFTP.

What we deliveredApplication intake

Six-step application form — Preliminary Questions → Personal Information → Education Questions → Choice of Study → Parent/Guardian Information → Current Scholarship Declaration.

Per-company application windows (company_dates) with configurable open/close dates and academic year labels.

Applications typed as either Bursary or Programme (learnerships, internships, certifications, full qualifications, skills programmes, etc.—nine SETA-aligned programme categories supported).

Configurable form fields — each field can be marked required or optional at company level; sections can be hidden via company settings.

Custom questionnaires per company, with drag-and-drop ordering.

Public-facing FAQ and terms/instructions per company.

SSO login for applicants via Microsoft Azure AD (SAML 2.0), directing users to their specific company subdomain.

Screening & selection

Stage

Actor

Outcome

Application submitted

Applicant

Confirmation e-mail sent

Line Manager review

Line Manager

Approve / decline with motivation

L&D Manager review

L&D Manager

Approve / decline with motivation

Programme Manager review (where applicable)

Programme Manager

Approve / decline

Operations approval

SV Operations team

Final internal sign-off

Automatic rejection — applications pending Line Manager action past the company's configurable deadline are declined automatically and both the applicant and Line Manager are notified by e-mail.

Incomplete-application auto-rejection — separately tracked and communicated with distinct e-mail templates.

Re-open capability — Line Managers can re-open a declined application within the active window.

Reminder engine — scheduled per company and per role (Line Manager, L&D Manager, Programme Manager), with configurable reminder dates and an aggregate table of pending applications embedded in each reminder e-mail.

Decline reasons — structured taxonomy (11 standard reasons plus free text) captured against every declined request, enabling downstream reporting.

Beneficiary management

Full beneficiary profile: personal details, identity, disability status, accommodation type (home / campus / rental), and family/guardian income declarations.

Employee batch import via SFTP — HR files dropped by the corporate into a designated SFTP folder are picked up nightly by a scheduled command, decrypted via SSH, validated (column count, e-mail domain rules, role constraints, cluster membership), and used to create or update applicant records, assign Line Managers and L&D Managers, and flag eligibility.

Per-applicant stop-payment flag and termination date, synced from HR data.

Company clusters — organisational segmentation (business unit, division) applied at import and used in reporting.

Applicant status lifecycle: Active → Dropped Out → Terminated → Graduated, tracked per academic year.

Document store per beneficiary: ID document, academic transcripts, proof of registration, fee statement, book quotation, lease agreement, signed contract, proof of income, disability documentation, EEA 1 form—all stored on AWS S3 with pre-signed URL access.

Internal notes and chat per beneficiary, visible to operations staff.

Flagging system for beneficiaries requiring attention.

Disbursement & funding

Invoice workflow — five mandatory steps with named actors and timestamps: Invoice Submitted → Line Manager Approval → Operations Approval → Payment Released → Payment Successful.

Invoice types: single payment, bulk payment, partial payment; paid to bursar directly or to a third-party supplier.

Automated payment release via Peach Payments gateway — a scheduled command queries invoices approved for release with a release date ≤ today, dispatches the payout, and records the gateway response and a disbursement fee.

Bank account verification — student and supplier bank accounts are validated against the Peach Payments bank verification service before any disbursement is permitted; validation runs nightly as a scheduled job.

Peach Payment webhook — inbound payment status updates are handled and reconciled automatically.

Reject-reason taxonomy for declined invoices (16 categories including fraud suspicion, duplicate invoice, Peach gateway rejection).

Budget tracking at both company and individual beneficiary level, broken down by funding category; used/balance figures updated on each successful payment.

Per-company configurable disbursement fee and payment gateway key (self-administered clients use their own Peach account).

Per-company configurable funding categories, each with its own budget allocation.

Workshop payments configurable at company level.

Academic tracking & renewals

Semester subject capture — up to ten subjects per semester (1st semester, 2nd semester, full year), with percentage results per subject.

Result status per subject: Pass / Fail / Supplementary / Pending.

Test results tracked separately from exam results.

Semester result summaries (pass/fail at semester level) and module performance reports.

Academic year status updated per beneficiary (Active / Graduated / Dropped Out / Terminated), driving renewal eligibility.

Bursary duration tracked in years (1–5), with year-of-study progression.

Year rollover — a scheduled command (bursary:company_add_year, bursary:applicant_add_year) advances academic year records annually without manual intervention.

Reporting to corporate funders

Batch report generation — a scheduled command (bursary:batch_file_report) assembles a structured CSV export of all bursar activity for the reporting period, including over 100 data points: employee number, approval chain actors, qualification details, NQF level, STEAM classification, semester subject results (up to 10 per term across three periods), invoice amounts, budget consumed/balance, programme details with SAQA ID, accreditation number, and capability classification.

The export schema maps directly to the fields corporates need for Skills Development, B-BBEE scorecard, and internal L&D reporting.

Outbound SFTP delivery — completed batch reports are transmitted back to the corporate's SFTP endpoint automatically.

Application report — filterable list of all applications with status, available to Company Report users.

SMS delivery report — per-company log of all SMS communications.

E-mail activity log — full outbound queue with subject, recipient, and body, queryable by operations staff.

Admin & configuration

Per-company branding — logo, large logo, banner, favicon, header and footer images for e-mail templates, footer text; all stored in a public AWS S3 bucket and served via CDN URL.

Customisable e-mail templates — 35 distinct e-mail event types (application applied, accepted, declined, auto-rejected, invoice notifications, reminder digests, and more); each template can be overridden per company with custom subject, body, and active/inactive toggle.

Terms & conditions and application instructions per company.

FAQ management with drag-and-drop ordering.

Per-company OTP login toggle (in addition to SSO).

Domain whitelisting — companies define their primary domain and trusted additional domains; batch imports and SSO are validated against this list.

Application form field settings — toggle any non-mandatory field on or off per company and per section.

Batch file management UI — status tracking (Pending → Processing → Completed → Sent → Error) with row-level error messages for failed records.

Technical highlightsStack by layer

Layer

Technology

Language / Runtime

PHP 8.2

Framework

Laravel 12

API style

REST (Laravel Sanctum token auth)

Database

MySQL (Eloquent ORM)

File storage

AWS S3 (private bucket for documents, public bucket for branding assets)

Serverless deployment

Bref + Laravel Bridge (AWS Lambda)

Authentication — admin portal

SAML 2.0 via Microsoft Azure AD (patrickallaert/php-saml)

Authentication — student portal

SAML 2.0 via Microsoft Azure AD (separate SP entity per environment)

API tokens

Laravel Sanctum

Social auth library

league/oauth2-google

Payment gateway

Peach Payments (bank validation + payout disbursement)

SMS

ClickATell (arcturial/clickatell) + AWS SNS

SFTP

league/flysystem-sftp-v3 + phpseclib (SSH key/password auth)

PDF generation

TCPDF (tecnickcom/tcpdf)

HTTP client

Guzzle 7

Logging

Logtail / Monolog (logtail/monolog-logtail)

Frontend build

Vite 6 + Laravel Vite Plugin

Testing

PHPUnit 11

Code style

Laravel Pint

Architecture decisions worth notingDomain-based multi-tenancy. Each corporate client is identified by a unique domain_name on the companies table. Applicant-facing portals are served on client-specific subdomains (e.g. nedbank2.bursary.sv.co.za). API requests are validated against the resolved company. All data queries flow through the company context, making cross-tenant data leakage structurally prevented rather than policy-enforced.Bounded context organisation. The app/Contexts/ directory groups the codebase into 17 explicit domains — Applicant, Auth, BatchFiles, Bursar, Company, CompanyProgram, File, Master, Payment, Qualification, Report, SortList, Tutor, University, User, Workshop — each with its own Models, Actions, Tasks, UI (Controllers, Middleware, Requests, Transformers, Routes), isolating domain logic and making the system maintainable as it scales.Action-based controller pattern. Controllers are thin dispatchers; all business logic lives in discrete Action classes injected by Laravel's service container. This makes individual operations independently testable and reusable across routes.Role-based access control with API-level enforcement. 17 distinct roles (Super Admin, Company Admin, Company Operations, Company Finance, Company Report, Company Settings, SV Admin, SV Operations, SV Finance, Applicant, Bursar, Line Manager, L&D Manager, Programme Manager, Batch, Program, and a standalone Batch-import role) are enforced by dedicated middleware (userAccess, adminRoleAccess, companyRoleAccess, financeAccess, roleAccess, checkApiAccess). Bursar-portal API endpoints have a separate access map (BURSAR_API_ACCESS) that can selectively expose or hide portal sections per company.Scheduled automation. 20 Artisan commands cover every recurring operational task, scheduled to run at appropriate intervals without human trigger:bursary:batch_file_import_check — Poll SFTP, decrypt, ingest HR batch files bursary:batch_file_data_process — Validate and apply batch file rows to user/applicant records bursary:batch_file_data_send — Transmit completed reports to corporate SFTP bursary:batch_file_report — Assemble and stage the structured CSV activity report bursary:payment_release — Dispatch approved invoices to Peach Payments bursary:bank_verify — Validate student and supplier bank accounts via Peach bursary:auto_reject_email — Auto-reject and notify on stale applications bursary:manager_reminder_mail — Send manager reminder digests bursary:pending_company_approval_reminder — Notify on pending approvals bursary:applying_mail — Send application confirmation e-mails bursary:send_mail — Process the outbound e-mail queue bursary:send_sms — Process the outbound SMS queue bursary:bulk_message — Dispatch bulk e-mail/SMS/chat campaigns bursary:workshop_reminder — Send workshop attendance reminders bursary:tutor_reminder — Send tutor-session reminders bursary:company_add_year — Roll company budgets to new academic year bursary:applicant_add_year — Roll applicant records to new academic year bursary:delete_db_logs — Prune request and activity log tablesDocument pipeline. Uploads go directly from the browser to a pre-signed S3 URL (no file passing through the server). Documents are stored in typed S3 folders (attachment, lease, signed contract, id, disability, certificate, acceptance, parent, fee, book, eea1) and served via expiring pre-signed download URLs, keeping sensitive student documents private even when URLs are shared.SFTP + SSH for HR data exchange. Batch files delivered by corporate HR systems to a shared SFTP server are picked up via phpseclib SSH, a remote decryption shell script is executed server-side, and the decrypted CSV is pulled into S3 for processing. This handles corporate security requirements around data-in-transit without requiring client changes to their existing HR export workflows.Dual SAML 2.0 SSO. Separate service-provider entity IDs and Azure AD application registrations are maintained for the admin/operations portal and the student-facing portal, each with environment-specific certificates. SAML assertions are validated server-side; a Sanctum token is issued on success and returned to the frontend via a redirect, keeping tokens out of SAML responses.Structured batch reporting schema. The outbound batch report (used by Nedbank and other clients for Skills Development and B-BBEE reporting) covers a precisely defined 130-column CSV schema (BATCH2_FIELDS), including all approval actors, full semester-by-semester subject results, invoice financials, programme metadata (SAQA ID, accreditation number, NQF level, capability), and budget consumed/balance. The schema is defined as a constant and validated at source, meaning it cannot drift silently.Architecture overview┌─────────────────────────────────────────────────────────────────────┐ │ Corporate Clients │ │ Vodacom · Nedbank · MultiChoice · Adapt IT · AECI · 36ONE │ └───────────────┬─────────────────────┬───────────────────────────────┘ │ Company subdomain │ SFTP (HR batch files) ▼ ▼ ┌───────────────────────────────────────────────────────────────────┐ │ Student Village Platform │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────────────────┐ │ │ │ Student / │ │ Admin / │ │ Operations / │ │ │ │ Applicant │ │ Company │ │ Finance Portal │ │ │ │ Portal │ │ Portal │ │ (SV team) │ │ │ │ (SAML SSO) │ │ (SAML SSO) │ │ (SAML SSO) │ │ │ └──────┬───────┘ └──────┬───────┘ └──────────┬───────────────┘ │ │ │ │ │ │ │ └─────────────────┴─────────────────────┘ │ │ │ │ │ Laravel 12 API (Sanctum) │ │ │ │ │ ┌────────────────────────┼─────────────────────────────────────┐ │ │ │ 17 Bounded Contexts │ │ │ │ Applicant · Company · Bursar · Payment · Report · Auth ··· │ │ │ └────────────────────────┼─────────────────────────────────────┘ │ │ │ │ │ ┌─────────────────┼───────────────────┐ │ │ ▼ ▼ ▼ │ │ MySQL DB AWS S3 Scheduled Jobs │ │ (multi-tenant (documents, (20 Artisan commands) │ │ by company_id) branding) │ │ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ Integrations │ │ │ │ Peach Payments (bank verify + payout) · ClickATell SMS │ │ │ │ AWS SNS (SMS) · Azure AD (SAML) · SFTP (HR + reports) │ │ │ └─────────────────────────────────────────────────────────────┘ │ └───────────────────────────────────────────────────────────────────┘ │ ┌──────────┴──────────┐ ▼ ▼ AWS Lambda SFTP (Bref serverless) (outbound reports to corporates)OutcomesBy the numbers

Metric

Value

Corporate clients on the platform

6 confirmed (Vodacom, Nedbank, MultiChoice, Adapt IT, AECI, 36ONE)

Bounded domain contexts

Distinct user roles

Automated Artisan commands

E-mail template event types

Document types managed per beneficiary

Invoice approval steps

5 (mandatory, with actor + timestamp)

NQF levels supported

0–10

Programme categories (SETA-aligned)

Application form steps

Decline reason categories

11 (bursary) + 16 (invoice)

Batch report output columns

130+

Semester subjects tracked per period

Up to 10 per semester × 3 periods

Before / after

Area

Before

After

Application intake

E-mail submissions, spreadsheet tracking

Structured online form with per-company configuration and SSO login

Approval workflow

Ad-hoc e-mail chains, no deadline enforcement

Mandatory multi-step workflow with automated reminders and auto-rejection

Bank account validation

Manual or absent

Nightly automated verification via Peach Payments

Disbursement

Manual EFT, high reconciliation effort

Scheduled automated payout via Peach Payments with full audit trail

Academic tracking

Spreadsheet or absent

Per-subject semester results with pass/fail/supplementary status

HR data synchronisation

Manual re-keying

Automated nightly SFTP batch import with validation and error reporting

Funder reporting

Manual CSV exports, inconsistent fields

Automated 130-column structured report delivered to corporate SFTP

Branding & templates

Shared generic interface

Per-client logo, banner, e-mail templates, and portal subdomain

Why this project mattersStudent Village is one of the most complete reference implementations of a corporate bursary management system built for the South African market. It demonstrates:

Production-grade multi-tenancy that scales from a single client to many without code changes—each corporate gets an isolated, branded experience.

End-to-end workflow automation covering the full beneficiary lifecycle: application → screening → selection → disbursement → academic monitoring → renewal.

Deep integration with South African operational realities—Peach Payments for local bank verification and EFT disbursement, Azure AD SSO for enterprise identity, and a reporting schema that maps directly to B-BBEE Skills Development and SETA programme category requirements.

Audit-ready compliance architecture—every financial action, approval decision, and document transaction is logged with actor, timestamp, and outcome, making regulatory and internal audit straightforward.

Sophisticated automation that removes the most common points of operational failure: stale applications, missed reminders, failed bank validation, and manual report assembly.

For any corporate running a bursary or CSI programme in South Africa—or any software studio building in this space—Student Village is a strong, production-proven reference.Services demonstrated

Custom SaaS architecture — domain-driven design with 17 bounded contexts, multi-tenant data isolation, and a fully configurable client layer

Systems integration — SAML 2.0 SSO, Peach Payments API, ClickATell/AWS SNS SMS, SFTP data exchange, AWS S3 document management

Workflow automation — 20 scheduled background jobs covering the full operational lifecycle without manual intervention

Compliance-aware design — structured audit logging, bank verification, mandatory multi-step approval chains, and regulatory-grade export schemas

API design — token-authenticated REST API serving three distinct portal types (student, company, operations) with role-based access control at route and API-endpoint level

Serverless deployment — Laravel on AWS Lambda via Bref for cost-efficient, scalable hosting

Enterprise authentication — dual SAML 2.0 service-provider registrations (admin portal and student portal) against Microsoft Azure AD

Get in touchIf your organisation runs a bursary, learnership, or CSI programme and needs a production-grade management platform—or if you are looking for a software studio to design and ship a custom enterprise application—Monthos would be glad to hear from you.Talk to Monthos →Case study prepared for Monthos.com · Project: Student Village Bursary Management SystemMonthos Group — Cheltondale, Johannesburg, SA. Email info@monthos.com, phone +27 (68) 750 7313.Case studies · Privacy Policy · Terms of Service