Plattformsarkitektur

En kärna, många gränssnitt – så fungerar plattformen på riktigt.

En genomgång av plattformen underifrån, från huvudboken: konton, KYC, kort och krypto som delar en dubbel bokföringskärna, hur en enskild betalning går från skapande till avstämning, och var applagret, operatörskonsolen och den reglerade gränsen ligger.

Prata med oss Se produkterna

Kärnan

En huvudbok under allt.

I plattformens centrum finns en enda kontohuvudbok. Varje konto – en kundplånbok, ett handlarsaldo, ett avgiftskonto, ett avvecklingskonto – är en nod i huvudboken, och varje värderörelse är en bokning med dubbel bokföring: ett konto debiteras, ett annat krediteras, och de två sidorna är alltid lika stora. Huvudboken är append-only. Poster redigeras eller raderas aldrig; en rättelse är en ny, motsatt post, så hela historiken för hur ett saldo nådde sitt nuvarande värde går alltid att rekonstruera. Konton, KYC-status, utfärdade kort och kryptoadresser hör alla till samma kontomodell. Därför kan en kortauktorisering, en banköverföring och en insättning on-chain bokas på ett och samma saldo, utan något avstämningslager som syr ihop separata system.

01Dubbel bokföring: varje bokning balanserar, debet är lika med kredit
02Append-only: rättelser är nya poster, aldrig ändringar
03En kontomodell för fiat, kort och krypto
04KYC-status följer med kontot, inte i en sidotabell

En betalning, från början till slut

En betalning, från skapande till avstämning.

En betalning är inte ett enda anrop utan en kort livscykel, och varje steg är ett tillstånd som både huvudboken och dina system kan se. Varje tillståndsändring skickar en webhook, och varje skrivning är idempotent – samma nyckel ger alltid samma resultat, så en omsänd förfrågan dubbeldebiterar aldrig.

01
Skapa
En betalningsavsikt öppnas: belopp, valuta och de konton som berörs. Inget har flyttats ännu – huvudboken registrerar en väntande post.
02
Auktorisera
Railen kontrollerar täckning och risk och lägger en reservation. För ett kort är detta auktoriseringen; för en överföring reserveras debiteringen.
03
Fånga
Det reserverade beloppet genomförs. Huvudboken bokför den dubbla bokföringen som faktiskt flyttar värde mellan de två kontona.
04
Avveckla
Medlen klareras över den underliggande railen – kortnätverk, bank eller kedja – och avvecklingskontona stäms av mot verkliga pengar.
05
Stäm av
Plattformen jämför sina egna bokningar med railens avvecklingsrapport; allt som inte stämmer flaggas, inte döljs.

Webhooks och idempotens finns i varje kant av det här flödet. Dina system får veta att en betalning har gått igenom genom att ta emot en händelse, inte genom polling, och varje förfrågan du skickar om efter en timeout löses – via sin idempotensnyckel – till samma resultat, så att en upprepning aldrig dubbeldebiterar. Tjänsten som kör auktorisering och capture är betalningsgatewayen.

Applagret

Whitelabel-appar överst, en plattform under.

Kärnan exponerar funktioner; applagret gör dem till produkter. Varje kundvänd app – webb och mobil – är en whitelabel-klient som visar samma konton, betalningar och kort under sitt eget varumärke. Temahantering styrs av tokens: färger, typografi, radie och avstånd kommer från ett designtokensystem (PDS), så en operatör ändrar utseendet på hela ytan genom att byta tokens, inte genom att forka appen. Samma plattform kan riktas åt helt olika håll – en neobank för konsumenter, en acquiring-app för handlare, ett kortutgivningsprogram, en on/off-ramp för krypto eller ett internt driftverktyg – utan att bli fem separata produkter. Det är en plattform i olika skepnader, där varje variant konfigureras i stället för att byggas om.

01Whitelabel-klienter för webb och mobil på gemensamma API:er
02Tokenstyrd temahantering (PDS): ändra utseende via konfiguration, inte fork
03Fem exempelinriktningar – neobank, acquiring, issuing, ramp, ops
04Nya gränssnitt konfigureras, de byggs inte om

