Комментарии 104
Остаётся вопрос: почему при СБП-переводах по номеру телефона отображается полное имя или фамилия получателя, а не маскированное обозначение со звёздочками. Фактически отправитель должен самостоятельно указывать имя получателя для подтверждения перевода, а не слепо переводить деньги, при этом раскрывая персональные данные любому, кто просто вводит номер телефона.
От фамилии только первая буква показывается. Показывать имя и отчество (не у всех банков) это вынужденная мера для контроля, нужная в первую очередь отправителю, т.к. в номерах телефонов нет контрольного разряда, поэтому опечатка в одной цифре с большой вероятностью приведет к отправке денег к постороннему человеку. Лучше проверить кто получатель до отправки, чем потом проходить непростой квест по возврату денег.
Это решается проверкой имени, которое вводит отправитель. Сейчас же вводим номер и сливаем ПДН, в угоду скорости отправки денег.
Имя + одна буква фамилии + одна буква отчества — это не ПНД
Отображение:
полного имени или
имени + первой буквы фамилии/отчества
при СБП-переводах по номеру телефона — это обработка и раскрытие ПДн.
Даже один номер телефона уже может считаться ПДн, если:
он привязан к конкретному человеку,
используется в системе, где личность абонента известна (банк, СБП).
А в связке с:
именем,
первой буквой фамилии/отчества,
это уже устойчивая идентификация.
Побольше инфы бывает. Смотрю интернет банк своего банка. Ввел случайный набор цифр в поле телефон. Вижу: Сергей Павлович Ф, основной банк ВТБ, еще есть Сбер, Т-Банк, МТС и Яндекс.
Вообще, СБП не дает Отчество, такое просто отсутствует в API.
Если видите отчество, то это ваш банк обогащает данные. Но это нарушение законодательства и можно лишить лицензии за такое дело.
Согласно регламенту использования СБП, банкам запрещается при использовании СБП обогащаться своими данными платежи.
Можете дать название банка?
Вообще, СБП не дает Отчество
Дает, смотрите мой пост выше, или просто наберите левый телефон в своем интернетбанке, тут зависит от банка.
Название банка дайте. СБП физически не может дать Фамилию. API контрактом это не предусмотрено.
Еще раз. СБП, не дает фамилию. Это не зависит от банка.
Может быть сценарий, если вы еще не выбрали платеж по СБП, он может из своих внутренних баз данных подтянуть. Но когда вы делаете платеж по СБП, перед вами только Имя и первая буква фамилии.
И еще раз. Само СБП вообще не передает фамилию целиком. Это физически не предусмотрено.
Название банка дайте
Ниже дал
СБП физически не может дать Фамилию
речь была про отчество
И еще раз. Само СБП вообще не передает фамилию целиком. Это физически не предусмотрено.
Да ну... ЭБД{50} и ЭБД{51} Вам о чем то говорит? А ЭБД{74} и ЭБД{75}?
Ну вот когда чего то не знаете, то пожалуйста, не надо столь уверенно что то заявлять. Банк (и отправитель и получатель) знает ФИО и отправителя и получателя. И прочие данные (какие предоставлены). Как минимум для того, что бы сходить в системы (свои и пр.) фрод мониторинга и узнать "а можно ли?"
Показ PAM - это стандартная практика при денежных переводах (и не только СБП).
PAM Плательщика/Получателя не относится персональным данным. Это не полное ФИО. Ничего кроме PAM + номер телефона в ДБО приложении клиентами никто и не показывает..
Уж лучше, так чем случайно попасть под "финансирование терроризма и прочую хрень.
Я, кстати, поражаюсь людям, которые С2С переводом шаурму на пляже покупают (условно), делая переводы совершенно незнакомым людям.
НЕ товарищу майору все равно будет. Ему галочку если что в плане поставить.
Вероятность всегда есть попасть под каток.
Да. Признаю ошибку. В противном случае тот же 115-фз невозможно будет исполнить.
ЭБД не знаю что такое, но чисто логически подумав, банк получатель должен делать проверку входящих платежей.
"ЭБД" и "{число}" - это характерная особенность документации НСПК (СБП). В частности, описание протокола "Банк Участник<->СБП" для "2" ('_' это буквы C,B,G,M,S,..)
Протокол был в "девичестве" (до изнасилования его НСПК) XML на базе ISO 20022.
так что мой вопрос про знание "ЭБД" и конкретных идентификаторов полей был "контрольным" на знание темы.
Вот тут вообще не соглашусь. Но повторюсь, был не прав, в части того что контракты СБП, не предусматривают передачу полного ФИО отправителя банку получателю в сценарии с2с.
Теперь, относительно того, в чем вы заблуждаетесь.
Не надо путать знание протокола и контрактов. Знание того же soap, не даст вам знание конкретной реализации того или иного эндпоинта. Так и тут, стандарта ISO 20022 не даст знание реализации контрактов на основе данного стандарта.
Контракты СБП, регламентируются соответствующими приказами ЦБ РФ, и если приказ запрещал бы передавать банку получателю полное ФИО, то даже при наличии соответствующих ЭДБ в описании протокола СБП, их бы не передавали бы в соответствующем контракте. В ЭДБ есть коды, где предусматривается и передача ИНН и адреса. Их передают в ситуации с2с? Нет. Обязательны ли они? Да, но при наличии соответствующих условий, которые регулируются регламентами ЦБ РФ, а не общераспространенным стандартом
Иными словами, вам нужно было не ЭДБ приводить, а соответствующие нормативные документы ЦБ РФ. Повторюсь, не надо путать протокол и контракты.
Далее. Не понял фразу.
Протокол был в "девичестве" (до изнасилования его НСПК) XML на базе ISO 20022.
СБП как был построен на базе ISO 20022, так и до сих пор на нем стоит. Более того, ЦБ РФ вообще всю национальную платежную систему переводит на ISO 20022.
В качестве пруфа, приведу конкретный регламент ЦБ РФ.
Письмо Банка России от 11 марта 2024 г. N 12-4-2/1643 “О применении статьи 7.2 Федерального закона N 115-ФЗ”.
Там черным по белому упоминается B05-pacs.008.001.07. Поясню, pacs.* — это семейство сообщений ISO 20022 для межбанковского обмена.
Почему, есть заблуждение, о том, что СБП был ранее ISO 20022, а потом его ЦБ исковеркал. Потому что идет путаница, между ядром и прикладным интерфейсом. Если та или иная система использует ISO 20022, это не значит что она должна использовать только XML. Это обычная мировая практика, над ядром выстраивать свой интерфейс. Идеология ISO 20022 в том, что оно дает универсальное ядро, но при этом не делает каких либо ограничений по внедрению надстроек над ним.
Далее. Не понял фразу.
Давайте определимся. Либо Вы знаете и работали над реализацией ВСЕХ вариантов платежей (как я) или основываетесь на косвенных данных.
Я так каждый день дорабатываю сервисы по очередным бюллетеням НСПК. И делал ВСЕ варианты переводов и регулярно логи с боя/песочницы анализирую (на предмет очередной недокументированной неожиданности)
Поболтать на тему как в НСПК менялась команда и какой замечательный микс протоколов json и XML получился и прочее и прочее я бы не против (претензий к архитектурным проблемам и некоторой упертости архитекторов в НСПК у меня накопилось много).
Но не на этом ресурсе. Да и вообще не на публичном месте.
А что я противоречивого сказал?
Если кратко:
Знание кодировок ЭБД ничего не дает, для понимания того, передается полное ФИО или нет. Надо читать соответствующие регламенты, описывающие разные сценарии СБП. И повторюсь, я оказался не прав насчет полного ФИО во взаимодействии ОПКЦ - банк-получатель.
СБП, как был ISO 20022, так и остался. Все остальное, откровенная вкусовщина и не вижу в ней особых проблем.
Знание кодировок ЭБД ничего не дает, для понимания того, передается полное ФИО или нет.
Ээ.. странное заявление.
Я вам говорю что работаю постоянно в этой теме. И, соответственно, знаю какие поля "Обязательные" или "Опциональные". Хотя бы потому что это ЯВНО прописано в документации прямо рядом с тем где поле описывается с учетом сценариев и пр..
А Вы мне "знание название полей не дает информации о..".
СБП, как был ISO 20022, так и остался.
Мы уже выяснили, что фактически протоколов (а там рядом с XML еще много чего наляпано, по разным причинам) обмена с СБП Вы не знаете (как минимум, документации нет/не читали).
Но при этом делаете какие то выводы и наблюдения.
Впрочем, какое мне до этого дело...
Я вам говорю что работаю постоянно в этой теме. И, соответственно, знаю какие поля "Обязательные" или "Опциональные". Хотя бы потому что это ЯВНО прописано в документации прямо рядом с тем где поле описывается с учетом сценариев и пр..
А Вы мне "знание название полей не дает информации о..".
Стандарты ОПКЦ СБП могут меняться. В одной версии определенный ЭБД может быть необязательным, а по прошествии нескольких лет, тот же самый ЭБД в том же самом сценарии может уже стать обязательным. Поэтому, знание того, что такое ЭБД есть, не дает знание того, обязательно оно или нет. Надо брать актуальную версию стандарта ОПКЦ СБП, который регламентирует интересующую вас операцию.
Мы уже выяснили, что фактически протоколов (а там рядом с XML еще много чего наляпано, по разным причинам) обмена с СБП Вы не знаете (как минимум, документации нет/не читали).Но при этом делаете какие то выводы и наблюдения.
По СБП все достаточно прозрачно. Ядро работает на основе стандарта ISO 20022. Для понимания, вот какое разделение:
Сообщения ISO 20022 (pacs.*) между банком и ОПКЦ СБП. Это платежный канал, где и живет xml.
JSON/API, с которым вы работаете, это ТСП/агент/эквайерский/ит.д. контур. В рамках данного канала невозможно произвести перевод денег, перевод денег проходит через ISO слой.
Также можно выделить 3-ий слой, который видят обычные пользователи в виде конечных QR, ссылок и прочего.
П.С. Насчет читал/не читал документацию СБП. Бюллетени НСПК которые вы выше упоминали не держал в руках, каюсь. Зато читал стандарты ОПКЦ СБП, а также iso 20022. Поэтому понимаю чем отличается pacs сообщение, от JSON контракта ОПКЦ (все же правильнее так называть, а не НСПК, так как стандарты черным по белому так и пишутся, Стандарт ОПКЦ СБП....., а не НСПК).
ЭБД не знаю что такое
Зато читал стандарты ОПКЦ СБП
Не сходится у меня.. эти два заявления.
в документации НСПК (извините.. все для СБП пишет НСПК)
нет фактически ни одной страницы где нет аббревиатуры ЭБД (Элемент Бизнес Данных). Везде есть.
Не только в бюллетенях. Но и в "Стандарт ОПКЦ СБП. ___", в XML примерах, и xslx таблицах условий использования и пр.
Впрочем. Вот зачем я то все пишу. Какое мне в сущности дело до того что Вы знаете, а что не знаете.
Вы спросили, про 50, 51, 74 и 75 ЭБД. Коды не знаю наизусть, это имел в виду, а не что такое ЭБД вообще. Что такое ЭБД вообще, знаю.
Но согласен, формулировка моего ответа выглядит так, что я вообще не знаю что такое ЭБД, тут прошу прошения.
Если этот момент прояснили... повторюсь:
Знание перечня ЭБД, не дает знание правил форматно-логического контроля со стороны ОПКЦ СБП по тем или иным контрактам. Для этого надо открыть действующий Стандарт ОПКЦ СБП, а не просто знать перечень ЭБД. Более того, Стандартов ОПКЦ СБП, более одного. Если в одном есть описание конкретного ЭБД, то это вам абсолютно ни какой информации не даст о том, как ЭБД применяется в другом стандарте. Иными словами, одно и тоже ЭБД может применять не только в разных операциях, но нужно открывать соответствующий стандарт. Например, вы прочитали стандарт Стандарт ОПКЦ СБП "Протокол и основные функциональные требования (C2B и B2C)", узнали что есть такие это ЭБД. Теперь что, можете B2B-шные операции реализовывать? Нет. Надо открывать другой Стандарт ОПКЦ СБП "Протокол и основные функциональные требования (В2В)".
СБП - это ISO 20022. Ни кто его не коверкал/насиловал. Pacs сообщения СБП соответствуют ISO 20022 без искажений. У ISO 20022 своя задача, у JSON/API от ОПКЦ СБП своя.
Здравствуйте. Во первых - Ваше утверждение "...Банк (и отправитель и получатель) знает ФИО и отправителя и получателя" совсем не означает, что при этом банки передают эту полную инфу между собой при СПБ. Каждый из банков сам независимо может проверить ФИО на антитеррор по своим прямым каналам без передачи этой инфы в другой банк.
Во вторых - банк отправитель может не знать полное ФИО получателя, как вам уже писали. И банк получатель может не знать полное ФИО отправителя, если передана только первая буква фамилии. Поэтому Ваше утверждение неточно.
совсем не означает, что при этом банки передают эту полную инфу между собой при СПБ.
Вот я же вроде бы написал, что занимаюсь разработкой ПО для СБП переводов и прекрасно ЗНАЮ что по факту передается (вот блин вижу глазами в логах).
Даже если забыть про то, что это обязательных поля в протоколах СБП (С2С, например)
Так нет же.. "не означает"...
Вы работает с этим? Явно нет.
Так чего же строите гипотезы и пытаетесь спорить с человеком которые это просто ЗНАЕТ.
Можете дать название банка?
Совкомбанк
Можете дать название банка?
Сбербанк, например. Он ещё по госномеру автомобиля даёт интересную информацию.
Пользователю лучше ничего не вводить, это не удобно в первую очередь
Персональные данные имеют разный уровень чувствительности, это закреплено законом. Перс.данные в СБП, имеют самый низкий уровень.
Далее. Вот сравним МИР и СБП
МИР - карточная модель:
карта - анонимизированный платёжный инструмент
проверка получателя лежит на:
мерчанте.
терминале.
и т.д.
В СБП :
перевод напрямую человеку.
по номеру телефона.
без посредников, поэтому требуется человеко-читаемая валидация.
Как итог: без минимального уровня перс.данных, платеж в СБП нельзя осуществлять, но при этом это самый минимальный уровень чувствительности персональных данных.
Тезис о «минимальном уровне чувствительности» не снимает требований минимизации и неизбыточности обработки ПДн.
То, что перевод в СБП идёт напрямую человеку, не означает необходимость раскрывать его полное имя любому, кто ввёл номер телефона.
Человеко-читаемая валидация возможна без раскрытия ПДн.
Например, в Турции при быстрых переводах по номеру/IBAN отображается маскированное имя (A* Y***)**, а отправитель обязан сам подтвердить получателя, ориентируясь на эти данные. Идентификация работает, платежи осуществляются, ПДн не раскрываются полностью.
Следовательно, показ полного имени в СБП — это выбор реализации, а не техническая необходимость.
Закон о персональных данных с этой целью и ввел градацию по уровню чувствительности ПДн.
Регуляторика уровней чувствительности ПДн, это своеобразный уровень удобства использования ПДн.
СБП, это быстрый платеж в один конец, и тут не подходит традиционная логика анонимных платежей карточной системы.
Важно, учитывать менталитет страны. Вы привели в пример Турцию, но там другой менталитет, там традиционно такие платежи было принято делать по заранее согласованности, тоесть, перед переводом, проводились более трудоемкие с обоих сторон шаги, для осуществления перевода. Именно на эту культурную модель и ориентирована FAST.
СБП же имеет другую базисную культурную модель, антипод системы МИР, максимально быстрая и удобная в плане UX модель. Когда можно по номеру телефона + Имени с инициалами за считанные секунды определить, правильно ли данные введены.
Как итог. СБП используют все, и не кто не плачется о персональных данных. Это тот самый момент, когда в требованиях к системе предложили оптимальный баланс.
Важно, учитывать менталитет страны. Вы привели в пример Турцию, но там другой менталитет, там традиционно такие платежи было принято делать по заранее согласованности, тоесть, перед переводом, проводились более трудоемкие с обоих сторон шаги, для осуществления перевода.
Однако, нововведения, что планируются (QR на стороне физика-получателя, платежные ссылки, которые можно отправить) -- это и есть дополнительные 'трудоемкие шаги'. Так что менталитет ту не настолько жесткий, можно было попытаться немного подправить.
Номер телефона заменили на QR-код/ссылку. Вместо ввода телефона, просто используете камеру. Где тут дополнительный шаг? Это замена одного идентификатора на другой.
Система как была из двух шагов, так и осталась:
Ввод идентификатора на выбор из варинатов.
В ручную через номер телефона
Через камеру по QR-коду
По ссылке
Верификация получателя со стороны отправителя.
Где тут дополнительный шаг?
Получатель должен их сгенерировать и сообщить отправителю. Просто по номеру телефона он может быть совершенно пассивен.
Не важно, как были 2 шага, так и остались.
Но... если рассуждать в вашем русле. Как много используют QR-код для СБП, в каких случая? Когда нужен конвейер.
Ваша ошибка в том, что вы не правы, что получатель может быть пассивен.
Например, рассмотрим кассу, через которую проходит большое количество платежей.
Если нет QR-кода, кассиру каждый раз надо говорить свой номер телефона и Имя + инициалы.
Если есть QR-код, достаточно просто его наклеить. Да, первоначально это затратно, но в последствии это экономит время.
Повторюсь. Это лишь дополнительные сценарии ввода идентификатора получателя. QR-код и ссылки, используются в основном между физ и коммерсантами. А номер телефона между физиками.
QR-код и ссылки, используются в основном между физ и коммерсантами.
Так перевода(не оплаты) для физиков их еще и нет вроде бы? Только планируется.
Да. Потому что физикам удобнее по номеру телефона. Что и доказывает, для разных сценариев, свой способ ввода идентификатора.
Это не дополнительный шаг, а лишь выбор способа ввода идентификатор, согласно удобству. Вот и все.
Потому что физикам удобнее по номеру телефона.
При общении голосом. При текстовом - отправителю удобней тапнуть по сслыке, чем телефон вводить.
Правда, гарантирую, что такие ссылки начнут немедленно присылать мошенники, прятать их под картинками на сайтах и делать прочие гадости.
Возможно именно из этих соображений их изначально и не было.
Время покажет. В Газпромбанке уже работают QR
https://nspk.ru/press-center/details/3ed67bc6-cf38-4468-8e57-f3f53bae839d
https://pnz.ru/finance/perevody-po-sbp-budut-osushhestvlyatsya-po-novym-pravilam
Номер телефона заменили на QR-код/ссылку.
Это замена одного идентификатора на другой.
Насколько спорим, что номер своего телефона Вы по памяти назвать сможете, а вот QR-ссылку нарисовать...
Все верно. Предоставление нескольких способов ввода идентификаторов, дают удобство в разных сценариях. Как выше и писал. Для перевода между физиками, проще номер телефона. Вы правильно отметили.
Для взаимодействия с условным магазином, тут qr код обычно удобнее, так как можно легко через смартфон оплатить, наведя камеру.
Разделение персональных данных по уровням чувствительности не означает, что даже «низкий уровень» можно свободно раскрывать всем подряд. Принцип минимизации всё равно должен соблюдаться.
По факту текущая реализация СБП породила отдельный класс мошеннических схем: зная номер телефона, любой может получить имя и инициалы, после чего звонки «по имени-отчеству» выглядят для человека убедительно и вызывают доверие. Это не абстрактный риск, а прямое следствие архитектурного решения.
Аргумент про «менталитет» и удобство UX тоже спорный. Безопасность и защита персональных данных не зависят от культурных особенностей, а быстрый и удобный пользовательский сценарий вполне можно реализовать и без полного раскрытия имени — через маскирование и подтверждение данных со стороны отправителя.
То, что системой пользуются все и никто массово не жалуется, само по себе не означает, что баланс найден оптимально. Баланс — это когда задача решается с минимально возможным раскрытием данных, а здесь этот порог, на мой взгляд, превышен.
На основании чего такая аргументация?
Есть статистика использования FAST в Турции, и СБП в России. И статистика показывает то, что СБП удобен для пользователей, с огромным преимуществом в сравнении с FAST.
Далее. По утечке персональных данных. У меня есть опыт в ИБ + моделировал несколько систем по KYC. Поэтому знаком с большинством наборов ПДн в даркнете. Но ни одного набора на основе СБП не видел. А эти набор, по моим наблюдениям покрывают минимум 90% населения.
СБП действительно удобен, с этим никто не спорит. Но аргумент про «лёгкую идентификацию получателя» не требует показа полного имени. Для валидации достаточно маскированного имени со звёздочками и подтверждения данных со стороны отправителя.
Текущая реализация упростила UX, но за счёт избыточного раскрытия ПДн. Это не техническая необходимость и не вопрос популярности системы, а осознанный архитектурный выбор и именно к нему и есть вопрос.
Не пойму. На основании чего вы аргументируете?
Есть уже огромный мировой опыт быстрых платежей. Тут не просто в удобстве дело.
Возьмем Индийский UPI. Из за стратегической ошибки, в силу неправильной оценки социо-культурных паттернов поведения индусов, данная система выбрала неправильную модель, которую вы предлагаете.
Как итог, NPCI перешла на модель, как у СБП.
В общем. Советую почитать историю развития UPI. Это реальная история, изучение которой, даст вам ответы.
В общем. Советую почитать историю развития UPI. Это реальная история, изучение которой, даст вам ответы.
Посылали бы куда-нибудь конкретнее. Это же трудно отгуглить. Одно "В году XYZ интегрировались с тем, в году ABCD - c этим, в году EFGH - начали принимать платежи там-то, в году TYUI- сам-то" находится.
Я аргументирую, исходя из модели идентификатора и вектора злоупотреблений.
В СБП публичный платёжный идентификатор — это номер телефона, который одновременно является каналом связи. Поэтому связка «номер + имя» позволяет не только идентифицировать получателя, но и сразу применять социальную инженерию.
В UPI ситуация иная: даже после перехода к отображению имени, платёж осуществляется по VPA (платёжному ID), по которому нельзя позвонить или связаться с человеком вне платёжного контекста. Это принципиально снижает побочные риски, хотя у UPI есть свои нюансы.
Поэтому мой аргумент не в том, что СБП «неудобна», а в том, что одинаковый UX-подход при разных типах идентификаторов даёт разный уровень рисков, и этот момент в СБП не был компенсирован.
Так и не понял, на чем вы базируете свою аргументацию? Вы можете привести пример того, что какая то система быстрых платежей ушла от модели СБП в сторону более сильного маскирования ПДн?
В свою очередь, вот более полный список систем, которые переходят на модель СБП:
UPI (Индия)
PIX (Бразилия)
Zelle (США)
Faster Payments (Великобритания)
Также, уже и SEPA Instant (ЕС) активно движется в сторону модели СБП.
Данный список покрывает почти все виды идентификаторов, у того же Zelle по номеру телефона можно.
Тэкс. Давайте так. Я не люблю дискуссию без четкой аргументации. Если есть пример, отхода от модели СБП в другую сторону. Буду рад про это узнать.
Системы быстрых платежей в мире уже 10 лет развиваются. Накоплено огромное количество опыта, общеизвестного.
Большинство систем быстрых платежей действительно пришли к похожему пользовательскому сценарию — это нормально для массовых сервисов. Но между ними есть принципиальная разница в идентификаторах.
В UPI, PIX, Faster Payments и SEPA Instant платёж обычно идёт по отдельному платёжному идентификатору — ID, IBAN или случайному ключу. Даже если имя получателя отображается, по самому идентификатору нельзя напрямую связаться с человеком или массово узнавать данные о случайных людях.
Zelle и СБП — особые случаи, потому что там используется номер телефона или e-mail, то есть контактный идентификатор. Именно в таких моделях показ полного имени означает, что данные становятся доступными любому, кто просто вводит номер или адрес. Для проверки получателя этого не требуется — маскированного имени достаточно, при этом скорость и удобство перевода не теряются.
Мы, похоже, по-разному смотрим на баланс UX и приватности, и вряд ли придём к общему выводу. Предлагаю завершить дискуссию.
Почему это Zelle и СБП особый случай? Вообще не пойму, это то как вы аргументировали?
Вот список на глаз:
Swish (Швеция)
Vipps (Норвегия)
MobilePay (Дания)
PayNow (Сингапур)
PromptPay (Таиланд)
BLIK (Польша)
PIX (Бразилия)
UPI (Индия) хотя вы и сказали что не по номеру телефона, но вы ошибаетесь, по номеру телефона тут тоже можно.
Zelle (США)
Confirmation of Payee (Австралия)
Хотя тут могут быть небольшие нюансы, но именно что нюансы. Но эти системы позволяют переводить по номеру телефона.
Список большой. Можете поискать аргументацию против моей позиции, в обсуждении данных систем. Буду рад увидеть.
Если нет, то согласен. Прекращаем дискуссию.
Да, многие из перечисленных систем поддерживают переводы по номеру телефона — с этим никто не спорит. Ключевой вопрос не в том, можно ли перевести по телефону, а в другом:
можно ли, не зная человека, перебором номеров получать его имя в открытом виде.
И вот здесь начинаются различия и «нюансы», которые на самом деле принципиальны:
В большинстве систем (Swish, Vipps, MobilePay, PayNow, PromptPay, BLIK, PIX, UPI) номер телефона — это один из способов адресации, но:
либо требуется, чтобы номер был в контактах,
либо имя показывается ограниченно,
либо нет свободного онлайнового перебора «ввёл номер → получил имя».
Zelle и СБП — особый случай, потому что:
номер телефона выступает публичным платёжным идентификатором,
его можно вводить напрямую,
и система возвращает человеко-читаемое имя без предварительного контекста или согласия.
Именно сочетание трёх факторов —
контактный идентификатор + свободный ввод + явное имя — и делает эти системы отдельным классом, а не сам факт «перевода по телефону».
Поэтому вопрос не в том, что «все системы плохие» или «кто-то откуда-то ушёл», а в том, что при такой модели идентификатора маскирование имени остаётся разумной мерой, не ломающей UX.
На этом, думаю, действительно можно завершать обсуждение — дальше мы просто будем ходить по кругу.
От вас опять не увидел аргументирования.
Упомянули утечку ПДн. Да, в даркнете есть наборы ПДн Россиян.
Самые распространённые, это телефон + ФИО (полное). Но эти утечки не связаны с СБП. СБП уже более 5 лет работает. Я еще не увидел наборов, которые были сформированы из базы СБП.
5 лет уже СБП. Если есть массовые факты использования мошеннических схем, через компрометацию имени через СБП. То было бы интересно об них услышать.
Являюсь аттестованным специалистом по защите ПДн и ИБ-шник (есть корочки соответствующие).
Впервые слышу, о том что есть какая то массовая схема утечек данных через СБП. В 99% случаев, просто покупают базы данных, которые утекают от операторов сотовой связи и прочих организаций, которые в ходе своей деятельности обрабатывают персональные данные.
Поэтому еще раз. Прошу. Аргументируйте свою позицию.
Просто приведите пример уже. Забьем на мировой опыт. Где они дата-сеты из СБП? Сколько сижу на ИБ-шных и около "этих" форумах. Не встречал реальных дата-сетов.
Несколько раз встречал дата-сеты, якобы сформированные на основе СБП, но на проверку они оказались фейковым разводом на деньги.
Речь изначально не про дампы и не про даркнет. Требовать «датасет из СБП» — это подмена предмета обсуждения.
В СБП утечка как дамп не требуется, потому что данные получаются онлайн, по запросу, в реальном времени: ввод номера телефона → получение имени. Это не компрометация базы, а архитектурно разрешённое раскрытие ПДн. Такие данные не накапливаются в виде наборов и потому не появляются на форумах.
Поэтому отсутствие датасетов из СБП ничего не доказывает — ровно так же, как отсутствие дампов CAPTCHA не означает, что её нельзя обойти. Это другой класс рисков, не про утечки, а про массово доступный интерфейс получения ПДн.
На этом аргументация исчерпана. Дальше мы действительно будем ходить по кругу.
Вы с собеседником по разному относитесь к серьёзности происходящего. Напомню, что в свое время были телефонные книги. И никого, кто о их существовании знал (т.е. все?) не должно было удивлять, когда по телефону сразу по ФИО обращались. Потому что они этот телефон только что по этому фио нашли. Или наоборот. И никакого дополнительного доверия это, соответственно, не создавало. И так, если здраво подумать, и должно быть. А вот в какой момент стало
после чего звонки «по имени-отчеству» выглядят для человека убедительно и вызывают доверие.
это было бы неплохо понять.
звонки «по имени-отчеству» выглядят для человека убедительно
Это чистая психология, обращение по имени-отчеству вызывает доверие к тому кто обращается, по крайней мере у старшего поколения кто не в курсе что что все слито в интернет.
Лично я не молодой, но нигде не свечу свое отчество, поэтому обращение по имени-отчеству сразу напрягает, это либо те кто видел мой паспорт, либо мошенники.
СБП не дает отчество. Только имя и инициал. Это архитектурное ограничение. Если банк дает, то скорее всего вы ошибочно используете внутребанковский перевод.
В СБП четко прописано, банк не имеет право по СБП раскрывать отчество.
upd. Проше прощения. Имел в виду что фамилия не отображается. Отчество может быть достаточно часто отображаться.
Это чистая психология, обращение по имени-отчеству вызывает доверие к тому кто обращается, по крайней мере у старшего поколения кто не в курсе что что все слито в интернет.
Берем известную сцену из терминатора. Обращаем внимание на толстенную книгу и ее содержание. Там даже адрес проживания есть. Теперь задаемся вопросом, может ли у адресата звонка в таком окружении возникнуть существенное "вызывает доверие" просто по обращении по полному имени. Когда он знает, что оно все вот буквально любому зашедшему в таксофон известно.
Доверие тут возникает только в том случае, когда мы по какой-то причине решили (а почему мы так решили?) что звонящий может не знать ФИО.
все вот буквально любому зашедшему в таксофон известно.
Мы не в штатах, домашний телефон был далеко не у всех следовательно и в справочнике их не было. Например мои родители смогли поставить только в середине 90х.
Про то что думают психологи по поводу обращения по имени можно в гугле почитать
Напомню, что в свое время были телефонные книги.
А ещё когда-то по всей Москве стояли киоски "МосГорСправки", где можно было адрес и телефон узнать по фио.
Тоесть, подмена обсуждения? В том то и дело, не пойму вашу аргументацию.
Какой класс рисков вы упоминаете? В целом, статистика мошеннических схем известна. Но схему с использованием СБП не слышал. Поясните о данных рисках. Это вообще о чем? Вы уже который пост, умалчиваете. Какие риски то?
В свою очередь, например, в Rabobank, после внедрения механизма Confirmation of Payee, за 9 месяцев с 2017 по 2018 год, снизили на 70% схемы мошенничества с платежными документами.
Да и вообще. Переход на схему в точности СБП или похожие, это мировой тренд, на внедрение Confirmation of Payee. В первую очередь, для снижения рисков в связи с колоссальным количеством мошеннических схем. И как то странно, слышать о каких то рисках на фоне этого, не приводя каких то примеров.
Спасибо за интересную дискуссию! Но вот лично моё мнение, в теме с мошенниками только два пункта!
1.Откуда у бабки десятки миллионов рублей?
2.Если они такие тупые, что их разводят мошенники, только из-за того, что эти мошенники знают как батью звали, то опять вызываем пункт 1!
Цикл продолжается до тех пор, пока у бабки есть бабло, а если нет бабла в десяток млн.руб. сэкономленных из зп или пенсии, то и персональные данные никому и даром не нужны! Вообще не понимаю, как бабка, в прошлом простая советская женщина, накопила миллионы...
"показ полного имени в СБП — это выбор реализации, а не техническая необходимость"
Зануда. Это удобно. А пдн слиты уже сто раз. И хер с ним.
Поясните, как это работает: в кафе я сканирую QR-наклейку (а иногда NFC-наклейку) на стойке, происходит оплата заказа. Следующий покупатель - аналогично. Но сумма заказа разная, QR напечатан и физически не меняется. Как это возможно?
Ссылка ведёт на API сервиса, где за каждым кодом закреплён столик, там формируется ссылка на оплату и вас редирректят на СБП с нужными параметрами в url-е.
Наклейка - ссылка на кассу, при переходит на ней происходит перенаправление на "страницу заказа".
На кассе сейчас под этим QR именно ваш заказ. Потом будет другой.
Коротко: там магия.
Подробнее: в ссылке только id, ведущий к записи в базе с идентификаторами кафе, кассы, банка, счета. В вашем случае кассир для каждой продажи к этой постоянной части генерит переменную часть с суммой и, возможно, составом платежа. Первый покупатель оплатил - эта переменная часть погашается и кассир может прикрепить следующую переменную часть к постоянному куску
Сегодня сотни тысяч банкоматов и POS-терминалов по всей стране принимают карты «Мир», на сегодняшний день их выпущено почти 470 млн шт.
Количество банкоматов в РФ - менее даже не двух, а полутора сотен.
Количество POS-терминалов - почти 5 миллионов.
Суть понятна - СБП круче за счёт мгновенного клиринга. НО главный вопрос - почему в МИР нельзя сделать такой же мгновенный клиринг? Просто вместо "заморозки" денег запускать так же как в СБП процедуру реального перевода и все? Зачем тогда делать платежи по СБП если платеж картой МИР может работать так же быстро и "дёшево". Сейчас же проблема в том что платеж по МИР дороже обходится как раз за счёт клиринга.
Ради совместимости с существующими МПС - чтобы облегчить миграцию.
Потому что это вообще две разные системы, хотя с первого взгляда и имеют одну цель. Мир, это карточная система, которая работает по схеме: авторизация -> накопление операций -> клиринг -> межбанковские расчёты.
Такая система обладает следующими функциональными возможностями: отмена (refund, chargeback), офлайн-платежи, кредитные лимиты, споры и арбитраж и т.д.
Такова архитектура, и если сделать из МИР очередной СБП, то это будет просто очередной СБП, а не карточная система с ее функциональными возможностями. Поменяв архитектуру, мы просто сломаем функции карточной системы, так как все банки работают по утвержденным протоколам и стандартам, согласно которым и выстроена МИР
Добавлю ещё разницу с точки зрения клиента: в случае МИР клиенту на следующий день приходят все деньги одним платежом (за вычетом всяких комиссий и chargeback'ов итд). Сидишь потом разбираешься какие платежи пришли, какие где-то по какой-то причине застряли.
СБП же приходят мгновенно, но выписка по банковскому счету превращается в огромную простыню. Если много платежей - тоже приходится разбираться. Для банков тоже нагрузка прикольная по выгрузке выписок в разном формате.
Из самых приколов: когда юр.лицо по СБП делает отмену платежа (её как таковой не существует), на самом деле делается новая операция по переводу денег по каким-то реквизитам (тут открывается простор для жульничеств, когда оплачивал с одного счета, а возврат делаешь на другой счет). Банки это видят как почти обычный перевод СБП, хотя это обычная отмена перевода.
Из самых приколов: когда юр.лицо по СБП делает отмену платежа
Наблюдал это в живую в Магните. На кассе пробили не тот виноград, покупатель увидел это только в чеке, цена чуть выше была, попросил исправить, а кассир говорит "Пока не могу возврат сделать, нет этого чека в компьютере, надо подождать пока появится"
Основная причина в том, что если провести клиринг, то мерчант должен заплатить за это комиссию, а если просто висит авторизация, то это для них бесплатно.
Например, мерчанты могут взять какой-нибудь депозит в случае аренды, и он может долго висеть в пендинге, и для мерчанта это просто бесплатная страховка, но и деньги клиента, по факту, остаются на его счете, они просто заблокированы. Если деньги не понадобились, мерчант может откатить транзакцию, а если-таки наступил случай, то можно прислать клиринг.
Другой пример: покупки в онлайн-магазинах. Например, я заказываю 10 макбуков, если сразу провести клиринг, то мерчант будет со всей суммы платить комиссию. Но он идет на склад и понимает, что макбуков только 5, он связывается с покупателем и предлагает или отменить транзакцию полностью, или уменьшить до 5. В обоих случаях мерчант экономит существенную комиссию за товары, которые он реально не продал, которая может быть 3-4%.
Если провести клиринг, то дальше можно делать только полноценный рефанд, что, опять же, стоит мерчанту денег.
Разработчики карт. Банки, понятно, не комментируют на этот счет. Но: почему в чипе карты нет приложения-автроизатора. В смысле - почему на этапе разработки не заложили хотя бы как цель второй очереди.
А именно: чтобы привязка приложения к пользователю можно было проводить в виде "приложите карту к телефону и наберите PIN"(не обязательно платежный). После чего по нормальных алгоритмам чип подтверждает, что да, он такого-то клиента чип.
Или оно там есть и банк просто старательно возможность игнорируют?
Банковская карта это практически полноценная смарт-карта, куда можно загрузить разные приложения. В европе в некоторых странах используются, например, пин-генераторы для подтверждения операций, в которые нужно физически вставить карту (не самая удобная штука впрочем).
Но в современных реалиях это кажется уже не таким и безопасным, особенно в том сценарии который вы описали. Много случаев мошенничества, когда жертву просят установить определенное приложение, приложить карту и ввести пин, якобы для подтверждения. А приложение - NFC прокси, которое позволяет с другой стороны имитировать прикладывание карты. И сейчас уже многие банки жёстко ограничивают бесконтактное снятие наличных в банкоматах из-за этого. То же самое возможно и тут.
ного случаев мошенничества, когда жертву просят установить определенное приложение, приложить карту и ввести пин, якобы для подтверждения.
Где много? И много по сравнению с чем? Если станет меньше, чем случаев, когда жертва код буквально сама диктовала мошенникам, без всякой установки приложения - уже хорошо.
Просто дорого. Бабло побеждает всегда.
Было модно (в узких кругах) в годах 2007 - 201x эту тему мусолить.
в 2009 чуть ли не 10ке стедов на Cartes валялись эти "локальные чиповые ридеры с экранчиком и клавиатурой". MasterCard запатентовал. Расчет одноразового кода на основе ARQC от карты.
Но 3d-secure (Visa) в итоге победила.
В России попытки внедрить это уперлись в вопрос "а кто платить будет за железки" и дальше редких пилотов не пошло.
SMS дешевле для банков. А push в мобильном вообще "бесплатно".
SMS дешевле для банков. А push в мобильном вообще "бесплатно".
Я не про 'калькуляторы', генерирующие код. Я про общение карты прямо с банковским приложением в телефоне. Тут банку никаких дополнительных железок не надо.
Сейчас теоретически ничего не мешает использовать это, ну например как второй фактор для аутентификации клиента в приложении банка через "читаем карту телефоном".
Но.. (и оно большое "но").
В стандартных HSM чаше всего этой функции нет или она под доп лицензией.
Т.е. для проверки цифрового (6-8 цифр) кода на основе ARQC нужна специальная функция в HSM.
Проверить ARQC в рамках платежа - есть во всех HSM. А вот этой функции обычно нет.
Ну и то, что хотя алгоритмов получения цифр из 8 байтного ARQC + определенные параметры "dummy платежа" можно придумать много, но не забываем, что есть патент MasterCard на технологию/принцип.
И это ставит крест на всех идеях "а давайте сделаем".
Я когда то делал такой функционал в FM прошивке HSM (HSM в девичестве Eracom. Который потом "пошел по рукам").
И даже этот функционал использовался (давно) в нескольких пилотных проектах.
Но.. мода прошла. Требования регуляторов к ПО и прочему повысились и для банков "суета что бы запустить" стала больше чем выгода от "запустили".
Кстати, последний закон насчет НДС на комиссии платежей по картам, означает(IMHO)
Ставка на вытеснение банков как таковых вообще из платежей и перенос все на СБП. СБП это централизировано и подконтрольно. Все же собрать информацию о платежах внутри банка хоть и возможно, но требует от "нетоварища майора" хотя бы каких то бумажек и обращений в банк.
Попытка собрать с населения биометрическую информацию. Путем темы "оплата по биометрии выгоднее". Пока еще мягкая попытка. Но лягушку нужно варить медленно. Потом это станет явно обязательным.
В стандартных HSM чаше всего этой функции нет или она под доп лицензией.
Они же программируемые? И поскольку МИР делали отдельно - можно было приложение написать и вписать "В МИР оно есть"
Ну и то, что хотя алгоритмов получения цифр из 8 байтного ARQC + определенные параметры "dummy платежа" можно придумать много, но не забываем, что есть патент MasterCard на технологию/принцип.
Патентов на алгоритм в России, вроде, нет.
И еще раз - отдельным приложением, что в чипе живет, со своим ключем и всем, чем нужно, а не тем, которое платежное. Вряд ли патенты MasterCard покрывают те способы и протоколы, что в карточках доступа используются, скажем. (Тех что посложнее, с криптографией на чипе).
Ставка на вытеснение банков как таковых вообще из платежей и перенос все на СБП.
Это не отменяет необходимость более адекватной привязки приложения вместо "набери номер карты и введи код из SMS", что у половины банков используется.
Они же программируемые?
"программируемый" HSM сертификацию PCI DSS не пройдет.
Патентов на алгоритм в России, вроде, нет.
У MC запатентован принцип, а не, например, конкретный алгоритм получения + параметры EMV команды. Если, например Крипто Про (или любой другой производитель HSM в России) на это забьет, то проблем нет. Хотя чего им терять. У них HSM - полная копия Thales по API.
Это не отменяет необходимость более адекватной привязки приложения вместо "набери номер карты и введи код из SMS", что у половины банков используется.
вообще я видел (и делал) пилоты, в которые
TOTP в брелке (не в телефоне. а отдельный брелочек с LCD экраном)
Вход в ДБО с использованием PKI карты и ридера.
Использование автономного картридера для генерации одноразового кода (патент MC)
Все это осталось на уровне пилотов. Потому что "кто за это будет платить".
"программируемый" HSM сертификацию PCI DSS не пройдет.
А как проходят сертификацию те карты, что с 'кошельком'? Там тоже два приложения, как я понимаю, стоит. Прямо с завода. Вот и приложение-авторизатор можно так же?
У MC запатентован принцип, а не, например, конкретный алгоритм получения + параметры EMV команды.
Все равно не понял, каким боком тут EMV.
Возможность иметь несколько приложений в смарт-чипе - прямо в спецификациях интерфейса смарт-карт прописана. Свое платежное приложение пусть патентуют сколько хотят. А соседние, которое вообще не даже, по факту, не про проплату - почему их интересуют?
Вон, уже упомянутое приложение 'электронного кошелька' для оплаты транспорта ставят же?
Потому что "кто за это будет платить".
Перечисленные варианты включали ридеры. С тех пор телефоны и карты с NFC стали гораздо более распространенными. Да и контактные ридеры чипов не так чтобы дорогие, если не ставить x10 к цене за сертификации, которая непонятно что проверять должна. При условии, что он универсальный в экосистеме МИР и подходит для всех банков - можно даже клиентов уговорить один купить.
Поэтому платить нужно только за разработку софта, которая размазывается на все карточки. В рамках платежной системы - как-то не выглядит дорого.
Вы не со мной спорьте. А с тор менеджментом банков и НСПК.
Я вас рассказываю, что все это было, но дальше пилотов не пошло, потому что в банках считают, что не окупится. По факту, это то что прямой прибыли не дает.
А вы мне "технически все можно, то почему бы не сделать"
Вопрос "почему бы не сделать" не ко мне.
Поэтому платить нужно только за разработку софта, которая размазывается на все карточки. В рамках платежной системы - как-то не выглядит дорого.
это из серии "что нам стоит дом построить - нарисуем будем жить". разработка ПО - это весьма малая часть затрат. Поверьте, запуск любого нового подобного (и не подобного) продукта это не только "да я тут за 5 минут код набросаю".
Я вот, например, могу сделать оценку (не раз делал подобное) сколько обойдется банку (не ПС)
добавление приложения на карту (не emv, например, что бы еще не иметь проблем с сертификацией в рамках платежной системы)
разработка такого апплета
аппаратная (в HSM) и/или программная реализация сервиса проверки кодов
процедуры обмена ключами/хранения ключей
Объем доработок в ДБО приложениях банка
заказ на персонализацию таких карт с доп апплетом
и пр.. и пр. нюансы которые лень стало писать
Было все это... проходили. Пилоты выпускали. Ну когда это модно было и НСПК (Мир) при гос поддержке еще не монополизировал весь рынок (не было еще НСПК).
Ну, приблизительно, как сейчас MAX. Типа "так народу лучше"
Так что, "Кушать подано. жрите что дают"
Вы не со мной спорьте.
Я не сколько спорю, сколько пытаюсь получить аргументы, почему оно может быть слишком дорого. Вы, кажется, единственный за очень долгое время из мне отвечавших, кто вообще к этому отношение имел.
На фоне расходов разработки МИР/СБП, внедрения прошивок в кассовые машинки для поддержки этого (вот эти все пункты 1-6 тоже явно были и не по одному разу - можно было прицепом авторизатор добавить), разработок и внедрения систем обмена информацией по поводу телефонных номеров и их владельцев, внедрения цифрового рубля, постепенное внедрение ГОСТ-овских алгоритмов -- тут добавление к чипам приложения авторизатора и обучение банковского приложений им пользоваться -- уж простите, мое обывательско-дилетанское сознание мимопроходящего отказывается принимать ответ, что оно слишком дорого для всей банковской системы в целом.
Особенно на фоне того, что, оказывает, социальная инженерия со сценариями, когда мошенникам код диктуют -- это проблема и с ней борются теми самыми системами про телефонные номера. А тут вот решение есть, как этот вариант атаки сразу исключить - и оно не используется.
Как я уже сказал - "Сделать можно практически все". Мой типичный ответ на вопрос "а можно ли сделать" от заказчика. Дальше идет грубая оценка затрат (и не только на разработку) и заказчик решает а готов ли он платить.
Я вот, например, хотел бы иметь полноприводный вариант ВАЗ (типа нивы, но не конструкции начала 70-х). "Но зачем?".
Не Вы и не я определяем это "Но зачем?".
Кстати, фразу "Банкам это не нужно" я от НСПК слышал не раз. В результате, оказывалось (через год два), все же нужно и это тихонечко появлялось в спецификации. В НСПК упертые архитекторы. IMHO
Им все это "А зачем?"
СБП при оплате товаров нормально работает только при условии нормальной мобильной связи. Когда впереди тебя в очереди какое-нибудь чудо пытается оплатить по QR коду ради нескольких рублей возможного кэшбэка и это чудо пять минут ждет вся очередь, начинаешь тихо ненавидеть эту технологию. А так, кроме C2B, полезно.
Клиринг - неизбежно зло, чтобы снизить нагрузку и не гонять сто тыщ мильонов платежей.
А что позволило СБП держать нагрузку? За секунды обеспечивать платеж, в котором столько действующих систем?
Клиринг - неизбежно зло, чтобы снизить нагрузку и не гонять сто тыщ мильонов платежей.
Эти миллионы платежей (сообщения о них) так или иначе есть. И их надо обрабатывать. Что с клирингом что без клиринга.
А что позволило СБП держать нагрузку?
Я так понял - выкинули все лишние. Условно: Было подтверждение "Держи деньги" - "ОК, взял". И после этого считаем, что деньги получены, а не требуем еще всех звеньев цепочки, что в традиционном способе есть. Как когда наличные магазину отдаешь - ту сразу считается, что деньги хозяина сменили, без многочисленных переводов через корсчета в разных банках.
Как бы банально не звучало, но это - развитие вычислительных технологий и коммуникаций. Мощности Расчетного центра, Операционного центра и банков стало хватать на обработку каждой операции отдельно, а не консолидированного клирингового файла - и появилась новая (по сравнению в карточками) архитектура
А существуют ли сейчас средства анонимного перевода небольших сумм наличных денег по СБП? Т.е. уличный терминал, вставляю наличные, ввожу номер телефона адресата или что там у него (qr-код) - и деньги переводятся
а почему банки не начисляют кэшбэк по операциям через СБП ? а за ту же оплату картой начисляют- технически ведь ничего не меняется ?)
За оплату картой банку капает пара процентов от суммы. И они частью от нее делятся.
А при оплате СБП банку не капает ничего. Делиться нечем.
Это очевидно и понятно , я имел ввиду механизм. Например плачу за электричество - СПБ нет кэшбека , картой Мир - есть. Клиент один и тот же , операция одна, в чем суть "капания процентов" именно по оплате картой . а не транзакцией эл. счета? Кэшбек инициатива банка по стимулированию использования безналичной оплаты ...
Клиент один и тот же , операция одна, в чем суть "капания процентов" именно по оплате картой . а не транзакцией эл. счета?
В том, что при оплате картой продавец электричества немного этими деньгами поделился (когда заплатил за обработку платежа). Ему денег чуточку меньше осталось.
В случае СБП - осталось чуточку больше и на кэшбек от банка уже не осталось. (Это причина, почему тут уже сами продавцы, а не банк пытаются эти оплаты стимулировать. Что, в общем, выглядит более прямолинейно и логично.)
Кэшбек инициатива банка по стимулированию использования безналичной оплаты ...
Вот только при оплате СБП банк как бы не в минус работает - он платит ЦБ (копейки, но тем не менее) за проведенную операцию и нечего не получает. Стимулировать такое ему - вряд ли интересно.
т.е. суть в том что оплата картой проходит как доходная операция для банка и банк делится частью этого дохода ,в отличие от СПБ транзакции , где по сути банк исполняет от имени клиента распоряжение ЦБ (пусть и оплачивая что-то ЦБ, но я думаю это в рамках общего клирингового обслуживания).
Если владелицу бизнеса за приём СБП будет такая же высокая комиссия
Если
А теперь идем и смотрим например https://tochka.com/acquiring/internet/ комиссии для интернет-эквайринг. По картам - от 3.2% до 1.8%, по СБП - 0% до 0.7%
Отдельно по СБП они же - https://tochka.com/rko/qr/
Полный их список тарифов на эквайринг включая - не интернет есть на https://tochka.com/links/acquiring-tarrifs/ (на не-интернет от 1.14% до 2.99%)
Ну или идем в модульбанк или любой другой и спрашиваем тарифы. Там примерно то же будет (ну конечно с обычными нюансами про обслуживание счета, платежки и прочее).
Вы когда почините приложение Мир Пэй? У вас почти месяц в проде глючная баганутая версия, а вы лепите отмазки про картхолдеры. С учётом новогодних каникул будет уже дольше месяца. Откатите код до старой версии, ещё есть шанс отмыть этот позор.
В Китае используют похожие на СБП системы: Alipay и WeChat. Они сильно лучше СБП тем, что работают без интернета у покупателя. А именно, покупатель может зайти в приложение и показать продавцу свой QR-код, и продавцу этого достаточно для списания денег с покупателя. Но для крупных сумм покупателю всё же нужен интернет, потому что ему нужно будет подтвердить операцию пин-кодом и/или 2FA-кодом от банка, который выпустил карту.
А что там настчет B2B платежей, почему еще не все банки перешли на СБП? (некоторые предлагают), и почему мы до сих пор платежки создаем в ИБ и ждем несколько часов?
Под капотом платежей: чем отличаются ПС «Мир» и СБП