PI-SPI merchant acceptance: what a participant builds after connecting

Where miaPOS stands on PI-SPI

PI-SPI in September 2026

BCEAO launched PI-SPI on 30 September 2025 across the eight WAEMU countries. As of 20 July 2026 the platform counted 30 million connected users and 80 connected institutions, and had processed one million transactions worth 110 billion CFA francs (Ecofin Agency). Reach has come faster than use.

Banks, e-money issuers and payment institutions have until 30 September 2026 to connect; microfinance institutions until 30 June 2027. Connection is the first half. The second half — the one that turns connected accounts into payments at a till — is merchant acceptance, and it runs through the Business API each participant exposes to its business customers.

What a participant builds after connecting

Seen from the participant, merchant acceptance on PI-SPI is six pieces of work. Some are the participant's by definition; others can sit with an acquiring platform.

1. The Business API, homologated. It is the only channel through which a participant may provide automation services to business customers, so every merchant integration — a till, a web shop, a platform — goes through it. A second, proprietary merchant API is not an option under the scheme's rules.
2. Merchant onboarding. A business account, the KYC data, an alias of the payment-address type (the only alias a PI-SPI QR code may carry), and the credentials: OAuth2 client credentials with their scopes, an API key and, in production, an mTLS certificate from the BCEAO certification authority, to which the OAuth token is bound.
3. Scopes cut to the use. BCEAO's guide recommends least privilege and separate credentials per function. Acceptance needs to create requests to pay, read received payments, return funds and manage webhooks; it does not need paiement.write, the scope that sends money out of the merchant's account.
4. The QR code at the point of sale. PI-SPI keeps one format: EMV merchant-presented mode, with a CRC and no personal data. A static code is printed once and leaves each payment to be matched on the merchant's side; a dynamic code is generated for each sale and carries a transaction reference in the Reference Label, which makes reconciliation automatic — down to the till.
5. Notifications and reconciliation. The participant notifies the business customer by webhook — PAIEMENT_RECU when a payment arrives or a request to pay is accepted — over HTTPS, authenticated with the participant's mTLS certificate and signed with HMAC-SHA256 in an X-Signature header. The merchant's system closes the sale on that notification, not on the payer's screen.
6. Returns and cancellation requests. A payment is irrevocable once the payer has confirmed it and PI-SPI has processed it. The beneficiary can return funds; the payer can ask for a cancellation, which the beneficiary accepts — producing a return — or rejects. Somebody has to run this from the till and the back office, with the right to do it limited to the right people.

How the miaPOS adapter is built

Built against the BCEAO Business API sandbox and run end to end there on 1–2 September 2026. What it does:

• One adapter, the same platform. PI-SPI sits behind the same rail interface as the platform's other rails, MIA included. The terminal app, the cashier's loop and the back office are the ones already in service; only the adapter is new.
• Authentication. OAuth2 client credentials and an API key on every call, with the token cached and renewed; mTLS in production (the sandbox runs without it).
• QR. Generated with BCEAO's official QR SDK. Each sale's code carries its own reference, derived from the platform's transaction id and decoded when the notification arrives — no lookup table to drift or to lose.
• Request to pay. Sent to the payer's alias in the merchant-payment category, in whole CFA francs: XOF has no minor unit, and a fractional amount is rejected rather than rounded.
• Notifications. The HMAC signature is checked on every webhook. A notification delivered twice is acknowledged and not applied twice. If processing fails, the adapter answers with an error so that the notification is delivered again.
• Returns. Full amount only, within 90 days, as the Business API allows; partial returns do not exist on this rail. In the sandbox, returns reached the irrevocable status and the merchant's balance reconciled to the franc.
• No outgoing payments. The adapter calls account, alias, webhook, request-to-pay, received-payment and return operations — never the operation that sends a payment.
• What has been exercised. In the sandbox, the cashier's screen. Web checkout, payment links and chat run on the same platform core and the same adapter, but have not yet been run against PI-SPI on their own.

Still to do for production: the participant's production credentials and a BCEAO-issued certificate for each business customer; a production endpoint for notifications; XOF localisation of receipts and reports.

Questions

What does a bank or e-money issuer build for merchant acceptance on PI-SPI?

Six pieces of work on top of the connection: the homologated Business API, the only channel allowed for automation services to business customers; merchant onboarding with an account, KYC, a payment-address alias and credentials; scopes limited to acceptance; the QR code at the point of sale; signed notifications and reconciliation; and the handling of returns of funds and cancellation requests. The last four can sit with an acquiring platform that works on the merchant side of the Business API.

Does a merchant need a card terminal to accept PI-SPI payments?

No. PI-SPI uses an interoperable QR code in EMV merchant-presented mode, valid across all WAEMU participants, and the payer confirms in their own institution's app. The code can be printed (static) or generated for each sale (dynamic); a dynamic code carries a transaction reference that makes reconciliation automatic.

How does the merchant know that a PI-SPI payment has arrived?

From the participant's webhook notification, PAIEMENT_RECU, delivered over HTTPS with mTLS and signed with HMAC-SHA256 in an X-Signature header. The merchant's system verifies the signature and closes the sale on that notification, not on what the payer's phone shows.

Can a PI-SPI payment be refunded?

A payment is irrevocable once the payer has confirmed it and PI-SPI has processed it. The beneficiary can send a return of funds, and the payer can request a cancellation, which the beneficiary accepts or rejects. In the Business API as miaPOS built against it, a return is for the full amount and within 90 days.

Is miaPOS live on PI-SPI?

No. miaPOS has built a PI-SPI adapter against the BCEAO PI-SPI Business API sandbox and run it end to end there, including dynamic QR, request to pay, signed notifications and returns of funds. It is not in production in the WAEMU, and it holds no BCEAO licence, approval or certification; in PI-SPI, homologation applies to the participant's Business API.

What are the PI-SPI connection deadlines?

Banks, e-money issuers and payment institutions must connect by 30 September 2026; microfinance institutions by 30 June 2027, according to BCEAO as reported by Ecofin Agency in July 2026.