В частных школах сбор оплаты обычно живёт в таблицах и мессенджерах. Здесь сайт приёмной кампании, родительский кабинет с виртуальным POS и массовые SMS построены вместе — оплата, учёт и уведомления сошлись на одной записи.
Три части: статический сайт под приёмную кампанию, платёжный кабинет на Docker, где родители оплачивают обучение картой или банковским переводом, и панель массовых SMS, привязанная к справочнику учеников. На стороне оплаты подключены два банковских виртуальных POS (Vakıfbank и Garanti). Для переводов добавлен процесс подтверждения/отклонения администрацией. Система работает с 285 учениками и 353 родителями.
Поиск частных школ сильно сезонный и локальный. Родители ищут «частная школа в Текирдаге» или «детский сад в Сулейманпаше», и вне периода набора такие запросы почти прекращаются. Сайт построен под это поведение: кампус, ступени (детский сад, начальная, средняя школа, лицей) и форма предварительной записи вынесены вперёд.
Сайт собирается как статический HTML генератором. Причина — типичный жизненный цикл школьного сайта: контент меняется несколько раз в год, но сайт получает большой трафик в период набора и никогда не должен оставаться без обслуживания. Статический сайт нельзя взломать через необновлённый плагин, у него не падает база данных, и он не задыхается от трафика.
Сайт работает за Cloudflare, поэтому очистка кэша — часть процесса обновления контента. Уведомление IndexNow также входит в настройку.
Один из самых пропускаемых и самых критичных шагов проекта: заявка на банковский виртуальный POS требует, чтобы на сайте уже были определённые юридические страницы.
Без договора дистанционной продажи, политики конфиденциальности, условий отмены и возврата, информации о доставке/услуге, контактов и уведомления о защите данных заявка не двигается. Эти страницы — не формальность, добавляемая потом, а предусловие платёжной инфраструктуры. Поэтому шесть юридических страниц были подготовлены ещё при публикации сайта.
Практический вывод для любого бизнеса, планирующего приём платежей: публикуйте юридические страницы до заявки на POS, а не после. Иначе техническая работа заканчивается, а система ждёт.
Кабинет — отдельное приложение, работающее на Docker:
На стороне POS работают сразу два банка: Vakıfbank и Garanti. Это не только резервирование, но и гибкость по рассрочке и комиссии — акционные условия различаются по банкам.
Значительная часть школьных платежей в Турции всё ещё приходит банковским переводом. Для системы это сложнее карты: деньги приходят в банк, а система об этом не знает.
Поэтому в кабинет добавлен процесс заявления о переводе с подтверждением/отклонением администратором. Родитель после перевода создаёт уведомление; администрация сверяет его с выпиской и подтверждает или отклоняет. Подтверждённое уведомление зачисляется во взнос.
Когда функция вышла, в очереди уже скопилось более двадцати необработанных уведомлений — потребность была не гипотетической, в системе действительно застряла работа. Уведомления отправляются нескольким получателям по почте, чтобы процесс не останавливался в день, когда один человек в отпуске или занят.
Большая часть школьной коммуникации идёт через SMS: напоминания об оплате, объявления, срочные уведомления. Панель массовых SMS построена на REST API NetGSM и привязана к справочнику учеников.
Ключевое решение — питать панель SMS теми же данными, что и записи учеников в платёжной системе, а не отдельной адресной книгой. Два списка неизбежно расходятся: у родителя меняется номер, его обновляют в одном месте и забывают в другом. При едином источнике напоминание доходит до нужного человека.
Система работает с 285 записями учеников и 341 номером телефона — цифры естественно различаются, так как у ученика может быть несколько доступных родителей.
Платёжный кабинет живёт на своём поддомене, и здесь всплыла деталь, которую стоит знать: бесплатный сертификат Cloudflare Universal SSL покрывает только поддомены первого уровня. То есть oplata.domen.com покрыт, а www.oplata.domen.com — нет.
Родители по привычке набирают «www», и это стало реальным источником сбоев: родитель, пытающийся открыть страницу оплаты, видел предупреждение о сертификате. Решением стал серверный сертификат, покрывающий и второй уровень, плюс постоянное перенаправление с www-адреса. Цепочка обновления сертификата была проверена отдельно — сертификат, работающий однажды, это сертификат, который сломается в день неудачного продления.
Школа ведёт сбор оплаты, учёт рассрочки и уведомление родителей в одной системе. Карточные платежи проходят мгновенно через два банковских POS, заявления о переводах фиксируются с подтверждением администратора, напоминания уходят SMS из тех же данных об учениках.
Переносимый вывод: в школьной платёжной системе рискованнее всего не код, а последовательность. Юридические страницы должны существовать до заявки на POS, справочник SMS должен питаться платёжными данными, а покрытие сертификата — проверяться по полному адресу платёжного поддомена. Пропустите эти три пункта — и система технически «готова», но практически непригодна.
Процесс скорее бумажный, чем технический. Банк требует, чтобы на сайте уже были договор дистанционной продажи, политика конфиденциальности, условия отмены и возврата, информация об услуге, контакты и уведомление о защите данных. Без этих страниц заявка стоит. Техническая интеграция обычно занимает меньше времени, чем ожидание одобрения.
Это решается без автоматической сверки с банком: родитель создаёт в системе заявление о переводе, администрация сверяет его с выпиской и подтверждает или отклоняет. Подтверждённое заявление зачисляется во взнос. Отправка уведомления нескольким администраторам не даёт процессу зависеть от одного человека.
Можно, но тогда вы держите два списка учеников, и они разойдутся. У родителя меняется номер, его обновляют в одном списке и забывают в другом — напоминание об оплате уходит не тому. Правильная схема: SMS-панель читает записи учеников прямо из платёжной системы.
У них разные профили риска и обслуживания. Сайт — публичная, часто читаемая, редко меняющаяся поверхность; кабинет — закрытое приложение с персональными данными и движением денег. При разделении изменение на сайте не угрожает платежам, а обновление кабинета не роняет сайт.