/// Arhitectura platformei

Un singur nucleu, mai multe suprafețe — cum funcționează de fapt platforma.

O parcurgere a platformei, de la registru în sus: conturile, KYC, cardurile și cripto care împart un singur nucleu în partidă dublă, cum se mișcă o plată de la creare la reconciliere și unde stau, fiecare, stratul de aplicații, consola de operare și linia reglementată.

Contactează-ne Vezi produsele

/// Nucleul

Un singur registru sub tot.

În centrul platformei se află un singur registru de conturi. Fiecare cont — un portofel de client, un sold de comerciant, un cont de comisioane, un cont de decontare — este un nod în acel registru, iar fiecare mișcare de valoare este o înregistrare în partidă dublă: un cont debitat, altul creditat, cele două părți mereu egale. Registrul crește doar prin adăugare. Înregistrările nu se editează și nu se șterg niciodată; o corecție este o nouă înregistrare, opusă, așa că istoricul complet al modului în care un sold a ajuns la valoarea sa curentă poate fi mereu reconstituit. Conturile, starea KYC, cardurile emise și adresele cripto se atașează toate aceluiași model de cont — de aceea o autorizare de card, un transfer bancar și un depozit on-chain pot fi înregistrate pe același sold, fără un strat de reconciliere care să coasă la un loc sisteme separate.

[ 01 ]Partidă dublă: fiecare înregistrare se echilibrează, debitele egalează creditele
[ 02 ]Doar prin adăugare: corecțiile sunt înregistrări noi, niciodată editări
[ 03 ]Un singur model de cont pentru fiat, carduri și cripto
[ 04 ]Starea KYC călătorește cu contul, nu într-un tabel separat

/// O plată, de la cap la coadă

O plată, de la creare la reconciliere.

O plată nu este un singur apel, ci un ciclu de viață scurt, iar fiecare etapă este o stare pe care o pot vedea și registrul, și sistemele tale. Fiecare schimbare de stare emite un webhook, iar fiecare scriere este idempotentă — aceeași cheie repetă același rezultat, așa că o cerere reîncercată nu taxează niciodată de două ori.

[ 01 ]
Creare
Se deschide o intenție: sumă, monedă, conturile implicate. Nimic nu s-a mișcat încă — registrul consemnează o înregistrare în așteptare.
[ 02 ]
Autorizare
Canalul verifică fondurile și riscul și pune o rezervare. Pentru un card, aceasta este autorizarea; pentru un transfer, debitul este rezervat.
[ 03 ]
Captare
Suma rezervată este confirmată. Registrul înregistrează partida dublă care mișcă efectiv valoarea între cele două conturi.
[ 04 ]
Decontare
Fondurile se compensează pe canalul de bază — schemă de card, bancă sau blockchain — iar conturile de decontare se reconciliază cu bani reali.
[ 05 ]
Reconciliere
Platforma potrivește propriile înregistrări cu raportul de decontare al canalului; ce nu se aliniază este semnalat, nu ascuns.

Webhook-urile și idempotența stau la fiecare margine a acestui flux. Sistemele tale află că o plată s-a mișcat primind un eveniment, nu interogând, iar orice cerere pe care o reîncerci după un timeout se rezolvă — prin cheia de idempotență — la același rezultat, așa că o repetare nu taxează niciodată de două ori. Serviciul care rulează autorizarea și captarea este gateway-ul de plată.

/// Stratul de aplicații

Aplicații whitelabel deasupra, o singură platformă dedesubt.

Nucleul expune capabilități; stratul de aplicații le transformă în produse. Fiecare aplicație către client — web și mobil — este un client whitelabel care redă aceleași conturi, plăți și carduri sub propriul brand. Tematizarea este condusă de token-uri: culorile, tipografia, raza și spațierea vin dintr-un sistem de token-uri de design (PDS), așa că un operator restilizează întreaga suprafață schimbând token-uri, nu făcând un fork al aplicației. Aceeași platformă poate fi îndreptată în direcții foarte diferite — o neobancă de consum, o aplicație de acceptare pentru comercianți, un program de emitere de carduri, un on/off-ramp cripto sau un instrument intern de operare — fără a deveni cinci produse separate. Este o singură platformă purtând straturi diferite, fiecare configurat, nu reconstruit.

[ 01 ]Clienți whitelabel web și mobil pe aceleași API-uri
[ 02 ]Tematizare pe token-uri (PDS): restilizezi prin configurare, nu prin fork
[ 03 ]Cinci direcții-exemplu — neobancă, acceptare, emitere, ramp, operare
[ 04 ]Suprafețele noi sunt configurate, nu reconstruite

