Цифровой рубль в торговой компании: как ИТ‑директору подготовить инфраструктуру к новым требованиям

До недавнего времени многие компании воспринимали цифровой рубль как еще один платежный инструмент, который появится наряду с банковскими картами, Системой быстрых платежей (СБП) и наличными деньгами. Однако с принятием Федерального закона № 248‑ФЗ от 23 июля 2025 года правила игры изменились: теперь возможность принимать оплату цифровыми рублями для части торговых сетей стала законодательной обязанностью.

У торговых компаний появилась весомая задача — обеспечить возможность приема оплаты цифровыми рублями и адаптировать под эту возможность собственный ИТ‑ландшафт.

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

Новый тип платежной операции должен корректно проходить через все корпоративные системы — от формирования QR‑кода на кассе до отражения в бухгалтерском и управленческом учетах. Поэтому подготовка к внедрению цифрового рубля — это полноценный ИТ‑проект. Разбираемся, что ждет торговый бизнес и как к этому подготовиться.

Что и когда изменится для торговых компаний

Федеральный закон от 23.07.2025 № 248‑ФЗ внес изменения в ряд законодательных актов, включая Закон РФ «О защите прав потребителей» и Федеральный закон «О национальной платежной системе», предусмотрев для торгового бизнеса поэтапное внедрение цифрового рубля.

Для этой отрасли установлены следующие сроки:

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

От этой обязанности освобождаются компании с годовой выручкой менее 5 млн рублей, торговые объекты без доступа к сети Интернет, а также компании, которые не осуществляют расчеты с физическими лицами.

Невыполнение требований после наступления назначенных сроков может повлечь административную ответственность для компании. В соответствии с частью 4 статьи 14.8 КоАП РФ отказ принять оплату цифровыми рублями при наличии такой обязанности влечет наложение штрафа:

• на должностных лиц — от 15 000 до 30 000 рублей;
• на юридических лиц — от 30 000 до 50 000 рублей.

Административная ответственность применяется за каждый установленный факт нарушения. Откладывать подготовку до контрольных сроков регулятора рискованно — стоит позаботиться об этом заранее.

Какие документы необходимо изучить перед началом проекта

Перед запуском проекта ИТ‑директору не требуется детально изучать весь массив нормативных документов по цифровому рублю. Для подготовки архитектуры решения достаточно ознакомиться с несколькими ключевыми документами.

Нормативная база:

1. Закон РФ № 2300‑1 «О защите прав потребителей» (в редакции Федерального закона № 248‑ФЗ) — определяет категории торговых организаций, для которых прием цифровых рублей становится обязательным, а также устанавливает обязанность предоставить покупателю возможность выбора способа оплаты.
2. Федеральный закон №161‑ФЗ «О национальной платежной системе» — дает общее понимание архитектуры цифрового рубля, универсального платежного QR‑кода и распределения ролей между продавцом, банком и платформой Банка России.
3. Положение Банка России № 820‑П «О платформе цифрового рубля» — описывает функционирование платформы и основные сценарии проведения операций. Для торговой компании достаточно понимать общую схему взаимодействия и границы ответственности участников.
4. Положение Банка России №833‑П «О требованиях к обеспечению защиты информации для участников платформы цифрового рубля» — устанавливает требования к защите информации; ИТ‑службе торговой компании важно учитывать их при взаимодействии с обслуживающим банком и организации ИБ.

Технические документы Банка России. Актуальная техническая документация размещается в разделе «Документы платформы цифрового рубля» на сайте Банка России. Для ИТ‑команды торговой компании достаточно сосредоточиться на документах, которые непосредственно влияют на проектирование приема платежей и интеграцию с банком.

Стандарты платформы цифрового рубля:

1. Требования и рекомендации к пользовательским интерфейсам при совершении операций с цифровым рублем — для понимания сценария оплаты, отображения цифрового рубля, статусов операций и использования универсального платежного QR‑кода.
2. Требования операционно‑технологического взаимодействия на платформе цифрового рубля — для общего понимания последовательности проведения операций, обмена сообщениями и обработки ошибок.

Альбомы распоряжений и электронных сообщений — основа для разработки интеграций:

1. Альбом распоряжений определяет состав операций, их реквизиты и данные, которые должны обрабатываться при проведении платежей. На его основе определяются требования к кассовым, учетным и интеграционным системам, в том числе к обработке возвратов и сохранению идентификатора исходной операции C2B.
2. Альбом электронных сообщений описывает структуру и последовательность обмена сообщениями. Он используется разработчиками при реализации интеграции с обслуживающим банком: определяет форматы сообщений, обязательные реквизиты, статусы, обработку ошибок и повторную передачу сообщений.

Как подготовить инфраструктуру к внедрению цифрового рубля

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

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

В нее, как правило, входят:

• ИТ‑архитектор;
• специалисты по интеграции;
• специалисты по информационной безопасности;
• представители финансового блока;
• сотрудники, отвечающие за кассовые решения и розничные операции.

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

Шаг 2. Провести инвентаризацию платежного контура. Необходимо составить карту всех систем, участвующих в обработке платежей:

• кассовое программное обеспечение;
• POS‑оборудование;
• платежный шлюз;
• интеграционная платформа (ESB);
• ERP;
• бухгалтерские системы;
• OMS;
• CRM;
• системы мониторинга и логирования.

Для каждой системы следует определить:

• требуется ли модернизация;
• какие изменения потребуется выполнить;
• кто отвечает за разработку;
• потребуется ли участие поставщика программного обеспечения.

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

