Aller au contenu

ADR-0022 — Hub PSP : cartes en agrégateur-first, acquisition carte native (EP/GIM-UEMOA) en cible flaggée

Date : 2026-06-30 Catégorie : B (engage la trajectoire produit PSP ; révocable 5 j — la licence EP relève de la catégorie C) Décideur : Lead architecte DYNORS (palier native conditionné à arbitrage CTO/direction) Statut : Acceptée S'appuie sur : [[0004-perimetre-fige-fiscal-books-paiement]] (PAIEMENT n'encaisse que via PSP), [[0010-payouts-et-tresorerie-groupe]] (trésorerie/reversements Groupe) Source de vérité : docs/projet-nouveau/DynorsPaiement/DYNORS_PAIEMENT_SPEC_v2_0.md §0, §4.2 (canaux PSP), §4.4 et §14 (roadmap EP/GIM-UEMOA)

Contexte

DYNORS PAIEMENT orchestre les PSP pour tous les satellites (/paiement/**). Pour le paiement par carte, deux voies existent et ne coûtent pas la même chose :

  • Via agrégateur : un PSP tiers (PayTech, et autres) expose CARD/LINK/QR/TPE, disponible immédiatement, commission ~2,5 %, aucune licence à obtenir côté DYNORS.
  • Acquisition carte native : DYNORS devient acquéreur en se connectant directement au réseau interbancaire GIM-UEMOA (cartes VISA/Mastercard, ~0,5-1 %). Cela exige une licence Établissement de Paiement (EP) BCEAO — chantier réglementaire de 6 à 18 mois qui touche le modèle économique et la structure juridique de la société.

Il faut une posture claire : ne pas bloquer la mise sur le marché des cartes en attendant la licence, sans pour autant fermer la porte à l'acquisition native qui améliore drastiquement les marges.

Décision

  1. Cartes en agrégateur-first. Le périmètre carte de la v2 passe par les agrégateurs (PayTech en premier, canaux CARD/LINK/QR_CODE/TPE). Aucun satellite n'intègre de PSP en direct — tout passe par /paiement/** via SLY, conformément à la frontière figée ([[0004-perimetre-fige-fiscal-books-paiement]]).

  2. L'acquisition carte native (licence EP + GIM-UEMOA) est la cible, mais flaggée catégorie C. Elle n'est pas engagée par cet ADR : l'obtention d'une licence EP BCEAO et l'opération comme acquéreur sont une décision exclusive CTO/direction (modèle économique + réglementaire). Cet ADR la documente comme trajectoire et prépare l'architecture pour l'accueillir sans rupture.

  3. Le canal est une donnée d'architecture, pas un branchement en dur. L'enum pspChannel inclut déjà PAYTECH, GIM_UEMOA, etc., et PspRoutingService choisit le canal au runtime. Basculer une partie du trafic carte de PAYTECH vers GIM_UEMOA le jour où la licence est obtenue ne change pas le contrat satellite : c'est une reconfiguration de routage.

  4. Trigger d'escalade C : décision d'engager le dossier licence EP, ou exigence BCEAO d'une incorporation/présence spécifique → escalade CTO/direction (cf. [[0007-gouvernance-architecte-categories-abc]]).

Conséquences

Positif : cartes commercialisables tout de suite (pas d'attente réglementaire) ; aucun couplage satellite au choix de canal ; marge améliorable plus tard sans refonte (simple reroutage) ; la décision lourde (licence EP) reste là où elle doit être, au niveau direction.

Coût : commissions agrégateur (~2,5 %) supérieures à l'acquisition native (~0,5-1 %) tant que la licence n'est pas obtenue ; dépendance commerciale aux agrégateurs sur le segment carte à court terme.

Composants impactés : DYNORS PAIEMENT (PspRoutingService, pspChannel, comptes de transit), dynors-platform/selebeyone (route /paiement/**), aucun impact sur les satellites.

Alternatives écartées

  • Engager la licence EP / GIM-UEMOA maintenant : meilleure marge cible mais chantier 6-18 mois qui bloquerait la mise sur le marché des cartes et empiète sur une décision direction. Écartée comme palier immédiat (conservée comme cible).
  • Pas de cartes du tout avant la licence : prive les satellites d'un moyen de paiement courant sans raison technique. Écartée.

Suivi

  • Critère de succès palier 1 : trafic carte opérationnel via agrégateur, zéro intégration PSP directe dans un satellite.
  • Réexamen du palier native déclenché par une décision CTO/direction sur la licence EP (catégorie C), pas par cet ADR.

Références

  • docs/projet-nouveau/DynorsPaiement/DYNORS_PAIEMENT_SPEC_v2_0.md §4.2 (table des canaux), §14 (roadmap phases 3-4)
  • ADR-0004 (frontière PAIEMENT), ADR-0010 (trésorerie Groupe), ADR-0007 (catégories A/B/C)