Une application qui veut encaisser au Sénégal aujourd'hui intègre en général trois à cinq passerelles distinctes. Un wallet, un second wallet, une passerelle carte, parfois un virement bancaire traité manuellement. Chacune a son API, son format de webhook, son cycle de réconciliation, sa grille tarifaire et son support.

Le coût réel n'est pas dans le développement initial. Il est dans la maintenance permanente de quatre intégrations qui évoluent chacune de leur côté.

La BCEAO a lancé le 30 septembre 2025 la Plateforme Interopérable du Système de Paiement Instantané, PI-SPI. Le calendrier réglementaire fixe au 30 septembre 2026 l'ouverture effective des services pour les banques, les établissements de monnaie électronique et les établissements de paiement, et au 30 juin 2027 pour les institutions de microfinance supervisées par la Commission Bancaire de l'UMOA. Au 24 juin 2026, 80 participants étaient déjà connectés.

Autrement dit, à très court terme, la quasi-totalité des comptes bancaires et des comptes de monnaie électronique de l'UEMOA deviennent adressables par un rail unique. Pour une équipe produit, c'est une décision d'architecture à prendre maintenant, pas en 2027.

PI-SPI en trois phrases

PI-SPI est une infrastructure régionale conçue et opérée par la BCEAO. Elle permet à toute personne disposant d'un compte dans l'un des huit pays membres, Bénin, Burkina Faso, Côte d'Ivoire, Guinée-Bissau, Mali, Niger, Sénégal et Togo, d'envoyer ou de recevoir de l'argent en quelques secondes, quel que soit l'établissement teneur du compte.

Tous les types de comptes sont éligibles : comptes bancaires, comptes de monnaie électronique, comptes de microfinance et comptes de paiement. Les transactions se font exclusivement en franc CFA. Pour les particuliers, les opérations nationales sont gratuites, et le délai d'encaissement passe de 48 heures à moins de 10 secondes.

Le point décisif pour un intégrateur n'est pas la rapidité, c'est l'adressage universel. Un seul point d'entrée technique permet d'atteindre un client de n'importe quelle banque comme un client d'un émetteur de monnaie électronique, sans négocier de contrat distinct avec chacun.

Les chiffres à retenir

• Moins de 10 secondes pour la mise à disposition des fonds chez le bénéficiaire
• 8 pays de l'UEMOA couverts par un seul rail de paiement
• 24h/24 et 7j/7, week-ends et jours fériés inclus
• 0 franc de frais pour les particuliers sur les opérations nationales
• 30 septembre 2026, échéance d'ouverture pour les banques, EME et établissements de paiement

La partie que personne n'explique : les quatre catégories de clients

C'est ici que la plupart des projets se trompent, parce que la règle n'est pas technique mais réglementaire, et qu'elle détermine la structure de compte à ouvrir avant même la première ligne de code.

PI-SPI classe les clients des participants en quatre catégories, chacune soumise à des règles spécifiques.

• Type P, personne physique. Compte personnel, non destiné à l'encaissement commercial récurrent.
• Type C, personne physique commerçante. Profil adapté au commerçant individuel et à l'entrepreneur en nom propre.
• Type B, personne morale. Le profil cible d'une SARL ou d'une SA qui encaisse via son application.
• Type G, administration publique. Régies de recettes, redevances, encaissements institutionnels.

La distinction entre transfert et paiement en découle directement. Un transfert est un virement en faveur d'un client de type P, dans la limite de trente réceptions par mois calendaire. Un paiement est un virement dont le bénéficiaire est un client de type B, C ou G. Lorsqu'un client de type P franchit le seuil de trente transferts reçus dans le mois, les virements suivants basculent en régime de paiement à partir du trente et unième.

Un entrepreneur qui encaisse sur son compte personnel change mécaniquement de régime au trente et unième encaissement du mois. Si votre application dépasse ce volume, la question du type de compte doit être réglée au cadrage, pas au moment de la mise en production.

Les trois parcours d'encaissement

PI-SPI n'expose pas une seule façon de se faire payer. Trois mécanismes coexistent, et le choix dépend du contexte d'usage bien plus que de la stack technique.

1. QR dynamique

Le QR est généré au moment du panier, avec le montant et la référence de commande embarqués dans le payload. Le client le scanne depuis l'application de sa banque ou de son wallet et valide.

C'est le parcours naturel pour un point de vente physique, une borne, une facture imprimée, ou un checkout consulté sur un autre écran que celui où le paiement est validé.

2. Demande de paiement

Le marchand pousse une requête vers l'alias du client, qui la retrouve dans son application et l'approuve.

C'est le parcours des abonnements, des relances de facture et des applications métier où le montant est connu du système avant d'être connu du client. C'est aussi celui qui supprime la friction du copier-coller de référence.

3. Alias

L'alias est un identifiant unique, adresse de paiement ou numéro de téléphone, associé à un compte. Sur le plan produit, cela signifie la fin de la saisie d'un IBAN dans un formulaire, et la fin des erreurs de frappe sur vingt-huit caractères.

Quel parcours pour quel besoin

Choisissez le QR dynamique quand le client est physiquement présent au point de vente, quand le montant est connu au moment de l'affichage sans que le client soit identifié, ou quand le paiement doit fonctionner sans création de compte utilisateur.

Choisissez la demande de paiement quand le client est déjà présent dans votre base, pour une facturation récurrente ou un échéancier, pour une relance sur impayé, ou dans une application métier avec cycle de validation.

L'outillage existe déjà

Ce n'est pas de la prospective. La BCEAO expose un environnement de sandbox sur developer.pispi.bceao.int, adossé à une API Business standardisée. On y trouve des bibliothèques officielles, des simulateurs, la génération de payloads EMV conformes PI-SPI, des applications de démonstration pour la génération de QR dynamique et pour l'envoi d'une demande de paiement, ainsi que la possibilité d'enrôler son entreprise et de récupérer ses identifiants API pour dérouler les parcours business de bout en bout.

