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

Одне ядро, багато поверхонь — як насправді працює платформа.

Огляд платформи від леджера й вище: рахунки, 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, операції
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 з ключем ідемпотентності на кожен запис. Зміни стану надходять вебхуками, тож ваші системи реагують на події, а не опитують сервер. Розробка ведеться в sandbox-тенанті — ізольованій копії платформи з тестовими рейками, де можна пройти весь шлях від створення до звірки без руху реальних грошей. Що саме кожен продукт відкриває вам і на якому рівні, визначає його access band; сторінки продуктів описують, що входить у кожен band.

01Задокументоване REST API, ідемпотентні записи
02Вебхуки на кожну зміну стану — події замість опитування
03Sandbox-тенант з тестовими рейками, ізольований від продакшну
04Обсяг і ліміти визначають access band-и окремих продуктів

Чесна межа

Protocore будує софт. Ліцензія тримає регульовану межу.

Платіжний продукт складається з двох нероздільних частин: регульованого дозволу зберігати й переміщувати гроші та софту, що дає інструкції, фіксує й звіряє. Protocore будує софт. Регульована діяльність — зберігання коштів клієнтів, відкриття рахунків, рух грошей у схемі — лежить на власній ліцензії оператора або ліцензованого партнера: банку, EMI чи платіжної установи. Платформа створена так, щоб працювати з будь-якими регульованими рейками, які ви приведете, і тримати картков– дані на рейці, щоб вони не потрапляли на ваші сервери; вона не замінює цей дозвіл, як і жоден софт. Де пройде регульована межа — рішення, яке ви ухвалюєте разом із партнером, а архітектура розрахована на те, щоб чисто лежати по обидва її боки.