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

Едно јадро, многу површини — како навистина работи платформата.

Преглед на платформата од главната книга нагоре: сметките, KYC, картичките и крипто што делат едно јадро со двојно книжење, како едно плаќање поминува од креирање до усогласување и каде се сместени апликацискиот слој, операторската конзола и регулираната линија.

Јавете ни се Погледнете ги производите

Јадрото

Една главна книга под сѐ.

Во центарот на платформата е една главна книга на сметки. Секоја сметка — клиентски паричник, салдо на трговец, сметка за провизии, сметка за порамнување — е јазол во таа книга, а секое движење на вредност е книжење со двојно книговодство: една сметка се задолжува, друга се одобрува, а двете страни се секогаш еднакви. Главната книга е само за додавање (append-only). Записите никогаш не се менуваат ниту бришат; корекцијата е нов, спротивен запис, па целата историја на тоа како салдото ја достигнало сегашната вредност секогаш може да се реконструира. Сметките, KYC статусот, издадените картички и крипто адресите се врзани за ист модел на сметка, па затоа картична авторизација, банкарски трансфер и on-chain депозит можат да се книжат на едно салдо без слој за усогласување што лепи одделни системи.

01Двојно книговодство: секое книжење е балансирано, задолженијата се еднакви на одобрувањата
02Append-only: корекциите се нови записи, никогаш измени
03Еден модел на сметка за фиат, картички и крипто
04KYC статусот оди со сметката, а не во споредна табела

Едно плаќање, од почеток до крај

Едно плаќање, од креирање до усогласување.

Плаќањето не е еден повик, туку краток животен циклус, а секоја фаза е состојба што ја гледаат и главната книга и вашите системи. Секоја промена на состојба испраќа webhook, а секое пишување е идемпотентно — истиот клуч дава ист резултат, па повторено барање никогаш не наплаќа двапати.

01
Креирање
Се отвора намера: износ, валута, засегнатите сметки. Сè уште ништо не е поместено — главната книга запишува запис на чекање.
02
Авторизација
Шината ги проверува средствата и ризикот и става блокада. Кај картичка тоа е авторизацијата; кај трансфер, задолжувањето се резервира.
03
Наплата
Блокираниот износ се потврдува. Главната книга го книжи двојниот запис што навистина ја пренесува вредноста меѓу двете сметки.
04
Порамнување
Средствата се порамнуваат преку подлабоката шина — картична шема, банка или chain — а сметките за порамнување се усогласуваат со вистински пари.
05
Усогласување
Платформата ги споредува сопствените книжења со извештајот за порамнување од шината; што не се поклопува, се означува, не се крие.

Webhooks и идемпотентност има на секој раб од овој тек. Вашите системи дознаваат дека плаќањето поминало преку примен настан, а не со polling, а секое барање што го повторувате по истек на времето се решава — преку својот клуч за идемпотентност — до ист резултат, па повторувањето никогаш не наплаќа двапати. Услугата што ги извршува авторизацијата и наплатата е платежен gateway.

Апликацискиот слој

Whitelabel апликации одозгора, една платформа одоздола.

Јадрото нуди функционалности; апликацискиот слој ги претвора во производи. Секоја апликација за клиенти — веб и мобилна — е whitelabel клиент што ги прикажува истите сметки, плаќања и картички преку сопствен бренд. Темите се водени од токени: боите, типографијата, заоблувањето и растојанијата доаѓаат од систем на дизајн-токени (PDS), па операторот ја менува целата површина со менување токени, а не со форкување на апликацијата. Истата платформа може да се насочи во сосема различни правци — потрошувачка necobanka, апликација за acquiring на трговци, програма за издавање картички, крипто on/off-ramp или внатрешна алатка за операции — без да стане пет одделни производа. Тоа е една платформа во различни облеки, секоја конфигурирана, а не изградена одново.

01Whitelabel веб и мобилни клиенти на заедничко API
02Теми водени од токени (PDS): рестилизирање со конфигурација, не со fork
03Пет примерни правци — neobank, acquiring, issuing, ramp, ops
04Новите површини се конфигурираат, не се градат одново

Операции

Управувајте од конзолата, со причина запишана во евиденција.

Зад секоја апликација стои операторска конзола. Таму агент за поддршка бара сметка, аналитичар за ризик замрзнува картичка, а раководител на операции сторнира книжење. Пристапот за читање е широк; привилегираните дејства не се. Сѐ што движи пари, менува лимити или засега средства на клиент бара наведена причина пред да се изврши и запишува неизменлив ревизорски запис — кој дејствувал, врз што, кога и зошто. Пристапот следи принцип на најмали привилегии, па секој оператор гледа и прави само што му дозволува улогата. Ова е моделот во Protocore Center, операторската конзола, а истиот пристап е вграден во секој систем на платформата: чувствителните дејства се намерни, припишливи и подложни на ревизија потоа.

01Широко читање, контролирано пишување — привилегираните дејства се исклучок
02Задолжителна причина пред секое дејство што засега средства
03Неизменлива ревизорска трага: кој, што, кога, зошто
04Најмали привилегии по операторска улога

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

Крипто и фиат во иста главна книга.

Крипто не е посебен silo на платформата; крипто адресата е уште една сметка во истата главна книга. On/off-ramp конвертира меѓу фиат и дигитални средства на работ — клиентот полни салдо со картичка или трансфер и добива крипто, или продава крипто и повлекува на банкарска сметка. On-chain вредноста може да се порамни до банкарска шина: дојдовно on-chain плаќање се одобрува на сметката, се конвертира и се исплаќа на IBAN, па примачот гледа обични пари на обична банкарска сметка. Бидејќи двете страни се книжат во една главна книга со двојно книговодство, движењето што почнува on-chain и завршува како банкарски трансфер е една усогласена историја, а не два системи усогласувани рачно.

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

Површината за градење

API, webhooks и sandbox за градење.

Сѐ што го прават апликациите, го прават преку документирано API — креирање сметка, отворање плаќање, издавање картичка, иницирање ramp. Илустративни повици изгледаат како POST /v1/wallets или POST /v1/payments; обликот е REST со idempotency клуч на секое пишување. Промените на состојбата се испорачуваат како webhooks, па вашите системи реагираат на настани наместо да ги бараат со polling. Развојот се одвива врз sandbox tenant — изолирана копија на платформата со тест шини, каде можете да го извршите целиот тек од креирање до усогласување без да движите вистински пари. Што му нуди секој производ и на кое ниво, го определува неговата пристапна лента; страниците на производите објаснуваат што опфаќа секоја лента.

01Документирано REST API, идемпотентни пишувања
02Webhooks за секоја промена на состојба — водено од настани, без polling
03Sandbox tenant со тест шини, изолиран од продукцијата
04Опсегот и лимитите ги одредуваат пристапните ленти по производ

Искрената граница

Protocore го гради софтверот. Лиценцата ја држи регулираната линија.

Платежниот производ е две работи споени заедно: регулирана дозвола за чување и движење пари и софтвер што го наредува, евидентира и усогласува тоа. Protocore го гради софтверот. Регулираната дејност — чување средства на клиенти, издавање сметки, движење пари преку шема — останува кај сопствената лиценца на операторот или кај лиценциран партнер: банка, EMI или платежна институција. Платформата е изградена да се вклопи во какви било регулирани шини што ги носите и да ги задржи податоците од картичките на шината за да не стигнат до вашите сервери; таа не е замена за таа дозвола, а ниту еден софтвер не е. Каде паѓа регулираната линија е одлука што ја носите со вашиот партнер, а архитектурата е дизајнирана чисто да стои на која било нејзина страна.