Platformos architektūra

Vienas branduolys, daug sąsajų — kaip platforma veikia iš tikrųjų.

Platformos apžvalga nuo apskaitos knygos (ledger) aukštyn: sąskaitos, KYC, kortelės ir kripto, kurie dalijasi vienu dvigubo įrašo branduoliu; kaip vienas mokėjimas keliauja nuo sukūrimo iki suderinimo; ir kur yra programų sluoksnis, operatoriaus konsolė bei reguliuojama riba.

Susisiekite Peržiūrėti produktus

Branduolys

Viena apskaitos knyga po viskuo.

Platformos centre yra viena sąskaitų apskaitos knyga. Kiekviena sąskaita — kliento piniginė, prekybininko likutis, komisinių sąskaita, atsiskaitymų sąskaita — yra šios knygos mazgas, o kiekvienas vertės judėjimas yra dvigubo įrašo operacija: viena sąskaita debetuojama, kita kredituojama, ir abi pusės visada lygios. Knyga yra tik papildoma (append-only). Įrašai niekada nekeičiami ir netrinami; pataisymas yra naujas, priešingas įrašas, todėl visada galima atkurti, kaip likutis pasiekė dabartinę vertę. Sąskaitos, KYC būsena, išduotos kortelės ir kripto adresai remiasi tuo pačiu sąskaitos modeliu, todėl kortelės autorizacija, banko pervedimas ir įmokėjimas blokų grandinėje gali patekti į tą patį likutį be suderinimo sluoksnio, siuvančio atskiras sistemas.

01Dvigubas įrašas: kiekviena operacija subalansuota, debetas lygus kreditui
02Tik papildoma: pataisymai yra nauji įrašai, ne redagavimas
03Vienas sąskaitos modelis fiat, kortelėms ir kripto
04KYC būsena keliauja kartu su sąskaita, o ne atskiroje lentelėje

Mokėjimas nuo pradžios iki galo

Vienas mokėjimas: nuo sukūrimo iki suderinimo.

Mokėjimas yra ne vienas iškvietimas, o trumpas gyvavimo ciklas, ir kiekvienas etapas yra būsena, kurią mato ir apskaitos knyga, ir jūsų sistemos. Kiekvienas būsenos pokytis siunčia webhook, o kiekvienas rašymas yra idempotentiškas — tas pats raktas atkartoja tą patį rezultatą, todėl pakartota užklausa niekada nenurašo dvigubai.

01
Sukūrimas
Atidaromas ketinimas (intent): suma, valiuta, dalyvaujančios sąskaitos. Dar nieko nepajudėjo — knyga užregistruoja laukiantį įrašą.
02
Autorizavimas
Kanalas patikrina lėšas ir riziką bei užrezervuoja sumą. Kortelei tai yra autorizacija, pervedimui — rezervuojamas debetas.
03
Užfiksavimas
Rezervuota suma patvirtinama. Knyga įrašo dvigubą įrašą, kuris iš tikrųjų perkelia vertę tarp dviejų sąskaitų.
04
Atsiskaitymas
Lėšos pereina per pagrindinį kanalą — kortelių schemą, banką ar grandinę — o atsiskaitymų sąskaitos suderinamos su realiais pinigais.
05
Suderinimas
Platforma sulygina savo įrašus su kanalo atsiskaitymų ataskaita; viskas, kas nesutampa, pažymima, o ne slepiama.

Webhooks ir idempotentiškumas veikia kiekviename šio srauto krašte. Jūsų sistemos sužino, kad mokėjimas pajudėjo, gaudamos įvykį, o ne klausinėdamos, o bet kuri po skirtojo laiko pakartota užklausa duoda tą patį rezultatą. Už tai atsakingas idempotentiškumo raktas — todėl pakartojimas niekada nenurašo dvigubai. Autorizavimą ir užfiksavimą vykdo mokėjimų gateway.

Programų sluoksnis

Viršuje — whitelabel programos, apačioje — viena platforma.

Branduolys suteikia galimybes, o programų sluoksnis paverčia jas produktais. Kiekviena klientams skirta programa — žiniatinklio ar mobilioji — yra whitelabel klientas, rodantis tas pačias sąskaitas, mokėjimus ir korteles per savo prekės ženklą. Temos valdomos per tokenus: spalvos, šriftai, kampų spindulys ir tarpai ateina iš dizaino tokenų sistemos (PDS), todėl operatorius visą sąsają pakeičia keisdamas tokenus, o ne kurdamas atskirą programos šaką. Ta pati platforma gali būti nukreipta labai skirtingomis kryptimis — vartotojų neobankas, prekybininkų acquiring programa, kortelių išdavimo programa, kripto on/off-ramp ar vidinis operacijų įrankis — netapdama penkiais atskirais produktais. Tai viena platforma su skirtingais rūbais: kiekviena sukonfigūruojama, o ne kuriama iš naujo.

01Whitelabel žiniatinklio ir mobilieji klientai su bendrais API
02Temos per tokenus (PDS): keiskite stilių konfigūracija, ne šakojimu
03Penki pavyzdiniai scenarijai — neobankas, acquiring, issuing, ramp, ops
04Naujos sąsajos konfigūruojamos, o ne kuriamos iš naujo

