Комментарии 25
Ну раз такая статья публичная появилась, то можно я задам вопросы.
Название ТСП, “имя на вывеске”. А кто решил, что 35 символов на это достаточно?
А почему банк плательщик не может по QRC узнать ОГРН/ИНН того кому клиент переводит C2B средства ДО, того как платеж совершен? Кто решил, что имени юр.лица достаточно.
Очень хочется узнать обоснования, а не отписку "бизнесу это не надо".
Название мерчанта на вывеске сделали по аналогии с карточными платежами, так было удобно банкам-эквайрерам.
ИНН, ОГРН, а также счет и банк обслуживания действительно не отдаются банку плательщика при сканировании. Вы думаете, это нужно клиенту-физику до платежа? Вот плательщику-юрлицу это нужно и он это получит в B2B-платеже, но это отдельная история.
Тем не менее, я рад Вас видеть снова среди первых комментаторов!
сделали по аналогии с карточными платежами, так было удобно банкам-эквайрерам.
Оплата по картам и оплата по СБП вообще мало пересекаются. Это разное ПО и разные правила. Чего уж тогда не ограничили an22 (поле 43 ISO 8583) для "полной совместимости" (сарказм)
Вы думаете, это нужно клиенту-физику до платежа?
Физику может и не особо нужно. А вот банку плательщику ДО того как выполнится B05 это не помешает. Например в системах фрод мониторинга банка:
Защитить своих клиентов от платежей в ИП/ООО/.. типа "Рога и копыта".
Контроль по законам связанным с "спонсирование терроризма" и пр.
Определить какой ЭБД{107} выставить в B05
По факту, сейчас, банк плательщик узнает кому клиент средства перечислил уже только после перечисления. Когда дергаться поздно.
А самое забавное, что есть уже V3 запроса получения инфы по QRC и ничего не стоило туда добавить ОГРН/ИНН (как это сделали для QRC с "привязкой счета"). Но упорно НСПК не добавляет это без сомнения полезную информацию для банка плательщика.
Все равно, рак на горе свиснет и ЦБ наконец сообразит, что переводы C2B на счет ИП однодневки - это способ и мошенничества и спонсирования "нежелательных" организаций и обязует либо СБП либо банки контролировать эти переводы (сумма/возможность).
А что насчёт пользователей из других стран? Они смогут оплатить таким образом?
Это Система БЫСТРЫХ платежей - то есть деньги переводятся на счет продавца раньше, чем покупатель залочил и убрал телефон
Это частичная правда, есть еще время прихода информации из банка до кассового ПО, мне пришлось ждать 30 секунд последний раз, что делает этот тип оплаты бессмысленным на данный момент.
А если поймет, что при использовании оплаты СБП он на рубль меньше тратит (то есть на рубль больше зарабатывает) - он будет давать бонус или скидку
Но он не дает. Вывод - возможность платить QR-кодом есть, но смысла в этом сейчас нет.
есть еще время прихода информации из банка до кассового ПО
Зачем ждать взаимодействие банка и кассового ПО? ОПКЦ сам напрямую отправляет callback в кассовое ПО, см шаг 8
Я лишь описываю реалии, когда оплата проходит по бумажному коду у кассы.
По честному, рынок еще учится поддерживать новые схемы оплаты. При взаимодействии с НСПК ответы идут моментально. Банки могут делать моментальные уведомления также, но у рынка разный опыт. Такие особенности рынка наверняка выровняются в ближайший год. А в каком магазине была задержка? Можно будет понять банк и подкорректировать сценарий.
В нашем случае для касс мы советуем использовать ограниченный срок жизни QR и опрашивать статус до 5 минут раз в секунду. Тогда никаких задержек быть не должно после оплаты.
Это была пиццерия, ее банк тиньков, если правильно запомнил. Еще раз повторюсь, код был на бумажке у кассы, никакого динамического кода не предусматривалось, сумму вводил руками. Подозреваю, там нет постоянного полинга, ибо трафик, и, если прикинуть масштабирование, банку тоже такой постоянный искусственный DDoS от миллиона точек совсем не нужен. Есть ли там SSE под капотом - большой вопрос.
Понятно что на Шаге 4 надо проверять правильность составления распоряжения, но почему бы не проверить
"у банка отозвана лицензия, это одноразовая ссылка и она уже была оплачена раньше и т.д."
на втором Шаге?
А еще можно проверить остаток/лимит на счете клиента и остаток банка плательщика в РКЦ.
Верно, на втором шаге (получение информации по предстоящему платежу) покупатель получит отказ, если на этот момент истек TTL для ссылки/QR или если это попытка повторно оплатить одноразовую ссылку.
Но проверять состояние счетов продавца и самого банка в этот момент рано - между первой и второй диаграммами может пройти какое-то время, а за это время много чего может случиться.
СПокупатель сканирует QR-код (или NFC-метку) телефоном (камерой в приложении банка, обычным приложением “камера” или специальным “сканер штрих-кодов”). Смартфон покупателя, разобрав QR-код (NFC-метку), получает ссылку вот такого вида:
Тот QR-код, что на чеках, похоже, специально не стали делать url-ом. А тут почему сделали? Злоумышленник же может просто наклеить свой QR-код поверх настоящего и увести потенциального покупателя на фишинговый сайт. Где, не разобравшись, можно ввести что-нибудь вроде 'введите код из SMS, пришедшей на телефон'.
Почему нельзя было сделать так, чтобы данные кода был в формате, который понимался бы исключительно предназначенным для этого приложением? Хотя бы при помощи регистрации предназначенной для этого URI схемы:
nspkpayto:AS100001ORTF4GAF80KPJ53K186D9A3G?type=01&bank=100000000007&crc=0C8A
или даже использования существующей payto
Нестандартная ссылка - иллюзорная защита от фишинга. В случае СБП мы советуем всем сканировать QR именно из банковского приложения. Тогда фишинг невозможен.
В любом случае, клиенты привыкают к переадресации в приложение банка. Если его нет, то сайт\ссылка странные и это нестандартный сценарий. Даже если бы обычной ссылки в QR от НСПК не было, то ничего не мешало бы размещать ссылки на левые сайты в мошеннических QR. Пользователь либо будет видеть, что это не банковское приложение, либо нет.
В любом случае, клиенты привыкают к переадресации в приложение банка.
Это работает, если приложение уже стоит. А что произойдет, если нет? Жертва (которую уболтали оплатить при помощи QR) успешно увидит в браузере чего-нибудь похожее на интерфейс оплаты, который будет нарисован мошенниками.
Логично, но такая штука провисит до первой оплаты в ритейле. У клиента сразу возникнет вопрос - я оплатил, а где товар? Кассиру придется объясниться что там за левый QR на кассе. :)
Сейчас в ссылке НСПК уже размещает список банков, а будет и платежная форма с прямыми ссылками на каждое банковское приложение. Это облегчает обучение пользователей.
А возврат товара как происходит?
Примерно так же, как и покупка, только зеркально. Продавец инициирует транзакцию, покупатель (получатель возврата) определяется по номеру телефона, а дальше примерно то же самое - проверки в ОПКЦ, подтверждение из банка получателя, что готовы принять деньги, поручение в РБ и уведомлеие банков, что перевод успешно выполнен.
Опять же - секунды, а не "сохраняйте чек до поступления денег"
Коллеги! А где можно найти описание API/правил для генерации QR кодов для оплаты через СБП? Можете кинуть в меня пару помидоров, но я пока не нашел. Все вот эти вещи: тип ссылки, сумма к оплате, redirect URL, TTL... Хотим внедрить этот функционал в наше кассовое ПО, где документацию посмотреть?
https://sbp.nspk.ru/api/ — не оно?
Описание API здесь: https://sbp.nspk.ru/api/
Но прошу не использовать статью как чёткое описание интеграции. У меня многие вещи упрощены, цель-то была иная
То есть организация сама ничего не внедрит, судя по API:
https://sbp.nspk.ru/api/#tag/LegalEntity, Продавец сам не может регистрировать в СПБ ни юрлицо, ни ТСП, как это дает понять п.1
https://sbp.nspk.ru/api/#operation/createQRC, Продавец сам не может генерировать ссылку, как это обещано в п.2
В любом случае требуется agentId, да и прямым текстом пишите в API, что такие-то вещи должен делать агент.
СБП C2B. Снаружи и изнутри