Платежные системы *

Привет, Хабр! Меня зовут Игорь Тулинов. Я руковожу центром архитектуры ИТ в Национальной системе платежных карт (АО НСПК) и хочу рассказать о том, как наша компания пришла к решению внедрить процессы управления Enterprise-архитектурой, выделить штат архитекторов предприятия и реализовать архитектурный контроль на ключевых стадиях создания ИТ-ценности.

В ИТ отрасли термин «Архитектура предприятия» (Enterprise Architecture) появился более тридцати лет назад. Со временем возник широкий ряд определений этого понятия, моделей, фреймворков и стандартов его описания. Во множестве ИТ и финтех компаний в том или ином виде реализованы процессы управления корпоративной архитектурой.

Но в какой именно момент в компании появляется Архитектура предприятия? Когда и на основе чего организация приходит к пониманию, что настало время внедрять процессы управления корпоративной архитектурой?

Реально ли запустить онлайн-банк за две недели?

Начинаем серию статей о безопасности в платежных технологиях. Тема большая, эта статья будет первой, вводной. О безопасности мы решили поговорить с Игорем Голдовским, главным архитектором и директором департамента, человеком, знающим все о платежных системах и их защите.

1. В манифест помещаем пустую Activity c intent-filter вида ACTION_VIEW и ACTION_DIAL со схемой “tel”.
2. В activity перебрасываем на форму оплаты через существующий deeplink, обогатив его данными из оригинального intent-а “tel:XXXXX”

Зачем?

• Предлагать ненавязчиво — кому нужно сам поставит галочку;
• Предлагать активно — галочка у привязки стоит по умолчанию, кто забыл её убрать — сам виноват;
• Привязывать без какого-то уведомления — сервис сам знает, как пользователю будет лучше.

Что такое платежный шлюз?

Платежный шлюз — это сервис, который авторизует и обрабатывает платежи по дебетовым/кредитным картам для онлайн-мерчантов и традиционных розничных, оффлайн торговцев. Платежный шлюз способствует бесперебойному прохождению таких транзакций, шифруя конфиденциальные данные и передавая их между платежным порталом (веб-сайт или мобильное устройство) и банком/процессором платежей.

Принцип работы платежного шлюза

В общем и целом, платежные шлюзы облегчают связь между вашим веб-сайтом или специализированным магазином, обработчиком платежей и банком, выпустившим кредитную карту, используемую для совершения покупки. Безопасность является основным компонентом всех платежных шлюзов, поэтому каждая транзакция, которая происходит между мерчантом и банком-эмитентом, шифруется для защиты конфиденциальной финансовой информации.

Хотя процесс транзакции занимает всего несколько секунд, в течение этого короткого промежутка времени выполняется несколько шагов. Как только клиент получает запрос на защищенную страницу оплаты и размещает заказ, данные по транзакции (номер кредитной карты, дата, CVV код) шифруются и отправляются вашему процессору платежей через шлюз. Процессор платежей связывается с банком-эмитентом кредитной карты и получает обратную связь в форме подтверждения или отклонения транзакции. Затем ответ передается на платежный шлюз, который передает его на ваш сайт. Наконец, информация интерпретируется и генерируется соответствующий ответ. Если сделка была одобрена, продавец выполняет заказ.

5 широко используемых платежных шлюзов в 2020

Кстати, к сожалению, не удалось встроить отчет в публикацию на Хабре ни через iframe, ни через тег oembed.

Привет!

Если вы читали наши предыдущие посты (читали же?), то точно помните, что мы в RBK.money очень сильно за опенсорс. Настолько, что выложили в открытый доступ наш антифрод в виде открытых исходников под лицензией Apache 2.0.

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

Зачем мы это сделали? Как это работает внутри? Как теперь жить дальше? Читайте под катом. Я гарантирую, что такого вы еще не встречали — еще никто в мире не опенсорсил платежную систему такого уровня.

История меняется прямо сейчас на ваших глазах!

Привет!

Не так давно мы писали в нашем блоге про антифрод и его устройство. В этом посте я хотел бы затронуть критерии идеального антифрода, который бы и клиентам жизнь упрощал, не блокируя платежи и при этом защищая их средства, и платежной системе время и ресурсы экономил. Мы поговорим о том, как относятся к фроду платежные системы и что может прилететь от них в сторону компании, как с фродом принято бороться сейчас и как бы хорошо это делать в будущем.

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

Для этого, кроме того, чтобы просто хорошо делать свою работу, писать правильный код, не бояться использовать современные технологии и в целом не тупить, надо обязательно обращать внимание на две штуки — документация и API. Без них человеку будет трудно понять, с чем вообще он имеет дело, как оно всё работает и что лучше не трогать вообще никогда. Конечно, можно гуглить, что обозначает та или иная спецификация, можно проверять в бою, чего и как (а потом так же бодро откатываться на предыдущую рабочую версию), но лучше, когда человеку дали подробную документацию.

Так вот, о чем я сегодня. В этом посте я расскажу, почему мы в RBK.money используем Swagger, как он помогает нам в работе и какие у него есть косяки.

Привет! В этом посте мы расскажем о том, как провели первый в истории RBK.money CTF (capture the flag). Механика соревнования была примерно такой же, как и на привычных вам CTF, а вот результаты немного удивили. Впрочем, возможно, мы просто перестарались с задачами.

В рамках CTF нужно было в составе команды или, если чувствовал, что справишься сам, единолично получить определенный флаг, заботливо спрятанный нашими ребятами в коде. Чтобы его получить, надо было либо взломать участвующие в CTF сервисы, либо написать программу, либо просто найти в нашем коде уязвимость и не замедлить ею воспользоваться.

Участвовали примерно 100 команд, в некоторых из которых было по 5-7 человек, а в других — по одному. Особенностью CTF стали две вещи. Первая — отчасти соревнование было посвящено Erlang. Штука не самая популярная, да. Вторая — несколько задач решить не осилил никто из участников, одно из заданий было очень типично для Erlang, ещё одно — на извлечение информации из аудиофайла. То ли люди перестали увлекаться стеганографией, то ли мы немного переборщили.

В общем, было всё. Реверс-инжиниринг, фишинг участников со стороны самих участников, слишком сложные задачи и попытки помешать остальным найти флаги. Под катом — подробности и сами задания, если решите попытать силы.

Статья про создание inhouse-решения для обнаружения и предотвращения мошеннических операций проводимых в интернет-банкинге одного маленького, но очень гордого банка в Татарстане. Из статьи узнаете о том зачем и кому нужен антифрод, почему внутренняя разработка оказалась дешевле покупки готового решения и к чему приводят пара строчек кода перед новым годом.