Привет!

В нашем блоге мы много рассказывали про устройство и работу нашей платёжной системы RBK.money — как в ней всё устроено, про микросервисы и логику, про идеальный антифрод.

Один из последних постов был про наш процессинг, который мы сделали таким, что нам за него не стыдно (нас дважды не смогли сломать на The Standoff, отметили Премией Рунета), и который мы выложили в опенсорс.

Собственно, к чему мы ведём. Мы решили и дальше сосредоточиться на развитии и доработке процессинга, будем добавлять к нему новые фичи и возможности, расширять продуктовую линейку. И поэтому мы вывели его в отдельное технологическое направление бизнеса под брендом Osnova (да, процессинг называется так же). Мы переименовываем блог компании и в дальнейшем будем рассказывать вам про процессинг, интересные кейсы, ну и в целом тема Open-Source в мире нам интересна, так что будем делиться самыми топовыми новостями. Да, если что — платежный сервис RBK.money никуда не уходит с рынка и продолжает исправно работать, обслуживать своих клиентов и помогать им настраивать прием любых видов платежей на сайте.

Osnova может стать для вас как основным процессингом, так и предпроцессингом либо маршрутизатором между имеющимися процессингами, спасибо универсальным интерфейсам платёжных протоколов. Одним словом, процессинг настолько гибкий, безопасный и динамичный, что позволяет реализовать любой платежный сценарий, как своими силами, так и с нашей поддержкой. Кстати, про поддержку, мы также запустили телеграм-чат https://t.me/rbkmoney_opensource и в нем консультируем, опертивно отвечаем на технические вопросы по нашему процессингу и его возможностям. Вступайте и задавайте вопросики!

Привет!

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

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

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

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

Привет!

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

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

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

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

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

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

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

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

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

Принцип security through obscurity не работает. Если пойти погуглить насчет новостей в разрезе «Клиента банка Х взломали и увели Y рублей», то такие новости будут всегда. Почти каждый день (почти — потому что не всегда об этом пишут).

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

Поэтому система, которая считается защищенной только потому, что люди не знают, как она работает — вообще ни разу не защищенная. А вот чем такая система открытее, тем быстрее въедливое сообщество укажет своим критически настроенным перстом на все косяки в реализации. Что позволит эти косяки устранить.

Я работаю именно в парадигме открытости протоколов и систем, и в этом посте я хочу рассказать про устройство стандартного антифрода, о работе нашего в RBK.money, почему будущее за OpenSource, а также о том, как всё это может работать в идеальном мире.

Который мы с вами и можем приблизить.

Истории по распиливанию монолита часто похожи одна на другую. Был у команды здоровенный неповоротливый монолит, решили его распилить на россыпь правильных и шустреньких микросервисов, все стало круто. Отличаются истории лишь степенью ужаса “до”, радости “после” и рядом вторичных характеристик.

У нас в RBK.money тоже микросервисы. Но пришли мы к ним немного не так, как большинство. У нас все было даже хуже монолита — у нас на старте просто все было хреново.

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

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

Привет, Хабр! Продолжаю публикацию цикла про внутренности платежной платформы RBK.money, начатую в этом посте. Сегодня речь пойдет про логическую схему процессинга, конкретные микросервисы и их взаимосвязь друг с другом, как логически разделены сервисы, обрабатывающие каждый свой кусок бизнес-логики, почему ядро процессинга ничего не знает про номера ваших платежных карт и как внутри платформы бегают платежи. Также, чуть более подробно раскрою тему о том, как мы обеспечиваем высокую доступность и масштабирование для обработки высокой нагрузки.

Привет Хабр! RBKmoney снова выходит на связь и продолжает цикл статей о том, как написать платежный процессинг своими руками.

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

Привет, Хабр! Мы в RBKmoney новый платежный процессинг написали. С нуля. Ну не мечта ли?

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

Мы расскажем, как написали весь процессинг RBKmoney Payments, так мы его назвали. Как делали его устойчивым к нагрузкам и сбоям оборудования, как придумали возможность его практически линейного горизонтального масштабирования.

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

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

• На банковскую карту российского банка
• На банковский счёт российского банка

1. Почтовым переводом
2. Без открытия счёта по системе CONTACT
3. На банковский счет физического лица
4. На банковскую карту