Plattformarkitektur

Én kjerne, mange flater – slik fungerer plattformen i praksis.

En gjennomgang av plattformen fra hovedboken og opp: kontoer, KYC, kort og krypto som deler én kjerne med dobbelt bokholderi, hvordan én enkelt betaling går fra opprettelse til avstemming, og hvor app-laget, operatørkonsollen og den regulerte grensen hører hjemme.

Snakk med oss Se produktene

Kjernen

Én hovedbok under alt.

I sentrum av plattformen ligger én enkelt kontohovedbok. Hver konto – en kundelommebok, en forhandlersaldo, en gebyrkonto, en oppgjørskonto – er et knutepunkt i hovedboken, og hver verdioverføring er en postering med dobbelt bokholderi: én konto debiteres, en annen krediteres, og de to sidene er alltid like store. Hovedboken er append-only. Posteringer blir aldri redigert eller slettet; en korreksjon er en ny, motsatt postering, slik at hele historikken for hvordan en saldo har kommet frem til dagens verdi alltid kan rekonstrueres. Kontoer, KYC-status, utstedte kort og kryptoadresser er alle knyttet til den samme kontomodellen. Derfor kan en kortautorisasjon, en bankoverføring og et innskudd on-chain posteres på én saldo, uten et avstemmingslag som syr sammen separate systemer.

01Dobbelt bokholderi: hver postering balanserer, debet er lik kredit
02Append-only: korreksjoner er nye posteringer, aldri redigeringer
03Én kontomodell for fiat, kort og krypto
04KYC-status følger kontoen, ikke en sidetabell

En betaling, fra start til slutt

Én betaling, fra opprettelse til avstemming.

En betaling er ikke ett kall, men en kort livssyklus, og hvert trinn er en tilstand som både hovedboken og systemene dine kan se. Hver tilstandsendring sender en webhook, og hver skriveoperasjon er idempotent – den samme nøkkelen gir alltid samme resultat, så en gjentatt forespørsel aldri belaster dobbelt.

01
Opprett
En intensjon åpnes: beløp, valuta og kontoene som er involvert. Ingenting er flyttet ennå – hovedboken registrerer en ventende postering.
02
Autoriser
Kanalen kontrollerer dekning og risiko og legger en reservasjon. For et kort er dette autorisasjonen; for en overføring reserveres debiteringen.
03
Capture
Det reserverte beløpet bekreftes. Hovedboken posterer det doble bokholderiet som faktisk flytter verdi mellom de to kontoene.
04
Oppgjør
Midlene gjøres opp over den underliggende kanalen – kortnettverk, bank eller chain – og oppgjørskontoene avstemmes mot reelle penger.
05
Avstem
Plattformen sammenligner sine egne posteringer med kanalens oppgjørsrapport; alt som ikke stemmer, flagges, ikke skjules.

Webhooks og idempotens finnes i alle ledd av denne flyten. Systemene dine får vite at en betaling er flyttet ved å motta en hendelse, ikke ved å polle, og alle forespørsler du prøver på nytt etter en timeout, ender – via sin idempotency key – i samme resultat, så en gjentakelse aldri belaster dobbelt. Tjenesten som kjører autorisasjon og capture er betalingsgatewayen.

App-laget

Whitelabel-apper øverst, én plattform nederst.

Kjernen tilbyr funksjoner; app-laget gjør dem om til produkter. Hver kundevendte app – web og mobil – er en whitelabel-klient som viser de samme kontoene, betalingene og kortene i sin egen merkevare. Temaer styres av tokens: farger, typografi, avrunding og avstand hentes fra et design-token-system (PDS), slik at en operatør kan endre hele uttrykket ved å endre tokens, uten å forke appen. Den samme plattformen kan rettes mot svært ulike formål – en neobank for forbrukere, en acquiring-app for forhandlere, et kortutstedelsesprogram, en on-/off-ramp for krypto eller et internt driftsverktøy – uten å bli fem separate produkter. Det er én plattform i ulike drakter, konfigurert i stedet for bygget på nytt.

01Whitelabel-klienter for web og mobil på felles API-er
02Token-styrt tema (PDS): endre uttrykk med konfigurasjon, ikke fork
03Fem eksempler på bruk – neobank, acquiring, issuing, ramp, ops
04Nye flater konfigureres, de bygges ikke på nytt

