Цифровой рубль уже списался. Почему заказ всё ещё нельзя выдавать
Покупатель стоит у стойки ПВЗ. В приложении банка уже появилось подтверждение оплаты цифровыми рублями, оператор видит «ожидает платёж», а заказ в системе доставки всё ещё готов к выдаче. Цифровой рубль уже списался — почему заказ всё ещё нельзя выдавать?
Потому что списание и передача товара подтверждаются разными системами. Пока они не сошлись на одном факте, оператор не может честно ответить, что происходит с заказом.
В Qtim оплату при получении рассматривают как цепочку событий между заказом, платёжной платформой, кассой, логистикой и поддержкой. Цифровой рубль добавляет способ расчёта, который делает разрывы между этими контурами заметнее. Продукту важно дать покупателю и оператору один ответ о состоянии заказа.
Для части продавцов с выручкой свыше 120 млн ₽ и установленными отношениями с банком приём цифровых рублей стал обязательным 1 сентября 2026 года. Дальше действуют сроки 2027 и 2028 годов. ЦБ подтверждает приём через сайты и приложения. Регулятор задаёт условия доступа к методу. Маршрут выдачи компания собирает из собственных статусов, интеграций и правил возврата.
Один статус «оплачено» создаёт лишние обращения
У выдачи происходят четыре разных факта: покупатель начинает платёж, деньги списываются, товар передаётся, возврат завершается. Один общий статус скрывает различия между ними. Отсюда появляются очереди у стойки, повторные попытки и обращения с одним вопросом в банк и магазин.
Для каждого события нужны источник, время, общий идентификатор операции и владелец. Тогда сотрудник поддержки видит последовательность в одном сценарии, а покупатель получает согласованные сообщения.
Полезно сразу договориться и о словаре. «Платёж начат» означает, что магазин создал попытку и ждёт ответ. «Деньги списаны» означает, что платёжный контур подтвердил перевод. «Товар выдан» появляется только после события кассы или логистики. «Возврат завершён» подтверждает отдельный процесс, а не исчезновение исходного платежа из истории. Эти определения нужны в OMS, CRM, интерфейсе ПВЗ и текстах поддержки.
Способ оплаты должен иметь запасной маршрут
Доступ к цифровому рублю покупатель получает через счёт на платформе Банка России и приложение банка-участника. Для физлица нужны совершеннолетие, подтверждённая учётная запись на Госуслугах и отношения с подключённым банком. Условия перечислены у ЦБ.
Показывайте способ оплаты после проверки доступности. Карта, СБП, наличные или другой разрешённый продавцом путь должны быть рядом до момента передачи заказа. Такой запасной маршрут снимает тупик, когда клиент уже выбрал оплату, а доступ к счёту или связь с банком отсутствуют.
Особый случай — частичный выкуп. Покупатель отказывается от одной позиции, итоговая сумма меняется, а заказ сохраняет прежний набор событий. OMS передаёт в платёжный контур обновлённую сумму и тот же идентификатор заказа. Иначе приложение и касса покажут разные цифры, а оператор будет объяснять расхождение на месте.
Запасной маршрут важен и для повторной попытки. До нового запуска система проверяет журнал операций по идентификатору заказа. Покупатель не должен выбирать между ожиданием без статуса и двойной оплатой. Оператору достаточно увидеть один факт: попытка ещё обрабатывается, завершилась или требует возврата.
Платёж и выдача товара подтверждают разные системы
Успешный перевод подтверждает платёжный контур. Передачу товара подтверждает логистика или касса. OMS связывает оба события с заказом. В рабочем сценарии каждая система передаёт результат по общему идентификатору и хранит время события.
Для предприятий, которые уже принимают СБП, Банк России допускает приём цифровых рублей через существующие онлайн-каналы и терминалы после настройки. Специальное оборудование не требуется, однако компании нужен счёт цифрового рубля и решение банка по интеграции. ЦБ описывает доступность канала. Контракт между кассой, OMS и поддержкой бизнес настраивает сам.
В пилоте проверьте четыре связи: заказ и попытку оплаты, попытку и списание, списание и выдачу, выдачу и возврат. Для каждой связи назначьте сервис-владелец, журнал операций и обработку повторной попытки. Плохая сеть или повторное нажатие на терминале не должны превращать один заказ в две неясные оплаты.
Ещё один полезный контроль — порядок прихода событий. Касса может получить ответ раньше, чем OMS обновит заказ. Логистика может зафиксировать выдачу с задержкой. В журнале нужен идентификатор, время получения и время создания события. Тогда команда отличит временную задержку от настоящего конфликта между системами.
Команда Qtim проектирует e-commerce-продукты вокруг сквозных сценариев оплаты, логистики и поддержки. Результат такой работы — карта событий, владельцев и текстов, которые одинаково читают покупатель, оператор и команда.
После списания поддержка запускает возврат
Перевод цифровых рублей становится безотзывным и окончательным с момента списания, сообщает ЦБ. Получатель может вернуть деньги. Для службы поддержки это задаёт последовательность: сотрудник сверяет платёж и заказ, запускает возврат по правилам продавца, сообщает следующий статус.
Сроки возврата, ответственность банка и магазина, а также доступность сценария требуют подтверждения в конкретном контуре. Регулятор описывает правило перевода, а не процесс отдельного продавца. Поэтому в тексте для клиента нужны факт, следующий шаг и владелец процесса.
Поддержке также нужен предел полномочий. Сотрудник ПВЗ подтверждает только те статусы, которые пришли из авторитетного источника. Он не называет срок возврата по памяти и не просит покупателя платить повторно до сверки операции. Такой предел защищает и клиента, и команду от обещаний, которые невозможно выполнить.
Смотрите на расхождения между системами
Доля успешных оплат полезна для отчёта. Для продукта и поддержки важнее расхождения: списание без выдачи, несколько попыток по одному заказу, обращения с ручной сверкой, возвраты без понятного статуса. Эти показатели не доказывают влияние цифрового рубля на конверсию или нагрузку. Они показывают конкретный участок пути для проверки.
Рост ручных сверок после выдачи указывает на задержку статусов или потерю идентификатора. Повторные попытки показывают, что покупатель не понял результат первой операции. Возврат без статуса обнаруживает разрыв между оплатой и клиентским сервисом. У каждого сигнала есть владелец и следующее действие, поэтому аналитика остаётся рабочим инструментом.
Здесь легко ошибиться с причиной. Два обращения по одному заказу не доказывают сбой платёжной платформы. Возможно, оператор открыл старый экран, OMS получил событие с задержкой или клиент не увидел статус. Метрика должна вести к журналу событий и проверяемой гипотезе, а не к автоматическому поиску виноватого.
Есть разумное возражение: небольшому магазину этот сценарий может быть пока не нужен. Обязанность зависит от условий закона, выручки и точки продаж. Регулятор освобождает часть компаний, а также точки с годовой выручкой менее 5 млн ₽. При этом карта состояний полезна для карт, СБП и других оплат при получении.
Начните с одного конфликта у выдачи
Не нужно одновременно перестраивать все способы оплаты. Выберите случай, где сегодня расходятся заказ, деньги и факт выдачи. Это может быть невыданный заказ после списания, частичный выкуп или повторная попытка из-за сети. Пройдите его от действия покупателя до закрытия обращения и назовите владельца каждого события.
Правило для запуска: передавайте товар после совпадения статуса платежа и статуса заказа в понятном оператору виде.
Команда Qtim поможет разобрать самый рискованный сценарий оплаты при выдаче и собрать карту интеграций, статусов и поддержки. Начать можно с одного конфликта, который уже создаёт очереди или повторные обращения.