Operacijos

Valdykite iš konsolės, kiekvienam veiksmui nurodydami priežastį.

Už kiekvienos programos stovi operatoriaus konsolė. Joje palaikymo specialistas randa sąskaitą, rizikos analitikas užšaldo kortelę, o operacijų vadovas atšaukia įrašą. Peržiūros prieiga plati, o privilegijuoti veiksmai — ne. Bet kuriam veiksmui, kuris juda pinigus, keičia limitus ar liečia kliento lėšas, prieš vykdymą reikia nurodyti priežastį, ir jis sukuria nekeičiamą audito įrašą: kas veikė, ką, kada ir kodėl. Prieiga grindžiama mažiausių privilegijų principu, todėl kiekvienas operatorius mato ir daro tik tai, ką leidžia jo rolė. Taip veikia Protocore Center, operatoriaus konsolė, ir toks pat požiūris įdiegtas kiekvienoje platformos sistemoje: jautrūs veiksmai yra apgalvoti, priskirti asmeniui ir peržiūrimi vėliau.

01Plati peržiūra, ribojamas rašymas — privilegijuoti veiksmai yra išimtis
02Priežastis privaloma prieš bet kokį lėšas liečiantį veiksmą
03Nekeičiamas audito pėdsakas: kas, ką, kada, kodėl
04Mažiausios privilegijos kiekvienai operatoriaus rolei

Kripto tiltas

Kripto ir fiat toje pačioje apskaitos knygoje.

Kripto platformoje nėra atskira sala; kripto adresas — tiesiog dar viena sąskaita toje pačioje apskaitos knygoje. On/off-ramp keičia fiat ir skaitmeninį turtą pakraštyje: klientas papildo likutį kortele ar pervedimu ir gauna kripto arba parduoda kripto ir išsiima į banko sąskaitą. Vertė blokų grandinėje gali būti atsiskaityta iki banko kanalo: gaunamas mokėjimas grandinėje įskaitomas į sąskaitą, konvertuojamas ir išmokamas į IBAN, todėl gavėjas mato įprastus pinigus įprastoje banko sąskaitoje. Kadangi abi pusės įrašomos į vieną dvigubo įrašo knygą, judėjimas, prasidedantis grandinėje ir pasibaigiantis banko pervedimu, yra viena suderinta istorija, o ne dvi sistemos, derinamos rankomis.

01Kripto adresas — tokia pati sąskaita kaip ir kitos
02On/off-ramp: fiat ir skaitmeninis turtas keičiami pakraštyje
03Atsiskaitymas blokų grandinėje iki išmokėjimo į IBAN
04Viena suderinta istorija per abi pusės

Kūrimo sąsaja

API, webhooks ir sandbox, kuriame galima kurti.

Viską, ką daro programos, jos daro per dokumentuotą API — sukurti sąskaitą, atidaryti mokėjimą, išduoti kortelę, inicijuoti ramp. Pavyzdiniai iškvietimai atrodo taip: POST /v1/wallets arba POST /v1/payments; sąsaja yra REST su idempotentiškumo raktu kiekvienam rašymui. Būsenų pokyčiai siunčiami kaip webhooks, todėl jūsų sistemos reaguoja į įvykius, o ne nuolat jų klausinėja. Kūrimas vyksta sandbox tenant aplinkoje — izoliuotoje platformos kopijoje su testiniais kanalais, kurioje galite paleisti visą srautą nuo sukūrimo iki suderinimo nejudindami tikrų pinigų. Ką kiekvienas produktas jums atveria ir kokiame lygyje, nustato jo prieigos juosta; produktų puslapiuose aprašyta, ką apima konkreti juosta.

01Dokumentuotas REST API, idempotentiški rašymai
02Webhooks kiekvienam būsenos pokyčiui — pagal įvykius, be nuolatinio klausinėjimo
03Sandbox tenant su testiniais kanalais, atskirtas nuo produkcijos
04Apimtį ir limitus nustato kiekvieno produkto prieigos juostos

Atvira riba

Protocore kuria programinę įrangą. Licencija laiko reguliuojamą ribą.

Mokėjimų produktas — tai dvi sujungtos dalys: reguliuojamas leidimas laikyti ir judinti pinigus bei programinė įranga, kuri duoda nurodymus, registruoja ir derina. Protocore kuria programinę įrangą. Reguliuojama veikla — kliento lėšų laikymas, sąskaitų išdavimas, pinigų judėjimas per schemą — priklauso paties operatoriaus licencijai arba licencijuotam partneriui: bankui, EMI ar mokėjimo įstaigai. Platforma sukurta taip, kad tiktų prie bet kokių jūsų atsinešamų reguliuojamų kanalų ir kad kortelių duomenys liktų kanale ir niekada nepasiektų jūsų serverių; ji nėra to leidimo pakaitalas, kaip ir jokia programinė įranga nėra. Kur eina reguliuojama riba, sprendžiate jūs kartu su partneriu, o architektūra sukurta taip, kad tvirtai tiktų bet kurioje jos pusėje.