Platvormi arhitektuur

Üks tuum, palju kasutajapindu — kuidas platvorm tegelikult töötab.

Käik läbi platvormi pearaamatust ülespoole: kontod, KYC, kaardid ja krüpto, mis jagavad ühte kahekordse kirjendamise tuuma, kuidas üks makse liigub loomisest sobitamiseni ning kus asuvad rakenduskiht, operaatorikonsool ja reguleeritud piir.

Tuum

Üks pearaamat kõige all.

Platvormi keskmes on üks kontopearaamat. Iga konto — kliendi rahakott, kaupmehe saldo, tasukonto, arvelduskonto — on selle pearaamatu sõlm ning iga väärtuse liikumine on kahekordne kanne: üks konto deebetitakse, teine kreeditakse ja mõlemad pooled on alati võrdsed. Pearaamat on ainult lisatav. Kandeid ei muudeta ega kustutata; parandus on uus vastupidine kanne, nii et saldo jõudmise lugu praeguse väärtuseni on alati taastatav. Kontod, KYC olek, väljastatud kaardid ja krüptoaadressid kuuluvad kõik samasse kontomudelisse. Seetõttu saavad kaardiautoriseerimine, pangaülekanne ja ahelasisene sissemakse kanduda ühele saldole ilma sobitamiskihita, mis eraldi süsteeme kokku õmbleks.

  1. 01Kahekordne kirjendamine: iga kanne on tasakaalus, deebet võrdub kreeditiga
  2. 02Ainult lisatav: paranduseks on uued kanded, mitte muutmine
  3. 03Üks kontomudel fiat-raha, kaartide ja krüpto jaoks
  4. 04KYC olek liigub kontoga kaasa, mitte kõrvaltabelis

Makse algusest lõpuni

Üks makse, loomisest sobitamiseni.

Makse ei ole üks päring, vaid lühike elutsükkel ning iga etapp on olek, mida näevad nii pearaamat kui ka sinu süsteemid. Iga olekumuutus saadab webhooki ja iga kirjutamine on idempotentne — sama võti annab sama tulemuse, nii et korratud päring ei tekita topeltmakset.

  1. 01

    Loomine

    Avatakse makse kavatsus: summa, valuuta, osalevad kontod. Midagi pole veel liikunud — pearaamatusse tekib ootel kanne.

  2. 02

    Autoriseerimine

    Kanal kontrollib vahendeid ja riski ning paneb summa ootele. Kaardi puhul on see autoriseerimine, ülekande puhul reserveeritakse deebet.

  3. 03

    Kinnitamine

    Ootel summa kinnitatakse. Pearaamat kannab kahekordse kirjendusega väärtuse tegelikult kahe konto vahel üle.

  4. 04

    Arveldus

    Vahendid liiguvad läbi aluseks oleva kanali — kaardiskeemi, panga või ahela — ja arvelduskontod sobivad päris rahaga.

  5. 05

    Sobitamine

    Platvorm sobitab enda kanded kanali arveldusaruandega; kõik, mis ei klapi, märgitakse, mitte ei peideta.

Webhookid ja idempotentsus on selle voo igas servas. Sinu süsteemid saavad makse liikumisest teada sündmusest, mitte pollimisest, ja iga pärast ajalõppu korratud päring lahendub oma idempotentsivõtme abil samaks tulemuseks, nii et kordus ei tekita topeltmakset. Autoriseerimist ja kinnitamist käitav teenus on makselüüs.

Rakenduskiht

Peal whitelabel-rakendused, all üks platvorm.

Tuum pakub võimekusi; rakenduskiht muudab need toodeteks. Iga kliendile suunatud rakendus — veebi- ja mobiilne — on whitelabel-klient, mis kuvab samu kontosid, makseid ja kaarte oma brändi all. Kujundus põhineb tokenitel: värvid, kirjastiil, nurgaraadiused ja vahed tulevad disainitokenite süsteemist (PDS), nii et operaator muudab kogu pinna ilme tokeneid vahetades, mitte rakendust hargnema panemata. Sama platvormi saab suunata väga erinevatesse suundadesse — tarbija neopank, kaupmeeste acquiring-rakendus, kaardiväljastusprogramm, krüpto on/off-ramp või sisemine operatsioonitööriist — ilma et see muutuks viieks eraldi tooteks. See on üks platvorm erinevates kuubedes, mida konfigureeritakse, mitte ei ehitata otsast uuesti.

  1. 01Whitelabel veebi- ja mobiiliklient ühistel API-del
  2. 02Tokenipõhine teemastamine (PDS): ilme muutub konfiguratsiooniga, mitte hargnemisega
  3. 03Viis näitesuunda — neopank, acquiring, issuing, ramp, ops
  4. 04Uusi kasutajapindu konfigureeritakse, mitte ei ehitata uuesti

Operatsioonid

Juhi seda konsoolist, põhjus kirjas.

