Platformarchitectuur

Eén core, vele kanalen — zo werkt het platform echt.

Een rondleiding door het platform, vanaf de ledger: de accounts, KYC, kaarten en crypto die één double-entry-core delen, hoe één betaling van aanmaken tot reconciliatie verloopt, en waar de app-laag, de operatorconsole en de gereguleerde grens zich bevinden.

Neem contact op Bekijk de producten

De core

Eén ledger onder alles.

In het hart van het platform staat één account-ledger. Elk account — een klantwallet, een merchantsaldo, een feeaccount, een settlementaccount — is een knooppunt in die ledger, en elke waardebeweging is een boeking volgens double-entry: één account wordt gedebiteerd, een ander gecrediteerd, en beide kanten zijn altijd gelijk. De ledger is append-only. Boekingen worden nooit aangepast of verwijderd; een correctie is een nieuwe, tegengestelde boeking, waardoor je altijd kunt reconstrueren hoe een saldo tot zijn huidige waarde is gekomen. Accounts, KYC-status, uitgegeven kaarten en crypto-adressen hangen allemaal aan hetzelfde accountmodel. Daarom kunnen een kaartautorisatie, een bankoverboeking en een on-chain storting op één saldo landen, zonder reconciliatielaag die losse systemen aan elkaar knoopt.

01Double-entry: elke boeking sluit, debet is gelijk aan credit
02Append-only: correcties zijn nieuwe boekingen, nooit wijzigingen
03Eén accountmodel voor fiat, kaarten en crypto
04KYC-status reist mee met het account, geen aparte tabel

Een betaling, van begin tot eind

Eén betaling, van aanmaken tot reconciliatie.

Een betaling is niet één aanroep maar een korte levenscyclus, en elke fase is een status die zowel de ledger als je systemen zien. Elke statuswijziging stuurt een webhook en elke schrijfactie is idempotent — dezelfde key geeft hetzelfde resultaat, dus een herhaald verzoek schrijft nooit dubbel af.

01
Aanmaken
Er wordt een intent geopend: bedrag, valuta, de betrokken accounts. Er is nog niets verplaatst — de ledger legt een pending boeking vast.
02
Autoriseren
De rail controleert saldo en risico en plaatst een hold. Bij een kaart is dit de autorisatie; bij een overboeking wordt de debitering gereserveerd.
03
Vastleggen
Het gereserveerde bedrag wordt definitief gemaakt. De ledger boekt de double-entry die de waarde daadwerkelijk tussen de twee accounts verplaatst.
04
Afwikkelen
Het geld wordt verrekend over de onderliggende rail — kaartscheme, bank of chain — en de settlementaccounts sluiten aan op echt geld.
05
Reconciliëren
Het platform vergelijkt zijn eigen boekingen met het settlementrapport van de rail; wat niet klopt, wordt gemarkeerd, niet verborgen.

Webhooks en idempotentie zitten in elke schakel van deze flow. Je systemen horen dat een betaling is verwerkt doordat ze een event ontvangen, niet door te pollen, en elk verzoek dat je na een timeout opnieuw verstuurt, komt — via de idempotency key — uit op hetzelfde resultaat, zodat een herhaling nooit dubbel afschrijft. De service die authorize en capture uitvoert, is de payment gateway.

De app-laag

Whitelabel-apps erbovenop, één platform eronder.

De core biedt functionaliteit; de app-laag maakt er producten van. Elke app voor eindklanten — web en mobiel — is een whitelabel-client die dezelfde accounts, betalingen en kaarten toont in een eigen huisstijl. Theming is token-gedreven: kleuren, typografie, radius en spacing komen uit een design-tokensysteem (PDS), zodat een operator het hele oppervlak herstylet door tokens aan te passen, niet door de app te forken. Hetzelfde platform kan een heel andere kant op worden gestuurd — een consumenten-neobank, een acquiring-app voor merchants, een kaartuitgifteprogramma, een crypto on/off-ramp of een interne operationele tool — zonder dat het vijf losse producten wordt. Het is één platform in verschillende jasjes, elk geconfigureerd in plaats van opnieuw gebouwd.

01Whitelabel web- en mobiele clients op gedeelde API's
02Token-gedreven theming (PDS): restylen via config, niet via een fork
03Vijf voorbeeldrichtingen — neobank, acquiring, issuing, ramp, ops
04Nieuwe oppervlakken configureer je, je bouwt ze niet opnieuw

