Ключевые темы
Связанные публичные страницы
Если нужен не только разбор, а страница продукта, API или операционного сценария, начните с этих разделов VPOS.am.
QR-код - это вход в платежный сценарий, а не просто картинка
За QR-кодом должен быть payment intent, сумма, назначение, получатель и понятное правило финального статуса.
В кафе, доставке, сервисном бизнесе или на мероприятии QR-код часто воспринимают как быстрый способ показать клиенту страницу оплаты. Но технически это такой же платежный сценарий, как checkout на сайте: нужно понимать, кто получает оплату, за что, в какой валюте и как бизнес узнает финальный статус.
Если QR ведет только на статичную страницу без нормального payment intent, оператору приходится вручную искать оплату по сумме, времени и комментарию клиента. Это быстро ломается при нескольких кассах, сменах, курьерах, чаевых или повторных попытках оплаты.
- QR должен вести к управляемому payment intent или платежной странице;
- назначение, сумма и получатель должны быть сохранены на backend;
- финальный статус должен приходить server-side, а не только с экрана клиента;
- для поддержки нужен reference, который можно найти в CRM или журнале.
Какие статусы нужны для офлайн-точки
Кассиру или менеджеру нужен простой ответ: оплачено, ожидает проверки, ошибка или нужен ручной разбор.
Офлайн-команда не должна читать raw provider status. Ей нужен нормализованный статус: payment created, pending, paid, failed, expired или manual review. Особенно важно разделять pending и paid, потому что клиент может показать экран возврата до того, как backend получил финальное подтверждение.
Для доставки и услуг полезно хранить связь платежа с заказом, курьером, столом, филиалом, сотрудником или invoice. Тогда спорный платеж можно быстро восстановить по контексту, а не по переписке в мессенджере.
- не выдавать услугу только по скриншоту клиента;
- показывать оператору last checked и provider reference;
- разделять оплату заказа, чаевые и донат;
- фиксировать ручное подтверждение с ответственным.
Как закрывать день по QR-платежам
QR-платежи должны попадать в ту же сверку, что сайт, CRM-счета и мобильные платежи.
Если QR-платежи не попадают в ежедневную сверку, они становятся отдельным ручным каналом. Бухгалтерия видит деньги у провайдера или в банке, менеджер видит заказ в CRM, а операционная команда не всегда понимает, какие оплаты закрыты.
Рабочая модель: каждый QR-платеж имеет merchant id, branch id, target id, amount, currency, provider reference, final status и timestamp. Система автоматически закрывает совпадения, а расхождения отправляет в список исключений.
- сверять QR-платежи вместе с другими каналами;
- хранить филиал, сотрудника, заказ или назначение;
- отдельно учитывать tips, donations и invoice payments;
- делать список исключений для ручного разбора.
FAQ
Можно ли использовать один QR-код для всех оплат?
Можно для простого сценария, но лучше, чтобы backend создавал или определял payment intent с назначением, суммой и получателем. Иначе сверка быстро становится ручной.
Достаточно ли скриншота клиента для подтверждения оплаты?
Нет. Скриншот удобен для коммуникации, но бизнес-статус должен подтверждаться server-side статусом, webhook или проверкой у провайдера.
Как учитывать чаевые по QR?
Чаевые лучше отделять от оплаты заказа: хранить получателя, филиал, сумму, комиссию, статус выплаты и связь с исходным платежом, если она есть.
