Construire un système de monnaie électronique

La directive 2009/110/CE définit la monnaie électronique comme une valeur monétaire stockée sous forme électronique, représentant une créance sur l'émetteur, émise contre la remise de fonds, et acceptée par une personne autre que l'émetteur. Chaque mot de cette phrase a une conséquence dans la base de données.

« Créance sur l'émetteur » signifie que le solde affiché à l'utilisateur est votre dette envers lui. Ce n'est pas un nombre qui vous appartient et que vous pouvez ajuster. « Émise contre la remise de fonds » signifie qu'aucune unité ne peut exister avant que les fonds correspondants soient arrivés et reconnus. « Remboursable à tout moment à la valeur nominale » signifie que votre système doit pouvoir éteindre cette créance sur demande, intégralement, sans la compenser avec quoi que ce soit.

Une équipe qui intègre cela cesse de se demander comment mettre à jour un solde et commence à se demander quel événement justifie que le solde change. Ce basculement, c'est toute l'architecture.

Avant toute fonctionnalité, quatre égalités doivent tenir en continu, et vous devez pouvoir prouver qu'elles tenaient à n'importe quel moment du passé.

Ce ne sont pas des raffinements comptables. Les deux premiers sont des exigences prudentielles sur lesquelles vous serez examiné. Les deux derniers sont ce qui rend les deux premiers démontrables plutôt qu'affirmés.

Si votre système ne sait pas recalculer le solde d'un utilisateur à une date d'il y a quatorze mois, vous n'avez pas un système de monnaie électronique. Vous avez un tableur avec une API.

L'exigence s'énonce simplement : les fonds reçus en échange de monnaie électronique doivent être séparés des fonds propres de l'établissement, soit déposés sur un compte dédié auprès d'un établissement de crédit, soit investis en actifs liquides à faible risque, soit couverts par une assurance ou une garantie comparable.

C'est à la mise en oeuvre que cela devient de l'ingénierie. Il vous faut une comparaison continue entre deux quantités indépendantes : l'encours de monnaie électronique calculé depuis votre grand livre, et le solde cantonné calculé depuis des relevés bancaires que vous n'avez pas produits. Ces deux nombres viennent de systèmes différents, arrivent à des rythmes différents, et vont diverger.

Construisez la comparaison comme un objet de premier rang, avec son propre historique. Chaque exécution stocke les deux chiffres, l'écart, l'explication de l'écart, et qui l'a revu. Quand un superviseur demande quelle était votre couverture un mardi quelconque de l'an dernier, vous répondez avec un enregistrement, pas avec une reconstitution.

Deux détails coûtent des mois quand on les découvre tard. Les fonds en transit doivent avoir une place explicite : l'argent qui a quitté un payeur sans être arrivé sur le compte de cantonnement n'est ni rien ni disponible. Et les commissions auxquelles vous avez droit ne sont pas des fonds cantonnés, mais elles ne cessent de l'être qu'au moment où votre contrat dit qu'elles sont acquises, ce qui est une règle que votre code doit encoder.

L'ordre de dépendance ci-dessous n'est pas une préférence. Chaque couche est inutilisable tant que la précédente n'est pas correcte.

Les équipes construisent régulièrement les points un, sept et huit, puis découvrent pendant l'instruction de l'agrément que les points deux à six étaient le vrai produit.

Si l'idempotence arrive si tôt, c'est parce que les systèmes de paiement rejouent. Les réseaux expirent, les prestataires renvoient leurs webhooks, les utilisateurs tapent deux fois. Sans clé de déduplication stockée avec le mouvement, chaque rejeu émet une nouvelle unité de monnaie électronique contre des fonds reçus une seule fois. Parler d'anomalie de reporting serait en dessous de la réalité. C'est une émission sans réception, la seule chose que la directive interdit frontalement.

• Un journal de mouvements en ajout seul, avec des identifiants stables
• Un plan de comptes internes qui exprime les invariants
• Le solde calculé comme somme du journal, jamais comme champ mutable stocké
• L'idempotence sur chaque point d'entrée, par une référence fournie par l'appelant
• Des mouvements en deux temps : autorisation qui réserve, capture qui règle, expiration qui libère
• Le rapprochement avec chaque source externe de vérité, sur un rythme, avec des résultats stockés
• Des plafonds et des contrôles évalués sur l'état du grand livre plutôt que sur une copie en cache
• La surface produit

Chaque mouvement porte au moins trois horodatages, et ils sont rarement égaux : quand l'événement s'est produit dans le monde extérieur, quand votre système l'a appris, et quand il prend effet comptable.

Une autorisation carte a lieu à 23h58 le trente et un, arrive dans un fichier de règlement à 4h00 le premier, et appartient au mois précédent pour le reporting. Si vous ne stockez qu'un horodatage, vous produirez un état défendable selon une interprétation et faux selon les deux autres, sans pouvoir dire laquelle.

Stocker séparément le temps de l'événement, le temps d'ingestion et la date de valeur coûte trois colonnes. Ne pas les stocker coûte un retraitement, et les retraitements sont la façon dont un superviseur apprend que vos chiffres sont des estimations.

Le remboursement à la valeur nominale, à tout moment, est l'obligation qui distingue la monnaie électronique d'un système de valeur prépayée, d'un solde de fidélité ou d'un produit prépayé avec expiration. C'est aussi le chemin le moins éprouvé en test, parce qu'en exploitation normale peu d'utilisateurs vident un compte à zéro pour le clôturer.

Testez-le comme le flux principal. Remboursez un solde qui comprend une autorisation en attente. Remboursez pendant qu'un écart de rapprochement est ouvert sur ce compte. Remboursez un montant qu'une grille de frais ramènerait sous la valeur nominale, et vérifiez que le système refuse de la réduire. Remboursez après une annulation partielle.

Chacun de ces cas force une décision, plus facile à prendre délibérément en revue de conception que pendant un incident.

Un système construit dans cet ordre est plus lent à la première démo et plus rapide à l'agrément, parce que les questions posées pendant l'instruction portent sur les invariants, pas sur l'interface.

Il est aussi moins cher à exploiter. Quand les soldes sont calculés plutôt que stockés, une catégorie d'incidents disparaît : plus de dérive à détecter, plus de script de réparation à écrire, plus de rapprochement entre deux copies internes de la même vérité. Les incidents restants concernent le monde extérieur, ce qui est leur place.