Contrôles cryptographiques & comptables stricts

Architecture de résilience

La sécurité intégrée au cœur de chaque transaction.

Des contrôles transactionnels et comptables gravés dans le modèle relationnel pour éliminer les ambiguïtés et garantir l'intégrité financière.

SECTION A · CONTRÔLE D'IDENTITÉ

Protection des accès et étanchéité multi-tenant

L'accès aux ressources financières exige une authentification forte continue. Chaque requête est bornée cryptographiquement et logiquement à l'organisation émettrice.

MFA TOTP obligatoire (RFC 6238) : Tout accès au portail marchand requiert un jeton dynamique régénéré toutes les 30 secondes.
Cloisonnement strict par organisation : Les clés API et les données transactionnelles sont isolées au niveau base de données avec filtres obligatoires.
Secrets à usage unique : Les secrets d'API ne sont affichés qu'une seule fois à la création et ne sont jamais renvoyés en clair par l'API.

Matrice des Permissions & Rôles (RBAC)

Rôle	Cotation	Paiement	Settlement	Approbation Payout
`Merchant Owner`	✓	✓	✓ (Initiation)	✕ (Auto-refusée)
`Merchant Finance`	✓	✕	✕	✓ (Validation 4 yeux)
`Developer`	✓	✓	✕	✕

SECTION B · DÉTERMINISME TRANSACTIONNEL

Protection des opérations et verrouillage des montants

Dans ChadPay, une application cliente ne décide jamais du montant final d'une transaction lors de l'exécution. Le flux suit un protocole déterministe strict.

Devis serveur obligatoire (quote-required) : Le devis arrête canoniquement le montant en XAF entier et génère un quoteId horodaté à validité bornée.
Clé d'idempotence obligatoire : L'en-tête Idempotency-Key protège les marchands contre les coupures réseau : la réémission renvoie déterministement la même réponse.
Rejet strict des champs inconnus : Toute injection de payload ou paramètre non conforme déclenche un rejet immédiat avec statut 422/400.

Devis canonique Calcul serveur verrouillant le montant en devise pivot XAF.

Contrôle d'idempotence Vérification d'unicité stricte pour interdire tout double débit.

Écriture comptable Scellement atomique Débit et Crédit dans le Grand Livre.

Résultat traçable Horodatage inaltérable et webhook signé par clé HMAC-SHA256.

SECTION C · VÉRITÉ COMPTABLE ABSOLUE

Grand livre en partie double et invariant mathématique

La plateforme refuse toute approximation financière. Chaque transaction, règlement ou remboursement génère des écritures équilibrées au centime près.

Principe de la partie double : Chaque écriture de Débit est rigoureusement compensée par une écriture de Crédit de montant équivalent.
Invariant de balance nulle : La somme nette algébrique des mouvements comptables est égale à zéro à chaque validation d'ordre.
Journaux immutables : Aucune mise à jour directe (UPDATE) n'est opérée sur les soldes comptables historiques ; seuls des mouvements compensatoires sont enregistrés.

⚖

Démonstration de l'Invariant Comptable Partie double stricte · Règle mathématique vérifiée

Compte Grand Livre	Sens	Montant XAF
`1010-TRÉSORERIE-COMPENSATION`	DÉBIT	+3 000 XAF
`2010-PASSIF-MARCHAND-DISPONIBLE`	CRÉDIT	-3 000 XAF
Somme nette des écritures		0 XAF (Parfaitement équilibré)

SECTION D · AUDIT & TRAÇABILITÉ

Chronologie immuable d'une opération financière

Chaque événement d'un paiement est horodaté et consigné dans un journal d'audit inaltérable consultable par les auditeurs et officiers de conformité.

ÉTAPE 1 Devis Horodaté

Émission du devis serveur avec expiration à 15 minutes et montant verrouillé.

ÉTAPE 2 Autorisation Idempotente

Vérification de non-rejeu et transmission à la passerelle concernée.

ÉTAPE 3 Écriture Grand Livre

Inscription atomique des mouvements Débit/Crédit en base relationnelle.

ÉTAPE 4 Signature & Webhook

Livraison de la notification signée par HMAC-SHA256 avec horodatage anti-rejeu.

SECTION E · GOUVERNANCE FINANCIÈRE

Contrôle à quatre yeux (Dual Control)

Les opérations de règlement sortant (payouts vers les comptes bancaires ou portefeuilles de fournisseurs) appliquent une séparation des pouvoirs stricte.

Initiation (Owner) : Le propriétaire du compte crée le projet de settlement et sélectionne la destination de paiement.
Interdiction d'auto-approbation : Le créateur ne peut en aucun cas valider sa propre demande. Toute tentative est bloquée côté API.
Validation (Finance) : Un collaborateur distinct détenant le rôle Finance examine les montants, vérifie la conformité et signe l'approbation via TOTP MFA.

Workflow d'approbation à 4 yeux (Sandbox) Séparation stricte des privilèges : Owner ≠ Finance

Owner

1. Création du règlement Génération de la demande (statut created) avec destination validée.

Système

2. Soumission & Provision Vérification des soldes et transition vers ready_for_payout.

Finance

3. Approbation croisée (4 yeux) Examen par un tiers habilité. L'auto-approbation Owner est formellement bloquée.

Finance

4. Signature TOTP MFA Validation cryptographique forte requise (RFC 6238) pour valider l'ordre.

Moteur

5. Préparation technique Contrôle d'intégrité, idempotence et génération du paquet de règlement.

Sandbox

6. Exécution & Grand Livre Dénouement du payout et inscription symétrique Débit/Crédit irréversible.

SECTION F · TRANSPARENCE INSTITUTIONNELLE

Périmètre des contrôles et engagements d'honnêteté

Information institutionnelle & conformité

Cette présentation illustre les mécanismes logiciels et cryptographiques effectivement codés et validés dans l'environnement Sandbox de ChadPay : authentification forte TOTP (RFC 6238), contrôle d'idempotence natif, invariant mathématique du Grand Livre en partie double et gouvernance à 4 yeux.

Elle ne constitue pas une certification PCI-DSS délivrée, un agrément bancaire formellement octroyé ni une connexion de production active au switch GIMAC ou aux opérateurs télécoms. Tous les raccordements effectifs dépendent des conventions et homologations futures.

Une question relative à la conformité technique ?

Nos équipes d'ingénierie et de sécurité répondent aux questions d'architecture de nos partenaires institutionnels.

Échanger avec l'équipe