Architettura della piattaforma
Un unico core, molte superfici: come funziona davvero la piattaforma.
Un percorso nella piattaforma a partire dal ledger: conti, KYC, carte e crypto che condividono un unico core a partita doppia, il cammino di un singolo pagamento dalla creazione alla riconciliazione e la posizione di app, console operatore e perimetro regolamentato.
Il core
Un unico ledger sotto ogni cosa.
Al centro della piattaforma c'è un unico ledger dei conti. Ogni conto — wallet di un cliente, saldo di un merchant, conto commissioni, conto di settlement — è un nodo di quel ledger, e ogni movimento di valore è una registrazione a partita doppia: un conto addebitato, un altro accreditato, con i due lati sempre uguali. Il ledger è append-only. Le scritture non vengono mai modificate né cancellate; una correzione è una nuova scrittura di segno opposto, così la storia completa di come un saldo ha raggiunto il suo valore attuale è sempre ricostruibile. Conti, stato KYC, carte emesse e indirizzi crypto si collegano tutti allo stesso modello di conto: per questo un'autorizzazione carta, un bonifico e un deposito on-chain possono registrarsi su un unico saldo, senza un livello di riconciliazione che cuce insieme sistemi separati.
- 01Partita doppia: ogni registrazione quadra, gli addebiti eguagliano gli accrediti
- 02Append-only: le correzioni sono nuove scritture, mai modifiche
- 03Un solo modello di conto per fiat, carte e crypto
- 04Lo stato KYC viaggia con il conto, non in una tabella a parte
Un pagamento, da capo a fondo
Un pagamento, dalla creazione alla riconciliazione.
Un pagamento non è una singola chiamata ma un breve ciclo di vita, e ogni fase è uno stato che il ledger e i tuoi sistemi vedono entrambi. Ogni cambio di stato emette un webhook e ogni scrittura è idempotente: la stessa chiave riproduce lo stesso risultato, quindi una richiesta ripetuta non addebita mai due volte.
- 01
Creazione
Viene aperto un intent: importo, valuta, conti coinvolti. Nulla si è ancora mosso: il ledger registra una scrittura in sospeso.
- 02
Autorizzazione
Il circuito verifica fondi e rischio e pone un blocco. Per una carta è l'autorizzazione; per un bonifico, l'addebito viene riservato.
- 03
Capture
L'importo bloccato viene confermato. Il ledger registra la partita doppia che sposta davvero il valore tra i due conti.
- 04
Settlement
I fondi vengono regolati sul circuito sottostante — circuito carte, banca o chain — e i conti di settlement si riconciliano con il denaro reale.
- 05
Riconciliazione
La piattaforma confronta le proprie registrazioni con il report di settlement del circuito; ciò che non quadra viene segnalato, non nascosto.
Webhook e idempotenza sono presenti a ogni estremità di questo flusso. I tuoi sistemi sanno che un pagamento si è mosso ricevendo un evento, non facendo polling, e qualsiasi richiesta che ripeti dopo un timeout si risolve, tramite la sua chiave di idempotenza, nello stesso risultato, così un nuovo tentativo non addebita mai due volte. Il servizio che esegue authorize e capture è il payment gateway.
Il livello app
App whitelabel in superficie, un'unica piattaforma sotto.
Il core espone le funzionalità; il livello app le trasforma in prodotti. Ogni app rivolta al cliente — web e mobile — è un client whitelabel che mostra gli stessi conti, pagamenti e carte con il proprio brand. Il theming è guidato da token: colori, tipografia, raggi e spaziature provengono da un sistema di design token (PDS), quindi un operatore ridisegna l'intera superficie cambiando i token, senza fare un fork dell'app. La stessa piattaforma può essere orientata in direzioni molto diverse — una neobank per consumatori, un'app di acquiring per merchant, un programma di emissione carte, un on/off-ramp crypto o uno strumento operativo interno — senza diventare cinque prodotti separati. È una sola piattaforma con pelli diverse, ciascuna configurata anziché ricostruita.
- 01Client whitelabel web e mobile su API condivise
- 02Theming a token (PDS): si ridisegna con la configurazione, non con un fork
- 03Cinque direzioni di esempio — neobank, acquiring, issuing, ramp, ops
- 04Le nuove superfici si configurano, non si ricostruiscono
Operatività
Gestisci tutto dalla console, con una motivazione a verbale.
Dietro ogni app c'è una console operatore. È qui che un addetto al supporto cerca un conto, un analista del rischio blocca una carta o un responsabile operativo storna una registrazione. L'accesso in lettura è ampio; le azioni privilegiate no. Qualsiasi operazione che muove denaro, modifica i limiti o tocca i fondi di un cliente richiede una motivazione dichiarata prima dell'esecuzione e genera una voce di audit immutabile: chi ha agito, su cosa, quando e perché. L'accesso segue il principio del minimo privilegio, quindi ogni operatore vede e fa solo ciò che il suo ruolo consente. È il modello di Protocore Center, la console operatore, e la stessa impostazione è integrata in ogni sistema della piattaforma: le azioni sensibili sono deliberate, attribuibili e verificabili a posteriori.
- 01Lettura ampia, scrittura controllata: le azioni privilegiate sono l'eccezione
- 02Motivazione obbligatoria prima di ogni azione che tocca i fondi
- 03Audit trail immutabile: chi, cosa, quando, perché
- 04Minimo privilegio per ogni ruolo operatore
Il ponte crypto
Crypto e fiat sullo stesso ledger.
Sulla piattaforma la crypto non è un silo a parte: un indirizzo crypto è semplicemente un altro conto sullo stesso ledger. Un on/off-ramp converte tra fiat e asset digitali ai margini del sistema — il cliente alimenta un saldo con carta o bonifico e riceve crypto, oppure vende crypto e preleva su un conto bancario. Il valore on-chain può regolarsi fino a un circuito bancario: un pagamento on-chain in ingresso viene accreditato sul conto, convertito e pagato su un IBAN, così il destinatario vede denaro ordinario su un normale conto bancario. Poiché entrambe le gambe si registrano su un unico ledger a partita doppia, un movimento che nasce on-chain e finisce in un bonifico è un'unica storia riconciliata, non due sistemi riconciliati a mano.
- 01Un indirizzo crypto è un conto come gli altri
- 02On/off-ramp: fiat e asset digitali convertiti ai margini del sistema
- 03Settlement on-chain fino al pagamento su IBAN
- 04Un'unica storia riconciliata su entrambe le gambe
La superficie di sviluppo
API, webhook e una sandbox su cui sviluppare.
Tutto ciò che fanno le app avviene tramite un'API documentata: creare un conto, aprire un pagamento, emettere una carta, avviare un ramp. Chiamate di esempio sono POST /v1/wallets o POST /v1/payments; lo stile è REST, con una idempotency key su ogni scrittura. I cambi di stato arrivano come webhook, così i tuoi sistemi reagiscono agli eventi invece di fare polling. Lo sviluppo avviene su un tenant sandbox — una copia isolata della piattaforma con circuiti di test — dove puoi eseguire l'intero flusso, dalla creazione alla riconciliazione, senza muovere denaro reale. Ciò che ogni prodotto ti espone, e a quale livello, è definito dalla sua fascia di accesso; le pagine dei singoli prodotti indicano cosa include ciascuna fascia.
- 01API REST documentata, scritture idempotenti
- 02Webhook per ogni cambio di stato: a eventi, senza polling
- 03Tenant sandbox con circuiti di test, isolato dalla produzione
- 04Ambito e limiti definiti dalle fasce di accesso di ogni prodotto
Il confine, senza giri di parole
Protocore costruisce il software. La licenza presidia il perimetro regolamentato.
Un prodotto di pagamento è fatto di due cose inscindibili: l'autorizzazione regolamentata a detenere e muovere denaro, e il software che dispone, registra e riconcilia. Protocore costruisce il software. L'attività regolamentata — detenere fondi dei clienti, emettere conti, muovere denaro su un circuito — resta in capo alla licenza dell'operatore o di un partner autorizzato: una banca, un EMI o un istituto di pagamento. La piattaforma è progettata per adattarsi ai circuiti regolamentati che porti e per tenere i dati delle carte sul circuito, così da non toccare mai i tuoi server; non sostituisce quell'autorizzazione, e nessun software può farlo. Dove cade il confine regolamentato lo decidi insieme al tuo partner, e l'architettura è pensata per stare con pulizia da entrambi i lati.
- 01Un livello software, non una licenza
- 02L'attività regolamentata resta all'operatore o a un partner autorizzato
- 03I dati delle carte restano sul circuito, fuori dai tuoi server
- 04Progettata per adattarsi ai circuiti regolamentati che porti
Dove si collega
Segui un filo più a fondo.
Ogni concetto di questa pagina ha una sede più completa: le definizioni, i prodotti e le fasce di accesso che indicano cosa include ciascun livello.
Idempotenza, webhook, settlement, IBAN virtuale, SCA: definizioni.
Il servizio che esegue authorize e capture.
Azioni privilegiate con motivazione obbligatoria e tracciate in audit.
Valore on-chain regolato fino a un IBAN.
Fiat e asset digitali convertiti ai margini del sistema.
Cosa include ogni prodotto, livello per livello.
Vuoi l'architettura per il tuo progetto?
Raccontaci cosa stai costruendo. Torneremo da te con un disegno del sistema e con la posizione del perimetro regolamentato, non con una presentazione commerciale.