Iga rakenduse taga on operaatorikonsool. Seal otsib klienditoe agent konto üles, riskianalüütik külmutab kaardi või operatsioonijuht tühistab kande. Lugemisõigus on lai, privilegeeritud toimingud mitte. Kõik, mis liigutab raha, muudab limiite või puudutab kliendi vahendeid, nõuab enne käivitamist põhjendust ja jätab muutumatu auditikirje — kes tegi, mida, millal ja miks. Juurdepääs järgib vähimate õiguste põhimõtet, nii et iga operaator näeb ja teeb ainult seda, mida tema roll lubab. Nii töötab Protocore Center, operaatorikonsool, ja sama hoiak on ehitatud igasse platvormi süsteemi: tundlikud toimingud on teadlikud, isikustatavad ja tagantjärele ülevaadatavad.

  1. 01Lai lugemisõigus, piiratud kirjutamine — privilegeeritud toimingud on erand
  2. 02Põhjus on nõutav enne iga vahendeid puudutavat toimingut
  3. 03Muutumatu auditijälg: kes, mida, millal, miks
  4. 04Vähimate õiguste põhimõte iga operaatorirolli jaoks

Krüptosild

Krüpto ja fiat-raha samas pearaamatus.

Krüpto ei ole platvormil eraldi siilo; krüptoaadress on lihtsalt üks konto samas pearaamatus. On/off-ramp konverteerib fiat-raha ja digivarasid serval — klient täidab saldo kaardi või ülekandega ja saab krüptot või müüb krüptot ja võtab raha pangakontole välja. Ahelasisene väärtus saab arveldada kuni pangakanalini: sissetulev ahelasisene makse kantakse kontole, konverteeritakse ja makstakse välja IBAN-ile, nii et saaja näeb tavalist raha tavalisel pangakontol. Kuna mõlemad osad kanduvad ühte kahekordse kirjendusega pearaamatusse, on ahelas alanud ja pangaülekandega lõppev liikumine üks sobitatud ajalugu, mitte kaks süsteemi, mida käsitsi sobitatakse.

  1. 01Krüptoaadress on konto nagu iga teinegi
  2. 02On/off-ramp: fiat-raha ja digivarad konverteeritakse serval
  3. 03Ahelasisene arveldus kuni IBAN-ile väljamaksmiseni
  4. 04Üks sobitatud ajalugu mõlemal osal

Arenduspind

API-d, webhookid ja sandbox, mille vastu arendada.

Kõik, mida rakendused teevad, tehakse dokumenteeritud API kaudu — konto loomine, makse avamine, kaardi väljastamine, ramp'i algatamine. Näidispäringud on kujul POST /v1/wallets või POST /v1/payments; stiil on REST, igal kirjutamisel idempotentsivõti. Olekumuutused tulevad webhookidena, nii et su süsteemid reageerivad sündmustele, mitte ei päri neid pidevalt. Arendus käib sandbox-tenandi vastu — platvormi isoleeritud koopia testkanalitega, kus saad läbi mängida kogu loomisest sobitamiseni voo ilma päris raha liigutamata. Mida iga toode sulle pakub ja millisel tasemel, määrab selle juurdepääsuriba; tootelehed kirjeldavad, mida konkreetne riba sisaldab.

  1. 01Dokumenteeritud REST API, idempotentsed kirjutamised
  2. 02Webhookid igale olekumuutusele — sündmuspõhine, mitte pollimine
  3. 03Sandbox-tenant testkanalitega, toodangust isoleeritud
  4. 04Ulatus ja limiidid sõltuvad toote juurdepääsubaridest

Aus piir

Protocore ehitab tarkvara. Litsents hoiab reguleeritud piiri.

Maksetoode koosneb kahest kokkusulatatud asjast: reguleeritud luba raha hoida ja liigutada ning tarkvara, mis seda juhib, kirjendab ja sobitab. Protocore ehitab tarkvara. Reguleeritud tegevus — klientide vahendite hoidmine, kontode väljastamine, raha liigutamine kaardiskeemis — jääb operaatori enda litsentsi või litsentseeritud partneri, nagu pank, e-raha asutus või makseasutus, kanda. Platvorm on ehitatud sobima igasuguste reguleeritud kanalitega, mille kaasa tood, ja hoidma kaardiandmed kanalis, nii et need ei jõua kunagi sinu serveritesse; see ei asenda seda luba ega suuda seda ükski tarkvara. Kuhu reguleeritud piir jääb, otsustad sina koos oma partneriga, ja arhitektuur on mõeldud istuma puhtalt mõlemal pool seda.

  1. 01Tarkvarakiht, mitte litsents
  2. 02Reguleeritud tegevus jääb operaatorile või litsentseeritud partnerile
  3. 03Kaardiandmed jäävad kanalisse, sinu serveritest eemale
  4. 04Ehitatud sobima sinu kaasatoodud reguleeritud kanalitega

Soovid oma projekti arhitektuuri?

Räägi, mida ehitad. Tuleme tagasi süsteemidisaini ja reguleeritud piiri asukohaga — mitte pitch deckiga.