Schémas de paiement · PI-SPI (BCEAO)

Acceptation marchande sur PI-SPI : ce que le participant construit après le raccordement

Le raccordement à PI-SPI donne à une banque ou à un émetteur de monnaie électronique l'accès au rail. L'acceptation chez le commerçant — le QR en caisse, la demande de paiement, la notification qui clôt la vente, le retour de fonds — se construit par-dessus, à travers l'API Business que le participant expose à ses clients entreprises. Cette page décrit cette couche du point de vue du participant, pas de celui du commerçant ni du développeur.

Nous écrire Pour les banques

Où en est miaPOS sur PI-SPI

miaPOS a développé un connecteur PI-SPI sur le sandbox de l'API Business PI-SPI de la BCEAO et l'y a fait fonctionner de bout en bout : QR dynamique, demande de paiement, notifications signées, retours de fonds intégraux, et l'écran du caissier qui passe à « payé ». Il n'est pas en production dans l'UEMOA. miaPOS ne détient aucune licence, autorisation ni certification de la BCEAO — dans PI-SPI, l'homologation porte sur l'API Business du participant — et la banque ou l'émetteur conserve l'agrément, la participation au système et la relation avec le commerçant.

PI-SPI en septembre 2026

La BCEAO a lancé PI-SPI le 30 septembre 2025 dans les huit pays de l'UEMOA. Au 20 juillet 2026, la plateforme comptait 30 millions d'utilisateurs connectés et 80 institutions raccordées, pour un million de transactions d'un montant de 110 milliards de francs CFA (Ecofin Agency). La portée a progressé plus vite que l'usage.

Les banques, les émetteurs de monnaie électronique et les établissements de paiement ont jusqu'au 30 septembre 2026 pour se raccorder ; les institutions de microfinance, jusqu'au 30 juin 2027. Le raccordement n'est que la première moitié. La seconde — celle qui transforme des comptes connectés en paiements en caisse — c'est l'acceptation marchande, et elle passe par l'API Business que chaque participant expose à ses clients entreprises.

Les rôles, tels que le système les définit

La BCEAO opère PI-SPI, le hub : chaque participant s'y raccorde une seule fois et peut ensuite échanger avec tous les autres — banques, institutions de microfinance, émetteurs de monnaie électronique, établissements de paiement.
Le participant — votre établissement — tient le compte, les diligences KYC et l'alias. Le système l'oblige à proposer une application mobile à ses clients personnes physiques et, dès qu'il offre des services d'automatisation à ses clients entreprises, à le faire par l'API Business standardisée : aucun autre canal n'est autorisé.
Le client business — le commerçant. Tout envoi reçu par un client business est un paiement. En production, il lui faut un compte chez un participant dont l'API Business a été homologuée par la BCEAO.
Le payeur confirme dans l'application de son propre établissement et valide l'identité du bénéficiaire avant l'exécution. Il n'y a pas de prélèvement : un paiement à l'initiative du bénéficiaire n'existe que sous forme de demande de paiement, que le payeur accepte ou rejette.
La plateforme d'acceptation — un logiciel côté commerçant de l'API Business : elle génère le QR ou la demande de paiement, reçoit la notification du participant, la rapproche de la vente et fait tourner le back-office du commerçant. Ce n'est pas un participant et elle ne détient pas de fonds : l'argent va du compte du payeur au compte du commerçant chez le participant.

Le vocabulaire de la catégorie, côté marchand du paiement de compte à compte : A2A acquiring (en anglais).

Ce que le participant construit après le raccordement

Vue du participant, l'acceptation marchande sur PI-SPI représente six chantiers. Certains lui reviennent par définition ; d'autres peuvent être portés par une plateforme d'acceptation.

