Platformsarkitektur

Én kerne, mange flader — sådan fungerer platformen i praksis.

En gennemgang af platformen fra hovedbogen og op: konti, KYC, kort og krypto, der deler én dobbelt bogføringskerne, hvordan en enkelt betaling bevæger sig fra oprettelse til afstemning, og hvor app-laget, operatørkonsollen og den regulerede grænse hver især placerer sig.

Kontakt os Se produkterne

Kernen

Én hovedbog under det hele.

I platformens centrum ligger én samlet kontohovedbog. Hver konto — en kundes wallet, en forhandlers saldo, en gebyrkonto, en settlement-konto — er et knudepunkt på hovedbogen, og hver værdiflytning er en dobbelt bogføring: én konto debiteres, en anden krediteres, og de to sider er altid lige store. Hovedbogen er append-only. Posteringer redigeres eller slettes aldrig; en rettelse er en ny, modsatrettet postering, så hele historikken for, hvordan en saldo er nået til sin nuværende værdi, altid kan genskabes. Konti, KYC-status, udstedte kort og kryptoadresser er alle knyttet til den samme kontomodel, og derfor kan en kortgodkendelse, en bankoverførsel og en on-chain-indbetaling bogføres på én saldo uden et afstemningslag, der sætter separate systemer sammen.

01Dobbelt bogføring: hver postering balancerer, debet er lig kredit
02Append-only: rettelser er nye posteringer, aldrig redigeringer
03Én kontomodel til fiat, kort og krypto
04KYC-status følger kontoen, ikke en sidetabel

En betaling, fra ende til anden

Én betaling, fra oprettelse til afstemning.

En betaling er ikke ét kald, men et kort forløb, og hvert trin er en tilstand, som både hovedbogen og dine systemer kan se. Hver tilstandsændring udløser en webhook, og hver skrivning er idempotent — den samme nøgle giver det samme resultat, så en gentaget anmodning aldrig trækker beløbet to gange.

01
Opret
Et intent åbnes: beløb, valuta, de involverede konti. Intet er flyttet endnu — hovedbogen registrerer en afventende postering.
02
Autorisér
Skinnen kontrollerer dækning og risiko og reserverer beløbet. For et kort er det autorisationen; for en overførsel reserveres debiteringen.
03
Capture
Det reserverede beløb gennemføres. Hovedbogen bogfører den dobbelte postering, der faktisk flytter værdi mellem de to konti.
04
Afvikl
Midlerne clearer over den underliggende skinne — kortsystem, bank eller chain — og settlement-konti afstemmes mod rigtige penge.
05
Afstem
Platformen matcher sine egne posteringer mod skinnens settlement-rapport; alt, der ikke stemmer, bliver markeret, ikke skjult.

Webhooks og idempotens findes i hver kant af dette flow. Dine systemer får at vide, at en betaling er gennemført, ved at modtage en hændelse, ikke ved at polle, og enhver anmodning, du gentager efter en timeout, ender — via sin idempotensnøgle — i det samme resultat, så en gentagelse aldrig trækker to gange. Den tjeneste, der kører autorisation og capture, er betalingsgatewayen.

App-laget

Whitelabel-apps øverst, én platform nedenunder.

Kernen stiller funktioner til rådighed; app-laget gør dem til produkter. Hver kundevendt app — web og mobil — er en whitelabel-klient, der viser de samme konti, betalinger og kort under sit eget brand. Temaer er token-drevne: farver, typografi, radius og afstande kommer fra et design token-system (PDS), så en operatør kan give hele fladen nyt udtryk ved at ændre tokens i stedet for at forke appen. Den samme platform kan pege i vidt forskellige retninger — en forbruger-neobank, en acquiring-app til forhandlere, et kortudstedelsesprogram, en krypto on/off-ramp eller et internt driftsværktøj — uden at blive til fem separate produkter. Det er én platform med forskellige skin, hvert konfigureret frem for bygget forfra.

01Whitelabel web- og mobilklienter på delte API'er
02Token-drevne temaer (PDS): nyt udtryk via konfiguration, ikke fork
03Fem eksempler på retninger — neobank, acquiring, issuing, ramp, drift
04Nye flader konfigureres, de bygges ikke forfra

