Pull to refresh

Comments 20

Оооо… на Erlang? Да вы решили открыть собственную велосипедостроительную фабрику…

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

Есть такая возможность. Вам достаточно передать popupMode=true в API чекаута он откроется в новой вкладке вот так: https://rbk.mn/3anEhu1a0ra

Статья ни о чем, деталей нет. Вроде как "блаблабла, да еще блаблабла".


  • Как реализована обработка транзакций, откатов и факапов с ними?
  • Сколько нагрузка в среднем или, уж, сколько ресурсов (запросов, вызовов внутри софта и памяти) жрет обработка?
  • Рилтайм или нерилтайм, и как быть с блокировками?

Где все это?

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


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


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


Этот блог не будет маркетинговой водой, честно!

Есть ли возможность для одного магазина создавать инвойсы в разной валюте? В заявке на открытие магазина можно указать только одну.

В одном магазине может быть только одна валюта одновременно. Но вы можете себе создать сколько угодно магазинов в нужной вам валюте, просто укажите ее символьный код в https://dashboard.rbk.money/shop/create/.


Единственный нюанс — платформа технически поддерживает любые валюты, но на бою будут доступны RUB, EUR и USD на данный момент. В тестовом магазине можете указывать какую угодно.

Интересно, что все эти штуки дают с точки зрения конечного продукта — для пользователя и для мерчанта?

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


Я не маркетолог и этот блог не бизнесовый.


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

Наконец-то динамический опердень на erlang
Когда увидел отсылку к Amazon Dynamo — сразу почему-то подумал, что речь пойдет о Riak, Erlang, Consistent hashing, Riak Pipes и т.д. Мы еще в далеком 14-м году это пробовали, но потом забросили, к сожалению. Очень интересны технические подробности. Кстати, работники в команду не нужны?:)

Технические подробности будут обязательно, следите за блогом.


Разработчики нам нужны всегда. Киньте контакты в личку плз, я все организую.

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

Интересный подход, обычно пишут чтоб комфортно было потребителям.

В описании bug bunty написано:
Политика вознаграждения
В настоящий момент мы не осуществляем выплату вознаграждения за найденные уязвимости в соответствии с правилами HackerOne Vulnerability disclosure program (VDP).


Насколько бесплатная программа будет эффективной?
Насколько бесплатная программа будет эффективной?

Ну чтобы прямо было сильное отличие от платной программы я не заметил. Мы благодарим за репорты кармой в ха1, это тоже имеет ценность для исследователей. Разве что сильно меньше трешака от "хакеров с кволисом" и репортов типа "у вас тут http без TLS в мир открыт, уязвимость!".

А как со сложностью администрирования всего этого хозяйства? Изначальные разработчики со временем разбегуться, а людям работать со стэком достаточно нетипичных для платёжной системы технологий.

Очень интересует общая схема маших сервисов+бд и как у вас реализованы транзакции и их откаты.

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


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


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

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

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

Sign up to leave a comment.