SakhSwim — сервис оплат и договоров

SakhSwim обучает плаванию детей и взрослых. Основатель школы и тренер Михаил сам занимался организационными вопросами: отправлял правила и расписание, проверял оплаты, выдавал ссылки на групповые чаты и напоминал о следующем платеже.

На одного нового ученика или его родителей приходилось до 11 сообщений. Клиенты присылали подтверждения оплаты, Михаил проверял поступление денег и после этого отправлял ссылку на нужную группу. При потоке около 80 новых записей в месяц сопровождение отнимало несколько часов каждую неделю.

На момент разработки в школе было более 200 записей. Клиенты уже приходили по рекомендациям, из поиска, 2ГИС и карт. Приоритетом стало обслуживание этого потока: перенести повторяющиеся действия в систему и сократить участие тренера в стандартных организационных вопросах.

Мы изучили существующий сервис, провели интервью с Михаилом, описали правила работы школы и разработали новую систему: мобильный интерфейс, запись на занятия, расчёт стоимости, формирование договоров, оплату, уведомления и административную панель.

В работу вошли интеграции с платёжными сервисами, проверка пользовательских сценариев, запуск и устранение проблем в рабочем окружении. После запуска проект остался у нас на техническом сопровождении.

Михаил участвовал в определении правил записи и расчётов, выборе условий оплаты и редактировании текстов. Внутреннее тестирование проводили наша команда и семья заказчика. Совместно с Михаилом как оператором персональных данных прорабатывали процессы обработки данных и подготовку уведомления в Роскомнадзор.

Нужно было связать запись, договор и оплату в один понятный сценарий. Клиент должен выбирать программу и расписание, после подтверждения записи Михаилом оформлять договор, оплачивать занятия и получать ссылку на свою группу. В следующие месяцы — самостоятельно возвращаться к оплате.

Для этого системе требовалось:

• учитывать сезоны, расписания и фактические даты занятий;
• рассчитывать стоимость с учётом праздников, неполного первого месяца и местного времени;
• формировать договор по актуальному шаблону;
• принимать платежи и автоматически определять их успешное завершение;
• выдавать ссылку на соответствующую группу после оплаты;
• отправлять напоминания о следующих платежах;
• позволять Михаилу менять расписание, цены, договор и материалы сайта без разработчика.

Интерфейс должен был подходить людям разного возраста: взрослым ученикам, детям, родителям, бабушкам и дедушкам. Отдельным условием была комиссия за оплату, по возможности близкая к привычной для заказчика оплате через СБП.

При этом нужно было уложиться в согласованный бюджет и сосредоточиться на регулярных операциях школы. Редкие исключения, например перерасчёт после отмены занятий, должны были оставаться управляемыми без сложной автоматизации каждого возможного случая.

Аудит существующего сервиса

У школы уже был сервис на Django: он формировал договоры и позволял управлять расписанием и стоимостью через административную панель.

Мы изучили код. Документации практически не было; обнаружились технические проблемы и вопросы безопасности, подробности которых не раскрываем. Продолжение разработки потребовало бы сначала восстановить устройство существующей системы и исправить накопленные проблемы.

Предложили заново разработать сервис на другом стеке. Такой подход позволил сохранить согласованный бюджет и построить административную часть, которую Михаил мог освоить после короткого знакомства с системой.

Правила работы школы и границы проекта

На интервью разобрали ручные действия Михаила и правила, которые до этого существовали в переписках и устных договорённостях. Основу системы составили связанные сущности: клиент, запись, договор и оплаты. Отдельно предусмотрели сезоны, расписания, тарифы и формы записи.

На этом же этапе определили состав проекта. Сложное SEO-продвижение, CRM, лид-магниты, маркетинговая аналитика и большая многостраничная структура не стали приоритетом. Михаил отказался от подключения Яндекс Метрики: в текущей задаче эти данные не определяли работу сервиса.

Обсудили и небольшой магазин очков и шапочек для плавания. Его исключили из разработки: два дополнительных товара не оправдывали усложнение основного сценария. Полноценную регистрацию пользователей и автоматизацию редких исключений также не включили в проект.