Détail qui a son importance : parmi les exemples d'intégration publiés figure une application React 19 et Next 16. Le rail de paiement régional arrive avec une documentation développeur qui parle le même langage que les applications qu'on construit aujourd'hui.

Architecture d'intégration recommandée

La tentation classique consiste à appeler l'API du participant directement depuis le service de commande. C'est le meilleur moyen de se retrouver bloqué le jour où l'établissement change de format, ou le jour où vous ajoutez un second participant.

Le découpage que nous appliquons sur nos projets tient en cinq blocs : application cliente, API métier, module de paiement isolé derrière une interface stable, connecteur du participant, moteur de réconciliation. La logique métier ne connaît jamais le format du participant, elle ne connaît qu'un contrat interne.

Quatre points méritent une attention particulière, et ce sont ceux qui font échouer les intégrations en production.

• L'idempotence sur la référence de transaction. Une notification peut être rejouée. Votre endpoint doit pouvoir la recevoir cinq fois sans créditer cinq fois la commande.
• L'état intermédiaire. Un paiement instantané n'est pas un paiement synchrone du point de vue de votre application. Entre l'initiation et la confirmation, il existe une fenêtre pendant laquelle la commande n'est ni payée ni annulée. Si votre modèle de données n'a que deux états, vous perdrez des commandes.
• La vérification de signature. Le webhook doit être authentifié avant toute lecture du corps de la requête, jamais après.
• La réconciliation quotidienne. La confirmation en temps réel ne dispense pas du rapprochement. Elle le rend simplement moins douloureux.

Ce que PI-SPI ne fait pas

Un article honnête sur un rail de paiement doit aussi dire où il s'arrête.

• Une seule monnaie. Toutes les transactions se font en franc CFA et aucune autre monnaie n'est supportée. Une application qui vise une clientèle hors zone UEMOA aura toujours besoin d'une passerelle carte internationale à côté.
• Pas de chargeback. Le modèle est celui du virement, pas celui de la carte. Il n'existe pas de mécanisme de rétrofacturation comparable. La gestion des litiges commerciaux reste à votre charge, et votre politique de remboursement doit être conçue en conséquence.
• Une couverture progressive. Le calendrier réglementaire donne une visibilité, il ne garantit pas que le participant de votre client soit opérationnel au jour J. Les institutions de microfinance disposent d'un délai jusqu'en juin 2027.

Le scénario réaliste sur les douze prochains mois est donc la coexistence, avec un basculement progressif du volume vers le rail instantané à mesure que les participants ouvrent le service.

Par où commencer

Une intégration PI-SPI bien menée commence par des décisions non techniques.

1. Identifier votre participant, c'est-à-dire l'établissement qui tient votre compte, et vérifier son état de connexion à la plateforme.
2. Déterminer votre catégorie de client, B, C ou G, et ouvrir le type de compte correspondant à votre volume réel.
3. Enrôler votre entreprise sur le sandbox et récupérer vos identifiants API.
4. Cadrer le parcours d'encaissement selon le contexte d'usage, et non selon la facilité d'implémentation.
5. Concevoir le modèle d'état des transactions avant d'écrire le connecteur.
6. Prévoir la réconciliation dès la première version, pas au premier incident.

FAQ sur l'intégration de PI-SPI

PI-SPI remplace-t-il Wave et Orange Money ?

Non, il les rend interopérables. Un émetteur de monnaie électronique connecté à PI-SPI devient joignable depuis n'importe quel autre participant. Vous n'avez plus besoin d'une intégration par opérateur pour toucher leurs clients respectifs.

Faut-il être une société pour encaisser via PI-SPI ?

Non, mais votre catégorie de client détermine les règles applicables. Un entrepreneur individuel relève du type C, une SARL ou une SA du type B. Encaisser durablement sur un compte de type P n'est pas le bon montage.

Combien de temps prend une intégration PI-SPI ?

Le connecteur technique se développe en quelques jours. Ce qui prend du temps, c'est le cadrage réglementaire, l'ouverture du bon type de compte auprès du participant et la conception du modèle de réconciliation. Comptez trois à six semaines pour une mise en production sérieuse.

Peut-on tester avant que notre banque soit connectée ?

Oui. Le sandbox de la BCEAO fournit un participant, une entreprise et des clients virtuels préconfigurés. Vous pouvez développer et valider l'ensemble des parcours avant l'ouverture effective du service.

Faut-il abandonner nos passerelles actuelles ?

Pas immédiatement. Conservez-les le temps que la couverture des participants se stabilise, et concevez votre module de paiement pour supporter plusieurs connecteurs derrière une interface unique.

PI-SPI fonctionne-t-il pour les paiements transfrontaliers ?

Oui à l'intérieur des huit pays de l'UEMOA, puisque le rail est régional et la monnaie commune. En dehors de cette zone, non.

Conclusion

Pour un encaissement national, une clientèle UEMOA et des volumes réguliers, PI-SPI devient le rail par défaut. Pour une clientèle internationale ou un besoin de chargeback, il faut conserver une passerelle carte en complément.

Le vrai chantier n'est pas l'appel API. C'est le modèle d'état des transactions et la réconciliation. Une équipe qui traite ces deux points correctement intègre PI-SPI sans douleur. Une équipe qui les traite après coup passe six mois à corriger des écarts de caisse.

Chez Absitech, nous concevons et intégrons des modules de paiement dans des applications, du cadrage réglementaire jusqu'à la mise en production et au suivi de la réconciliation. Si vous préparez l'échéance de septembre 2026, parlons-en.