Архитектура платформы

Одно ядро, много интерфейсов — как на самом деле устроена платформа.

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

Связаться с нами Смотреть продукты

Ядро

Один леджер под всем.

В центре платформы — единый леджер счетов. Каждый счёт — кошелёк клиента, баланс мерчанта, комиссионный счёт, расчётный счёт — это узел в этом леджере, а каждое движение средств — проводка по двойной записи: один счёт дебетуется, другой кредитуется, обе стороны всегда равны. Леджер работает только на добавление (append-only). Записи никогда не редактируются и не удаляются; исправление — это новая, обратная запись, поэтому всю историю того, как баланс пришёл к текущему значению, всегда можно восстановить. Счета, статус KYC, выпущенные карты и крипто-адреса привязаны к одной модели счёта, поэтому авторизация по карте, банковский перевод и ончейн-депозит попадают на один баланс без слоя сверки, который склеивал бы разные системы.

01Двойная запись: каждая проводка сбалансирована, дебет равен кредиту
02Append-only: исправления — это новые записи, а не правки
03Одна модель счёта для фиата, карт и крипто
04Статус KYC хранится в счёте, а не в отдельной таблице

Платёж от начала до конца

Один платёж: от создания до сверки.

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

01
Создание
Открывается интент: сумма, валюта, задействованные счета. Деньги пока не двигались — леджер фиксирует ожидающую запись.
02
Авторизация
Рельс проверяет средства и риск и ставит холд. Для карты это авторизация, для перевода — резервирование дебета.
03
Списание
Удержанная сумма фиксируется. Леджер проводит двойную запись, которая реально переводит стоимость между двумя счетами.
04
Расчёт
Средства проходят клиринг по базовому рельсу — карточной схеме, банку или блокчейну, — и расчётные счета сверяются с реальными деньгами.
05
Сверка
Платформа сопоставляет собственные проводки с отчётом рельса о расчётах; всё, что не сошлось, помечается, а не скрывается.

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

Прикладной слой

Whitelabel-приложения сверху, одна платформа внизу.

Ядро предоставляет возможности, а прикладной слой превращает их в продукты. Каждое клиентское приложение — веб и мобильное — это whitelabel-клиент, который показывает те же счета, платежи и карты под своим брендом. Темизация построена на токенах: цвета, шрифты, скругления и отступы берутся из системы дизайн-токенов (PDS), поэтому оператор меняет оформление всего интерфейса, правя токены, а не форкая приложение. Одну платформу можно направить в очень разные стороны — необанк для частных клиентов, эквайринг для мерчантов, программа выпуска карт, крипто on/off-ramp или внутренний операционный инструмент — и она не распадётся на пять отдельных продуктов. Это одна платформа в разных обличьях: каждое настраивается, а не пишется заново.

01Whitelabel-клиенты для веба и мобильных на общих API
02Темизация на токенах (PDS): оформление меняется конфигом, а не форком
03Пять примеров направлений — необанк, эквайринг, эмиссия, ramp, ops
04Новые интерфейсы настраиваются, а не пишутся заново

Операции

Управляйте из консоли — с причиной в журнале.

За каждым приложением стоит консоль оператора. Через неё агент поддержки находит счёт, риск-аналитик замораживает карту, а руководитель операций сторнирует проводку. Просмотр доступен широко, привилегированные действия — нет. Любое действие, которое двигает деньги, меняет лимиты или затрагивает средства клиента, требует указать причину до выполнения и пишет неизменяемую запись аудита: кто действовал, с чем, когда и зачем. Доступ строится по принципу наименьших привилегий: каждый оператор видит и делает только то, что позволяет его роль. Так устроен Protocore Center — консоль оператора, и тот же подход заложен в каждую систему платформы: чувствительные действия осознанны, атрибутированы и доступны для проверки постфактум.

01Чтение — широко, запись — под контролем: привилегированные действия остаются исключением
02Причина обязательна перед любым действием со средствами
03Неизменяемый журнал аудита: кто, что, когда, зачем
04Наименьшие привилегии для каждой роли оператора

Крипто-мост

Крипто и фиат в одном леджере.

Крипто на платформе — не отдельный изолированный контур: крипто-адрес — это просто ещё один счёт в том же леджере. On/off-ramp конвертирует фиат в цифровые активы и обратно на границе системы: клиент пополняет баланс картой или переводом и получает крипто либо продаёт крипто и выводит деньги на банковский счёт. Ончейн-стоимость может дойти до банковского рельса: входящий ончейн-платёж зачисляется на счёт, конвертируется и выплачивается на IBAN, так что получатель видит обычные деньги на обычном банковском счёте. Поскольку обе стороны операции проводятся в одном леджере с двойной записью, движение, начавшееся в блокчейне и закончившееся банковским переводом, — это единая сверенная история, а не две системы, которые сверяют вручную.

01Крипто-адрес — такой же счёт, как и любой другой
02On/off-ramp: фиат и цифровые активы конвертируются на границе
03Ончейн-расчёт с выплатой на IBAN
04Единая сверенная история по обеим сторонам операции

Интерфейс для разработчиков

API, вебхуки и песочница для разработки.

Всё, что делают приложения, они делают через документированный API: создать счёт, открыть платёж, выпустить карту, запустить ramp. Примеры вызовов — POST /v1/wallets или POST /v1/payments; интерфейс REST, в каждой операции записи — ключ идемпотентности. Изменения состояния приходят вебхуками, поэтому ваши системы реагируют на события, а не опрашивают API. Разработка идёт в тенанте-песочнице — изолированной копии платформы с тестовыми рельсами, где можно прогнать весь путь от создания до сверки без движения реальных денег. Что именно каждый продукт открывает вам и на каком уровне, определяет его уровень доступа; на страницах продуктов расписано, что входит в каждый из них.

01Документированный REST API, идемпотентные записи
02Вебхуки на каждое изменение состояния — по событиям, без опроса
03Тенант-песочница с тестовыми рельсами, изолирован от продакшена
04Объём и лимиты задаются уровнями доступа для каждого продукта

Честная граница

Protocore делает софт. Регулируемая граница — за лицензией.

Платёжный продукт состоит из двух сросшихся частей: регулируемого разрешения хранить и переводить деньги и программного обеспечения, которое отдаёт команды, фиксирует и сверяет операции. Protocore создаёт софт. Регулируемая деятельность — хранение средств клиентов, открытие счетов, перевод денег через платёжную схему — остаётся за лицензией оператора или лицензированного партнёра: банка, EMI или платёжной организации. Платформа рассчитана на любые регулируемые рельсы, которые вы приводите, и держит данные карт на стороне рельса, чтобы они не попадали на ваши серверы; она не заменяет это разрешение — как и любой другой софт. Где пройдёт регулируемая граница, вы решаете вместе с партнёром, а архитектура спроектирована так, чтобы чисто встать по любую её сторону.

01Программный слой, а не лицензия
02Регулируемая деятельность — на стороне оператора или лицензированного партнёра
03Данные карт остаются на рельсе, вне ваших серверов
04Рассчитано на регулируемые рельсы, которые вы приводите

Что с чем связано