Платформа афиши и билетов в мессенджере: кейс разработки

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

Коротко: клиент — организатор регулярных событий; проблема была в разрозненных инструментах и оплате переводом на карту без гарантий. Я построил платформу афиши и билетов внутри мессенджера: QR-билеты, онлайн-оплата с проверкой вебхука, геймификация и кабинет организатора. В результате появился единый управляемый поток от анонса до входа и аналитики.

Проблема: разрозненные инструменты и недоверие к оплате

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

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

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

Решение: платформа целиком в мессенджере

Мы договорились строить всё внутри мессенджера — без отдельного мобильного приложения, которое нужно скачивать и объяснять, как им пользоваться. Архитектура получилась из трёх частей: бот на aiogram как точка входа и уведомлений, мини-приложение на React для пользователей и отдельная админ-панель на React для организаторов.

Backend собран на FastAPI с асинхронной работой с PostgreSQL — это важно при пиковой нагрузке в момент старта продаж на популярное событие. Redis и фоновые задачи взяли на себя всё, что не должно тормозить отклик интерфейса: обработку платежей, рассылки, пересчёт баллов и рангов.

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

Честная оплата: вебхук, идемпотентность, никаких потерь

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

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

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

QR-билеты и контроль на входе

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

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

Геймификация: баллы, ранги, рефералка, конкурсы

Отдельный блок системы отвечает за то, чтобы аудитория возвращалась снова. В основе — два вида баллов, начисляемых за разные действия, трёхуровневая реферальная программа и система рангов с бейджами-достижениями за конкретные результаты.

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

Здесь важна экономическая логика, а не просто «значки ради значков». Два вида баллов позволяют разделить внутреннюю валюту и репутационный счёт: одни баллы можно тратить, другие только копятся и определяют ранг. Трёхуровневая реферальная программа устроена так, что пригласивший получает выгоду не только от прямого друга, но и от тех, кого привёл уже этот друг, — это и есть механизм органического роста, когда аудитория расширяет сама себя. А конкурсы приглашений с призами превращают разовую вспышку интереса к конкретному событию в измеримый прирост базы пользователей, который остаётся с платформой и после того, как событие прошло.

Отдельно стоит социальный слой: подписки между пользователями и функция «друзья идут» на конкретное событие — но только с учётом согласия каждого участника, без раскрытия чужих данных без разрешения.

Кабинет организатора и рассылки

Организатор работает в собственном кабинете: полный CRUD по своим событиям, статистика продаж, список пришедших гостей и рассылки собственной аудитории. Демография участников выводится прямо на дашборд, чтобы организатор понимал, кто на самом деле приходит на его события.

Рассылки сделаны сегментированными — по городу, полу, возрасту, интересам и активности пользователя, что заметно повышает отклик по сравнению с рассылкой «всем подряд». При этом на рассылки новостей и акций действует строгий opt-in: без явного согласия пользователя такие сообщения не отправляются, что закрывает и юридические риски, и вопрос доверия аудитории.

Сегментация здесь — не косметика, а прямой рычаг эффективности. Организатор камерного мероприятия может обратиться только к тем, кому оно объективно интересно по возрасту и интересам, и не жечь доверие остальной базы нерелевантными сообщениями. Данные для сегментов берутся из того же профиля и истории активности, поэтому настраивать ничего вручную не нужно — достаточно выбрать условия. А поскольку демография сразу видна на дашборде, организатор принимает решения по цифрам, а не по ощущениям: видно, какая аудитория реально формируется вокруг его событий и куда её стоит развивать.

Эксплуатация: бэкапы, мониторинг, стабильность

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

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

Что получил клиент

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

Частые вопросы

Как сделать афишу событий и продажу билетов внутри мессенджера? Собрать мини-приложение, которое открывается прямо в мессенджере без установки, и подключить к нему афишу с категориями, оплату и выдачу QR-билета. В этом проекте весь путь — от поиска события до билета — проходит внутри одного окна, без отдельного мобильного приложения.

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

Можно ли обойтись без отдельного мобильного приложения для событий? Да. Мини-приложение внутри мессенджера открывается мгновенно, не требует установки и покрывает весь пользовательский путь — от афиши до билета, — поэтому отдельное приложение не нужно.

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

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

Как организатору событий видеть аналитику и делать рассылки аудитории? Через кабинет организатора: статистика продаж, список пришедших и демография на дашборде, плюс сегментированные рассылки по городу, полу, возрасту, интересам и активности со строгим opt-in на новости и акции.

Коротко о главном

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

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