как быть со всякими подписками? А с "сохранением" карты (видимо токен сохраняется) и оплаты потом по нажатию пары кнопок на сайте? Запретить? Каждый раз требовать QR?
вот кстати с привязкой счета для рекуррентных платежей в СБП все отлично. В приложении своего банка можно видеть список подписок и их мерчантов и тут же отозвать любую привязку. Это новинка, но реализации уже есть
Если фразу про мышеловку и сыр переписать как "бесплатных завтраков не бывает, просто за них платит кто-то другой", то это объяснит позиции обоих спорщиков (мне так кажется)
Виктор, спасибо за статью! Хорошо систематизировано.
я регулярно отвечаю на подобные вопросы
Могу порекомендовать обратное упражнение — задавать окружающим вопросы: что такое «аналитик», как вы его видите? Зачем он вам? Что вы от него ждёте? Помимо того, как мы себя видим, эта роль в глазах коллег может сильно отличаться.
Ответы очень многообразные — как минимум, интересно послушать ответы.
Но главное, так как граница обязанностей и компетенций в глазах коллег очень неясная, полезно выяснить ожидания в каждом конкретном взаимодействии — в этом подразделении, у этого начальника, в этом проекте. Аналитик же умеет работать с требованиями — почему бы не выявить требования к самому себе.
Например, я участвую в собеседованиях при поиске системных аналитиков в соседние команды. У меня есть своё видение, какую пользу аналитик приносит команде. Но, если заставить высказаться команду, кандидат узнает что именно от него ждут. Кому-то нужен переговорщик с бизнес-заказчиком, но вслух они произносят слово «аналитик». Кому-то проектировщик API, и это опять же аналитик. Кому-то валидатор решений, и этого архитектора тоже зовут аналитиком.
Оба банка подключились к системе как раз в части С2С-переводов (https://sbp.nspk.ru/participants/), так что… должно работать. Для начала проверьте, что СБП подключена как услуга и в том, и в другом банке (что стоят нужные галочки). И что при переводе выбираете именно канал «перевод через СБП»
oraclejob, с удовольствием позвал бы Вас к нам в команду, аналитиком или архитектором. Вы сходу написали и контекст проблемы, и накидали решение к своему же вопросу; круто.
По вопросу: введение другого идентификатора в обозримых планах не стоит, так как сейчас в сконцентрировались над расширением списка сервисов.
конкретно для такого кейса, когда банков несколько, и есть любимый и нелюбимый(-ые), сделали сценарий Me2Me pull — что бы перевести деньги в любимый банк, используя любимое ДБО. terein, идея с приложением хорошая, но в roadmap её сейчас нет. Кстати, пойдёте к нам аналитиком или архитектором? :)
Вот кстати, иногда не хватает одной «специальной программки» (от той же НСПК, например), которая бы все С2С переводы через СБП по номеру телефона делала. Указываешь номер телефона инициатора и его банк, номер телефона получателя и его банк, вводишь сумму, затем получаешь на эти номера OTP, подтверждаешь — и перевод совершён. Технически СБП такое потянет, подходящие операции вроде как есть. Дело за политической волей (ну и порядка пары месяцев разработки).
Мне видится это как усложнение UX. Пользователь привык делать все денежные операции в ДБО своего банка; более того — банки тащат в ДБО всю свою экосистему, и вдруг одну из операций нужно вынести в отдельное приложение? Ну такое… Я эту идею коллегам донесу, конечно, но пока я бенефтов не вижу.
такой обывательский вопрос: к примеру е меня есть карта/счет в банке А, это всё привязано к номеру мобильного телефона. Я иду в банк Б и хочу там завести карту/счет и так же привязать к этому же номеру телефона. Банк Б мне откажет в этой привязке или нет? Если нет, то как будет осуществляться выбор, а куда собственно говоря будут переводится деньги по номеру телефона при использовании СБП? В какой банк?
Можно привязать к СБП счета в нескольких банках на один номер телефона.
Один из банков можно объявить банком по умолчанию.
Отправитель при этом сможет отправить деньги в любой из этих банков, но в дефолтный — на пару куликов быстрее
Не сложно, но другие идентифкаторы оказались невостребоваными. Более того, при проектировании такой задел оставили.
Давайте пофантазируем - если идентифицировать пользователя по строке в самой СБП, то точно такая же идентификация по строке должна быть у ВСЕХ банков, это раз.
А как верифицировать пользователя, что он является хозяином этой строки? Вот подслушал я, что Вы решили идентифицировать себя по строке 'qwerty' в СБП, и быстро побежал во все банки, открыл там счета и сказал банкам: я - qwerty, если будут приходить переводы на qwerty, то это мне. Что должны банки сделать - верить мне? Я бы не стал. Отказать? Тоже нет причин. Когда Вы ппротом идете в банк и скажите, что qwerty - это Вы, что банк должен сделать? Ну что-то сложно. С телефоном проще, да и сложилась уже практика идентифицировать клиента по телефонному номеру, не только в банках.
Сначала ТСП записывает в БД СБП информацию о будущем платеже - банк, счёт в нем, опционально сумму и др. В ответ получает QR с идентификатором.
Пользователь сканирует QR с идентификатором, банк запрашивает в СБП данные о платеже и о ТСП и демонстрирует клиенту. Клиент в ДБО-приложении своего банка нажимает "оплатить" - банк плательщика делает платёж по реквизитам, которые ТСП предоставило в п. 1
Это оооооочень упрощённо. Подробности будут в продолжении.
Есть мсс как атрибут QRки и транзакции. Показывать его клиенту или нет - это уже как банк реализовал. У меня есть, только проверил
вот кстати с привязкой счета для рекуррентных платежей в СБП все отлично. В приложении своего банка можно видеть список подписок и их мерчантов и тут же отозвать любую привязку. Это новинка, но реализации уже есть
Зачем ждать взаимодействие банка и кассового ПО? ОПКЦ сам напрямую отправляет callback в кассовое ПО, см шаг 8
Если фразу про мышеловку и сыр переписать как "бесплатных завтраков не бывает, просто за них платит кто-то другой", то это объяснит позиции обоих спорщиков (мне так кажется)
Спасибо, хорошо структурировано и понятно написано. Лишний импульс мне самому тоже подумать о сертификации
Могу порекомендовать обратное упражнение — задавать окружающим вопросы: что такое «аналитик», как вы его видите? Зачем он вам? Что вы от него ждёте? Помимо того, как мы себя видим, эта роль в глазах коллег может сильно отличаться.
Ответы очень многообразные — как минимум, интересно послушать ответы.
Но главное, так как граница обязанностей и компетенций в глазах коллег очень неясная, полезно выяснить ожидания в каждом конкретном взаимодействии — в этом подразделении, у этого начальника, в этом проекте. Аналитик же умеет работать с требованиями — почему бы не выявить требования к самому себе.
Например, я участвую в собеседованиях при поиске системных аналитиков в соседние команды. У меня есть своё видение, какую пользу аналитик приносит команде. Но, если заставить высказаться команду, кандидат узнает что именно от него ждут. Кому-то нужен переговорщик с бизнес-заказчиком, но вслух они произносят слово «аналитик». Кому-то проектировщик API, и это опять же аналитик. Кому-то валидатор решений, и этого архитектора тоже зовут аналитиком.
Секунды
По вопросу: введение другого идентификатора в обозримых планах не стоит, так как сейчас в сконцентрировались над расширением списка сервисов.
terein, идея с приложением хорошая, но в roadmap её сейчас нет. Кстати, пойдёте к нам аналитиком или архитектором? :)
Мне видится это как усложнение UX. Пользователь привык делать все денежные операции в ДБО своего банка; более того — банки тащат в ДБО всю свою экосистему, и вдруг одну из операций нужно вынести в отдельное приложение? Ну такое… Я эту идею коллегам донесу, конечно, но пока я бенефтов не вижу.
Можно привязать к СБП счета в нескольких банках на один номер телефона.
Один из банков можно объявить банком по умолчанию.
Отправитель при этом сможет отправить деньги в любой из этих банков, но в дефолтный — на пару куликов быстрее
Не сложно, но другие идентифкаторы оказались невостребоваными. Более того, при проектировании такой задел оставили.
Давайте пофантазируем - если идентифицировать пользователя по строке в самой СБП, то точно такая же идентификация по строке должна быть у ВСЕХ банков, это раз.
А как верифицировать пользователя, что он является хозяином этой строки? Вот подслушал я, что Вы решили идентифицировать себя по строке 'qwerty' в СБП, и быстро побежал во все банки, открыл там счета и сказал банкам: я - qwerty, если будут приходить переводы на qwerty, то это мне. Что должны банки сделать - верить мне? Я бы не стал. Отказать? Тоже нет причин. Когда Вы ппротом идете в банк и скажите, что qwerty - это Вы, что банк должен сделать? Ну что-то сложно. С телефоном проще, да и сложилась уже практика идентифицировать клиента по телефонному номеру, не только в банках.
А вот и нет. Сам факт номинации - уже уважение в глазах коллег и разговоры у кулера "а нашего Васю на key people выдвинули!"
Если совсем в двух словах - то
Сначала ТСП записывает в БД СБП информацию о будущем платеже - банк, счёт в нем, опционально сумму и др. В ответ получает QR с идентификатором.
Пользователь сканирует QR с идентификатором, банк запрашивает в СБП данные о платеже и о ТСП и демонстрирует клиенту. Клиент в ДБО-приложении своего банка нажимает "оплатить" - банк плательщика делает платёж по реквизитам, которые ТСП предоставило в п. 1
Это оооооочень упрощённо. Подробности будут в продолжении.
Кажется, это был не наш QR :(
В СБП есть система форд-мониторинга, алгоритмы которой, увы, я рассказывать не буду. Описанный вами кейс - это самый первый, простой вид перебора