In private schools, collections usually run on spreadsheets and messaging groups. Here the prospectus site, a parent payment portal with virtual POS, and bulk SMS were built together — so payment, tracking and notification meet on the same record.
Three parts: a static prospectus site aimed at the enrolment season, a Dockerised payment portal where parents pay tuition by card or bank transfer, and a bulk SMS panel bound to the student directory. Two bank virtual POS integrations went live (Vakıfbank and Garanti), and an approve/reject flow was added so school administration can process transfer notifications. The system runs with 285 students and 353 parents on record.
Private-school searches are strongly seasonal and strongly local. Parents search for things like "private school in Tekirdağ" or "kindergarten in Süleymanpaşa", and outside enrolment season those searches nearly stop. The site was built around that behaviour: campus, the stages (kindergarten, primary, middle, high school) and the pre-registration flow are foregrounded.
The site is produced as static HTML from a generator script. The reason is the typical lifecycle of a school site: content changes a few times a year, but the site takes heavy traffic during enrolment and must never be left unmaintained. A static site cannot be compromised through an outdated plugin, cannot suffer a database failure, and does not struggle under traffic.
The site is served behind Cloudflare, so cache purging is part of the content-update process. IndexNow notification is part of the setup as well.
One of the most-skipped and most critical steps in this project: a bank virtual POS application requires specific legal pages to already exist on the site.
Without a distance sales agreement, a privacy policy, cancellation and refund terms, delivery/service information, contact details and a data-protection notice, the application does not progress. These pages are not a formality added later; they are a precondition of the payment infrastructure. So six legal pages were prepared while the prospectus site was still being published.
The practical takeaway for any business planning to take payments: publish your legal pages before the POS application, not after. Otherwise the technical work finishes and the system sits waiting.
The portal is a separate application from the prospectus site, running on Docker:
Two banks are live on the POS side: Vakıfbank and Garanti. Running both is not only redundancy — it also gives instalment and commission flexibility, since promotional instalment options differ by bank.
A significant share of school payments in Turkey still arrives by bank transfer. That is harder for a system than a card payment: the money reaches the bank, but the system does not know about it.
So the portal gained a transfer declaration and administrator approve/reject flow. After transferring, a parent creates a notification; administration compares it against the bank account and approves or rejects. An approved notification posts to the instalment.
When this feature shipped, more than twenty notifications had already piled up waiting to be processed — the need was not hypothetical, there was real work stuck in the system. Notifications are emailed to multiple recipients so the process does not block on the day one person is away or busy.
Most school communication runs over SMS: payment reminders, announcements, urgent notices. A bulk SMS panel was built on the NetGSM REST API and bound to the student directory.
The key design decision was to feed the SMS panel from the same data as the payment system's student records, not a separate address book. Two lists inevitably drift: a parent whose number changes gets updated in one and not the other. With a single source, the payment reminder reaches the right person.
The system runs 285 student records against 341 phone numbers — naturally different figures, since a student can have more than one reachable parent.
The payment portal lives on its own subdomain, which surfaced a detail worth knowing: Cloudflare's free Universal SSL certificate covers only first-level subdomains. So payments.domain.com is covered; www.payments.domain.com is not.
Because parents habitually type "www", this was a real source of failure: a parent trying to reach the payment page saw a certificate warning. The fix was a server-side certificate covering the second-level name too, plus a permanent redirect from the www address. The renewal chain was verified separately after the change — a certificate that works once is a certificate that breaks the day it fails to renew.
The school now runs collection, instalment tracking and parent notification from one system. Card payments settle instantly through two bank POS integrations, transfer declarations are recorded with administrator approval, and reminders go out by SMS from the same student data.
The transferable lesson: in a school payment system the riskiest part is not code but sequence. Legal pages must exist before the POS application, the SMS directory must be fed from payment data, and certificate coverage must be tested against the payment subdomain's full address. Skip those three and the system is technically "finished" but practically unusable.
The process is more paperwork than engineering. The bank requires a distance sales agreement, privacy policy, cancellation and refund terms, delivery/service information, contact details and a data-protection notice to be live on your site. Without those pages the application stalls. Technical integration is usually the shorter part, once approval comes through.
You can solve it without automated bank reconciliation: the parent files a transfer declaration in the system, and administration compares it with the bank statement and approves or rejects it. Approved declarations post to the instalment. Emailing the notification to several administrators keeps the process from depending on one person.
You could, but then you keep two student lists and they will drift apart. A parent whose number changes gets updated in one and not the other, and the payment reminder goes to the wrong person. The correct setup has the SMS panel read the payment system's student records directly.
They have different risk and maintenance profiles. The prospectus site is a public, frequently read, rarely changed surface; the payment portal is a closed application handling personal data and money. Kept separate, a change to the site cannot endanger payments, and a portal update cannot take the site down.