Drift

Styr det fra konsollen, med en begrundelse på record.

Bag hver app står en operatørkonsol. Her slår en supportmedarbejder en konto op, en risikoanalytiker fryser et kort, eller en driftsleder tilbagefører en postering. Læseadgang er bred; privilegerede handlinger er det ikke. Alt, der flytter penge, ændrer grænser eller berører en kundes midler, kræver en angivet begrundelse, før det kører, og skriver en uforanderlig auditpost — hvem der handlede, på hvad, hvornår og hvorfor. Adgang følger princippet om mindste privilegium, så hver operatør kun ser og gør det, rollen tillader. Sådan fungerer det i Protocore Center, operatørkonsollen, og den samme tilgang er bygget ind i alle systemer på platformen: følsomme handlinger er bevidste, kan henføres til en person og kan gennemgås bagefter.

01Bred læseadgang, begrænset skriveadgang — privilegerede handlinger er undtagelsen
02Begrundelse påkrævet før enhver handling, der berører midler
03Uforanderligt revisionsspor: hvem, hvad, hvornår, hvorfor
04Mindste privilegium pr. operatørrolle

Kryptobroen

Krypto og fiat på samme hovedbog.

Krypto er ikke en separat silo på platformen; en kryptoadresse er blot endnu en konto på samme hovedbog. En on/off-ramp konverterer mellem fiat og digitale aktiver i kanten — en kunde fylder en saldo op med kort eller overførsel og modtager krypto, eller sælger krypto og hæver til en bankkonto. On-chain-værdi kan afvikles videre til en bankskinne: en indgående on-chain-betaling krediteres kontoen, konverteres og udbetales til en IBAN, så modtageren ser helt almindelige penge på en helt almindelig bankkonto. Fordi begge led bogføres på én dobbelt hovedbog, er en bevægelse, der starter on-chain og ender som bankoverførsel, én samlet afstemt historik, ikke to systemer afstemt i hånden.

01En kryptoadresse er en konto som alle andre
02On/off-ramp: fiat og digitale aktiver konverteres i kanten
03On-chain-settlement helt frem til udbetaling til IBAN
04Én afstemt historik på tværs af begge led

Udviklerfladen

API'er, webhooks og en sandbox at bygge imod.

Alt, hvad appsene gør, gør de via et dokumenteret API — opret en konto, åbn en betaling, udsted et kort, start en ramp. Eksempler på kald er POST /v1/wallets eller POST /v1/payments; formatet er REST med en idempotensnøgle på hver skrivning. Tilstandsændringer leveres som webhooks, så dine systemer reagerer på hændelser i stedet for at polle efter dem. Udvikling sker mod en sandbox-tenant — en isoleret kopi af platformen med testskinner, hvor du kan køre hele forløbet fra oprettelse til afstemning uden at flytte rigtige penge. Hvad hvert produkt giver dig adgang til, og på hvilket niveau, bestemmes af dets access band; produktsiderne beskriver, hvad et givent band omfatter.

01Dokumenteret REST API, idempotente skrivninger
02Webhooks ved hver tilstandsændring — hændelsesdrevet, ikke polling
03Sandbox-tenant med testskinner, isoleret fra produktion
04Omfang og grænser fastsat af access bands pr. produkt

Den ærlige grænse

Protocore bygger softwaren. Licensen bærer den regulerede grænse.

Et betalingsprodukt er to ting smeltet sammen: den regulerede tilladelse til at opbevare og flytte penge og softwaren, der instruerer, registrerer og afstemmer dem. Protocore bygger softwaren. Den regulerede aktivitet — at opbevare kundemidler, udstede konti, flytte penge på et kortsystem — ligger hos operatørens egen licens eller en licenseret partner: en bank, en EMI eller et betalingsinstitut. Platformen er bygget til at passe til de regulerede skinner, du selv medbringer, og til at holde kortdata på skinnen, så de aldrig rører dine servere; den er ikke en erstatning for den tilladelse, og det er ingen software. Hvor den regulerede grænse går, afgør du sammen med din partner, og arkitekturen er designet til at sidde rent på begge sider af den.