Мобильный интерфейс и страница школы

Интерфейс проектировали прежде всего для смартфонов. В нижнюю часть экрана вынесли мобильную навигацию, сократили количество обязательных действий, предусмотрели проверку данных при заполнении полей и понятные сообщения об ошибках.

Тексты несколько раз перерабатывали вместе с Михаилом. Пользователю нужно было понимать, как записаться, оформить договор и оплатить занятия, без знакомства с техническими терминами. Регистрацию не добавляли в сценарии, где она не давала дополнительной пользы.

Публичную часть оформили как компактную страницу школы: кто проводит занятия, кому подходит обучение, какие направления доступны, как проходят занятия и как записаться. При выборе коммуникаций учитывали привычные местной аудитории сервисы и каналы.

Пользовательские сценарии проверяли внутри команды и с семьёй заказчика.

Запись, расписания и сезоны

На сайте клиент выбирает программу и доступное расписание. Для детских и взрослых групп, разных типов записи и сезонов предусмотрены отдельные настройки.

Михаил может самостоятельно изменить расписание и стоимость занятия, открыть или закрыть сезонную запись, включить отдельную летнюю форму. Эти же данные используются при оформлении договора: параметры записи и последующие расчёты опираются на общие настройки.

Подтверждение новой записи осталось за Михаилом. Он оценивает, подходит ли обучение человеку, и проверяет его мотивацию. Последующие стандартные действия клиент выполняет через сервис.

Расчёт стоимости по фактическим занятиям

Стоимость зависит от числа доступных занятий. Клиент выбирает расписание и месяцы посещения, система определяет даты и умножает их количество на цену одного занятия.

В расчёте учитываются:

• дни выбранного расписания и их количество в месяце;
• официальные праздники;
• неполный первый месяц;
• сахалинское время;
• момент оформления договора.

Отдельно проработали запись в день занятия. Если клиент оформляет договор слишком поздно и уже не успевает приехать, занятие не должно попадать в стоимость. При этом запись за несколько часов до начала может оставаться допустимой.

Так в расчёт перенесли реальные правила школы, включая ситуации, которые Михаил раньше разбирал вручную.

Формирование договора и обработка данных

Пользователь заполняет данные на сайте, после чего сервер формирует PDF по актуальному шаблону. В документ подставляются данные клиента, реквизиты Михаила, выбранное расписание, рассчитанная стоимость и другие параметры договора.

Паспортные данные не записываются в базу. На сервере они обрабатываются в оперативной памяти при формировании и отправке документа. Постоянное хранение PDF с паспортными данными также не предусмотрено. В проекте используется офертная модель с принятием условий через оплату.

Для обработки данных предусмотрели разграничение доступа, ограничение частоты запросов, механизмы противодействия злоупотреблениям и резервное копирование. Состав хранимых данных ограничили необходимым для работы сервиса.

Эти меры и процессы учитывали при совместной с заказчиком подготовке уведомления в Роскомнадзор.

Выбор платёжного сервиса

Договором предусматривалась интеграция с ЮKassa, однако требование к комиссии привело к проверке нескольких вариантов.

Сначала реализовали интеграцию со Сбербанк QR и дошли до тестовых платежей. Затем банк ограничил работу из-за требований к сайту, а получение разъяснений затянулось из-за недоступности ответственных специалистов.

Следующим вариантом стала ЮKassa. Обсудили с Михаилом более высокую комиссию при оплате картой по сравнению с СБП, но дополнительные условия тарификации, выявившиеся в процессе, заказчика не устроили.

После этого реализовали интеграцию с ATOL Pay и успешно провели тестовые платежи. Обнаружились расхождения между опубликованной документацией и фактической работой сервиса. В итоге выбрали прямое подключение к API Т-Банка.

Дополнительные переделки выполнили без увеличения стоимости проекта. К финальному переходу основную логику расчётов и платежей уже отделили от конкретного эквайера. Поэтому меняли преимущественно способ взаимодействия с банком, сохраняя пользовательский сценарий.

Первая оплата и доступ к группе

