Пошаговый план создания приложения для продажи билетов и чек-ина: роли, флоу, QR-коды, офлайн-сканирование, безопасность, интеграции и тестирование.
Приложение для билетов и чек-ина решает одну практическую задачу: быстро и точно провести человека от «получил билет» до «прошёл на площадку», а организатору — дать понятную картину продаж и фактической посещаемости.
На уровне продукта чаще всего нужны четыре блока:
Подход должен одинаково хорошо работать и для конференций (много категорий и бейджи), и для концертов (максимальная скорость прохода), и для клубных встреч (часто есть списки гостей), и для бесплатных событий (важнее учёт и лимиты, чем оплата).
Чаще всего используются смартфоны и планшеты с камерой; иногда — отдельные сканеры (если поток большой или нужен более надёжный считыватель). Важно заранее определить, сколько устройств будет работать параллельно и кто отвечает за зарядку и резерв.
Оцените продукт по измеримым метрикам: скорость прохода (например, среднее время на одного гостя), процент ошибок (ложные отказы/двойные проходы) и устойчивость при плохой связи (возможность продолжать чек-ин при нестабильной сети с последующей синхронизацией).
Удобнее всего думать о системе билетов как о трёх интерфейсах под разные задачи: участник, контролёр на входе и организатор. Их можно собрать в один продукт или развести на отдельные приложения/модули — выбор влияет на сроки, поддержку и безопасность.
Если вы хотите быстрее проверить гипотезу и собрать рабочий MVP без тяжёлого классического цикла разработки, часть команд в РФ сейчас собирают такие системы на vibe-coding платформах вроде TakProsto.AI: вы описываете сценарии и роли в чате, а платформа помогает собрать веб‑админку (React), бэкенд (Go + PostgreSQL) и мобильные клиенты (Flutter) с возможностью экспорта исходников и отката по снапшотам.
Здесь важны простота и доверие. Минимальный набор: покупка билета, «кошелёк» с билетами (QR и детали заказа), статусы (действителен/использован/возврат), уведомления (покупка, напоминание, изменения по событию) и быстрый доступ к помощи на месте (FAQ, контакты, карта входов).
Частая ошибка — перегрузить участника настройками. Пусть всё критичное будет «в один тап»: открыть билет, показать QR, найти поддержку.
Сканер — рабочий инструмент, а не витрина. Нужны: максимально быстрый скан, крупная индикация результата (пускать/не пускать), офлайн-режим, журнал действий (кто, когда, какой билет проверил). Полезны фильтры по входам/зонам и режим «ручного поиска» по номеру билета на случай проблем с камерой.
В веб‑панели создают события и типы билетов, управляют продажами и промокодами, настраивают команды контролёров и права доступа, смотрят отчёты и выгрузки. Важно иметь понятный аудит действий и статус синхронизации устройств на площадке.
Один «суперапп» проще развернуть и сопровождать, но сложнее разделять права и снижать риск ошибок на входе. Модульный подход (отдельный сканер + отдельная админка) обычно безопаснее и удобнее для операций на площадке.
Для старта достаточно: кошелька билетов у участника, сканера с офлайном и базовой админки (события, продажи, список заказов, права, простые отчёты). Можно отложить: сложные схемы залов, продвинутую сегментацию уведомлений, автоматические интеграции с большим числом внешних систем и расширенную аналитику (оставив экспорт в CSV из /reports).
Хорошая модель данных — способ заранее договориться, «что такое событие» и «что такое билет», чтобы покупки, проход на входе и отчёты работали без ручных правок. Ниже — практичная структура, которую удобно поддерживать и масштабировать.
Событие лучше хранить не одним «постом», а набором сущностей:
Такой разрез поддерживает и простые события «на один вечер», и многодневные форматы с несколькими площадками.
Обычно выделяют:
Технически «тип билета» — это продукт с ценой, правилами доступа и ограничениями. А конкретный билет — экземпляр, привязанный к заказу и участнику.
Важно хранить ограничения отдельно от текста на лендинге — чтобы сканер мог проверять их автоматически:
Чем короче форма, тем выше конверсия. Базовый набор: имя, телефон или email, согласие на обработку данных. Дополнительные поля (дата рождения, компания, документ) включайте только если они реально нужны для льготы, бейджа или требований площадки — и делайте их условными по типу билета.
Чтобы предусмотреть возвраты/обмены и при этом не «зашить» бизнес-правила, удобно закладывать нейтральные статусы:
Такие статусы дают прозрачные отчёты и предсказуемую логику для сканера, даже если процессы со временем меняются.
Путь участника должен быть предсказуемым: минимум шагов, максимум уверенности, что «билет точно есть, вход пройду». Ниже — логика экранов и сообщений, которые помогают не потеряться до начала события.
В карточке события важно сразу показать ключевое: дата и время, адрес (с возможностью открыть маршрут), краткие правила входа и список типов билетов.
Для выбора билета лучше использовать простую таблицу: название тарифа, цена, что включено, условия возврата/обмена и ограничения (например, «вход до 20:00», «18+», «места свободные/нумерованные»). Если есть промокод — ввод на этом же экране, чтобы участник видел итоговую стоимость до оплаты.
После оплаты участник должен получить подтверждение сразу в трёх местах:
Ключевой момент — явный статус: «Оплачен», «Ожидает подтверждения», «Возврат оформлен». Это снижает нагрузку на поддержку в день события.
На билете QR/штрихкод должен открываться одним нажатием и быть доступен офлайн. Чтобы снизить риск случайного скриншота и пересылки, можно:
Участнику полезны 2–3 уведомления: за день, за пару часов и при подходе ко времени входа. Внутри — адрес, время начала/допуска, правила (документы, дресс-код, запреты), подсказка «Откройте билет заранее».
В «Моём билете» разместите короткий FAQ (как найти билет, что делать при ошибке оплаты, как переоформить). Рядом — контакт организатора/службы поддержки с рабочими часами и ожидаемым временем ответа. Это лучше, чем общая форма «мы скоро ответим», особенно в день мероприятия.
Контролёр — человек, от которого зависит скорость очереди и впечатление гостей. Поэтому его путь должен быть предельно коротким: открыть сканер → навести камеру → получить результат и понятную инструкцию за секунды.
Сканер запускается сразу в режиме камеры, без лишних экранов. Требование по скорости простое: один скан — один результат за 1–2 секунды, даже при слабом интернете.
После считывания QR-кода приложение показывает крупный статус и следующее действие:
Важно, чтобы контролёр не «расшифровывал» сообщение: статус должен читаться с первого взгляда и сопровождаться короткой подсказкой.
На случай треснувшего экрана, распечатки плохого качества или забытого телефона нужен ручной поиск по:
Поиск должен вести на карточку участника/заказа с теми же статусами, что и в сканере.
Если входов несколько, в приложении задаются точка входа и права доступа: разные типы билетов, отдельные зоны (VIP/балкон), доступ персоналу. Тогда сканер проверяет билет «в контексте» — и реже требует разбирательств на месте.
Каждое действие фиксируется в журнале: кто сканировал, когда, какой был результат и на каком входе. Это помогает разбирать спорные случаи, находить узкие места на входе и дисциплинирует команду без лишнего контроля.
QR‑код — это лишь «упаковка» данных билета. Настоящая защита строится вокруг того, что именно зашито в код и как система принимает решение «пускать/не пускать».
Практичный вариант — QR содержит короткий токен (например, 16–32 символа), а не персональные данные. Токен указывает на билет на сервере и минимизирует риски утечки.
Чтобы усложнить подделку, добавляют подпись (HMAC/подпись приватным ключом) и срок действия:
Ключевое правило: билет должен иметь статус и «жить» в системе как сущность. При первом успешном проходе он помечается как использованный.
Есть два уровня проверок:
Обычно QR выдаётся:
Важно: один билет — один токен. При возврате/замене токен должен инвалидироваться.
Для площадок с нестабильной связью сканер заранее загружает кэш «разрешённых билетов» на конкретное событие (или по зонам доступа). Все сканы пишутся в локальную очередь событий и синхронизируются при появлении сети.
Типичный кейс — дублирование: один и тот же QR показали дважды или два контролёра просканировали почти одновременно.
Решение: у каждого скана есть временная метка и ID устройства. При синхронизации сервер принимает первое событие как «успешное», остальные помечает как «дубликат» и возвращает причину. В интерфейсе сканера это должно отображаться явно: кто, когда и на каком входе уже пропустил билет.
Офлайн-режим в сканере — не «приятная опция», а страховка от реальности. На входных группах часто нестабильный интернет: подвальные клубы, стадионы, павильоны с экранирующими конструкциями, а также перегруженная сеть, когда тысячи людей одновременно пытаются подключиться.
Если проверка билета зависит от сервера, любой обрыв связи превращает очередь в конфликт. Офлайн-сканирование позволяет продолжать вход даже при нулевом интернете, а синхронизация «догоняет» позже.
Локальные данные должны быть достаточными для быстрой и безопасной проверки, но не избыточными.
Минимальный набор:
Персональные данные стоит минимизировать: если для контроля достаточно статуса билета, не нужно хранить ФИО/телефон. Это упрощает комплаенс и снижает последствия потери устройства.
Рабочая схема — отправлять на сервер не «изменения статуса билета», а события сканирования: кто/где/когда/какой результат. Сервер уже применяет правила и собирает аналитику.
Практические правила синхронизации:
Офлайн всегда несёт риски дублей: если два сканера без связи проверяют один и тот же билет, оба могут «пустить». Снизить риск помогают:
Чтобы не сорвать вход, нужен простой аварийный план:
Хороший офлайн-режим незаметен, пока всё работает, и спасает мероприятие, когда связь внезапно исчезает.
Интеграции превращают «приложение для мероприятий» в рабочий инструмент: деньги доходят организатору, участник вовремя получает билет, а команда — понятные отчёты после события.
Обычно подключают платёжного провайдера (банковский эквайринг/кошелёк) и строят процесс вокруг статусов платежа: создан, в обработке, успешен, неуспешен, возврат.
Ключевой элемент — вебхуки (уведомления от провайдера на ваш сервер). Именно вебхук должен считаться «истиной»: пользователь мог закрыть приложение, связь могла прерваться, но вебхук всё равно подтвердит оплату и позволит автоматически:
Важно заранее продумать идемпотентность: один и тот же вебхук может прийти дважды — система не должна выдать два билета.
Уведомления лучше планировать как цепочку, а не разрозненные сообщения. Типовые этапы:
Шаблоны держите в админ-панели: организатор меняет текст, но переменные (имя, событие, QR-ссылка, номер заказа) подставляются автоматически.
Организаторам почти всегда нужен CSV-экспорт: продажи, список участников, статусы чек-ина, промокоды, возвраты. Для продвинутых — API, чтобы отправлять данные в CRM/таблицы/BI-аналитику без ручной выгрузки.
Полезно поддержать импорт:
Если вы сравниваете уровни функций и интеграций, удобно вынести детали на /pricing, а подборки кейсов и разборы ошибок — в /blog.
Безопасность в билетном приложении — это не только «не дать пройти без билета», но и аккуратная работа с данными людей. Хорошая новость: для чек-ина обычно не нужен широкий профиль пользователя, и это упрощает соблюдение требований.
Собирайте только то, что реально нужно для входа и отчётов: идентификатор билета, статус (действителен/использован/возврат), событие и зона входа. Персональные данные (ФИО, телефон, email) подключайте опционально — например, только если нужны именные билеты или отправка уведомлений.
Отдельно продумайте сроки хранения: операционные данные для события (например, списки входа) можно хранить ограниченное время, а затем агрегировать в статистику без привязки к личности.
Разделите роли как минимум на: организатор (админ), контролёр (сканер) и поддержка. Ограничивайте доступ по событиям и даже по точкам входа: один контролёр видит только «свои» мероприятия и турникеты.
Добавьте журнал действий: кто и когда выполнял чек-ин, отменял проход, менял настройки, делал экспорт. Это помогает разбирать спорные ситуации и повышает дисциплину.
QR-код должен быть не просто номером билета. Используйте подпись (например, HMAC/EdDSA) так, чтобы приложение сканера могло проверить подлинность без обращения к серверу (важно для офлайна).
Поддержите ротацию ключей: новые билеты подписываются свежим ключом, старые остаются проверяемыми в течение заданного периода. На API добавьте rate limiting и базовую защиту от перебора кодов.
Подготовьте понятную политику конфиденциальности, опишите цели обработки, сроки хранения, порядок удаления и обращений пользователей. Реализуйте удаление/анонимизацию по запросу и автоматическое удаление после завершения периода хранения.
Отмечайте подозрительные сценарии: массовые покупки с одного устройства, повторяющиеся попытки оплаты, аномально частые возвраты, множество регистраций на одинаковые контакты.
Для чек-ина следите за аномалиями: слишком быстрые сканы одним контролёром, попытки повторного прохода, сканы билетов «в разных входах одновременно». Такие события отправляйте на ручную проверку в админ-панели и ограничивайте риск автоматическими правилами.
Тестирование системы билетов и чек-ина стоит планировать как отдельный мини‑проект: здесь важны не только «правильные экраны», но и скорость, устойчивость к сбоям и поведение в нестандартных ситуациях. Ошибка на входе превращается в очередь за минуты.
Проведите замеры на нескольких типичных устройствах контролёров (разные модели, «средние» камеры) и при разном освещении: дневной свет, полумрак, прожекторы, мерцание. Фиксируйте метрики: среднее время от наведения до результата, долю нераспознанных QR, влияние защитных стёкол и чехлов.
Нужны два вида нагрузочных тестов:
Пики продаж — одновременные покупки, выдача QR, отправка уведомлений.
Пики на входе — параллельная работа нескольких сканеров в одной зоне.
Проверяйте, не «задумывается» ли сервер, не растёт ли время ответа, корректно ли обрабатываются одновременные попытки пройти по одному билету.
Смоделируйте реальность: авиарежим, пропадающая сеть, переключение между Wi‑Fi и LTE. Важно проверить, что сканер:
Отдельно прогоните сценарии: дубли прохода, возврат/отмена, замена билета, неверная зона, ручная проверка по фамилии. Результат должен быть однозначным для контролёра: что делать дальше и кого звать.
Пилот запускайте на небольшом событии с реальной аудиторией. Перед стартом — чек‑лист: актуальные списки, тестовый проход, запасные устройства/пауэрбанки, инструкции для персонала, контакты ответственных.
На площадке нужен план дежурства: кто принимает решения по спорным проходам, кто следит за связью и синхронизацией, кто собирает обратную связь. После пилота соберите отчёт: узкие места, причины задержек, список улучшений и приоритеты для следующего релиза.
Аналитика в приложении для билетов — это не «красивые графики», а инструмент управления: где теряются продажи, хватает ли персонала на входе, какие ошибки сканирования повторяются и как меняется посещаемость по времени. Метрики лучше продумать заранее, чтобы данные собирались автоматически и без ручных отчётов после мероприятия.
Организатору критично видеть воронку покупки: просмотр → выбор билета → оформление → оплата. Полезный минимум:
Отдельно стоит выделять продажи по типам билетов (обычный/VIP/льготный), возвраты и апгрейды — это помогает прогнозировать нагрузку на входы и рассадку.
На площадке нужны показатели, которые быстро отвечают на вопрос «успеваем ли мы»:
Если ошибки типовые, их стоит выводить контролёру понятным текстом и собирать статистику — это ускоряет обучение персонала и уменьшает очередь.
После мероприятия важны отчёты, которые помогают делать следующие события лучше:
Эти отчёты удобно выгружать в CSV/XLSX и смотреть вместе с финансовыми данными.
В админ-панели нужен дашборд реального времени: продано/вошло, текущий темп входа, активные сканеры, очередь по входам (хотя бы косвенно — по задержкам сканов). Такой экран полезно держать открытым у руководителя смены.
Добавьте быстрый сбор обратной связи от контролёров: кнопка «сообщить проблему» с категориями (связь, камера, подсветка, конфликт с гостем) и коротким комментарием. Совмещая это с метриками ошибок и временем скана, вы получите понятный список улучшений — от подсказок в интерфейсе до изменений в логике проверки билетов.
Хороший чек-ин строится не вокруг «всех функций сразу», а вокруг минимального набора, который выдержит реальное мероприятие: очередь, плохую связь, человеческий фактор и необходимость быстро получить отчёт. Поэтому план лучше начинать с MVP и заранее расписать, что пойдёт во второй и третий релизы.
Для первой версии достаточно функциональности, которая закрывает полный цикл «купил билет → пришёл → прошёл контроль»:
Срок 4–8 недель реалистичен, если не усложнять правила доступа (места, таймслоты, сложные категории) и не пытаться сразу покрыть все интеграции.
После MVP логично нарастить возможности, которые чаще всего просят организаторы:
Важно: каждую функцию планировать вместе с изменениями в админ-панели и отчётах, иначе появится «невидимая» работа, которая съедает сроки.
Минимальный состав, чтобы уложиться в сроки и не провалить качество:
Кроссплатформа подходит, если нужно быстрее выпустить две платформы и интерфейсы не перегружены. Нативная разработка чаще оправдана, когда критичны скорость сканирования, работа камеры на разных устройствах и нестандартные требования площадки. Практичное правило: если сканер — ключевой риск, уделите ему максимум внимания независимо от стека.
Помимо разработки заложите:
Для большинства команд реалистичный ориентир — 4–8 недель на MVP, если держать правила доступа простыми.
Минимальный набор:
Оптимально разделить систему на три интерфейса:
Так проще управлять доступами и снижать риск ошибок на входе.
Офлайн нужен, чтобы очередь не зависела от качества связи на площадке.
Практичный подход:
Важно заранее предупредить организатора о риске дублей при длительной работе без синхронизации.
QR лучше делать не «номером билета», а токеном, который проверяется правилами системы.
Хорошая практика:
Так снижается риск подделки и пересылки скриншотов.
Нужен предсказуемый набор сущностей, чтобы покупки, проход и отчёты работали без ручных правок.
Минимум обычно такой:
Статусы продумывайте заранее: «оплачен/выдан/аннулирован/возврат/обмен/использован».
Типовой конфликт — когда один и тот же QR сканируют два устройства почти одновременно.
Надёжная схема:
Это особенно важно при офлайне и последующей синхронизации.
Скорость зависит от устройств, света, качества камеры и того, сколько действий должен сделать контролёр.
Что помогает:
В тестах измеряйте медиану и 95-й перцентиль времени скана, а не только среднее.
Оплата должна подтверждаться не экраном «успех», а событием от провайдера.
Практические правила:
Это снижает число обращений в поддержку в день события.
Начните с отчётов, которые помогают управлять входом и продажами, а не просто рисуют графики.
Полезный минимум:
Для выгрузок достаточно CSV, а расширение можно вынести в экспорт из /reports.
Чек-ин обычно не требует «широкого профиля» пользователя — это плюс для безопасности.
Рекомендации:
Потеря устройства контролёра не должна раскрывать лишние данные.
