A platform for online schools and teachers, built around a transparent payment-management system.
A managed monetization platform for courses and lessons, built in a white-label model: each teacher or school sells learning products under its own brand, while the platform centrally handles payments, access rights, invoices, and communications. The user journey runs through purchase, access activation, and learning, while the school owner manages plans, add-ons, and access rules through the interface. The service was designed so monetization is part of the product's domain logic — not a stack of disconnected payment settings.
Laura is a former English-school teacher who has spent a long time working on a solution for teachers, tutors, experts, and educational projects. She understands how lessons and courses are sold, when payment issues show up, and why students drop out. Laura doesn't have a technical background, so she came to us with a clear view of the real problems and a list of scenarios that had to work reliably. Her main requirement was simple: the product had to be usable by people with no technical experience.
Multi-tenancy
One shared core, but every school runs under its own domain and brand. Pricing plans, invoices, emails, taxes, currencies, and access rules had to be isolated so a mistake in one tenant couldn't reach the others.
One access model
The product had to support one-time purchases, subscriptions, durations, limits, remaining time, and add-ons at the same time — all reduced to one entitlement model.
Remaining-time transfers
Moving unused time from one product to another carries a long tail of edge cases. The transfer had to be fair, reproducible, and resistant to conflicts.
Add-ons
Toggling add-ons on and off had to play correctly with the next payment date, plan compatibility, disabling, pausing, overdue states, and rollback after failed payments. The UX had to stay simple anyway.
Wallet and balance with ledger logic
A balance as prepaid credit adds risk. The platform needed a ledger model where every cent has a reason, a status, and a history — so disputes can actually be resolved.
Invoices and emails
A white-label product requires documents and communications to stay financially and legally consistent. They had to support renewal, failed payment, cancellation, transfer — and never drift from the actual billing state.
We designed the product as a white-label SaaS where billing and learning access merge into one domain mechanic: plans → payments → entitlements → content restriction → add-ons → cancel / transfer → invoices / emails. Instead of a pile of settings, we built a coherent system with states, dates, charge reasons, and an event audit trail.
Multi-tenancy and white-label
We implemented a tenant model with separate domains, branding, currencies, taxes, pricing plans, invoices, and email templates at the school level. Licensing and installation registration go in as the control point for connecting a new tenant and as the anchor for the white-label environment.
Pricing-plan builder for one-time purchases and subscriptions
A Pricing Plan builder covers purchase type, price, billing period, access duration, usage limits, and package naming. Changes go through configuration, not code — pricing experiments don't create monetization risk.
Content access
A single source of truth for access. Every purchase, subscription, or add-on creates an entitlement with an expiration date, limits, and a relation to a specific course, module, or lesson. Content restriction works as an entitlement check, which closes the two critical failure modes systematically: "paid but no access" and "unpaid but access still active."
Wallet and balance as a ledger
A balance model with top-up and a ledger history — every charge has a reason, a link to the related plan or add-on, and a status. The balance covers recurring payments and smaller add-on charges, and the ledger makes every cent explainable.
Add-ons as a managed product with explicit states
An add-ons engine with a catalog of add-on features, compatibility rules, on/off states, next-charge date logic, and failed-payment handling. The UI toggle changes state only through validated transitions — activated, pending charge, overdue, disabled, rolled back after an error.
Cancel and Transfer Remaining Time as reproducible domain operations
Two scenarios: cancellation without refund, and transfer of remaining time to another course or product. Transfer runs through checks and atomic operations, so it never creates duplicate access, breaks limits, or mishandles partial periods, upgrades, downgrades, or add-ons.
Invoices and emails
Invoice generation and a white-label notification system, scoped to the school context — tenant-specific details, numbering, billing periods, service description, currency. Email triggers wire into billing events (successful payment, failed payment, renewal, cancellation, transfer), so communication never drifts from the system's actual state.
We started by breaking the specification into modules — plans, billing, wallet, access, add-ons, cancel, licensing, invoices. From there we defined the key states and transitions, together with the list of edge cases that most often break monetization in production.
+4 Resource
The platform turned online-learning monetization into a managed white-label product where payment rules and access rights are reproducible, and users see states and dates without needing a support explanation.
support requests about payments and access
time spent on manual financial reconciliation and payment tracking
at the cancellation point, thanks to the Transfer Remaining Time flow
through the configuration-driven pricing builder
a new school onboards without a separate product branch
Or send us a message and we'll get back to you within 15 minutes during business hours