После оформления договора клиент может оплатить первый месяц. Если в текущем месяце осталось мало занятий, система может предложить оплатить и следующий.

Успешный платёж фиксируется автоматически. Сервис определяет группу клиента и предоставляет нужную ссылку. В стандартном сценарии клиенту больше не требуется отправлять чек Михаилу, а Михаилу — проверять поступление денег и вручную выдавать ссылку.

Последующие оплаты и нестандартные суммы

Для повторной оплаты клиент вводит номер телефона и видит связанные с ним активные договоры. Он выбирает месяцы, которые хочет оплатить. Полноценный аккаунт с паролем для этого не требуется; чувствительные персональные данные в интерфейсе не раскрываются.

Кроме рассчитанной суммы предусмотрели платёж на свободную сумму. Занятия могут отменяться из-за погоды и других обстоятельств, поэтому редкие отклонения от стандартного расчёта остаются на усмотрение Михаила. Такой способ оплаты позволяет учитывать исключения без разработки отдельных правил для каждого случая.

Напоминания и журнал отправок

Для напоминаний об оплате рассматривали DashaMail и UniSender. По требованию заказчика реализовали собственный механизм внутри сервиса.

Из административной панели можно запускать массовые email-напоминания вручную или автоматически. Журнал событий показывает получателей, успешные отправки и ошибки.

Управление школой через административную панель

В одной панели Михаил работает с клиентами, записями, договорами и платежами. Здесь же настраиваются детские и взрослые группы, сезонные формы, расписания, стоимость и содержание договора.

Через панель можно редактировать блог, документы об образовании, реквизиты и контакты, ссылки на Telegram и другие каналы, а также включать сервисный режим сайта. Наиболее востребованные действия разместили выше, учитывая работу и с компьютера, и со смартфона.

Сервис разработали на Next.js, PayloadCMS и PostgreSQL. Для размещения и эксплуатации использовали Docker, nginx и Timeweb; оплату подключили через API Т-Банка, почтовые отправки — через SMTP.

Запуск оплаты в рабочем окружении

При переходе на Т-Банк тестовые платежи проходили, но в рабочем окружении запросы к банку начали завершаться ошибкой 503. Диагностика привела к проверке TLS-сертификатов: проблема была связана с цепочкой доверия после изменений сертификатной инфраструктуры.

Исправили проблему, после чего через сервис начали проходить реальные платежи. Это требовалось завершить к началу нового сезона записи; ручная оплата оставалась временным вариантом.

Доступность сайта в мобильных сетях

После запуска часть пользователей в Южно-Сахалинске не могла открыть сайт через мобильный интернет. При этом приложение и сервер работали, а с нашей стороны соединение устанавливалось.

Проверили инфраструктуру и вместе с технической поддержкой локализовали проблему до доступности конкретного IP-адреса в мобильных сетях в условиях ограничений и режима «белых списков». Выборочный характер сбоя усложнял диагностику.

По оценке Михаила, проблема мешала записаться примерно 100 новым и существующим клиентам. После смены IP-адреса сервера доступ восстановился.

Школа использует сервис для записи, договоров и оплаты занятий. Система отработала летний сезон — июнь и июль; затем через неё оформлялись договоры на сентябрь 2026 года и проходили реальные платежи.

По данным исходного среза за первые 10–15 дней нового сезона в системе были зафиксированы:

• 215 новых клиентов;
• 129 договоров на сентябрь 2026 года;
• 61 платёж;
• 377 отправленных email.

Стандартный путь клиента теперь проходит через выбор расписания, запись, подтверждение Михаилом, оформление договора, расчёт и оплату первого месяца. После успешного платежа клиент получает ссылку на группу, а в дальнейшем самостоятельно выбирает и оплачивает следующие месяцы. Напоминания отправляются из системы.

Из этого процесса ушли ручная проверка чеков, выдача ссылок после стандартной оплаты и персональная отправка регулярных напоминаний. Расчёт стоимости и формирование договоров выполняет сервис.

Михаил управляет расписанием и условиями через административную панель. За ним остаются подтверждение новых записей, работа с учениками и решения по нестандартным ситуациям. Проект находится у нас на техническом сопровождении.