Создание статических кодов оплаты в Системе Быстрых Платежей.
«…если вам, как истому джентльмену, взбредёт на мысль делать записи на манжетах, вам придётся писать мелом.»
О.Бендер «Золотой теленок»
Цель данной статьи - поделиться практическими советами и замечаниями, которые я хотел бы услышать перед началом работы над проектом (проект я выполнил, так что данная статья является описанием моего опыта и работа над ошибками, и я надеюсь, что кому-то сбережет немного нервов и времени).
Если вкратце, то поставленная задача выглядела так:
Клиенту было необходимо создавать qr-коды для оплаты своей продукции в СБП. Коды должны быть статическими (бизнес клиента связан с самообслуживанием на доверии). Коды должны были создаваться и печататься из 1С инструментами клиента.
Для тех, кто не знаком с СБП и основными понятиями, есть очень хорошая статья: СБП C2B Снаружи и внутри .
Из поставленной задачи и материала статьи я вынес следующее: необходимо сформировать статический (динамический не устраивал клиента ограниченным (пусть и очень большим) сроком жизни) платежный код в системе СБП с указанием в коде номенклатуры, суммы платежа, точки реализации.
Первый шаг - это получение первоначальной информации и инструментов (доступа) для работы с контуром СБП. Для этого необходимо обратиться в отдел автоматизации банка клиента (описание API, данные для авторизации и пр.). Отдел автоматизации выдаст документацию, доступы к тестовому контуру (аналогу СБП для отладки и проверки работы реализуемого функционала).
Вторым шагом будет необходимо ознакомиться с работой http-запросов. Ссылки на статьи и ресурсы давать не буду – их много как в сети, так и в роликах на youtube.com. Но необходимо чётко уяснить отличия между запросами get, post, put.
Для авторизации в СБП используется протокол OAuth2.0. Статья: OAuth 2.0 простым и понятным языком. Если резюмировать – то мы получаем токен, значение токена вставляем в заголовок наших запросов (поле с токеном в заголовке каждого нашего запроса), работаем дальше согласно документации. Если время жизни токена истекло, токен неверен, токена нет – запросы не обрабатываются, программный модуль не работает.
Третий шаг – получить возможность посмотреть то, что отправляется на сервер (тестовый контур) СБП из 1С – а именно: заголовки и тело запросов.
Для проверки содержания запросов я использовал Fiddler Classic – программа, позволяющая поймать исходящий запрос и посмотреть его содержимое. Fiddler ставится без проблем, однако для работы с протоколом https необходимо его настроить. Статья: Запись web-запросов с помощью Fiiddler - и мы можем смотреть исходящие запросы. Без этого – никак. При обращении в спорных ситуациях к тех.поддержке банка – лучше сразу отсылать заголовки и тело запроса – сбережет время.
1С и HTTP. Если вкратце для себя (подробно – в документации): создаем соединение, создаем запрос, используя метод соединения, посылаем запрос. И тут самый главный вопрос, который я задавал себе: где get, put, post? Итак, на языке 1С это будет звучать так: get - Получить, put – Записать, post – ОтправитьДляОбработки. Вот, собственно, и все волшебство. Установка заголовков и тела в запросах описаны в документации.
Тут можно сказать, что есть такая вещь, как библиотека Коннектор (https://github.com/vbondarevsky/Connector) в 1С. И не нужно переводить запросы в своей голове на язык 1С и обратно. И удобно, и понятно, и легко. Но суть в том, что код 1С для запрашиваемого заказчиком функционала работы в СБП оказался краток, прозрачен и прост, и использовать библиотеку Коннектор я посчитал избыточным (впрочем, это мое личное мнение).
Следует отметить, что большим откровением для меня стало получение, а точнее преобразование, текстовой строки в двоичный код. Схема получения qr-кода следующая – отправляем наименование и сумму – получаем картинку. Но картинка приходит в символьном виде. И тут мне (нам всем) помогла функция Base64Значение. И уже полученные двоичные данные можно сохранять в файл, в базу, выводить «на лету» в картинку печатной формы – вариантов масса.
Стоит отметить, что по требованиям банка придется реализовать и отладить всю функциональную цепочку (даже если функционал избыточен для вас): создание qr-кода, оплату суммы по коду, проверку проведения оплаты, возврат оплаты покупателю. И только после подтверждения работы всех элементов функционала, отдел автоматизации выдаст учетные данные для работы в реальной СБП.
На этом можно закончить.
Но я продолжу: если что-то не работает - обратитесь в тех.поддержку банка. Тестовый контур не идеален, не стоит думать, что соблюдая все требования документации, вы напишете и получите верный результат. Увы, нет. Обращайтесь в тех.поддержку, не стесняйтесь – сбережёте массу времени и нервов.
Рад, если мои заметки кому-то окажутся полезными. (И да, кода не будет, извините).