/// Operare

O operezi din consolă, cu un motiv consemnat.

În spatele fiecărei aplicații stă o consolă de operator. Este locul unde un agent de suport caută un cont, un analist de risc blochează un card sau un responsabil de operațiuni stornează o înregistrare. Accesul de citire este larg; acțiunile privilegiate nu sunt. Orice mișcă bani, schimbă limite sau atinge fondurile unui client cere un motiv enunțat înainte să ruleze și scrie o înregistrare de audit imutabilă — cine a acționat, asupra a ce, când și de ce. Accesul urmează principiul privilegiului minim, așa că fiecare operator vede și face doar ce îi permite rolul. Acesta este modelul din Protocore Center, consola de operator, iar aceeași disciplină este integrată în fiecare sistem al platformei: acțiunile sensibile sunt deliberate, atribuibile și verificabile ulterior.

[ 01 ]Citire largă, scriere restricționată — acțiunile privilegiate sunt excepția
[ 02 ]Motiv obligatoriu înainte de orice acțiune care atinge fonduri
[ 03 ]Traseu de audit imutabil: cine, ce, când, de ce
[ 04 ]Privilegiu minim pentru fiecare rol de operator

/// Puntea cripto

Cripto și fiat pe același registru.

Cripto nu este un siloz separat pe platformă; o adresă cripto este pur și simplu încă un cont pe același registru. Un on/off-ramp convertește între fiat și active digitale la margine — un client alimentează un sold cu un card sau un transfer și primește cripto, sau vinde cripto și retrage într-un cont bancar. Valoarea on-chain poate deconta până la un canal bancar: o plată on-chain de intrare este creditată în cont, convertită și plătită către un IBAN, așa că beneficiarul vede bani obișnuiți într-un cont bancar obișnuit. Pentru că ambele picioare se înregistrează pe un singur registru în partidă dublă, o mișcare care începe on-chain și se termină într-un transfer bancar este un singur istoric reconciliat, nu două sisteme reconciliate de mână.

[ 01 ]O adresă cripto este un cont ca oricare altul
[ 02 ]On/off-ramp: fiat și active digitale convertite la margine
[ 03 ]Decontare on-chain până la o plată către IBAN
[ 04 ]Un singur istoric reconciliat pe ambele picioare

/// Suprafața de construire

API-uri, webhook-uri și un sandbox pe care construiești.

Tot ce fac aplicațiile, fac printr-un API documentat — creezi un cont, deschizi o plată, emiți un card, inițiezi un ramp. Apelurile ilustrative arată ca POST /v1/wallets sau POST /v1/payments; forma este REST, cu o cheie de idempotență la fiecare scriere. Schimbările de stare sunt livrate ca webhook-uri, așa că sistemele tale reacționează la evenimente în loc să interogheze după ele. Dezvoltarea se face pe un tenant sandbox — o copie izolată a platformei, cu canale de test, unde poți rula întregul flux de la creare la reconciliere fără să miști bani reali. Ce îți expune fiecare produs, și la ce nivel, este stabilit de nivelul lui de acces; paginile fiecărui produs detaliază ce include un anumit nivel.

[ 01 ]API REST documentat, scrieri idempotente
[ 02 ]Webhook-uri pentru fiecare schimbare de stare — pe evenimente, nu prin interogare
[ 03 ]Tenant sandbox cu canale de test, izolat de producție
[ 04 ]Domeniu și limite stabilite de nivelurile de acces ale fiecărui produs

/// Limita onestă

Protocore construiește software-ul. Licența ține linia reglementată.

Un produs de plăți sunt două lucruri contopite: permisiunea reglementată de a deține și mișca bani și software-ul care instruiește, înregistrează și reconciliază. Protocore construiește software-ul. Activitatea reglementată — deținerea fondurilor clienților, emiterea de conturi, mișcarea banilor printr-o schemă — stă la licența proprie a operatorului sau la un partener licențiat: o bancă, un EMI sau o instituție de plată. Platforma este construită să se potrivească oricăror canale reglementate pe care le aduci și să țină datele de card pe canal, ca să nu atingă niciodată serverele tale; nu este, și niciun software nu este, un substitut pentru acea permisiune. Unde cade linia reglementată este o decizie pe care o iei cu partenerul tău, iar arhitectura este proiectată să stea curat de o parte sau de alta a ei.