A.9 — Gestion des paiements
Chapitre A.9 du Manuel PIGBF
- A.9.9.1 — Vue d'ensemble du module paiements
- A.9.9.2 — Gestion des prestataires
- A.9.9.3 — Paiements Equity BCDC — Cycle complet
- A.9.9.4 — Paiements Vodacom M-Pesa — Cycle complet
- A.9.9.5 — Bonnes pratiques et points de vigilance — Paiements
A.9.9.1 — Vue d'ensemble du module paiements
9.1 Vue d'ensemble du module paiements
Le module Paiements est le plus critique de la PIGBF du point de vue financier. Il orchestre l'intégralité du cycle de décaissement des bourses, depuis la préparation des instructions jusqu'à la confirmation de réception par les bénéficiaires et le reporting associé.
La PIGBF gère deux circuits de paiement distincts correspondant aux deux types de bénéficiaires financiers :
| Circuit | Prestataire | Destinataire | Mécanisme technique | Objet du paiement |
|---|---|---|---|---|
| Equity BCDC | Equity Bank Congo | Comptes bancaires des écoles | Fichiers H2H via SFTP chiffré PGP | Frais scolaires (part école de la bourse) |
| Vodacom M-Pesa | Vodacom | Comptes mobile money des tuteurs ou élèves | API B2C (Business-to-Consumer) | Subvention directe (part tuteur/élève de la bourse) |
Les deux circuits suivent le même cycle en quatre étapes obligatoires et séquentielles :
┌─────────────────────────────────────────────────────────────────┐
│ ÉTAPE 1 — GÉNÉRATION │
│ Sélection des bénéficiaires éligibles pour la tranche, │
│ calcul automatique des montants, création des lots en attente │
└──────────────────────────┬──────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ ÉTAPE 2 — VALIDATION │
│ Contrôle humain des lots par le Validateur de paiement PAAF, │
│ vérification des montants et des comptes, approbation ou rejet │
└──────────────────────────┬──────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ ÉTAPE 3 — ENVOI │
│ Transmission sécurisée au prestataire : │
│ OTP par email obligatoire pour Equity / API directe pour M-Pesa│
└──────────────────────────┬──────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ ÉTAPE 4 — SUIVI │
│ Réception et traitement des retours prestataires : │
│ ACK/NACK/PSR pour Equity, confirmations API pour M-Pesa │
└─────────────────────────────────────────────────────────────────┘
🔒 Restreint — Séparation des rôles : L'architecture de sécurité financière de la PIGBF repose sur le principe fondamental que la même personne ne peut pas gérer à elle seule l'intégralité du cycle. Par défaut, l'Admin PAAF génère les instructions, et le Validateur de paiement PAAF (rôle autonome distinct) les valide et les envoie. Cette séparation des rôles est un contrôle interne indispensable.
A.9.9.2 — Gestion des prestataires
9.2 Gestion des prestataires
Les prestataires financiers (Equity BCDC et Vodacom M-Pesa) doivent être configurés dans la plateforme avec leurs paramètres techniques d'API avant de pouvoir effectuer des paiements.
Accéder à la liste des prestataires
Informations d'un prestataire
Cliquez sur Voir pour consulter la configuration technique d'un prestataire.
Configurer ou modifier un prestataire
- Cliquez sur Modifier (crayon) du prestataire concerné.
- Le formulaire de configuration s'ouvre avec trois éditeurs JSON :
Credentials (JSON) : contiennent les informations d'authentification auprès du prestataire : token d'accès, clés API, identifiants de connexion. Ces données sont hautement confidentielles.
API Config (JSON) : définit les paramètres des appels API de paiement : URL de l'endpoint, méthode HTTP (POST/GET), headers requis, structure du corps de la requête. Des placeholders dynamiques permettent d'injecter les valeurs à l'exécution (ex. : {{token}}, {{montant}}, {{reference_prestataire}}).
Tracking Config (JSON) : configure le suivi du statut des paiements après envoi : URL de l'endpoint de vérification, méthode, headers, structure de la réponse.
⚠️ Attention critique : La configuration des prestataires est une opération hautement technique et sensible réservée exclusivement à l'équipe IT GROUP ou au Super Admin technique. Une configuration incorrecte peut entraîner l'échec total ou partiel de tous les paiements, voire des virements vers des comptes incorrects. Ne modifiez jamais ces paramètres sans avoir obtenu les nouvelles valeurs techniques directement auprès du prestataire et sans avoir consulté l'équipe IT GROUP.
A.9.9.3 — Paiements Equity BCDC — Cycle complet
9.3 Paiements Equity BCDC — Cycle complet
9.3.1 Étape 1 — Génération des instructions Equity
La génération consiste à préparer les lots de virements qui seront soumis à Equity Bank pour créditer les comptes bancaires des écoles sélectionnées.
Accéder à l'écran de génération
Sélectionner la tranche de paiement
La sélection d'une tranche de paiement est obligatoire. Sans cette sélection, aucune école n'est affichée dans le tableau. Cette contrainte est intentionnelle pour éviter de générer des instructions sans contexte défini.
- Dans la liste déroulante Tranche de paiement, sélectionnez la tranche à traiter (ex. : « Première Tranche 2024-2025 »). Les tranches disponibles sont celles configurées dans les Paramètres de l'année scolaire active.
- Le tableau des écoles éligibles s'affiche automatiquement.
Qui apparaît dans cette liste ? Uniquement les écoles réunissant simultanément les conditions suivantes :
- Validée pour paiement (interrupteur activé dans le module Validation des écoles)
- Possédant un compte Equity BCDC configuré et actif dans leur fiche
- Ayant des élèves validées pour paiement pour la tranche sélectionnée
- N'ayant pas encore reçu le paiement de cette tranche (pour éviter les doublons)
Examiner les données avant génération
Avant toute sélection, prenez le temps d'examiner la liste :
- Vérifiez que le nombre d'élèves éligibles par école est cohérent avec vos données de terrain
- Vérifiez que le montant total par école est correct (= nombre d'élèves × montant par élève de la tranche)
- Identifiez les écoles absentes de la liste qui devraient y figurer (vérifiez leur validation pour paiement et leurs comptes)
Si vous souhaitez affiner la liste, utilisez les filtres PROVED, Sous-PROVED ou la sélection multi-écoles.
Sélectionner les écoles et générer
- Cochez les écoles à inclure dans le lot. Utilisez la case en en-tête pour sélectionner toutes les écoles de la page.
- Un bandeau récapitulatif apparaît en haut du tableau :
- Cliquez sur Générer les instructions.
- La fenêtre modale « Générer les instructions Equity » s'ouvre :
- Vérifiez les métriques récapitulatives (écoles, élèves, montant).
- Saisissez un Commentaire descriptif (optionnel mais recommandé) : « Première tranche — Sous-PROVED Kamuesha — novembre 2024 ». Ce commentaire sera visible dans tous les écrans suivants du cycle de paiement et dans l'historique.
- Cliquez sur Lancer la génération.
Les lots sont créés dans la base de données paiements avec le statut « Généré — en attente de validation ». Un lot distinct est créé pour chaque école sélectionnée.
9.3.2 Étape 2 — Validation des instructions Equity
Les lots générés passent dans la file de validation. Le Validateur de paiement PAAF doit examiner chaque lot, vérifier son exactitude et l'approuver ou le rejeter avant l'envoi à la banque.
Accéder à l'écran de validation
Valider un lot individuellement
- Repérez le lot dans le tableau. Vérifiez la référence, l'école, le nombre de paiements et le montant.
- Pour un contrôle approfondi, cliquez sur la Référence du lot pour ouvrir le détail complet (liste des paiements individuels, commentaire saisi à la génération).
- Cliquez sur Valider (coche verte).
- Vérifiez une dernière fois l'exactitude de toutes les informations.
- Cliquez sur Valider. Le lot passe au statut « Validé » et devient visible dans l'écran d'envoi.
Rejeter un lot
Si une anomalie est détectée — montant incorrect, compte bancaire erroné, école en doublon, cohérence douteuse — il faut rejeter le lot plutôt que de le laisser en attente.
- Cliquez sur Rejeter (croix rouge) sur la ligne du lot concerné.
- Renseignez la Raison du rejet (obligatoire) : soyez précis et descriptif pour faciliter la correction.
- Cliquez sur Rejeter. Le lot est marqué comme rejeté, les paiements associés restent en attente.
ℹ️ Après un rejet : L'administrateur doit corriger l'anomalie identifiée (généralement sur la fiche de l'école concernée), puis régénérer un nouveau lot via l'écran de Génération.
9.3.3 Étape 3 — Envoi des instructions vers Equity BCDC
C'est l'étape de transmission effective et sécurisée des instructions de paiement à Equity Bank. Elle est protégée par un code OTP (One-Time Password) envoyé par email, constituant une double vérification d'identité avant tout décaissement financier.
Accéder à l'écran d'envoi
Sélectionner les lots à envoyer
- Filtrez par dates de validation si nécessaire.
- Cochez un ou plusieurs lots validés. La case en en-tête coche tous les lots visibles.
- Un bandeau d'alerte apparaît :
Procédure d'envoi sécurisé par OTP — étape par étape
- Cliquez sur Envoyer vers Equity.
- La fenêtre modale « Envoi vers Equity BCDC » s'ouvre.
- Étape 1 — Demande du code OTP : Vérifiez le récapitulatif de la sélection. Cliquez sur Recevoir le code OTP. Un code à 6 chiffres à usage unique est envoyé à l'adresse email de l'utilisateur connecté. Une alerte verte confirme l'envoi et un compte à rebours indique la durée de validité du code.
- Étape 2 — Saisie du code OTP : Consultez immédiatement votre boîte email (vérifiez aussi le dossier spam). Copiez le code reçu et saisissez-le dans le champ Code OTP. Le bouton Envoyer s'active dès qu'un code valide est détecté.
- Étape 3 — Confirmation finale : Cliquez sur Envoyer. Le système effectue les opérations suivantes en séquence :
- Marque les lots sélectionnés au statut « Envoyé »
- Met à jour les instructions associées au statut « En attente de traitement »
- Déclenche la génération des fichiers H2H (format spécifique Equity Bank)
- Chiffre les fichiers avec la clé PGP d'Equity Bank
- Dépose les fichiers sur le serveur SFTP d'Equity pour traitement
⚠️ Important — Code OTP expiré : Si le compte à rebours atteint 00:00 avant votre saisie, le code expire. Cliquez à nouveau sur Recevoir le code OTP pour en générer un nouveau. Vous pouvez demander plusieurs codes successivement sans limitation.
⚠️ Important — Sécurité absolue du code OTP : Le code OTP est votre signature électronique pour cette opération financière. Ne le partagez jamais avec une autre personne, y compris un supérieur hiérarchique. Si quelqu'un vous demande votre code OTP, refusez et signalez cet incident à l'équipe IT GROUP. La demande de votre OTP par une tierce personne est le signe d'une tentative de fraude.
9.3.4 Étape 4 — Suivi des paiements Equity H2H
Après l'envoi, Equity Bank traite les fichiers et renvoie des fichiers de retour (ACK = accusé positif, NACK = rejet, PSR = rapport de synthèse final). L'écran de suivi permet de monitorer en temps réel l'état de chaque fichier et de chaque instruction de paiement.
Accéder à l'écran de suivi
Comprendre les statuts des fichiers H2H
| Statut | Couleur du badge | Signification |
|---|---|---|
| Non envoyé | Gris | Fichier généré côté plateforme, pas encore transmis au SFTP Equity |
| Envoi en cours | Bleu | Transmission SFTP en cours de traitement |
| Envoyé | Bleu ciel | Fichier déposé sur le SFTP Equity, en attente d'accusé de réception |
| Reçu | Vert clair | Accusé de réception (ACK) reçu — Equity confirme avoir le fichier |
| Traité avec succès | Vert foncé | Paiements exécutés par Equity — fonds décaissés |
| Rejeté | Rouge | Fichier rejeté par Equity (NACK) — voir fichier de rejet pour le motif |
| Erreur | Orange | Problème technique lors de la transmission SFTP |
Actions disponibles sur un fichier (menu trois points)
- Voir détails — ouvre la fenêtre modale de détail complet du fichier
- Télécharger — selon disponibilité : fichier H2H original, ACK, NACK, PSR
- Renvoyer — redéclenche le dépôt SFTP (uniquement pour les fichiers en statut "Non envoyé" ou "Erreur")
- Supprimer — suppression irréversible du fichier et des instructions associées
Consulter le détail d'un fichier
La fenêtre de détail permet à l'administrateur de descendre jusqu'au niveau de l'instruction individuelle (une école = une instruction) et de voir précisément le statut de chaque virement, qui a effectué chaque étape du workflow, et quand.
⚠️ Attention — Suppression d'un fichier H2H : La suppression d'un fichier H2H supprime également toutes les instructions de paiement associées côté plateforme. Cette opération ne peut pas annuler un virement déjà en cours de traitement ou exécuté chez Equity Bank. Elle ne doit être utilisée qu'en cas d'erreur manifeste sur un fichier non encore envoyé. Une fenêtre d'alerte forte récapitule le nom du fichier, la référence Equity, le nombre d'instructions et le montant total avant confirmation.
A.9.9.4 — Paiements Vodacom M-Pesa — Cycle complet
9.4 Paiements Vodacom M-Pesa — Cycle complet
9.4.1 Étape 1 — Génération des instructions M-Pesa
La génération M-Pesa prépare les virements mobile money destinés aux tuteurs (ou directement aux élèves si elles sont désignées comme bénéficiaires perceptrices dans leur fiche).
Accéder à l'écran de génération
Sélectionner la tranche et afficher les tuteurs éligibles
- Sélectionnez la Tranche de paiement dans la liste déroulante.
- Le tableau des tuteurs éligibles s'affiche. Seuls les tuteurs réunissant ces conditions apparaissent :
- Ils ont des élèves validées pour paiement pour la tranche choisie
- Un compte M-Pesa est configuré et coché "compte choisi pour paiement" dans leur fiche
- Pour vérifier le détail des élèves incluses dans le calcul d'un tuteur, cliquez sur le bouton ▼ (déplier) de sa ligne :
- Affinez si nécessaire avec les filtres École(s), Classe et Option.
Sélectionner et générer
- Cochez les tuteurs à inclure. Le bandeau récapitulatif apparaît :
- Cliquez sur Générer les instructions de paiement.
- Ajoutez un Commentaire descriptif, cliquez sur Générer. Pour chaque tuteur sélectionné, le système crée un lot contenant un paiement individuel par élève (1 paiement M-Pesa = 1 virement = 1 élève).
9.4.2 Étape 2 — Validation des instructions M-Pesa
Accéder à l'écran de validation
Valider un lot individuellement
- Cliquez sur Valider (coche verte) sur la ligne du lot.
- Vérifiez toutes les informations. Cliquez sur Valider. Le lot passe au statut « Validé ».
Rejeter un lot
- Cliquez sur Rejeter (croix rouge).
- Renseignez la Raison du rejet (obligatoire). Cliquez sur Rejeter. Le lot est marqué rejeté, tous les paiements du lot passent au statut « Annulé ».
Validation ou rejet groupé
- Cochez plusieurs lots.
- Les boutons Valider plusieurs instructions et Rejeter plusieurs instructions apparaissent.
- Chaque action ouvre une fenêtre modale récapitulative :
- Pour la validation : nombre de lots, total élèves, montant global à confirmer
- Pour le rejet : même récapitulatif + champ Raison du rejet unique applicable à tous les lots sélectionnés
9.4.3 Étape 3 — Envoi des instructions M-Pesa
Accéder à l'écran d'envoi
- Filtrez si nécessaire.
- Cochez les lots à envoyer.
- Cliquez sur Envoyer (n) (n = nombre de lots sélectionnés). Les paiements sont soumis en temps réel à l'API Vodacom M-Pesa. Chaque paiement individuel (un par élève) est initié séparément, permettant un suivi granulaire.
ℹ️ Note sur la sécurité M-Pesa : L'envoi M-Pesa ne nécessite pas de code OTP, contrairement à Equity. La sécurisation repose ici sur la stricte séparation des rôles (génération, validation et envoi peuvent être attribués à des personnes différentes) et sur la traçabilité exhaustive de chaque action dans le journal d'activités.
9.4.4 Étape 4 — Suivi des paiements M-Pesa
Accéder à l'écran de suivi
Comprendre les compteurs par lot
Chaque lot M-Pesa contient un paiement individuel pour chaque élève rattachée au tuteur. Les quatre compteurs détaillent l'état en temps réel :
| Compteur | Couleur | Signification |
|---|---|---|
| Total paiements | Bleu | Nombre total de paiements dans le lot (un par élève) |
| Payé | Vert | Paiements reçus et confirmés par Vodacom M-Pesa |
| En cours | Orange | Paiements soumis, confirmation pas encore reçue de Vodacom |
| Échoué / Annulé | Rouge | Paiements échoués (numéro incorrect, compte inexistant, solde insuffisant) ou annulés manuellement |
Consulter le détail d'un lot
Cliquez sur Voir les détails pour ouvrir la fenêtre modale de détail :
Cette vue granulaire permet à l'administrateur de :
- Vérifier qu'une élève spécifique a bien été payée (recherche par UID ou nom)
- Identifier les paiements échoués et leur motif (compte inexistant, numéro incorrect) pour correction
- Préparer les justificatifs individuels pour un audit ou une réclamation d'une bénéficiaire
A.9.9.5 — Bonnes pratiques et points de vigilance — Paiements
9.5 Bonnes pratiques et points de vigilance — Paiements
Vérifier les conditions d'éligibilité avant la génération. Si une école ou un tuteur attendu n'apparaît pas dans la liste de génération, vérifiez méthodiquement : (1) validation pour paiement active, (2) compte bancaire ou M-Pesa correctement renseigné et coché « choisi pour paiement », (3) élèves validées pour paiement pour la tranche concernée, (4) tranche correctement configurée dans les Paramètres de l'année scolaire.
Respecter la séparation des rôles. Cette séparation n'est pas une contrainte administrative — c'est un contrôle interne fondamental contre la fraude et les erreurs. Une seule personne ne doit jamais être en mesure de générer ET valider ET envoyer un paiement.
Commenter systématiquement les lots générés. Un commentaire précis (tranche, zone géographique, date) facilite considérablement le suivi, le reporting et les investigations ultérieures. Il est visible dans tous les écrans du cycle et dans les exports.
Ne jamais supprimer un fichier Equity H2H déjà envoyé. Une fois un fichier déposé sur le SFTP Equity Bank, sa suppression côté plateforme ne l'annule pas côté banque. Tout problème sur un fichier déjà en cours de traitement doit être géré en coordination avec l'équipe technique IT GROUP et directement avec Equity Bank.
Surveiller quotidiennement les statuts de suivi pendant les périodes de paiement. Des paiements Equity en statut « Envoyé » depuis plus de 48h sans évolution vers « Reçu » ou « Traité » méritent une investigation. Des paiements M-Pesa « En cours » depuis plus de 24h peuvent indiquer un problème de callback API. Dans les deux cas, contactez l'équipe IT GROUP avec la référence du fichier ou du lot concerné.
Documenter tous les rejets. La raison de rejet saisie est enregistrée dans le journal d'activités. Des rejets répétés sur les mêmes écoles ou tuteurs signalent un problème structurel (compte bancaire systématiquement erroné, numéro M-Pesa invalide) qui doit être corrigé à la source dans les fiches correspondantes.