Architecture de la plateforme
Un seul cœur, de multiples interfaces : comment la plateforme fonctionne vraiment.
Un parcours de la plateforme, du ledger vers le haut : les comptes, le KYC, les cartes et les cryptos qui partagent un même cœur en partie double, le trajet d'un paiement de sa création à son rapprochement, et la place de la couche applicative, de la console opérateur et de la frontière réglementée.
Le cœur
Un seul ledger sous tout le reste.
Au centre de la plateforme se trouve un grand livre de comptes unique. Chaque compte — portefeuille client, solde marchand, compte de frais, compte de règlement — est un nœud de ce ledger, et chaque mouvement de valeur est une écriture en partie double : un compte débité, un autre crédité, les deux côtés toujours égaux. Le ledger est en ajout seul (append-only). Les écritures ne sont jamais modifiées ni supprimées ; une correction est une nouvelle écriture de sens contraire, de sorte que l'historique complet de la formation d'un solde reste toujours reconstituable. Les comptes, l'état KYC, les cartes émises et les adresses crypto s'rattachent tous au même modèle de compte. C'est pourquoi une autorisation de carte, un virement bancaire et un dépôt on-chain peuvent être imputés sur un même solde, sans couche de rapprochement pour recoudre des systèmes distincts.
- 01Partie double : chaque écriture est équilibrée, les débits égalent les crédits
- 02Append-only : les corrections sont de nouvelles écritures, jamais des modifications
- 03Un seul modèle de compte pour le fiat, les cartes et les cryptos
- 04L'état KYC suit le compte, il ne vit pas dans une table annexe
Un paiement, de bout en bout
Un paiement, de la création au rapprochement.
Un paiement n'est pas un seul appel mais un court cycle de vie, dont chaque étape est un état visible à la fois par le ledger et par vos systèmes. Chaque changement d'état émet un webhook, et chaque écriture est idempotente — la même clé rejoue le même résultat, donc une requête renvoyée ne débite jamais deux fois.
- 01
Création
Une intention de paiement est ouverte : montant, devise, comptes concernés. Rien n'a encore bougé — le ledger enregistre une écriture en attente.
- 02
Autorisation
Le rail vérifie les fonds et le risque, puis place une réservation. Pour une carte, c'est l'autorisation ; pour un virement, le débit est réservé.
- 03
Capture
Le montant réservé est confirmé. Le ledger passe l'écriture en partie double qui déplace réellement la valeur entre les deux comptes.
- 04
Règlement
Les fonds transitent sur le rail sous-jacent — schéma de cartes, banque ou chaîne — et les comptes de règlement se rapprochent de l'argent réel.
- 05
Rapprochement
La plateforme confronte ses propres écritures au rapport de règlement du rail ; tout écart est signalé, jamais masqué.
Les webhooks et l'idempotence interviennent à chaque extrémité de ce flux. Vos systèmes apprennent qu'un paiement a eu lieu en recevant un événement, sans polling, et toute requête que vous renvoyez après un délai dépassé aboutit — grâce à sa clé d'idempotence — au même résultat, si bien qu'un doublon ne débite jamais deux fois. Le service qui exécute l'autorisation et la capture est la passerelle de paiement.
La couche applicative
Des apps whitelabel en surface, une seule plateforme en dessous.
Le cœur expose des capacités ; la couche applicative en fait des produits. Chaque application destinée aux clients — web et mobile — est un client whitelabel qui affiche les mêmes comptes, paiements et cartes sous sa propre marque. Le thème repose sur des tokens : couleurs, typographie, rayons et espacements proviennent d'un système de design tokens (PDS), si bien qu'un opérateur redessine toute l'interface en modifiant des tokens, sans forker l'application. La même plateforme peut être orientée dans des directions très différentes — une néobanque grand public, une app d'acquisition marchande, un programme d'émission de cartes, une on/off-ramp crypto ou un outil d'exploitation interne — sans devenir cinq produits distincts. C'est une seule plateforme qui change d'habillage, chaque déclinaison étant configurée plutôt que reconstruite.
- 01Clients whitelabel web + mobile sur des API partagées
- 02Thèmes pilotés par tokens (PDS) : on restylise par la config, pas par un fork
- 03Cinq exemples d'usage — néobanque, acquiring, issuing, ramp, ops
- 04Les nouvelles interfaces se configurent, elles ne se reconstruisent pas
Exploitation
Pilotez depuis la console, avec un motif consigné.
Derrière chaque app, il y a une console opérateur. C'est là qu'un agent du support consulte un compte, qu'un analyste risque gèle une carte ou qu'un responsable des opérations annule une écriture. L'accès en lecture est large ; les actions privilégiées, non. Toute opération qui déplace de l'argent, modifie des plafonds ou touche aux fonds d'un client exige un motif explicite avant son exécution et génère une entrée d'audit immuable — qui a agi, sur quoi, quand et pourquoi. Les accès suivent le principe du moindre privilège : chaque opérateur ne voit et ne fait que ce que son rôle autorise. C'est le modèle de Protocore Center, la console opérateur, et la même rigueur est intégrée à chaque système de la plateforme : les actions sensibles sont délibérées, attribuables et vérifiables a posteriori.
- 01Lecture large, écriture encadrée — les actions privilégiées sont l'exception
- 02Motif obligatoire avant toute action touchant aux fonds
- 03Piste d'audit immuable : qui, quoi, quand, pourquoi
- 04Moindre privilège selon le rôle de l'opérateur
Le pont crypto
Crypto et fiat sur le même ledger.
Sur la plateforme, la crypto n'est pas un silo à part : une adresse crypto est simplement un compte de plus sur le même ledger. Une on/off-ramp convertit entre fiat et actifs numériques en périphérie — un client alimente un solde par carte ou par virement et reçoit des cryptos, ou vend ses cryptos et retire vers un compte bancaire. La valeur on-chain peut être réglée jusqu'à un rail bancaire : un paiement on-chain entrant est crédité sur le compte, converti, puis versé sur un IBAN, de sorte que le bénéficiaire voit de l'argent ordinaire sur un compte bancaire ordinaire. Comme les deux jambes sont imputées sur un seul ledger en partie double, un mouvement qui démarre on-chain et se termine par un virement bancaire forme un historique unique et rapproché, et non deux systèmes rapprochés à la main.
- 01Une adresse crypto est un compte comme un autre
- 02On/off-ramp : fiat et actifs numériques convertis en périphérie
- 03Règlement on-chain jusqu'au versement sur IBAN
- 04Un historique rapproché unique sur les deux jambes
La surface de développement
API, webhooks et un sandbox pour développer.
Tout ce que font les apps passe par une API documentée — créer un compte, ouvrir un paiement, émettre une carte, lancer une ramp. Des appels typiques ressemblent à POST /v1/wallets ou POST /v1/payments ; l'API est REST, avec une clé d'idempotence sur chaque écriture. Les changements d'état sont envoyés sous forme de webhooks : vos systèmes réagissent aux événements au lieu de les interroger en boucle. Le développement se fait sur un tenant sandbox — une copie isolée de la plateforme avec des rails de test, où vous pouvez exécuter tout le flux, de la création au rapprochement, sans déplacer d'argent réel. Ce que chaque produit vous expose, et à quel niveau, dépend de sa bande d'accès ; les pages produit détaillent ce que comprend chaque bande.
- 01API REST documentée, écritures idempotentes
- 02Webhooks pour chaque changement d'état — événementiel, sans polling
- 03Tenant sandbox avec rails de test, isolé de la production
- 04Périmètre et limites définis par des bandes d'accès propres à chaque produit
La frontière, en toute franchise
Protocore construit le logiciel. La licence porte la frontière réglementée.
Un produit de paiement réunit deux choses indissociables : l'autorisation réglementaire de détenir et de déplacer des fonds, et le logiciel qui les ordonne, les enregistre et les rapproche. Protocore construit le logiciel. L'activité réglementée — détenir les fonds des clients, émettre des comptes, faire circuler l'argent sur un schéma — relève de la licence propre de l'opérateur ou d'un partenaire agréé : une banque, un EMI ou un établissement de paiement. La plateforme est conçue pour s'adapter aux rails réglementés que vous apportez, et pour garder les données de carte sur le rail afin qu'elles ne touchent jamais vos serveurs ; elle ne remplace pas cette autorisation, et aucun logiciel ne le fait. Où passe la frontière réglementée, c'est une décision que vous prenez avec votre partenaire, et l'architecture est pensée pour s'insérer proprement de part et d'autre.
- 01Une couche logicielle, pas une licence
- 02L'activité réglementée relève de l'opérateur ou d'un partenaire agréé
- 03Les données de carte restent sur le rail, hors de vos serveurs
- 04Conçu pour s'adapter aux rails réglementés que vous apportez
Pour aller plus loin
Tirez le fil.
Chaque concept de cette page a une page dédiée plus complète — les définitions, les produits et les bandes d'accès qui détaillent ce que comprend chaque niveau.
Idempotence, webhooks, règlement, IBAN virtuel, SCA — définis.
Le service qui exécute l'autorisation et la capture.
Actions privilégiées auditées, avec motif obligatoire.
Valeur on-chain réglée jusqu'à un IBAN.
Fiat et actifs numériques convertis en périphérie.
Ce que comprend chaque produit, niveau par niveau.
Une architecture pour votre projet ?
Dites-nous ce que vous construisez. Nous reviendrons avec une conception système et l'emplacement de la frontière réglementée — pas une plaquette commerciale.