L'API Business, homologuée. C'est le seul canal par lequel un participant peut fournir des services d'automatisation à ses clients entreprises : toute intégration marchande — une caisse, une boutique en ligne, une plateforme — passe par elle. Une seconde API marchande propriétaire n'est pas une option au regard des règles du système.
L'enrôlement du commerçant. Un compte business, les données KYC, un alias de type adresse de paiement (le seul alias qu'un QR PI-SPI puisse porter) et les accès : identifiants OAuth2 avec leurs scopes, une clé API et, en production, un certificat mTLS délivré par l'autorité de certification de la BCEAO, auquel le jeton OAuth est lié.
Des scopes taillés pour l'usage. Le guide de la BCEAO recommande le moindre privilège et des identifiants séparés par fonction. L'acceptation a besoin de créer des demandes de paiement, de consulter les paiements reçus, d'effectuer des retours de fonds et de gérer les webhooks ; elle n'a pas besoin de paiement.write, le scope qui fait sortir de l'argent du compte du commerçant.
Le QR au point de vente. PI-SPI retient un seul format : le mode EMV présenté par le marchand, avec un CRC et sans aucune donnée personnelle. Un QR statique s'imprime une fois et impose de rapprocher chaque paiement côté commerçant ; un QR dynamique est généré pour chaque vente et porte une référence de transaction dans le Reference Label, ce qui rend le rapprochement automatique — y compris caisse par caisse.
Notifications et rapprochement. Le participant notifie le client business par webhook — PAIEMENT_RECU quand un paiement arrive ou qu'une demande de paiement est acceptée — en HTTPS, authentifié par le certificat mTLS du participant et signé en HMAC-SHA256 dans l'en-tête X-Signature. Le système du commerçant clôt la vente sur cette notification, pas sur l'écran du payeur.
Retours de fonds et demandes d'annulation. Un paiement est irrévocable dès qu'il a été confirmé par le payeur et traité par PI-SPI. Le bénéficiaire peut effectuer un retour de fonds ; le payeur peut demander une annulation, que le bénéficiaire accepte — ce qui produit un retour — ou rejette. Quelqu'un doit piloter cela depuis la caisse et le back-office, avec un droit réservé aux bonnes personnes.

Qui fait quoi

La frontière entre le participant et une plateforme d'acceptation, chantier par chantier.

Chantier	Participant (banque, EME)	Plateforme d'acceptation (miaPOS)
Agrément, participation, relation commerçant	Le participant	Aucun rôle réglementaire ; le logiciel s'inscrit dans le dispositif du participant
Compte business, KYC, alias	Les crée	Utilise l'alias créé par le participant
API Business et accès	Expose l'API homologuée, délivre les identifiants et les scopes	Appelle l'API avec les accès du commerçant, conservés hors du code
QR en caisse	—	Génère un QR dynamique par vente avec le SDK officiel de la BCEAO
Demande de paiement	La transmet via PI-SPI au payeur	La crée depuis l'écran du caissier
Notification	Envoie le webhook signé	Vérifie la signature, écarte les doublons, rapproche le paiement de la vente et de la caisse
Retour de fonds	L'exécute sur le rail	Le déclenche (montant intégral) et l'inscrit sur la vente

Le modèle de sécurité de miaPOS — qui autorise un paiement, ce que nous vérifions et ce que vérifie la banque, quelles données nous conservons : security model (en anglais).

Comment le connecteur miaPOS est construit

Développé sur le sandbox de l'API Business de la BCEAO et exécuté de bout en bout les 1er et 2 septembre 2026. Ce qu'il fait :

Un connecteur, la même plateforme. PI-SPI se branche derrière la même interface de rail que les autres rails de la plateforme, dont MIA. L'application terminal, la boucle du caissier et le back-office sont ceux déjà en service ; seul le connecteur est nouveau.
Authentification. Identifiants client OAuth2 et clé API à chaque appel, avec un jeton mis en cache et renouvelé ; mTLS en production (le sandbox fonctionne sans).
QR. Généré avec le SDK QR officiel de la BCEAO. Le QR de chaque vente porte sa propre référence, dérivée de l'identifiant de transaction de la plateforme et décodée à l'arrivée de la notification — pas de table de correspondance qui puisse diverger ou se perdre.
Demande de paiement. Envoyée à l'alias du payeur dans la catégorie paiement marchand, en francs CFA entiers : le XOF n'a pas de subdivision, et un montant fractionnaire est refusé plutôt qu'arrondi.
Notifications. La signature HMAC est vérifiée sur chaque webhook. Une notification reçue deux fois est acquittée sans être appliquée deux fois. Si le traitement échoue, le connecteur répond par une erreur afin que la notification soit renvoyée.
Retours de fonds. Montant intégral uniquement, sous 90 jours, comme le permet l'API Business ; le retour partiel n'existe pas sur ce rail. Dans le sandbox, les retours ont atteint le statut irrévocable et le solde du commerçant s'est rapproché au franc près.
Aucun paiement sortant. Le connecteur appelle les opérations de compte, d'alias, de webhook, de demande de paiement, de paiement reçu et de retour — jamais l'opération qui envoie un paiement.
Ce qui a été éprouvé. Dans le sandbox, l'écran du caissier. Le paiement en ligne, les liens de paiement et la messagerie reposent sur le même cœur de plateforme et le même connecteur, mais n'ont pas encore été exécutés sur PI-SPI en tant que tels.

