КЕЙС: Разработка системы онлайн-покупки билетов для сети зоопарков
«Дом Попугаев»

«Дом Попугаев» – сеть контактных парков, где посетители покупают билеты на конкретную локацию, дату и состав визита. У каждой точки своя операционная логика: график, цены, доступность, возрастные параметры, правила посещения и бизнес-настройки.

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

Создать единую систему онлайн-покупки билетов, которая работает как простая витрина для пользователя и как управляемый транзакционный backend для бизнеса.

Решение было реализовано в виде отдельного WordPress-плагина. Это важный архитектурный выбор: бизнес-логика продажи билетов изолирована от темы сайта, не зависит от визуальных шаблонов и может развиваться как самостоятельный модуль.

Внутри системы был собран модульный backend на PHP с объектно-ориентированной архитектурой. Для платежей создан абстрактный слой, который описывает базовые операции: создание заказа, временное сохранение данных, получение webhook URL, логирование и управление жизненным циклом оплаты.

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

Система проектировалась под четыре независимые физические точки. У каждой локации могут отличаться цены, условия, тексты, доступность и параметры продажи. Чтобы это не превращалось в ручную правку кода, управление вынесли в ACF Options Page.

Администратор может менять параметры в привычной админке WordPress. Для бизнеса это принципиально: операционные изменения не должны каждый раз превращаться в задачу для разработчика. Если меняется цена, акция или доступность локации, это можно обновить через интерфейс управления.

Фронтенд реализован как модульное JavaScript-приложение. Сценарий покупки собран коротко и понятно: пользователь выбирает точку, дату, количество детей и возраст, видит автоматический расчет стоимости, подтверждает телефон через SMS и переходит к оплате.

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

Отдельный блок работ касался платежной модели и перехода на Т-Банк. Процесс оплаты был формализован в строгий backend-пайплайн: фронтенд передает нормализованные данные заказа, сервер проводит валидацию, платежный модуль формирует запрос к API, заказ получает уникальный OrderId и сохраняется до подтверждения оплаты.

Фискальная часть приведена к модели ФФД 1.2. Чек формируется как полноценная структура: отдельные позиции билетов, цена до и после скидки, налоговая модель, электронный способ оплаты и контактные данные клиента. Скидка стала частью фискальной модели, а не декоративным расчетом на фронтенде.

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

Ключевым событием системы стал подтвержденный платеж. Webhook от платежного провайдера запускает всю post-payment логику: проверку заказа, генерацию документов, отправку письма и очистку временных данных. Обрабатывается только статус: CONFIRMED. Все остальные статусы игнорируются на уровне бизнес-логики.

Дополнительно реализована идемпотентность: один OrderId обрабатывается только один раз. Это защищает систему от повторной генерации билетов, дублирования писем и ошибок при повторных webhook-запросах.