Drift

Styr alt fra konsollen, med en begrunnelse i loggen.

Bak hver app ligger en operatørkonsoll. Her slår en kundeservicemedarbeider opp en konto, en risikoanalytiker fryser et kort, eller en driftsleder reverserer en postering. Lesetilgangen er bred, men privilegerte handlinger er det ikke. Alt som flytter penger, endrer grenser eller berører kundens midler krever en oppgitt begrunnelse før det utføres, og skriver en uforanderlig revisjonspost – hvem som handlet, på hva, når og hvorfor. Tilgang følger prinsippet om minste privilegium, slik at hver operatør bare ser og gjør det rollen tillater. Dette er modellen i Protocore Center, operatørkonsollen, og den samme holdningen er bygget inn i alle systemer på plattformen: sensitive handlinger er bevisste, kan tilskrives en person og kan etterprøves i ettertid.

01Bred lesetilgang, kontrollert skrivetilgang – privilegerte handlinger er unntaket
02Begrunnelse kreves før enhver handling som berører midler
03Uforanderlig revisjonsspor: hvem, hva, når, hvorfor
04Minste privilegium per operatørrolle

Kryptobroen

Krypto og fiat i samme hovedbok.

Krypto er ikke en egen silo på plattformen; en kryptoadresse er bare en konto til på samme hovedbok. En on-/off-ramp konverterer mellom fiat og digitale eiendeler i kanten – en kunde fyller på en saldo med kort eller overføring og mottar krypto, eller selger krypto og tar ut til en bankkonto. Verdi on-chain kan gjøres opp helt frem til en bankkanal: en innkommende betaling on-chain krediteres kontoen, konverteres og utbetales til en IBAN, slik at mottakeren ser vanlige penger på en vanlig bankkonto. Fordi begge leddene posteres i én hovedbok med dobbelt bokholderi, er en overføring som starter on-chain og ender som en bankoverføring én samlet, avstemt historikk – ikke to systemer som avstemmes for hånd.

01En kryptoadresse er en konto som alle andre
02On-/off-ramp: fiat og digitale eiendeler konverteres i kanten
03Oppgjør on-chain helt frem til utbetaling til IBAN
04Én avstemt historikk på tvers av begge ledd

Byggeflaten

API-er, webhooks og en sandbox å bygge mot.

Alt appene gjør, gjør de via et dokumentert API – opprette en konto, åpne en betaling, utstede et kort, starte en ramp. Eksempler på kall er POST /v1/wallets eller POST /v1/payments; formatet er REST med en idempotency key på hver skriveoperasjon. Tilstandsendringer leveres som webhooks, slik at systemene dine reagerer på hendelser i stedet for å polle etter dem. Utviklingen skjer mot en sandbox-tenant – en isolert kopi av plattformen med testkanaler, der du kan kjøre hele flyten fra opprettelse til avstemming uten å flytte ekte penger. Hva hvert produkt gir deg tilgang til, og på hvilket nivå, bestemmes av tilgangsbåndet; produktsidene beskriver hva et gitt bånd inneholder.

01Dokumentert REST API, idempotente skriveoperasjoner
02Webhooks for hver tilstandsendring – hendelsesdrevet, ikke polling
03Sandbox-tenant med testkanaler, isolert fra produksjon
04Omfang og grenser styres av tilgangsbånd per produkt

Den ærlige grensen

Protocore bygger programvaren. Lisensen bærer den regulerte delen.

Et betalingsprodukt er to ting som henger sammen: den regulerte tillatelsen til å holde og flytte penger, og programvaren som instruerer, registrerer og avstemmer dem. Protocore bygger programvaren. Den regulerte virksomheten – å holde kundemidler, utstede kontoer og flytte penger i et kortnettverk – ligger hos operatørens egen lisens eller en lisensiert partner: en bank, en EMI eller et betalingsforetak. Plattformen er laget for å passe til de regulerte kanalene du tar med, og for å holde kortdata på kanalen slik at de aldri berører serverne dine; den er ikke, og ingen programvare er, en erstatning for den tillatelsen. Hvor den regulerte grensen går, avgjør du sammen med partneren din, og arkitekturen er laget for å fungere rent på begge sider av den.