/
Оплата QR-кодом: Газпромбанк СБП (API с UniQR и цифровой рубль)

Публичное пространство

Оплата QR-кодом: Газпромбанк СБП (API с UniQR и цифровой рубль)

НАПИСНО ИИ

https://crystals.atlassian.net/browse/SRTZ-4428

https://crystals.atlassian.net/browse/CR-13438

10.4.24.0

Описание

Доработка направлена на поддержку новых методов API Газпромбанка для обработки оплат по QR-коду в рамках УПК (универсального платежного контура).

Основные изменения включают:

  • переход на новые методы опроса статуса для:

    • динамических QR-кодов

    • кассовых ссылок

  • прием и обработку новых атрибутов:

    • paymentServiceId — идентификатор платежного сервиса

    • SBP_ID (sbp.id) — идентификатор транзакции в НСПК

  • сохранение этих данных в чеках и передаче в ERP

  • доработку печати чеков и Z-отчетов с учетом платежного сервиса

При этом подмена СБП на УПК и наполнение платежными сервисами выполняется на стороне банка, без изменений логики вызовов на кассе.

Ценность

Доработка обеспечивает:

  • поддержку новых платежных сервисов Газпром ЦИФРОВОЙ РУБЛЬ

  • корректную обработку статусов оплат через обновленный API

  • полный финансовый учет за счет сохранения:

    • идентификаторов транзакций

    • платежного сервиса

  • прозрачность для ритейлеров и покупателей при оплате по QR-коду

  • расширенную аналитику:

    • в чеках

    • в Z-отчетах

    • в операционном дне

 

Логика работы и настройка

Сохранение плагинных свойств оплат

Функциональность обеспечивает корректную передачу и сохранение полей в экспорте чека в плагинных свойствах оплат.

Все текущие поля, согласно документации https://crystals.atlassian.net/wiki/spaces/INT/pages/830964045/SetRetail10+ERP+-+ERP#id-%D0%AD%D0%BA%D1%81%D0%BF%D0%BE%D1%80%D1%82%D1%87%D0%B5%D0%BA%D0%BE%D0%B2%D0%B8%D0%B7SetRetail10%D0%B2ERP(%D0%B2%D0%B5%D0%B1-%D1%81%D0%B5%D1%80%D0%B2%D0%B8%D1%81%D0%BD%D0%B0%D1%81%D1%82%D0%BE%D1%8, в выгрузке чека сохраняются без изменений.

В рамках данного пункта:

  • Добавлены новые свойства: sbp.id,  payment.service.id

  • Обновлен способ заполнения существующих свойств, используя данные из новых методов.

  1. Для операции ОПЛАТЫ в чеке сохраняются следующие плагинные свойства:

    • operation.id - идентификатор транзакции оплаты.

      • Источник для оплаты по кассовой ссылке - значение trxId .

      • Источник для оплаты по динамическому QR - transactionId

    • qrc.id - идентификатор зарегистрированного QR кода в СБП.

    • payment.service.id - идентификатор платежного сервиса (например, "СБП", "Цифровой рубль Банка России", "Gazprom Pay").

      • Источник -значение paymentServiceId, полученное в ответах от API.

    • sbp.id - номер транзакции в НСПК.

      • При успешной оплате по методу PUT /merchant/v2/qrc-status источник - значение fpMessageId

      • При успешной оплате по методу GET /merchant/payment/v1/cash-register-qrc/{qrcId}/{paramsId} источник - значение fpTransactionId -

  2. Для операции ВОЗВРАТА в чеке должны сохраняются следующие плагинные свойства:

    1. operation.id - идентификатор транзакции исходной успешной оплаты из чека основания

    2. payment.service.id - Идентификатор платежного сервиса, через который был проведен возврат.

      • Источник - значение paymentServiceData.id при проверке статуса с помощью метода v2/operation/info.

    3. sbp.id - номер транзакции в НСПК.

      1. Источник - значение fpMessageId при проверке статуса с помощью метода v2/operation/info.

Настйроки и информация о платёжном сервисе в отчете и печатном чеке

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

Выводятся данные новых подстановок для шаблонов чека “has_payment_service_id“, “payment_service_id“ и “payment_service_name“ при включенной настройке в базе данных set на сервере SetCentrum/SetRetail print.group.payment.types.in.check = true пример секции payment в шаблоне чека:

<section id="payment"> <list> <line font="normal"> <condition name="psid1"> <operand key="equal"> <varLogical> <element value="has_payment_service_id" width="0" align="left"/> </varLogical> <varLogical> <boolean value="false"/> </varLogical> </operand> </condition> <!-- Формат оплат в группах --> <element precision="0" value="payment_subclass" clip="true" width="25" filler="space" align="left"/> <element precision="2" value="sumpay" width="10" prefix="equalsign" filler="space" align="right"/> </line> <line font="normal"> <condition name="psid2"> <operand key="equal"> <varLogical> <element value="has_payment_service_id" width="0" align="left"/> </varLogical> <varLogical> <boolean value="true"/> </varLogical> </operand> </condition> <!-- Формат оплат в группах --> <element precision="0" value="payment_subclass" clip="true" width="25" filler="space" align="left"/> </line> <line font="normal"> <condition name="psid3"> <operand key="equal"> <varLogical> <element value="has_payment_service_id" width="0" align="left"/> </varLogical> <varLogical> <boolean value="true"/> </varLogical> </operand> </condition> <text value=" " width="1" filler="space" align="left"/> <element precision="0" value="payment_service_name" clip="true" width="25" filler="space" align="left"/> <element precision="2" value="sumpay" width="10" prefix="equalsign" filler="space" align="right"/> </line> <header> <line font="normal"> <text value="" clip="true" width="0" filler="dash" align="left"/> </line> </header> <footer> <line font="normal"> <!-- Формат оплат, которые не попали в группы и не имеют subclass (например, наличные) --> <element precision="0" value="payment_type_name" clip="true" width="25" filler="space" align="left"/> <element precision="2" value="sumpay" width="10" prefix="equalsign" filler="space" align="right"/> </line> </footer> </list> </section>



  1. Реализована настройка для агрегации в z-отчетах по платежному сервису

    1. Настройка в базе данных set на сервере SetCentrum/SetRetail 'print.paymentServiceId.in.report'

  2. При включении выше описанных настроек выполняется агрегирование оплат по расширенной схеме:

image-20260319-122519.png

 

В рамках функциональности реализовано применение расширенного агрегирования оплат по схеме
typeClass → subclass → paymentServiceId в печати чеков и Z-отчётах возможно только при активированных настройках, а именно:

  1. Печать безналичных оплат в чеке с группировкой по подтипам оплат
    Включите настройку в базе данных set на сервере SetCentrum/SetRetail: print.group.payment.types.in.check = true

  2. Агрегация типов оплат в программном печатном и фискальном Z-отчётах
    Включите настройку в базе данных set на сервере SetCentrum/SetRetail: : print.subpayments.in.report

Если соответствующие настройки отключены - агрегация по subclass и paymentServiceId производится не будет.

 

Отчет по операционному дню

На сервере SetRetail10 → Операционный день → Чеки → Транзакции оплаты - добавлено поле “Платежный сервис”, в котором требуется отображается информация, полученная из выгрузки чека и параметра paymentServiceId.

image-20260319-122759.png

 

Ограничения

  • Для мерчантов:

    • все запросы на СБП автоматически маршрутизируются в УПК

    • логика кассы не изменяется

  • Ограничения по цифровому рублю:

    • возвраты и rollback временно не поддерживаются

    • при попытке возврата возвращается ошибка

  • Агрегация оплат:

    • работает только при включенных настройках

    • иначе данные отображаются без детализации по сервисам

 

Перерегистрация статичной кассовой ссылки

https://crystals.atlassian.net/browse/SRTZ-4569

https://crystals.atlassian.net/browse/CR-14921

10.4.27.0

Описание

Функциональность позволяет выполнять повторную привязку (перерегистрацию) статичной кассовой ссылки Газпромбанка (ГПБ) для оплаты через СБП, если она уже была зарегистрирована на другом терминале. Система контролирует допустимость операции на основе прав доступа пользователя, предотвращая несанкционированный перенос ссылок между кассами.

Ценность

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

Пример работы

  1. Кассир в меню банковских операций выбирает функцию настройки кассовой ссылки для процессинга «Газпромбанк (СБП)».

  2. Система выводит запрос на сканирование QR-кода кассовой ссылки.

  3. Кассир сканирует QR-код, после чего касса получает ответ от банка о том, что ссылка уже привязана к другому устройству.

  4. При наличии прав доступа касса отображает диалоговое окно: «Кассовая ссылка уже привязана на другой кассе. Хотите заменить?».

  5. Кассир нажимает кнопку Да, система отправляет запрос на перепривязку и выводит сообщение «Ссылка успешно сохранена».

Ограничения

  • Перерегистрация кассовой ссылки в интерфейсе касс самообслуживания (SCO V3) в текущей версии не поддерживается.

  • Для изменения привязки на SCO V3 требуется ручная корректировка параметров на сервере SetCentrum/SetRetail10 в базе данных set таблица sales_management_properties → property_key=cashLinkID.

  • Операция возможна только в рамках одного мерчанта (Merchant ID) и расчетного счета (Account).

Настройки

Для настройки возможности перепривязки кассовых ссылок выполните следующие действия на сервере SetCentrum/SetRetail10:

Сервер

  1. Перейдите в раздел Персонал → Роли кассиров → выберите роль для редактирования.

  2. Назначьте требуемым ролям привилегию Меню → Перепривязка кассовой ссылки.

  3. Откройте раздел Интеграция → Внешние процессинги → Газпромбанк (СБП) и убедитесь, что процессинг «Газпромбанк (СБП)» добавлен.

  4. Перейдите в Кассовый модуль → Шаблон касс → выберите шаблон клавиатурной кассы для редактирования → вкладка Интерфейс → кнопка РЕДАКТИРОВАТЬ КОНФИГУРАЦИЮ → на требуемые раздел меню добавьте кнопку Банковские операции.

Касса

На кассе в режиме инженера проверьте, что процессинг задействован, а также параметры процессинга сервиса проверки номеров:

  1. Что введен актуальный Merchant ID и номер расчетного счета (Account) в конфигураторе банка на кассе.

  2. Выполните проверку связи с сервером процессинга для подтверждения корректности настроек, например тестовой продажей.

Статьи по теме