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

Едно ядро, много повърхности — как всъщност работи платформата.

Разходка из платформата от счетоводната книга нагоре: сметките, KYC, картите и кripto, които споделят едно ядро с двойно записване, как едно плащане преминава от създаване до равняване и къде стоят приложният слой, операторската конзола и регулираната линия.

Свържете се с нас Вижте продуктите

Ядрото

Една счетоводна книга под всичко.

В центъра на платформата е една книга на сметките (ledger). Всяка сметка — портфейл на клиент, баланс на търговец, сметка за такси, сметка за сетълмент — е възел в тази книга, а всяко движение на стойност е запис с двойно записване: една сметка се дебитира, друга се кредитира, като двете страни винаги са равни. Ledger-ът е само за добавяне (append-only). Записите никога не се редактират и не се изтриват; корекцията е нов, насрещен запис, така че пълната история на това как балансът е стигнал до текущата си стойност винаги може да бъде възстановена. Сметките, KYC статусът, издадените карти и крипто адресите са свързани към един и същ модел на сметка — затова картова авторизация, банков превод и депозит on-chain могат да се отразят в един баланс, без слой за равняване, който да свързва отделни системи.

01Двойно записване: всеки запис е балансиран, дебитите са равни на кредитите
02Само добавяне: корекциите са нови записи, никога редакции
03Един модел на сметка за фиат, карти и крипто
04KYC статусът върви със сметката, а не в странична таблица

Плащане от край до край

Едно плащане — от създаване до равняване.

Плащането не е едно извикване, а кратък жизнен цикъл, и всеки етап е състояние, което виждат както ledger-ът, така и вашите системи. Всяка промяна на състоянието изпраща уебхук, а всеки запис е идемпотентен — един и същ ключ води до същия резултат, така че повторена заявка никога не таксува два пъти.

01
Създаване
Отваря се намерение за плащане: сума, валута, участващите сметки. Още нищо не е преместено — ledger-ът записва висящ запис.
02
Авторизация
Релсата проверява средствата и риска и налага блокиране. При карта това е авторизацията; при превод дебитът се резервира.
03
Захващане (capture)
Блокираната сума се потвърждава. Ledger-ът отразява записа с двойно записване, който реално премества стойността между двете сметки.
04
Сетълмент
Средствата се уреждат по съответната релса — картова схема, банка или блокчейн — и сметките за сетълмент се равняват с реалните пари.
05
Равняване
Платформата сверява собствените си записи с отчета за сетълмент на релсата; всичко, което не съвпада, се маркира, а не се скрива.

Уебхуковете и идемпотентността присъстват във всяка точка на този поток. Системите ви научават, че плащане е преминало, като получат събитие, а не като питат непрекъснато, и всяка заявка, която повторите след изтекло време, се разрешава — чрез своя idempotency key — със същия резултат, така че повторението никога не таксува два пъти. Услугата, която изпълнява авторизацията и capture, е платежният gateway.

Приложният слой

Whitelabel приложения отгоре, една платформа отдолу.

Ядрото предоставя възможности; приложният слой ги превръща в продукти. Всяко приложение за клиенти — уеб и мобилно — е whitelabel клиент, който показва същите сметки, плащания и карти под собствената си марка. Темите се управляват чрез токени: цветовете, шрифтовете, радиусите и разстоянията идват от система от дизайн токени (PDS), така че операторът променя целия облик, като сменя токени, а не като разклонява приложението. Една и съща платформа може да бъде насочена в съвсем различни посоки — потребителска необанка, приложение за търговски аквайринг, програма за издаване на карти, крипто on/off-ramp или вътрешен инструмент за операции — без да се превръща в пет отделни продукта. Това е една платформа с различни облици, всеки конфигуриран, а не изграден отново.

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

Операции

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

Зад всяко приложение стои операторска конзола. Там поддръжката търси сметка, анализаторът по риска замразява карта, а ръководителят на операциите отменя запис. Достъпът за четене е широк; привилегированите действия — не. Всичко, което движи пари, променя лимити или засяга средства на клиент, изисква посочена причина преди изпълнение и създава неизменим одитен запис — кой е действал, върху какво, кога и защо. Достъпът следва принципа на най-малките привилегии, така че всеки оператор вижда и прави само това, което ролята му позволява. Такъв е моделът в Protocore Center, операторската конзола, а същата позиция е заложена във всяка система на платформата: чувствителните действия са съзнателни, проследими и подлежат на преглед впоследствие.

01Широко четене, контролиран запис — привилегированите действия са изключение
02Задължителна причина преди всяко действие със средства
03Неизменима одитна следа: кой, какво, кога, защо
04Най-малки привилегии за всяка роля на оператор

Крипто мостът

Крипто и фиат в една счетоводна книга.

Кriptото не е отделен силоз в платформата; крипто адресът е просто поредна сметка в същия ledger. On/off-ramp конвертира между фиат и дигитални активи на границата — клиентът зарежда баланс с карта или превод и получава крипто, или продава крипто и тегли към банкова сметка. Стойност on-chain може да се уреди чак до банковата релса: входящо on-chain плащане се заверява по сметката, конвертира се и се изплаща към IBAN, така че получателят вижда обикновени пари в обикновена банкова сметка. Тъй като двете страни се записват в един ledger с двойно записване, движение, което започва on-chain и свършва като банков превод, е една равнена история, а не две системи, равнявани на ръка.

01Крипто адресът е сметка като всяка друга
02On/off-ramp: фиат и дигитални активи се конвертират на границата
03On-chain сетълмент чак до изплащане към IBAN
04Една равнена история и за двете страни

Повърхността за разработка

API, уебхукове и sandbox, върху който да изграждате.

Всичко, което приложенията правят, го правят през документирано API — създаване на сметка, откриване на плащане, издаване на карта, стартиране на ramp. Примерни извиквания са POST /v1/wallets или POST /v1/payments; структурата е REST с idempotency key при всеки запис. Промените в състоянието се доставят като уебхукове, така че системите ви реагират на събития, вместо да ги питат непрекъснато. Разработката се води в sandbox тенант — изолирано копие на платформата с тестови релси, където можете да изпълните целия поток от създаване до равняване, без да движите реални пари. Какво предоставя всеки продукт и на кое ниво се определя от неговата access band; страниците на отделните продукти описват какво включва всяка от тях.

01Документирано REST API, идемпотентни записи
02Уебхукове за всяка промяна на състоянието — по събития, без постоянно питане
03Sandbox тенант с тестови релси, изолиран от продукцията
04Обхватът и лимитите се задават от access band за всеки продукт

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

Protocore изгражда софтуера. Лицензът държи регулираната линия.

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