Отметка прихода по QR-коду: как не пропустить одного гостя дважды

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

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

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

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

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

Если QR содержит ссылку с секретом, учитывайте её возможное попадание в историю, журналы и стороннюю аналитику. OWASP описывает такие каналы утечки для идентификаторов сессий в URL. Применительно к билетному доступу это основание отдельно проверить журналирование и права токена, а не считать билет полноценной пользовательской сессией.

Открытие ссылки не должно само отмечать приход. Почтовый сервис или предпросмотр сообщения может обратиться к адресу раньше посетителя. RFC 9110 определяет GET как безопасный метод по запрашиваемой семантике; изменение состояния посещения нужно выполнять отдельным защищённым действием после необходимых проверок.

QR-код можно переслать или сфотографировать. Одноразовое использование предотвращает повторное принятие уже использованного билета, но не доказывает личность первого предъявителя. Если формат требует именного допуска, предусмотрите соразмерную проверку по установленным правилам. Не обещайте, что обычная картинка сама исключает передачу билета.

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

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

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

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

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

Не переводите визит в статус «услуга завершена» только по сканированию на входе. Человек мог прийти, но занятие ещё не состоялось или было прервано. Аналогично наличие оплаты не доказывает явку. Раздельные события позволяют корректно оценивать неявки и фактическую посещаемость.

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