Operations

Beheer alles vanuit de console, met een reden op de plank.

Achter elke app zit een operatorconsole. Daar zoekt een supportmedewerker een account op, bevriest een risicoanalist een kaart of draait een operationeel lead een boeking terug. Leestoegang is breed; geprivilegieerde acties zijn dat niet. Alles wat geld verplaatst, limieten wijzigt of de middelen van een klant raakt, vereist vooraf een opgegeven reden en schrijft een onwijzigbare auditregel weg — wie, wat, wanneer en waarom. Toegang volgt het principe van least privilege: elke operator ziet en doet alleen wat zijn rol toestaat. Zo werkt het in Protocore Center, de operatorconsole, en dezelfde houding zit ingebouwd in elk systeem op het platform: gevoelige acties zijn bewust, herleidbaar en achteraf te controleren.

01Ruime leestoegang, beperkte schrijftoegang — geprivilegieerde acties zijn de uitzondering
02Reden verplicht vóór elke actie die geld raakt
03Onwijzigbare audittrail: wie, wat, wanneer, waarom
04Least privilege per operatorrol

De crypto-brug

Crypto en fiat op dezelfde ledger.

Crypto is geen aparte silo op het platform; een crypto-adres is gewoon een account op dezelfde ledger. Een on/off-ramp wisselt aan de rand tussen fiat en digitale assets: een klant stort geld op een saldo met een kaart of overboeking en ontvangt crypto, of verkoopt crypto en neemt op naar een bankrekening. On-chain waarde kan doorsettelen naar een bankrail: een inkomende on-chain betaling wordt op het account bijgeschreven, omgezet en uitbetaald naar een IBAN, zodat de ontvanger gewoon geld op een gewone bankrekening ziet. Omdat beide kanten op één double-entry-ledger worden geboekt, is een beweging die on-chain begint en als banktransfer eindigt één gereconcilieerde historie, geen twee systemen die je met de hand afstemt.

01Een crypto-adres is een account als elk ander
02On/off-ramp: fiat en digitale assets omgezet aan de rand
03On-chain settlement tot en met een uitbetaling naar een IBAN
04Eén gereconcilieerde historie over beide kanten

Het bouwoppervlak

API's, webhooks en een sandbox om tegenaan te bouwen.

Alles wat de apps doen, doen ze via een gedocumenteerde API — een account aanmaken, een betaling openen, een kaart uitgeven, een ramp starten. Voorbeeldaanroepen zien eruit als POST /v1/wallets of POST /v1/payments; de vorm is REST, met een idempotency key bij elke schrijfactie. Statuswijzigingen komen binnen als webhooks, zodat je systemen op events reageren in plaats van te pollen. Ontwikkelen doe je op een sandbox-tenant — een geïsoleerde kopie van het platform met testrails, waarop je de volledige flow van aanmaken tot reconciliatie kunt draaien zonder echt geld te verplaatsen. Wat elk product voor jou beschikbaar maakt, en op welk niveau, bepaalt de toegangsband; de productpagina's beschrijven wat een bepaalde band omvat.

01Gedocumenteerde REST API, idempotente schrijfacties
02Webhooks bij elke statuswijziging — event-gedreven, niet gepolld
03Sandbox-tenant met testrails, geïsoleerd van productie
04Scope en limieten bepaald door toegangsbanden per product

De eerlijke grens

Protocore bouwt de software. De licentie draagt de gereguleerde grens.

Een betaalproduct bestaat uit twee dingen die samenkomen: de gereguleerde toestemming om geld te houden en te verplaatsen, en de software die dat aanstuurt, vastlegt en reconcilieert. Protocore bouwt de software. De gereguleerde activiteit — klantengelden houden, accounts uitgeven, geld verplaatsen via een scheme — ligt bij de eigen licentie van de operator of bij een gelicentieerde partner: een bank, een EMI of een betaalinstelling. Het platform is gebouwd om te passen op de gereguleerde rails die je meebrengt en om kaartdata op de rail te houden, zodat die nooit je servers raakt; het is geen vervanging voor die toestemming, en dat is software nooit. Waar de gereguleerde grens ligt, bepaal je samen met je partner, en de architectuur is ontworpen om aan beide kanten ervan netjes te passen.