Vue des technologies utilisées
Vue d'ensemble de l'infrastructure, des rôles et des flux entre WeSettle, le Switch National (SMT), les facturiers et PaySmart.
Les acteurs clés de l'infrastructure WeSettle et leurs rôles respectifs
Orchestre tous les paiements, dialogue directement avec le Switch National (SMT) et les facturiers. Centralise les sessions, verrous, statuts et webhooks. Point d'entrée unique pour tous les initiateurs.
PaySmart Web : Application web servie par Nginx (assets statiques, pages HTML/JS). CMS configurable : services et factures configurables graphiquement.
PaySmart Mobile : Application Flutter qui consomme directement les APIs exposées par le backend (Apache + PHP-FPM). Elle n'est pas servie par Nginx. CMS configurable : services et factures configurables graphiquement.
Les deux versions initient les paiements au nom des utilisateurs finaux et appellent uniquement les APIs du Core agrégateur. Ne communiquent jamais directement avec le système des facturiers.
Kit de paiement PaySmart pour les sites des facturiers et des fournisseurs de services publics. Utilise les APIs du Core agrégateur pour initier des paiements. Reçoit des webhooks du Core agrégateur pour les notifications de statut final.
Exposent les APIs de consultation, verrouillage et confirmation de factures au Core agrégateur. N'interagissent jamais directement avec le Switch National (SMT).
Gestionnaire de l'agrégateur national PaySmart en sa qualité de switch. Reçoit les demandes de paiement du Core agrégateur et route vers les FSP concernés.
Partenaire technologique du Switch National (SMT), mettant en place la plateforme d'agrégation en marque blanche PaySmart Core pour le service national.
Banques et établissements de paiement interfacés avec le Core agrégateur PaySmart pour exposer le service de paiement des factures au sein de leurs solutions de paiement.
Les différents workflows de paiement dans l'écosystème WeSettle
Les mécanismes de communication asynchrone entre les composants
Reçus par le Core agrégateur depuis le Switch National (SMT), les FSP ou les facturiers. Ils contiennent des événements tels que : statuts de paiement, notifications de débit, confirmations techniques.
Callbacks de paiement : Le Switch National (SMT) envoie des callbacks HTTP sécurisés au Core agrégateur avec le statut final (succès / échec).
signé HTTPSEnvoyés par le Core agrégateur vers les facturiers, PaySmart ou les FSP. Ils notifient du statut final d'une transaction (succès, échec, expiration).
Webhooks vers PaySmart, SDK, facturiers, FSP : Le Core agrégateur notifie les partenaires des événements de paiement (ID de transaction, statut final, détails pertinents).
retriable horodatéNote importante : Les flux métiers (consultation, lock, paiement) ne sont pas des webhooks. Les webhooks sont des notifications techniques envoyées ou reçues par le Core agrégateur.
Vue d'ensemble des services backend, des bases de données et de la scalabilité du système WeSettle.
Front web : PaySmart Web et SDK PaySmart servis par Nginx (assets statiques, pages web).
Front mobile : Application Flutter qui consomme directement les APIs exposées par le backend (Apache + PHP-FPM). Elle n'est pas servie par Nginx.
Tous les clients intègrent uniquement les APIs REST exposées par le Core agrégateur PaySmart.
Core agrégateur et services backend exécutés sur Apache + PHP-FPM (APIs REST, webhooks, workers). Services stateless responsables de l'orchestration métier et des échanges avec le Switch National (SMT) / facturiers.
Technologies : Apache + PHP-FPM pour l'exécution des APIs et services backend. Services containerisés (Docker), orchestration (Kubernetes). Nginx sert uniquement le front web et fait reverse proxy, il n'exécute pas de PHP.
Connecteurs vers facturiers et connecteurs vers le Switch National (SMT) / FSP. Gérés comme des services internes orchestrés par le Core agrégateur.
Bases de données relationnelles pour stocker de façon persistante les transactions, factures, configurations. Réplication et sauvegardes prévues pour la haute disponibilité (HA) et la récupération.
Technologies : PostgreSQL pour le stockage transactionnel, ClickHouse pour l'analytics et les tableaux de bord (vues FSP ou facturiers).
Cache distribué pour accélérer les consultations et réduire la charge. Système de file de messages / workers pour traiter les callbacks du Switch National (SMT) et les webhooks sortants de manière asynchrone.
Technologies : Redis (cache distribué + queues), RabbitMQ (optionnel).
Stack de logs centralisée, métriques techniques (latence, taux d'erreur), tableaux de bord pour le suivi de la plateforme.
Technologies : Prometheus + Grafana pour les métriques, ELK / OpenSearch ou Loki pour les logs.
Vue détaillée des composants, clusters et flux de données de l'infrastructure PaySmart / core agrégateur
Les mesures de sécurité mises en place pour protéger les échanges
Les initiateurs (PaySmart, Facturiers via SDK PaySmart) s'authentifient via OAuth2 auprès du Core agrégateur. Les utilisateurs s'authentifient à PaySmart via son propre système d'authentification.
Le Switch National (SMT) n'interagit jamais directement avec les initiateurs. Toutes les communications passent exclusivement par le Core agrégateur, garantissant une isolation complète.
Les webhooks du Switch National (SMT) utilisent des secrets partagés et peuvent utiliser des signatures HMAC sur le payload. Tous les endpoints sont en HTTPS uniquement.
Le Core agrégateur applique le verrouillage de factures (invoice locking) pour éviter les paiements simultanés et garantit l'idempotence sur les demandes de paiement.
Journaux d'audit détaillés pour tous les callbacks et webhooks, permettant une traçabilité complète de toutes les opérations.
Les mécanismes garantissant la disponibilité et la fiabilité du système
Le Core agrégateur traite les callbacks du Switch National (SMT) de manière asynchrone avec un modèle de queue/worker, garantissant une haute disponibilité et une meilleure performance.
Si un partenaire externe (Facturiers via SDK PaySmart, PaySmart) est temporairement indisponible, le Core agrégateur réessaie plus tard. Toutes les tentatives sont journalisées, aucune perte de callback du Switch National (SMT).
Stratégies de timeout et de retry configurées sur les appels sortants pour garantir la fiabilité des communications avec les partenaires.
Métriques et logs disponibles pour le monitoring et le débogage, permettant un suivi en temps réel de la santé du système.
Répartition claire des responsabilités entre les différents acteurs