Классика жанра

Обычная постановка на создание сайта для продажи билетов (терминология, орфография и пунктуация автора):

«Необходимо разработать одностраничный сайт с возможностью покупки билетов на мероприятие. По типу онлайн-покупки билетов в театр (есть даты, есть схема зала. Выбрал места, нажал на нужное количество квадратиков, внизу высветилась сумма, нажал оплатить, ввел номер карты, получил отбивку с билетами на введенную электронную почту)»

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

Онлайн покупка билетов потребует создания корзины с выбранными билетами, создания заказа, который будет отправлен в эквайринг банка, и далее, через подключенного Оператора Фискальных Данных (ОФД), на онлайн кассу, которая создаст чек и отправит его на почту покупателя. Это потребует от заказчика заключить договор с банком и ОФД, создать, настроить и зарегистрировать кассу.

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

Очевидно, что для продажи билетов нужна информация о событии, его дате и месте проведения, о схеме зала с местами. Всю эту информацию надо ввести и сохранить в базе данных. Причем, схема зала в определенном формате (например SVG) )должна содержать места с координатами (сектор, ряд, место), ценовые категории и тарифы, например, взрослый, детский, льготный и т.д. Необходим функционал для управления доступностью мест, изменения ценовых категории и тарифов «на лету». Все это задачи для серверной части проекта.

Схему нужно получить по API от сервера, показать покупателю, «оживить» ее скриптом, чтобы можно было выбрать места. Также по API необходимо забронировать места на время покупки (чтобы их не купил кто-то другой), сформировать из них заказ и подготовить его к отправке в эквайринг банка. Это основной функционал билетного процессинга - сложной штуки, которая, в том числе, управляет статусами мест (свободно, забронировано, продано), и статусами билетов (оформляется, оплачен, возвращается, возвращен). Здесь большой простор для того, чтобы сделать плохо, например, как описано в этой статье

Места и билеты – это разные сущности. На одно место, например, сектор партер, ряд 1, место 17, может быть продано несколько билетов (удивительно, да?). У каждого билета будет свой уникальный номер. При этом действующим билетом гарантировано будет только один, только с ним можно будет пройти через Систему Контроля Доступа (СКД) в зал. Остальные билеты получаются в процессе неоднократных покупок и возвратов, что является нормой на билетном рынке.

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

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

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

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

Также следует сразу продумать действия в ситуации, если изменятся протоколы эквайринга и/или ОФД, если из-за санкций закроют доступ к облачному хранилищу или используемой базе данных, а также понять, сколько будут стоить доделки/переделки и поддержка такого проекта.

В качестве вывода предложу две более верные постановки, прочнее связанные с реальностью, чем та, что приведена в начале статьи:

1. Необходимо разработать и внедрить новую билетную систему.

2. Необходимо создать сайт для продажи билетов, интегрированный с такой-то билетной системой или платформой, выступающей в качестве backend’а проекта.

Первый случай – это много времени, денег и рисков, о чем заказчик и исполнитель могут не догадываться в начале проекта. Второй случай - это оптимальное решение, почитать о котором можно в статье «Хочу свой сайт для продажи билетов…»