Platformarchitektúra
Egy mag, sok felület – így működik valójában a platform.
Végigvezetjük a platformon a főkönyvtől felfelé: a számlákon, a KYC-n, a kártyákon és a kriptón, amelyek egyetlen, kettős könyvvitelű magon osztoznak; azon, hogyan jut el egy fizetés a létrehozástól az egyeztetésig; és hogy hol helyezkedik el az alkalmazásréteg, az operátori konzol és a szabályozott határvonal.
A mag
Egyetlen főkönyv mindennek az alapja.
A platform közepén egyetlen számlafőkönyv áll. Minden számla – ügyfélwallet, kereskedői egyenleg, díjszámla, elszámolási számla – ennek a főkönyvnek egy csomópontja, és az érték minden mozgása kettős könyvvitelű könyvelés: egy számla megterhelésre kerül, egy másik jóváíródik, a két oldal pedig mindig egyenlő. A főkönyv csak bővíthető (append-only). A tételeket soha nem szerkesztjük és nem töröljük; a helyesbítés egy új, ellentétes tétel, így az egyenleg kialakulásának teljes története mindig visszakövethető. A számlák, a KYC-állapot, a kibocsátott kártyák és a kriptocímek mind ugyanahhoz a számlamodellhez kapcsolódnak, ezért egy kártyás engedélyezés, egy banki átutalás és egy on-chain befizetés egyetlen egyenlegre könyvelhető anélkül, hogy különálló rendszereket egyeztető réteg ragasztaná össze őket.
- 01Kettős könyvvitel: minden könyvelés egyensúlyban van, a tartozik és a követel egyenlő
- 02Append-only: a helyesbítések új tételek, soha nem módosítások
- 03Egyetlen számlamodell fiathoz, kártyákhoz és kriptóhoz
- 04A KYC-állapot a számlával együtt mozog, nem egy mellékes táblában él
Egy fizetés az elejétől a végéig
Egy fizetés a létrehozástól az egyeztetésig.
A fizetés nem egyetlen hívás, hanem rövid életciklus, és minden szakasz egy olyan állapot, amelyet a főkönyv és a te rendszereid is látnak. Minden állapotváltozás webhookot küld, és minden írás idempotens – ugyanaz a kulcs ugyanarra az eredményre játszódik vissza, így egy újrapróbált kérés sosem terhel kétszer.
- 01
Létrehozás
Megnyílik egy intent: összeg, deviza, az érintett számlák. Még semmi nem mozdult – a főkönyv függőben lévő tételt rögzít.
- 02
Engedélyezés
A rail ellenőrzi a fedezetet és a kockázatot, majd zárolást helyez el. Kártyánál ez az authorization; átutalásnál a megterhelés foglalása.
- 03
Capture
A zárolt összeg véglegesítésre kerül. A főkönyv elkönyveli azt a kettős könyvvitelű tételt, amely ténylegesen mozgatja az értéket a két számla között.
- 04
Elszámolás
A pénz átfut az alapul szolgáló railen – kártyatársaságon, bankon vagy láncon –, és az elszámolási számlák valódi pénzzel egyeztetődnek.
- 05
Egyeztetés
A platform összeveti a saját könyvelési tételeit a rail elszámolási jelentésével; ami nem egyezik, azt jelzi, nem rejti el.
A webhookok és az idempotencia a folyamat minden szélén jelen vannak. A rendszereid úgy értesülnek egy fizetés mozgásáról, hogy eseményt kapnak, nem lekérdezéssel, és minden időtúllépés után újraküldött kérés – az idempotencia-kulcsa révén – ugyanarra az eredményre jut, így az ismétlés sosem terhel kétszer. Az engedélyezést és a capture-t futtató szolgáltatás a payment gateway.
Az alkalmazásréteg
Whitelabel appok felül, egyetlen platform alul.
A mag képességeket tesz elérhetővé; az alkalmazásréteg termékeket formál belőlük. Minden ügyféloldali app – webes és mobil – egy whitelabel kliens, amely ugyanazokat a számlákat, fizetéseket és kártyákat jeleníti meg a saját arculatában. A témázás tokenvezérelt: a színek, a tipográfia, a lekerekítés és a térközök egy design token rendszerből (PDS) érkeznek, így az operátor a teljes felületet a tokenek módosításával formálja át, nem az app forkolásával. Ugyanazt a platformot nagyon különböző irányokba lehet terelni – fogyasztói neobank, kereskedői acquiring app, kártyakibocsátási program, kripto on/off-ramp vagy belső működési eszköz –, anélkül hogy öt külön termékké válna. Egyetlen platform, különböző megjelenésekkel, amelyeket konfigurálunk, nem újraépítünk.
- 01Whitelabel web- és mobilkliensek közös API-kon
- 02Tokenvezérelt témázás (PDS): konfigurációval alakítható át, forkolás nélkül
- 03Öt példa irány – neobank, acquiring, issuing, ramp, ops
- 04Az új felületeket konfiguráljuk, nem építjük újra
Működés
Vezéreld a konzolról, indoklással a naplóban.
Minden app mögött ott áll egy operátori konzol. Itt keres rá egy ügyfélszolgálati munkatárs egy számlára, itt fagyaszt le egy kockázatelemző egy kártyát, és itt von vissza egy könyvelést egy műveleti vezető. Az olvasási jogosultság széles; a kiemelt műveletek nem azok. Minden, ami pénzt mozgat, limitet módosít vagy ügyfélpénzhez nyúl, futtatás előtt megadott indoklást igényel, és megváltoztathatatlan auditbejegyzést ír: ki, mit, mikor és miért tett. A hozzáférés a legkisebb jogosultság elvét követi, így minden operátor csak azt látja és teheti, amit a szerepköre megenged. Ez a Protocore Center, az operátori konzol modellje, és ugyanez a szemlélet minden platformrendszerbe be van építve: az érzékeny műveletek tudatosak, névhez köthetők és utólag is ellenőrizhetők.
- 01Széles olvasás, szabályozott írás – a kiemelt műveletek a kivételek
- 02Indoklás kötelező minden pénzmozgatással járó művelet előtt
- 03Megváltoztathatatlan audit trail: ki, mit, mikor, miért
- 04Legkisebb jogosultság operátori szerepkörönként
A kriptohíd
Kripto és fiat ugyanazon a főkönyvön.
A kripto nem különálló silo a platformon; a kriptocím egyszerűen egy újabb számla ugyanazon a főkönyvön. Az on/off-ramp a határon váltja át a fiatot digitális eszközre és vissza – az ügyfél kártyával vagy átutalással tölti fel az egyenlegét és kriptót kap, vagy eladja a kriptót, és bankszámlára utalja ki. Az on-chain érték egészen a banki rail-ig elszámolható: a beérkező on-chain fizetés jóváíródik a számlán, átváltásra kerül, majd IBAN-ra történik a kifizetés, így a kedvezményezett hétköznapi pénzt lát egy hétköznapi bankszámlán. Mivel mindkét szál egyetlen kettős könyvvitelű főkönyvre könyvelődik, az on-chain induló és banki átutalással záruló mozgás egyetlen egyeztetett történet, nem két, kézzel egyeztetett rendszer.
- 01A kriptocím is ugyanolyan számla, mint bármelyik másik
- 02On/off-ramp: fiat és digitális eszközök átváltása a határon
- 03On-chain elszámolás egészen az IBAN-kifizetésig
- 04Egyetlen egyeztetett történet mindkét szálon
A fejlesztői felület
API-k, webhookok és sandbox, amelyen építkezhetsz.
Amit az appok csinálnak, azt dokumentált API-n keresztül teszik – számlát hoznak létre, fizetést nyitnak, kártyát bocsátanak ki, rampet indítanak. A szemléltető hívások így néznek ki: POST /v1/wallets vagy POST /v1/payments; a felépítés REST, minden írási műveleten idempotencia-kulccsal. Az állapotváltozásokat webhookként kézbesítjük, így a rendszereid eseményekre reagálnak, nem lekérdezgetik azokat. A fejlesztés sandbox tenanten zajlik – a platform elkülönített másolatán, teszt railekkel –, ahol a teljes létrehozástól az egyeztetésig tartó folyamatot valódi pénzmozgás nélkül lefuttathatod. Hogy az egyes termékek mit tesznek elérhetővé számodra és melyik szinten, azt a hozzáférési sáv határozza meg; a termékoldalak részletezik, mit tartalmaz egy adott sáv.
- 01Dokumentált REST API, idempotens írások
- 02Webhook minden állapotváltozásról – eseményvezérelt, nem lekérdezéses
- 03Sandbox tenant teszt railekkel, a productiontől elszigetelve
- 04A hatókört és a limiteket termékenkénti hozzáférési sávok szabják meg
Az őszinte határvonal
A Protocore a szoftvert építi. A szabályozott határvonalat az engedély tartja.
A fizetési termék két dolog egybeötvözése: a pénz tartására és mozgatására vonatkozó szabályozott engedély, valamint az a szoftver, amely utasít, rögzít és egyeztet. A Protocore a szoftvert építi. A szabályozott tevékenység – ügyfélpénzek tartása, számlák kibocsátása, pénzmozgatás egy kártyatársasági vagy más rendszeren – az operátor saját engedélyénél vagy egy engedéllyel rendelkező partnernél van: banknál, EMI-nél vagy fizetési intézménynél. A platform úgy készült, hogy illeszkedjen a hozott szabályozott railekhez, és a kártyaadatok a railen maradjanak, sosem érintve a te szervereidet; ez az engedélynek nem helyettesítője, és semmilyen szoftver nem az. Hogy hol húzódik a szabályozott határvonal, azt te döntöd el a partnereddel, az architektúra pedig úgy van kialakítva, hogy tisztán elférjen a vonal mindkét oldalán.
- 01Szoftverréteg, nem engedély
- 02A szabályozott tevékenység az operátornál vagy egy engedéllyel rendelkező partnernél van
- 03A kártyaadatok a railen maradnak, a szervereiden kívül
- 04Úgy építve, hogy illeszkedjen a hozott szabályozott railekhez
Itt kapcsolódik tovább
Kövess egy szálat tovább.
Az oldal minden fogalmának van egy részletesebb helye – a definíciók, a termékek és a hozzáférési sávok, amelyek leírják, mit tartalmaz egy szint.
Idempotencia, webhookok, elszámolás, virtuális IBAN, SCA – definíciók.
A szolgáltatás, amely az engedélyezést és a capture-t futtatja.
Indoklást igénylő, auditált kiemelt műveletek.
On-chain érték, amely egészen IBAN-ig elszámolódik.
Fiat és digitális eszközök átváltása a határon.
Mit tartalmaz az egyes termék, szintenként.
Szeretnéd az architektúrát a saját projektedhez?
Mesélj, mit építesz. Rendszertervvel jövünk vissza, és megmutatjuk, hol húzódik a szabályozott határvonal – nem pitch deckkel.