Reste à faire pour la production : les accès de production et le certificat délivré par la BCEAO pour chaque client business, via le participant ; un point de réception des notifications de production ; la localisation en XOF des reçus et des rapports.

Une séquence réaliste

Aucune durée n'est annoncée ici : les étapes longues relèvent du participant — homologation, délivrance des accès, contrats commerçants — et varient d'un établissement à l'autre. L'ordre, lui, ne varie pas.

Raccordement et homologation. Le participant est raccordé à PI-SPI et son API Business est homologuée. L'échéance du 30 septembre 2026 porte sur le raccordement.
Sandbox. Le parcours d'acceptation est éprouvé sur le sandbox de la BCEAO avant qu'aucun accès de production n'existe. Pour miaPOS, cette étape est faite.
Scopes et rôles par écrit. Quels scopes porte un jeton d'acceptation, qui signe le contrat commerçant, qui opère les retours et les demandes d'annulation, qui répond au commerçant.
Premiers commerçants. Pour chacun : un compte business, un alias adresse de paiement, des accès et un certificat de production, un point de réception des notifications. Puis quelques caisses en QR dynamique, rapprochées chaque jour avec les écritures du participant.
Routine. L'enrôlement devient une procédure plutôt qu'un projet, et une seule intégration à l'API Business par commerçant sert tous les canaux par lesquels il encaisse.

Questions fréquentes

Que doit construire une banque ou un EME pour l'acceptation marchande sur PI-SPI ?

Six chantiers au-dessus du raccordement : l'API Business homologuée, seul canal autorisé pour les services d'automatisation aux clients entreprises ; l'enrôlement du commerçant avec compte, KYC, alias adresse de paiement et accès ; des scopes limités à l'acceptation ; le QR au point de vente ; les notifications signées et le rapprochement ; la gestion des retours de fonds et des demandes d'annulation. Les quatre derniers peuvent être portés par une plateforme d'acceptation qui travaille côté commerçant de l'API Business.

Le commerçant a-t-il besoin d'un terminal de paiement par carte pour accepter PI-SPI ?

Non. PI-SPI utilise un QR interopérable en mode EMV présenté par le marchand, valable pour tous les participants de l'UEMOA, et le payeur confirme dans l'application de son propre établissement. Le QR peut être imprimé (statique) ou généré pour chaque vente (dynamique) ; un QR dynamique porte une référence de transaction qui rend le rapprochement automatique.

Comment le commerçant sait-il qu'un paiement PI-SPI est arrivé ?

Par la notification webhook du participant, PAIEMENT_RECU, transmise en HTTPS avec mTLS et signée en HMAC-SHA256 dans l'en-tête X-Signature. Le système du commerçant vérifie la signature et clôt la vente sur cette notification, pas sur ce qu'affiche le téléphone du payeur.

Un paiement PI-SPI peut-il être remboursé ?

Un paiement est irrévocable dès que le payeur l'a confirmé et que PI-SPI l'a traité. Le bénéficiaire peut effectuer un retour de fonds, et le payeur peut demander une annulation, que le bénéficiaire accepte ou rejette. Dans l'API Business telle que miaPOS l'a intégrée, un retour porte sur le montant intégral et intervient sous 90 jours.

miaPOS est-il en production sur PI-SPI ?

Non. miaPOS a développé un connecteur PI-SPI sur le sandbox de l'API Business PI-SPI de la BCEAO et l'y a fait fonctionner de bout en bout, y compris QR dynamique, demande de paiement, notifications signées et retours de fonds. Il n'est pas en production dans l'UEMOA et ne détient aucune licence, autorisation ni certification de la BCEAO ; dans PI-SPI, l'homologation porte sur l'API Business du participant.

Quelles sont les échéances de raccordement à PI-SPI ?

Les banques, les émetteurs de monnaie électronique et les établissements de paiement doivent être raccordés au 30 septembre 2026 ; les institutions de microfinance, au 30 juin 2027, selon la BCEAO citée par Ecofin Agency en juillet 2026.

Sources

Les mécanismes du système sont repris des guides publics de la BCEAO ; les chiffres de marché, d'Ecofin Agency.