На этом этапе рекомендуется запросить:

• способ интеграции;
• используемые API и интерфейсы;
• форматы сообщений;
• порядок тестирования;
• сроки готовности банка;
• сценарии проведения возвратов и отмен операций.

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

Шаг 4. Модернизировать кассовое ПО. Кассовое программное обеспечение первым начинает работать с новым способом оплаты.

Необходимо обеспечить:

• поддержку оплаты цифровыми рублями;
• генерацию универсального платежного QR‑кода;
• отображение QR‑кода на кассовом оборудовании;
• обработку новых статусов операций;
• поддержку отмены и возврата платежей.

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

Шаг 5. Доработать интеграционный слой. Основной объем технических изменений обычно приходится не на кассовое программное обеспечение, а на интеграционный слой. Именно он обеспечивает обмен данными между кассовыми системами, ERP, учетными решениями и сервисами обслуживающего банка.

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

В рамках проекта рекомендуется выполнить следующие работы:

1. Реализовать обмен сообщениями с банком в соответствии с утвержденным форматом интеграции.
2. Обеспечить обработку всех предусмотренных сценариев: оплата, подтверждение операции, отмена, возврат денежных средств.
3. Настроить очереди сообщений и механизмы повторной отправки при временных ошибках.
4. Реализовать защиту от повторной обработки одной и той же операции (идемпотентность).
5. Организовать журналирование всех этапов прохождения платежа.

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

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

Как правило, потребуется:

• добавить новый способ оплаты в используемые справочники;
• настроить обработку операций с цифровыми рублями в ERP и бухгалтерской системе;
• обеспечить автоматическое формирование необходимых бухгалтерских проводок;
• адаптировать процессы резервирования, отмены заказа и возврата денежных средств в OMS;
• предусмотреть возможность последующей сверки операций с данными обслуживающего банка.

Отдельной задачей является определение так называемой мастер‑системы — единственного источника достоверной информации о статусе платежа. Именно эта система должна использоваться при сверке данных между кассовым программным обеспечением, ERP, бухгалтерией и другими корпоративными сервисами. Такой подход позволяет избежать расхождений при обработке операций и существенно упрощает сопровождение системы после запуска.

Шаг 7. Проверить готовность ИТ‑инфраструктуры. После завершения разработки необходимо убедиться, что существующая инфраструктура способна обеспечить стабильную работу нового платежного сценария.

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

Не менее важной задачей является обеспечение информационной безопасности. Несмотря на то, что требования Положения Банка России № 833‑П адресованы участникам платформы цифрового рубля, торговой компании необходимо обеспечить защищенное взаимодействие с обслуживающим банком, контроль доступа к платежным сервисам, журналирование операций и мониторинг событий безопасности.

Также рекомендуется заранее настроить средства мониторинга, позволяющие контролировать:

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

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

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

Полноценная программа испытаний должна включать:

• успешное проведение платежа;
• отмену операции до завершения обработки;
• полный и частичный возврат денежных средств;
• повторную отправку сообщений после временного сбоя;
• восстановление работы после потери соединения;
• корректную обработку ошибок;
• нагрузочное тестирование при имитации пикового количества операций.

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

До перехода к промышленной эксплуатации рекомендуется:

• обновить внутренние регламенты;
• подготовить инструкции для кассиров;
• определить порядок действий при технических сбоях;
• обучить сотрудников бухгалтерии особенностям учета операций;
• подготовить специалистов службы поддержки к работе с обращениями покупателей.

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

Как торговая компания проходит путь от подготовки до промышленной эксплуатации

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

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

У банка необходимо получить:

• описание предлагаемой схемы взаимодействия;
• техническую документацию и требования к интеграции;
• сведения о доступных интерфейсах и форматах обмена;
• порядок подключения к тестовой среде;
• требования к кассовому и платежному оборудованию;
• график проведения тестирования и перехода в промышленную эксплуатацию.

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

Поставщики — подтвердить готовность решений. Получив требования банка, необходимо передать их поставщикам кассовой системы, POS‑решения и платежного ПО.

У каждого поставщика нужно запросить:

• готовность продукта к приему цифровых рублей;
• сроки выхода необходимых обновлений;
• поддержку универсального платежного QR‑кода;
• перечень необходимых лицензий или дополнительного оборудования;
• возможность работы в тестовом контуре;
• описание ограничений и известных особенностей решения.

Если штатное решение не поддерживает необходимые сценарии, ИТ‑директору нужно принять решение: ждать обновления поставщика, заказать доработку либо заменить решение.

Результат: зафиксирован способ модернизации фронтального платежного контура и понятен объем закупок или разработки.

Внутренние команды — утвердить изменения. На основании требований банка и поставщиков формируется техническое задание на доработку корпоративных систем.

На этом этапе утверждаются:

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

Результат: утверждена целевая архитектура и сформирован план разработки.

Финансы и бухгалтерия — согласовать учет. ИТ‑директору необходимо передать финансовому блоку описание нового платежного сценария и согласовать, как операции с цифровыми рублями должны отражаться в учете.

Совместно определяются:

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

Результат: требования к ERP, бухгалтерии и сверке платежей зафиксированы до начала разработки.

Пройти тестирование с банком. Когда кассовое ПО, интеграционный слой и учетные системы готовы, компания переходит в тестовый контур, предоставленный банком.

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

Результаты тестирования необходимо оформить и передать банку в предусмотренном им порядке.

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

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

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

Результат: подтверждена готовность не только ИТ‑систем, но и операционных процессов компании.

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

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

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

Подводим итоги

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

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