HostelEase Documentation
Everything you need to run hostel management for your institution - capacity, allocations, payments, bursary codes, branding and support. Written for tenants, staff and students of the HostelEase platform by SSM Limited.
What is HostelEase?
HostelEase is a multi-tenant hostel management platform by SSM Limited - one system for capacity, allocations, payments and student support.
HostelEase is a multi-tenant hostel management platform developed and owned by SSM Limited. It gives universities, polytechnics, colleges of education and private hostel operators one system for everything that used to live in spreadsheets and paper registers: modelling hostel capacity, allocating beds to students, collecting fees online, issuing bursary codes, checking students in with QR codes and supporting students after they move in.
Every institution runs on its own isolated tenant with its own subdomain (for example buk.ssm.com.ng), its own staff accounts, its own branding and its own payment configuration. Tenant data is scoped at the database level, so institutions never see each other’s records.
Key capabilities at a glance
- Hostel structure modelling - blocks, rooms and beds with gender types (male, female, mixed) and per-bed status: available, occupied, maintenance or locked.
- Applications and allocations - students apply online and pick a room and bed; admins allocate manually, in batch, or straight from an approved application.
- Online payments - Paystack, Flutterwave, OPay, Remita, Kora and Zainpay gateways, plus a debit/credit-card method powered by Flutterwave and bursary (authorization) codes.
- Own Payment Account (BYOK) - institutions on Growth or above plug in their own provider accounts so student fees settle directly to the institution’s bank account.
- Bursary codes - issue fee-waiver or payment-authorization codes that students redeem at checkout.
- QR check-in - every allocation carries a QR code; staff scan it at the gate and anyone can verify an allocation on the public
/qr-verifypage. - Support - an AI-first in-app chat that escalates to a human agent, maintenance tickets for room issues and a staffed support-ticket queue.
- Reports and audit - occupancy, payment and application reports with export, plus a full audit log of sensitive actions.
Where everything lives
| Surface | Address | What it is for |
|---|---|---|
| Marketing site | https://ssm.com.ng | Product tour, pricing, and contacting SSM Limited. |
| Institution portal | your-school.ssm.com.ng | The tenant’s own HostelEase workspace: student portal, admin dashboard, bursary office, moderator tools and public pages. |
This documentation site (doc.ssm.com.ng) and the status page (status.ssm.com.ng) complete the picture: docs tell you how the product works and the status page shows platform health at a glance.
Where should you start?
New institution? Read First steps for an institution. Staff member? Jump to Roles and permissions. Setting up payments? Go straight to Own Payment Account.
First steps for an institution
From sign-up to the first allocated student: tenant creation, subdomain, sessions, hostel structure, fees, staff and go-live.
This section walks a brand-new tenant from sign-up to the first checked-in student. Each step links to the section of these docs that covers it in depth.
Create your tenant
Visit ssm.com.ng and choose a plan. You create the first super admin account for your institution - this is the owner login that can do everything inside your tenant.
Claim a subdomain
From your portal, submit a subdomain request with the prefix you want (for example
buk). The platform team reviews it, and once approved your portal is reachable atbuk.ssm.com.ng. See Tenants and subdomains.Create an academic session
Applications, allocations and payments are tied to the active academic session. Create it (and set it active) before anything else - students cannot apply until a session exists.
Model your hostels
Open Hostel Management → Hostel Structure and build your capacity: blocks (with a gender type: male, female or mixed), then rooms, then beds. The same screen marks beds for maintenance or locks them. Aim for bed-level accuracy - allocations, the warden map and the public availability pages all read this structure.
Set your fees
Configure room pricing (by room type / bed count) in payment settings so students see the correct fee when they reach checkout. Fees are per-room and apply to every bed in that room.
Add staff
Open Access Control → Users and create accounts for admins, bursary officers, moderators and support reps. Fine-tune exactly what each role can do in Role Permissions - see Roles and permissions.
Go live
Announce the portal to students with Announcements, let them apply and pick beds, and watch allocations land on the Warden Map. Publish your public availability pages (
/roomsand/availability) so students can check capacity before signing in.
Tenants and subdomains
What a tenant is, how subdomains like buk.ssm.com.ng work, the request/approval flow and custom domains.
A tenant is one institution’s isolated workspace: its users, students, hostels, allocations, payments, branding and settings. Two tenants on the same platform share nothing - even the database queries are tenant-scoped, and staff accounts only ever see their own institution’s data.
How subdomains work
Each tenant is addressed through a subdomain of the main platform domain - buk.ssm.com.ng, unizik.ssm.com.ng and so on. The subdomain decides which tenant’s branding, portal and public pages you see. When you sign up you get an initial address automatically; you can request a friendlier one at any time.
Signing in is the same everywhere: open your subdomain and use the sign-in form. Students, staff and the public pages all live under the same subdomain - the student portal, the admin dashboard, /rooms, /availability and /qr-verify.
Requesting a subdomain
Open the tenant portal area
Sign in to your tenant and open the portal/subdomain settings view.
Choose a prefix
Between 3 and 20 characters, lowercase letters and numbers only. The prefix must not already be in use by another tenant or pending another tenant’s request.
Submit the request
The request is created as PENDING and is reviewed by the platform team. You can cancel it while it is pending, and each tenant can only have one pending request at a time.
Approval
Once the platform team approves it, your tenant is switched to the new subdomain. Sign-in, emails, receipts and public pages immediately start using the new address.
Custom domains (Enterprise)
Enterprise tenants can serve their portal from their own domain, for example hostels.your-university.edu.ng. Because that involves DNS changes and certificate issuance, custom domains are set up together with the SSM Limited team - reach out via the support channels to plan the cutover.
Roles and permissions
The seven built-in roles, the granular manage/view permission flags, and custom roles on Growth and above.
Every user on HostelEase has exactly one role, and the role decides which parts of the portal they can reach. There are seven built-in roles; on Growth and above you can also create custom roles with their own permission sets.
| Role | Who it is for and what they can do |
|---|---|
| SUPER_ADMIN | The tenant owner (the first account created at sign-up). Full access to every module: billing and plan, Own Payment Account, branding, settings, users, payments, reports - everything. Super admins are never restricted by permission flags. |
| ADMIN | Day-to-day administrators: allocations, applications, students, payments, announcements, reports. Exactly what an admin sees is tunable by the super admin through role-permission flags. |
| BURSARY | The finance office. Payments, bursary codes and requests, approved payment evidence, QR check-in scanning and settlement reconciliation. |
| FINANCE | A focused finance desk: bursary requests and approved evidence, with read access to allocations and reports. |
| MODERATOR | Verifies student profiles, works maintenance tickets and monitors the student inbox. |
| SUPPORT_REP | Front-line support: the support-ticket queue, live-chat takeover and notifications. |
| STUDENT | The student portal: apply for a bed, pay, view allocation and receipts, request reallocation, open maintenance tickets and chat with support. |
Role permission flags
For the staff roles (ADMIN, BURSARY, MODERATOR, SUPPORT_REP and FINANCE), the super admin can grant or revoke individual capabilities in Access Control → Role Permissions - for example canManagePayments, canManageBursaryCodes, canScanQrCode, canViewAuditLogs, canHandleSupportChat and dozens more.
Permissions come in pairs: a manage flag (create, edit and act) and a view flag (read-only access). That means you can give an internal auditor read-only visibility of payments without the ability to verify or edit anything. Changes apply immediately - no re-login needed.
SUPER_ADMIN is always full-access and is not governed by the flags table.
Custom roles (Growth and above)
On Growth and Enterprise plans, Access Control → Role Definitions lets you create custom roles such as "Hall Warden" or "Finance Officer" - with their own label, colour, authority rank and permission set. Custom roles appear in the user-creation dropdown alongside the built-ins, and inactive ones can be hidden without deleting them.
Plans and billing
Starter, Growth and Enterprise - pricing, what each plan gates, upgrading, invoices, checkout methods and what happens at expiry.
HostelEase is subscription software. Plans are per tenant (per institution), billed in Naira, and they set both limits (students, staff, gateways) and features (bulk import, analytics, custom branding, BYOK and more). The platform team can also adjust prices and limits for individual tenants.
Longer billing cycles are discounted: quarterly, biannual and yearly subscriptions cost less per month than paying month-to-month - the exact saving for each cycle is shown with the live prices above. Enterprise is custom-priced; contact the platform team for a quote.
What each plan gates
- Starter - full hostel management, applications and sessions, bursary codes and bursary requests, announcements, reports and export, audit logs and email logs. One payment gateway, 25 bed reallocations per month, up to 5 staff.
- Growth - everything in Starter plus: 5 payment gateways and unlimited reallocations, bulk import (CSV), custom roles, the AI assistant, analytics and system-health dashboards, audit export, maintenance tickets, live support chat, student feedback, custom branding (logo + colour), the public room-availability pages, priority support and Own Payment Account (BYOK).
- Enterprise - everything in Growth, unlimited, plus white-label branding, a custom domain, the enterprise overview dashboard, dedicated infrastructure, SLA guarantees and 24/7 priority support.
Three plan-gated features worth knowing
roomAvailability (public /rooms + /availability pages) and brandColor (custom branding) unlock on Growth, and byokGateways (own payment account) is Growth and above. Enterprise adds white-label and custom domains.
Upgrading, invoices and billing
Pick a plan
From your dashboard open Plans and Pricing (or follow an upgrade prompt when you hit a plan limit). Choose the plan and billing cycle.
Check out
Billing checkout supports Paystack, Flutterwave and Remita, plus a card method powered by Flutterwave. Enter your billing details (name, email, phone, address) and pay - you are redirected to the gateway’s secure hosted page and back again.
Manage billing
The billing area shows your current plan, period end, usage and invoice history with downloadable PDF invoices. Keep the billing email current - renewal reminders go there.
What happens at plan expiry
HostelEase issues your renewal invoice 7 days before the due date (the start of the next cycle) and emails a reminder. If the invoice is still unpaid on the due date, a 3-day grace period follows - the portal stays fully online. If it is still unpaid when the grace window ends, the tenant is automatically suspended by the daily billing job and the subdomain falls back to the platform's default page. Settling the invoice restores service within minutes - and your billing cycle is never shifted by a late payment (a cycle that ends 8 Nov still ends 8 Nov even if you pay on the 20th). See the Billing Policy for the full terms.
Suspension hides the portal but keeps every byte of data. Students, allocations, payments and settings are all intact when you renew - and there is no reactivation fee.
Security
Two-factor authentication, device verification, password policies, audit logs and tenant data isolation.
HostelEase treats hostel records, fee payments and student identity documents as sensitive data. These are the protections in place for every tenant - no configuration required.
Two-factor authentication (2FA)
Any account - student or staff - can enable TOTP two-factor authentication from Profile → Password and Security. Scan the QR code with any authenticator app (Google Authenticator, Authy, 1Password and friends), confirm one code, and save the generated backup codes somewhere safe. After that, sign-in asks for a 6-digit code in addition to the password.
Device verification
Staff sign-ins from a new browser trigger device verification: the account is asked to confirm the new device before it is marked trusted. Trusted devices are remembered per browser fingerprint, and the security page lists the devices seen on your account so unusual activity is easy to spot.
Password policies
Staff roles (admin, super admin, bursary, moderator, support, finance) require a strong password: 12+ characters with upper case, lower case, a number and a special character. Student accounts use the standard 8-character policy. Password changes and resets are audited.
Audit logs
Sensitive actions - allocations and vacation, payment verification, bursary-code issuance, settings and role changes, student edits - are recorded in the audit log with the actor, timestamp and request context. Admins can filter by entity, action and actor; audit export to CSV is available on Growth and above.
Data isolation
Every query is tenant-scoped at the database layer (row-level tenant injection), so one institution can never read another’s rows even if a bug slipped through the application layer. Payment keys saved in Own Payment Account are encrypted at rest with AES-256-GCM, and webhook payloads are signature-verified before any payment is marked paid.
Platform-wide security posture (rate limiting, brute-force protection and session handling) is managed by the platform team.
Student portal guide
Applying for a bed, the bed hold and invoice model, paying and downloading receipts, reallocation, profile verification, notifications, maintenance tickets and the support chat.
Students sign in at the institution’s subdomain. The student portal covers the full journey: apply, pay, get allocated, move in, get support. This guide walks each step the way a student experiences it.
Applying for a bed
Open Apply for Hostel
From the dashboard, open Apply for Hostel. The active academic session is shown; applications only run against an active session.
Browse rooms
The bed picker shows blocks and rooms with live availability, room type and the fee for each room. Filter by block or search to narrow things down. Blocks can be male-only, female-only or mixed - you only see the ones you are eligible for.
Pick a bed and confirm
Choose a free bed, confirm, and the application is submitted. Depending on your institution’s settings it is either confirmed straight away or queued for an admin to review.
Pay before the hold expires
Confirming a bed creates a pending allocation with an invoice and holds the bed for you - see the next section. Complete payment within the hold window and the bed is yours.
The bed hold (invoice model)
When a student confirms a bed, HostelEase creates an invoice and locks that bed for a configurable window (institutions typically set 48 hours - your bursary/admin sets the exact duration). Pay inside the window and the allocation activates and the invoice settles. Let the window lapse and the bed is automatically released back to the pool and the pending allocation lapses.
You can leave and come back: the Payments view keeps your pending invoice with a resume-checkout button and a countdown of the remaining hold time.
Paying and receipts
From Payments, open the pending invoice and you are taken to a secure checkout page. Choose how to pay:
- Any gateway your institution enabled - Paystack, Flutterwave, OPay, Remita, Kora or Zainpay - as a gateway checkout.
- The card method: an inline card form powered by Flutterwave, with the accepted card schemes (Visa, Mastercard, Verve and others) shown on the tile.
- A bursary code, if the bursary issued you one - enter the code and the invoice settles against it.
After paying you land on a confirmation screen and can download a stamped PDF receipt. Every payment - gateway or bursary - appears in the payment history with its reference, status and receipt. Failed or abandoned payments can be retried from the same place.
Allocation, reallocation and history
My Allocation shows your block, room and bed, plus the session and your allocation QR code. If you want a different bed, submit a reallocation request: institutions choose whether reallocations always need admin approval, never need approval, or are auto-approved up to a set number of requests per student. The allocation-history view lists every bed you have held across sessions.
Profile and verification
Your profile carries your photo, contact details, next-of-kin and (if required) identity documents. A complete profile speeds up verification: moderators review profiles in the Verifications queue, and some institutions require verification before allocation. You can track your verification status on the profile page.
Notifications and announcements
Announcements from your institution (application windows, deadlines, maintenance notices) arrive in the notifications view and - where email is enabled - in your inbox. Unread counts appear in the top bar.
Maintenance tickets
Something broken in the room? Open Maintenance, describe the issue, pick a category and attach a photo. The ticket flows to the moderators, and you can follow its status from open to in-progress to resolved.
Support chat
The in-app support chat answers instantly, around the clock: an AI assistant handles common questions, and if it cannot resolve the issue the conversation is escalated to a human agent. You get a transcript of every conversation and can rate the resolution.
The allocation QR code
Your allocation card (PDF) includes a QR code that encodes a verification URL. Hall staff scan it at check-in, and anyone - including you - can confirm an allocation is genuine by opening /qr-verify on the institution’s domain and scanning or entering the code.
Admin dashboard guide
Overview stats, hostel structure, the warden map, allocations and applications, student management, bulk import, faculties, announcements and reports.
The admin dashboard is where a tenant’s staff run day-to-day operations. Exactly which modules each staff member sees depends on their role and the permission flags the super admin granted - see Roles and permissions.
Overview
The dashboard opens with live stats - occupancy, beds available, applications pending, payments collected - plus block-level occupancy bars, a payment breakdown, recent activity and quick actions. It is the single screen to answer "how are we doing today?".
Hostel structure
Hostel Management → Hostel Structure is a tree editor for your capacity: Block → Room → Bed. Create blocks with a code (A, B, C…), name, gender type (MALE, FEMALE or MIXED) and floor count; add rooms with numbers and floors; add beds individually or as bunks (top/bottom/single). Every level shows live occupancy, and beds can be marked for maintenance, locked, edited or deleted (occupied beds cannot be deleted - vacate them first).
Mixed-gender blocks matter: the public /rooms page shows Male Hostel, Female Hostel and Mixed Hostel cards, and a mixed block would be invisible if gender types were not set correctly. Always set the gender type when creating a block.
The warden map
The Warden Map renders every block as a colour-coded grid of beds - available, occupied, locked or maintenance, each instantly readable. Click a bed to open its detail sheet: occupant details (with gender-mismatch warnings), bed notes and actions - allocate a student, check in, check out, vacate, mark maintenance or lock. It is the fastest way to answer hall-warden questions like "which beds are free on floor 2?".
Allocations
- Manual allocate - search a student by name or registration number, pick a bed (gender mismatches are flagged), allocate, then check in when they arrive.
- Batch allocate - auto-fill applications into free beds in one run; review the result before committing.
- From applications - approve an application and allocate a bed in the same action.
- Reallocation - handle student requests to move beds; approval can be required always, never, or only after a student’s Nth request.
- Check-in / check-out / vacate - individually from the bed sheet or in bulk from the allocations table.
Applications
The applications queue lists every student application for the active session with status and review actions: approve (optionally allocating a bed immediately), reject with a reason, or bulk-approve. Filters by status, session and room type keep the queue navigable during rush periods.
Students
The students area covers the whole student lifecycle: the All Students table (filter by faculty, department, session, verification and allocation status), Add Student for one-off creation, Bulk Import for CSV (Growth and above - upload or paste, validate a preview first, then import; a template download is built in), Faculties and Departments management, and Deleted Students (super admin, for recoverable mistakes).
Announcements and notifications
Broadcast announcements to students or specific roles - they appear in the in-app notifications view and, where email is enabled, in student inboxes. The email log shows every message sent, with delivery status, so you can prove the deadline reminder actually went out.
Reports
The reports centre covers occupancy, payments and applications, with filters by session and date range and CSV export. Growth plans add the analytics dashboard (trends and charts), system-health monitoring and audit export.
Payments overview
How money moves on HostelEase: the invoice model, checkout methods, webhooks, the Payment Webhooks console for manual verification and reconciliation.
Fees move through one of two rails. On platform gateways, student payments are charged through the platform’s shared provider accounts and reconciled to the institution. On Own Payment Account (BYOK) - Growth and above - the institution plugs in its own provider accounts and fees settle directly to the institution’s bank account. Students see the same checkout either way; what changes is whose provider account charges the card.
The invoice model
Every fee charge is an invoice with a unique payment reference. When a student confirms a bed, the invoice is created, the bed is held for the configured window, and payment settles the invoice and activates the allocation. The same reference powers receipts, webhook deduplication and verify-API reconciliation, so it is the single source of truth for a payment.
Methods available at checkout
| Method | What it is |
|---|---|
| Paystack | Nigerian gateway - cards, bank transfer and USSD. |
| Flutterwave | Pan-African gateway - inline card payments with OTP. |
| OPay | OPay merchant checkout - cards and wallet. |
| Remita | Nigerian government and education payments (RRR-based). |
| Kora | Pan-African payments - cards and bank transfer. |
| Zainpay | Card and bank transfer via zainbox. |
| Card | An inline debit/credit card form powered by Flutterwave, with the accepted schemes shown on the tile. |
| Bursary code | Redeem a code the bursary issued - see Bursary codes. |
Which of these a student actually sees depends on what the institution (or, without BYOK, the platform) has enabled and configured. Test-mode gateways are clearly labelled so nobody pays real money by accident.
Webhooks and callbacks
Payments confirm automatically when the provider calls your webhook URL - every gateway card in the dashboard shows the exact URL (and the browser callback URL) with copy buttons. Register the webhook in the provider’s dashboard once, and every charge, success or failure, is recorded and applied without manual work.
The Payment Webhooks console
Finance → Payment Webhooks is the page that keeps payments confirmed. It shows, per provider: configuration state (platform or own keys, test or live), the webhook and callback URLs to paste, pending payments with a per-payment Verify button (which calls the provider’s verify API through the account that charged), a Verify all pending bulk action, and a live feed of received webhook events with signature and applied state. Use it whenever a provider’s webhook is late or was never registered.
Reconciliation
For the bursary, Reconciliation (Growth and above) pulls settlement reports and cross-checks them against the payment ledger, so the amount in the bank matches the amount in HostelEase - with an audit trail for every discrepancy investigation.
Own Payment Account (BYOK)
Bring Your Own Keys: charge student fees through your own Paystack, Flutterwave, OPay, Remita, Kora or Zainpay account with direct settlement to your bank.
BYOK - Bring Your Own Keys - lets a Growth or Enterprise institution plug in its own payment-provider accounts, so student fees are charged by the institution’s own Paystack/Flutterwave/OPay/Remita/Kora/Zainpay account and settle directly to the institution’s bank account. Keys are encrypted at rest with AES-256-GCM and never leave the tenant. Configure it in Settings → Own Payment Account (super admin only).
Platform keys vs own keys
Without BYOK, payments are charged through the platform’s centralized gateway accounts and reconciled to you. With BYOK the gateway switches to your account - your settlement, your provider dashboard reporting.
General setup (every provider)
Open Own Payment Account
Sign in as the tenant super admin and open Settings → Own Payment Account. Every provider card shows the integration URLs you will need in a moment.
Gather your keys from the provider
Log in to your provider’s dashboard and copy the credentials for the provider you are connecting (exact keys per provider below). Live keys for production, test keys for a dry run.
Paste and save
Paste the keys into the provider’s card and save. The gateway immediately switches to your account. You can store separate TEST and LIVE sets and switch between them later without re-pasting.
Register the webhook and callback URLs
On every provider card, copy the Webhook and Callback URLs and paste them into the corresponding field in your provider’s dashboard. Payments only confirm automatically once the webhook is registered.
Set the webhook secret (where supported)
If the provider supports a webhook secret or hash, set the same value on both sides - the card’s field and the provider’s dashboard - so signatures verify.
Test, then switch to live
Use the built-in Test action (it probes the provider with your stored keys - read-only, never a charge) and run a small test-mode payment. When you are satisfied, switch the active key set to LIVE.
Webhook https://buk.ssm.com.ng/api/payments/webhook?provider=PAYSTACK
Callback https://buk.ssm.com.ng/payment/callback
# Each provider has its own webhook URL - the provider code at the end changes:
https://buk.ssm.com.ng/api/payments/webhook?provider=FLUTTERWAVE
https://buk.ssm.com.ng/api/payments/webhook?provider=OPAY
https://buk.ssm.com.ng/api/payments/webhook?provider=REMITA
https://buk.ssm.com.ng/api/payments/webhook?provider=KORA
https://buk.ssm.com.ng/api/payments/webhook?provider=ZAINPAYThe URLs are tenant-scoped
The webhook and callback URLs always carry your subdomain as the origin. Do not paste the platform’s webhook URL - that is a different integration with a different claim on the event. Always copy from your own dashboard’s provider card.
Per-provider setup guides
Every provider follows the same pattern - get keys from the provider, paste them into the card, register the webhook. These are the exact fields each provider asks for and where to find them.
Paystack
- Keys: Public key (
pk_live_…/pk_test_…), Secret key (sk_live_…/sk_test_…), optional webhook secret. - Where: Paystack Dashboard → Settings → API Keys and Webhooks.
- Webhook: paste the card’s webhook URL on the same settings page, and use your own secret key as the signing key if you do not set a dedicated secret.
Flutterwave
- Keys: Public key (
FLWPUBK-…), Secret key (FLWSECK-…), Encryption key (used for inline card charges), optional webhook secret hash. - Where: Flutterwave Dashboard → Settings → API keys for the keys, and Settings → Webhooks for the webhook URL and secret hash.
- The card method at checkout (inline card form) also runs on your Flutterwave credentials once connected.
OPay
- Keys: Merchant ID, Public key, Secret key.
- Where: OPay Merchant Dashboard - your merchant profile for the ID and keys.
- Webhook: OPay Merchant Dashboard → Webhooks - paste the card’s webhook URL.
Remita
- Keys: Service type ID (from your service/biller profile - required for charges), Merchant ID, API key, optional webhook secret.
- Where: Remita Dashboard - your biller profile for the service type ID and merchant ID; Profile → Webhooks for the webhook.
- Remita suits institutions already on RRR-based payment rails.
Kora
- Keys: Public key (
pk_…), Secret key (sk_…), optional webhook secret. - Where: Kora Dashboard → Settings for the keys and Settings → Webhooks for the URL.
Zainpay
- Keys: Public key (
zp_…), Secret key (zs_…), optional webhook secret. - Where: Zainpay Dashboard → Settings for the keys and Settings → Webhooks for the URL.
Disconnect vs wipe
| Action | What it does |
|---|---|
| Disconnect | Switches the gateway back to the platform’s keys but keeps your stored (encrypted) keys, so you can re-enable with one click later. |
| Wipe | Switches back to the platform’s keys and deletes your stored keys entirely. Use this when rotating credentials or leaving BYOK. |
Test and live key sets
Each provider card stores a TEST and a LIVE key set. Saving test keys and running a small test charge lets you rehearse the flow end-to-end (the checkout clearly labels test mode - no real money moves). Switch mode flips the active set without re-pasting anything, and the gateway’s test/live badge follows the active set.
Bursary codes
Fee-waiver and payment-authorization codes: issuing, redeeming at checkout, student requests with evidence upload and the approved-evidence view.
A bursary code is a fee waiver or payment authorization the bursary issues to a specific student - for scholarships, sponsorships, government-covered fees or any case where the institution settles (or forgives) a student’s hostel fee. The student redeems the code at checkout and the invoice settles against it; the code is then consumed and recorded.
Issuing a code
Open Bursary Codes
Bursary officers open Bursary → Bursary Codes (permission
canManageBursaryCodes).Issue code
Select the student, set the code’s value or policy, and issue it. Codes can be re-issued if a student loses one, and revoked if issued in error.
Student redeems
The student opens their pending invoice at checkout, chooses the bursary / authorization code option, enters the code, and the invoice settles. The code appears in the student’s payment history alongside regular payments.
Requests and evidence
Students who believe they qualify for a bursary code can request one and upload payment evidence - bank transfer receipts and similar proof. Requests land in the Bursary Requests queue (super admins and finance), each with the student’s details and attached evidence for review before a code is issued. Once evidence is approved it moves to the Approved Evidence view for the record.
Bursary codes are authorizations, not payment records: they appear in the student’s history and in reports, but reconciliation treats them separately from gateway payments.
Branding
Institution logo, favicon, name and tagline, the plan-gated brand colour, and how subdomain theming works.
The Branding manager (Settings → Branding) controls how your portal looks: the institution logo (used across the portal, receipts and emails), the favicon and PWA icon, the institution name and code, the tagline and the primary colour.
What the brand colour affects
The primary colour repaints the tenant’s surfaces - staff and student dashboards, buttons, public pages and the checkout - with a contrast-safe foreground computed automatically for legibility. Upload a logo with a transparent background for the best result.
Plan gating
Custom branding (the brand colour in particular) is a Growth and above feature. On the Starter plan, dashboards render in the platform’s signature black-and-white theme regardless of saved branding - the portal stays fully functional, just uniformly styled. The logo and name still apply where the platform allows.
How subdomain theming works
Branding is resolved per subdomain: when someone opens buk.ssm.com.ng, the tenant’s saved branding (logo, name, colour) is injected into that visit. The same person opening a different tenant’s subdomain sees that tenant’s branding instead. Public pages (/rooms, /availability, /qr-verify, checkout) carry the tenant’s brand too, so students always feel they are paying their own institution.
Checkout provider logos are platform-level
The logos shown for gateways and card schemes (Visa, Mastercard, Verve…) at checkout are curated by the platform team.
Support
The AI-first in-app support chat with human escalation, support tickets, maintenance tickets and the status page.
Support on HostelEase is layered so that most questions never need a human, and the ones that do reach one quickly.
In-app support chat
The support widget is available in the portal (where the institution has the chat widget enabled). It is AI-first: an assistant answers immediately, any time of day, on questions from fees and applications to account help. When the assistant cannot resolve the issue, the conversation is escalated to a human agent - the session shows its state (with AI, in queue, with an agent) and, once resolved, asks for a quick rating. Every transcript is downloadable.
The same widget serves staff: tenant administrators chat with the HostelEase team, while student chats route to the institution’s support desk. Staff with the canHandleSupportChat permission can take over student sessions from the Live Support view.
Support tickets
For structured, trackable issues there is a support-ticket queue (Support view) with statuses, assignment and history - used for everything from data corrections to access problems.
Maintenance tickets
Room issues reported by students flow to the moderators’ maintenance queue (Growth and above) - category, description, photo - and progress from open to in-progress to resolved with the student kept in the loop.
Status page
Platform health - uptime and incidents - is published at `status.ssm.com.ng`. Check it first when something looks off platform-wide; the docs and the status page are the two public sources of truth.
Frequently asked questions
Real answers to real questions, written from how HostelEase actually behaves - payments, gateways, subdomains, plans and day-to-day operations.
These are the questions support actually receives. If something is missing, use the search bar above or read the support section.