Verksamhetsstyrning

Styr allt från konsolen, med en motivering i loggen.

Bakom varje app finns en operatörskonsol. Där slår en supportagent upp ett konto, en riskanalytiker spärrar ett kort eller en driftchef återför en bokning. Läsåtkomsten är bred, men privilegierade åtgärder är det inte. Allt som flyttar pengar, ändrar gränser eller berör en kunds medel kräver en angiven motivering innan det körs och skapar en oföränderlig granskningspost – vem som agerade, på vad, när och varför. Åtkomsten följer principen om minsta möjliga behörighet, så varje operatör ser och gör bara det som rollen tillåter. Så fungerar det i Protocore Center, operatörskonsolen, och samma hållning finns i alla system på plattformen: känsliga åtgärder är medvetna, spårbara och går att granska i efterhand.

01Bred läsbehörighet, spärrad skrivåtkomst – privilegierade åtgärder är undantaget
02Motivering krävs före varje åtgärd som berör medel
03Oföränderlig granskningslogg: vem, vad, när, varför
04Minsta möjliga behörighet per operatörsroll

Kryptobryggan

Krypto och fiat i samma huvudbok.

Krypto är inget separat silo på plattformen; en kryptoadress är bara ännu ett konto i samma huvudbok. En on/off-ramp växlar mellan fiat och digitala tillgångar i kanten – en kund fyller på ett saldo med kort eller överföring och får krypto, eller säljer krypto och tar ut till ett bankkonto. Värde on-chain kan avvecklas hela vägen till en bankrail: en inkommande betalning on-chain krediteras kontot, växlas och betalas ut till ett IBAN, så mottagaren ser vanliga pengar på ett vanligt bankkonto. Eftersom båda leden bokförs i en och samma huvudbok med dubbel bokföring blir en rörelse som börjar on-chain och slutar som en banköverföring en enda avstämd historik, inte två system som stäms av för hand.

01En kryptoadress är ett konto som alla andra
02On/off-ramp: fiat och digitala tillgångar växlas i kanten
03Avveckling on-chain hela vägen till utbetalning till IBAN
04En avstämd historik över båda leden

Byggytan

API:er, webhooks och en sandbox att bygga mot.

Allt som apparna gör sker via ett dokumenterat API – skapa ett konto, öppna en betalning, utfärda ett kort, starta en ramp. Exempel på anrop är POST /v1/wallets eller POST /v1/payments; formatet är REST med en idempotensnyckel på varje skrivning. Tillståndsändringar levereras som webhooks, så att dina system reagerar på händelser i stället för att polla efter dem. Utvecklingen sker mot en sandbox-tenant – en isolerad kopia av plattformen med testrails, där du kan köra hela flödet från skapande till avstämning utan att flytta riktiga pengar. Vad varje produkt ger dig tillgång till, och på vilken nivå, styrs av dess åtkomstband. Sidorna för respektive produkt beskriver vad ett givet band omfattar.

01Dokumenterat REST-API, idempotenta skrivningar
02Webhooks för varje tillståndsändring – händelsestyrt, inte pollat
03Sandbox-tenant med testrails, isolerad från produktion
04Omfattning och gränser styrs av åtkomstband per produkt

Den ärliga gränsen

Protocore bygger mjukvaran. Tillståndet håller den reglerade gränsen.

En betalprodukt består av två saker som är hopfogade: det reglerade tillståndet att hålla och flytta pengar, och mjukvaran som instruerar, registrerar och stämmer av det. Protocore bygger mjukvaran. Den reglerade verksamheten – att hålla kundmedel, utfärda konton och flytta pengar via ett kortnätverk – ligger hos operatörens eget tillstånd eller hos en licensierad partner: en bank, ett e-pengainstitut (EMI) eller ett betalningsinstitut. Plattformen är byggd för att passa de reglerade rails du själv tar med dig, och för att hålla kortdata på railen så att den aldrig når dina servrar. Den ersätter inte det tillståndet, och det gör ingen mjukvara. Var den reglerade gränsen går avgör du tillsammans med din partner, och arkitekturen är utformad för att ligga rent på båda sidor om den.