Цифровой рубль в интернет-магазине: что я проверил бы до первой оплаты

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

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

Поводом для этого разбора стала статья Сибирикса о цифровом рубле в интернет-магазине. Мне хочется посмотреть на тему со стороны собственника: что спросить у банка и команды, как определить объём работ и по каким признакам принять результат.

Сначала выяснить, когда это касается вашего магазина

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

Для продавцов обязанность принимать цифровые рубли вводится поэтапно. На дату этого материала, 10 октября 2026 года, первый этап уже наступил.

• С 1 сентября 2026 года — для продавцов с выручкой за предыдущий календарный год свыше 120 млн рублей, у которых на 1 января 2026 года был соответствующий договор о приёме электронных средств платежа с системно значимым банком или банком, признанным значимым на рынке платёжных услуг.
• С 1 сентября 2027 года — для продавцов с выручкой за предыдущий календарный год свыше 30 млн рублей, у которых на 1 января 2026 года был договор о приёме электронных средств платежа с системно значимым банком, банком, признанным значимым на рынке платёжных услуг, или банком с универсальной лицензией.
• С 1 сентября 2028 года — для остальных продавцов, подпадающих под общее требование, с выручкой за предыдущий календарный год свыше 20 млн рублей.

Условия первых этапов изложены в документе ЦБ о развитии финансового рынка на 2026–2028 годы, сноска 70. Формулировку общего порога «превышает двадцать миллионов рублей» приводит Роспотребнадзор.

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

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

Первый разговор — с банком, затем с разработчиком

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

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

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

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

Показать покупателю понятный путь

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

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

Само наличие отдельной кнопки «Цифровой рубль» ещё ничего не говорит о готовности магазина. В сценарии с универсальным QR-кодом выбор платёжного инструмента может происходить на платёжной странице. Эту механику объясняет Банк России в материале об универсальном QR-коде НСПК.

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

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

Деньги пришли — магазин должен об этом узнать

Самая важная часть начинается за экраном покупателя. Нужно связать конкретный платёж с конкретным заказом и убедиться, что сумма совпадает.

Возврат человека на страницу «Спасибо» я бы не использовал как доказательство оплаты. Для решения об отгрузке нужен подтверждённый статус из доверенного источника, предусмотренного интеграцией банка или провайдера.

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

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

Об этой связи я уже писал в материале про единые статусы заказа между отделами. Новый способ оплаты должен попадать в тот же понятный процесс, по которому работают продажи, склад и бухгалтерия.

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

Возврат проверять вместе с оплатой

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

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

Фраза «возврат поддерживается» слишком короткая для приёмки. Я бы попросил показать полный возврат, частичный возврат и повторное нажатие кнопки, пока первая попытка ещё обрабатывается. Возможности каждого сценария нужно подтвердить у выбранного провайдера.

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

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

Касса и учёт должны понимать новый способ оплаты

Цифровой рубль не снимает требования к кассовым чекам при интернет-продажах, для которых нужна ККТ. ФНС описывает реквизиты безналичной оплаты, включая цифровой рубль, в разъяснении о форматах чеков.

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

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

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

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

Комиссию считать вместе со стоимостью работы

По решению Банка России от 28 августа 2026 года, до конца 2026 года приём цифровых рублей от физического лица бизнесом бесплатный. С 1 января 2027 года тариф составляет 0,3% от суммы, максимум 1500 рублей за операцию. Возврат по ранее совершённому платежу имеет нулевой тариф.

Это тариф платформы. Условия посредника и стоимость доработок нужно выяснять отдельно.

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

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

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

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

Как я бы принимал такую доработку

Для приёмки я бы попросил команду показать несколько завершённых историй. Не только успешную оплату, но и ситуации, в которых покупатель или сотрудник может растеряться.

1. Покупатель оплатил заказ с компьютера и с телефона. Магазин получил подтверждение, документы сформированы по согласованной схеме, заказ виден сотрудникам.
2. Покупатель закрыл страницу после оплаты. Заказ всё равно получил правильный статус.
3. Подтверждение задержалось или пришло повторно. Система корректно обработала оба случая.
4. Оплаченный заказ полностью вернули. Деньги и документы сошлись.
5. Из заказа вернули одну позицию. Суммы и оставшийся состав покупки правильные.
6. При временной ошибке кассы или обмена с учётом сотрудник видит проблему и знает порядок восстановления.
7. Ответственный сверил платежи, заказы и возвраты за тестовый период без необъяснённых расхождений.

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

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

С чего я бы начал завтра

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

Затем выбрал бы один заказ и на листе описал его путь: оплата, подтверждение, чек, сборка, возврат, сверка. Рядом с каждым шагом поставил бы систему и ответственного человека.

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

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