Arquitectura de la plataforma
Un sol nucli, moltes superfícies: com funciona realment la plataforma.
Un recorregut per la plataforma des del llibre major cap amunt: els comptes, el KYC, les targetes i les criptos que comparteixen un mateix nucli de partida doble, com viatja un pagament des de la creació fins a la conciliació, i on se situen la capa d'aplicacions, la consola d'operador i la frontera regulada.
El nucli
Un sol llibre major sota de tot.
Al centre de la plataforma hi ha un únic llibre major de comptes. Cada compte —la cartera d'un client, el saldo d'un comerç, un compte de comissions, un compte de liquidació— és un node d'aquest llibre, i cada moviment de valor és un assentament de partida doble: un compte es carrega, un altre s'abona, i les dues bandes sempre quadren. El llibre és només d'addició (append-only). Els apunts mai no s'editen ni s'esborren; una correcció és un apunt nou de signe contrari, de manera que sempre es pot reconstruir tot l'historial de com un saldo ha arribat al valor actual. Els comptes, l'estat del KYC, les targetes emeses i les adreces cripto s'associen al mateix model de compte, i per això una autorització de targeta, una transferència bancària i un dipòsit on-chain poden assentar-se en un mateix saldo sense cap capa de conciliació que cusi sistemes separats.
- 01Partida doble: cada assentament quadra, el dèbit és igual al crèdit
- 02Només d'addició: les correccions són apunts nous, mai edicions
- 03Un únic model de compte per a fiat, targetes i criptos
- 04L'estat del KYC viatja amb el compte, no en una taula auxiliar
Un pagament, de punta a punta
Un pagament, de la creació a la conciliació.
Un pagament no és una sola crida, sinó un cicle de vida curt, i cada etapa és un estat que el llibre major i els teus sistemes poden veure. Cada canvi d'estat emet un webhook i cada escriptura és idempotent: la mateixa clau reprodueix el mateix resultat, de manera que una petició reintentada mai no cobra dues vegades.
- 01
Crear
S'obre una intenció de pagament: import, divisa i comptes implicats. Encara no s'ha mogut res; el llibre major registra un apunt pendent.
- 02
Autoritzar
La via comprova fons i risc i fa una retenció. En una targeta és l'autorització; en una transferència, es reserva el dèbit.
- 03
Capturar
L'import retingut es confirma. El llibre major assenta la partida doble que realment mou el valor entre els dos comptes.
- 04
Liquidar
Els fons s'alliberen a través de la via subjacent —esquema de targetes, banc o cadena— i els comptes de liquidació es quadren amb diners reals.
- 05
Conciliar
La plataforma contrasta els seus assentaments amb l'informe de liquidació de la via; tot el que no quadra es marca, no s'amaga.
Els webhooks i la idempotència són presents a cada extrem d'aquest flux. Els teus sistemes saben que un pagament s'ha mogut en rebre un esdeveniment, no per polling, i qualsevol petició que reintentis després d'un timeout es resol —mitjançant la seva clau d'idempotència— al mateix resultat, de manera que una repetició mai no cobra dues vegades. El servei que executa l'autorització i la captura és el payment gateway.
La capa d'aplicacions
Apps whitelabel a dalt, una sola plataforma a sota.
El nucli exposa capacitats; la capa d'aplicacions les converteix en productes. Cada app de cara al client —web i mòbil— és un client whitelabel que mostra els mateixos comptes, pagaments i targetes amb la seva pròpia marca. L'aparença es basa en tokens: colors, tipografia, radis i espaiats provenen d'un sistema de design tokens (PDS), de manera que un operador restyla tota la superfície canviant tokens, sense fer un fork de l'app. La mateixa plataforma es pot orientar cap a direccions molt diferents —un neobanc de consum, una app d'adquirència per a comerços, un programa d'emissió de targetes, una on/off-ramp cripto o una eina interna d'operacions— sense convertir-se en cinc productes separats. És una sola plataforma amb pells diferents, cadascuna configurada i no reconstruïda.
- 01Clients whitelabel web i mòbil sobre API compartides
- 02Aparença basada en tokens (PDS): es restyla per configuració, no per fork
- 03Cinc direccions d'exemple: neobanc, adquirència, emissió, ramp i operacions
- 04Les noves superfícies es configuren, no es reconstrueixen
Operacions
Gestiona-ho des de la consola, amb un motiu registrat.
Darrere de cada app hi ha una consola d'operador. És on un agent de suport consulta un compte, un analista de risc bloqueja una targeta o un responsable d'operacions reverteix un assentament. L'accés de lectura és ampli; les accions privilegiades, no. Qualsevol cosa que mogui diners, canviï límits o toqui els fons d'un client exigeix indicar un motiu abans d'executar-se i deixa un apunt d'auditoria immutable: qui ha actuat, sobre què, quan i per què. L'accés segueix el principi de mínim privilegi, de manera que cada operador només veu i fa el que el seu rol permet. Aquest és el model de Protocore Center, la consola d'operador, i la mateixa filosofia és present en tots els sistemes de la plataforma: les accions sensibles són deliberades, atribuïbles i revisables a posteriori.
- 01Lectura àmplia, escriptura controlada: les accions privilegiades són l'excepció
- 02Motiu obligatori abans de qualsevol acció que toqui fons
- 03Traça d'auditoria immutable: qui, què, quan i per què
- 04Mínim privilegi per rol d'operador
El pont cripto
Cripto i fiat en un mateix llibre major.
A la plataforma, la cripto no és un compartiment estanc: una adreça cripto és simplement un compte més del mateix llibre major. Una on/off-ramp converteix entre fiat i actius digitals a la vora: el client carrega un saldo amb targeta o transferència i rep cripto, o ven cripto i ho retira a un compte bancari. El valor on-chain pot liquidar-se fins a una via bancària: un pagament on-chain entrant s'abona al compte, es converteix i s'envia a un IBAN, de manera que el destinatari veu diners normals en un compte bancari normal. Com que les dues potes s'assenten en un únic llibre major de partida doble, un moviment que comença on-chain i acaba en una transferència bancària és un sol historial conciliat, no dos sistemes conciliats a mà.
- 01Una adreça cripto és un compte com qualsevol altre
- 02On/off-ramp: fiat i actius digitals convertits a la vora
- 03Liquidació on-chain fins al pagament a un IBAN
- 04Un sol historial conciliat a les dues potes
La superfície de desenvolupament
API, webhooks i un sandbox per desenvolupar-hi.
Tot el que fan les apps ho fan mitjançant una API documentada: crear un compte, obrir un pagament, emetre una targeta, iniciar una ramp. Algunes crides d'exemple són POST /v1/wallets o POST /v1/payments; l'estil és REST, amb una clau d'idempotència a cada escriptura. Els canvis d'estat es lliuren com a webhooks, de manera que els teus sistemes reaccionen a esdeveniments en lloc de consultar-los contínuament (polling). El desenvolupament es fa sobre un tenant de sandbox: una còpia aïllada de la plataforma amb vies de prova, on pots executar tot el flux, de la creació a la conciliació, sense moure diners reals. El que cada producte t'exposa, i en quin nivell, ho determina la seva banda d'accés; les pàgines de cada producte detallen què inclou cada banda.
- 01API REST documentada, escriptures idempotents
- 02Webhooks per a cada canvi d'estat: basat en esdeveniments, sense polling
- 03Tenant de sandbox amb vies de prova, aïllat de producció
- 04Abast i límits definits per bandes d'accés per producte
La frontera, sense embuts
Protocore construeix el programari. La llicència cobreix la part regulada.
Un producte de pagaments són dues coses fusionades: el permís regulat per custodiar i moure diners, i el programari que ho ordena, ho registra i ho concilia. Protocore construeix el programari. L'activitat regulada —custodiar fons de clients, emetre comptes, moure diners en un esquema— correspon a la llicència pròpia de l'operador o a un soci amb llicència: un banc, una EMI o una entitat de pagament. La plataforma està pensada per encaixar amb les vies regulades que aportis i per mantenir les dades de targeta a la via, perquè mai no toquin els teus servidors; no substitueix aquest permís, ni cap programari ho fa. On cau la frontera regulada és una decisió que prens amb el teu soci, i l'arquitectura està dissenyada per funcionar bé a qualsevol dels dos costats.
- 01Una capa de programari, no una llicència
- 02L'activitat regulada correspon a l'operador o a un soci amb llicència
- 03Les dades de targeta es queden a la via, fora dels teus servidors
- 04Pensada per encaixar amb les vies regulades que aportis
On es connecta tot plegat
Segueix el fil una mica més enllà.
Cada concepte d'aquesta pàgina té un espai més complet: les definicions, els productes i les bandes d'accés que detallen què inclou cada nivell.
Idempotència, webhooks, liquidació, IBAN virtual, SCA: definits.
El servei que executa l'autorització i la captura.
Accions privilegiades amb motiu obligatori i auditades.
Valor on-chain liquidat fins a un IBAN.
Fiat i actius digitals convertits a la vora.
Què inclou cada producte, nivell a nivell.
Vols l'arquitectura per al teu projecte?
Explica'ns què estàs construint. Et respondrem amb un disseny de sistema i amb el punt on cau la frontera regulada, no amb una presentació comercial.