Ранее я опубликовал две статьи (1, 2) о способах приема платежей на сайте. В предыдущих статьях было одно условие — подключение к платежным системам производилось как физическое лицо. Теперь я решил выйти из сумрака делать все максимально честно, и хочу рассказать о способах подключения к платежным системам в качестве ИП и легального вывода заработанного на расчетный счет в банке.

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

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

Итак, герои сегодняшнего обзора: WebMoney, Яндекс.Касса, PayPal, Единая Касса (Wallet One), RBKMoney, PayMaster, РобоКасса, QIWI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Привет!

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

Привет!

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

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

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

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

Square, PayPal, iZettle — известные во всем мире компании, которые предлагают решения по приему банковских карт. Ни один из брендов не представлен в России. Зато у нас есть десять собственных. Мною проведено независимое исследование сервисов мобильного эквайринга в России, позволяющих принимать платежи по банковским картам Visa и MasterCard: iPay, Sum Up, Pay Me, 2Can, SimplePay, LifePay, Термит, ibox, Paybyway и RBK Card.

Захотелось понять: что движет людьми и рынком, что предлагают сервисы и кому могут быть интересны эти решения. Если Вы занимаетесь частной практикой или фрилансом, у Вас есть свой бизнес, или Вы интересуетесь e-commerce — эта статья для Вас. Под катом Вы найдете обзор сервисов, отчет о тестировании, а также конкретные рекомендации по приему карт.

Более трех лет назад я написал пост о выборе платежной системы для приема платежей на своем прошлом проекте. С тех пор прошло довольно много времени и многое в способах приема платежей изменилось. Теперь я расскажу как делал прием платежей на сайте poiskvps.ru.

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

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

Системы электронных денег неплохо справляются с задачей учета денег своих пользователей.

Давайте попробуем поменяться местами и посчитать деньги в кармане самих платежных систем.

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

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

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

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

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

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

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

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

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

…или как хакеры ломали наш опенсорс платежный процессинг в кибергороде.

Привет! Мы тут недавно с процессингом RBK.money приняли активное участие в киберполигоне The Standoff — это когда делают виртуальную модель целого мегаполиса со всей его инфраструктурой, энергостанциями, магазинами и прочими важными элементами. А потом пускают в этот цифровой двойник города команды blue team (6 команд в этом году) и red team (29 команд в этом году соответственно), первая защищает всю эту инфраструктуру, вторая же активно пытается что-то сломать.


из к/ф “Бегущий по лезвию 2049”

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

В этом посте я хочу рассказать, как нас ломали хакеры (спойлер: и не сломали), а также как мы сами пару раз стрельнули себе в ногу в процессе подготовки и разворачивания своего решения. И да, главное — для нас это изначально была ситуация win-win: не сломают нас, значит, не зря мы настолько уверены в своем процессинге, что выложили его в опенсорс и теперь отдаем хакерам. Сломают — вообще отлично, увидим, где были слабые места, и станем ещё более защищенными с точки зрения безопасности для наших клиентов.

Внедрялись в кибергород мы в ощутимой спешке: это один из первых наших деплойментов в Kubernetes (до этого мы все разворачивали Salt-стейтами), и нам пришлось использовать новые подходы по инсталляции. И последствия от этой спешки не заставили себя долго ждать.