Callbacks PI, interfaces internes et simulateurs

Messages entrants de PI

Les routes comme /transferts, /transferts/rapports, /verifications-identites et /notifications sont exposées par participant-api pour recevoir des messages de PI. Elles figurent donc dans cette référence, dans la rubrique Callbacks PI.

Leur chemin peut ressembler à celui d’une API distante de PI ; le sens est ici PI vers notre participant. Le corps reçu est un message XML signé. Le canal mTLS et la destination du message déterminent et contrôlent le contexte participant. L’Inbox permet de traiter les réceptions répétées sans reproduire un effet métier.

Le serveur utilisé pour les appels métier et celui des callbacks ne sont pas nécessairement identiques : l’adresse et le port mTLS sont fournis par le déploiement. N’envoyez pas un callback à l’adresse HTTP métier en pensant tester un transfert sortant.

Pour initier un transfert, utilisez les routes JSON /api/v1/{participantCode}/… présentées dans le guide transferts. Le cœur prépare, signe et envoie les messages sortants.

Liaison interne Business

Les routes Interne Business sont celles que l’application business-api appelle sur le cœur. Elles ne constituent pas le contrat public de l’API Business et ne doivent pas être appelées en remplaçant simplement le préfixe /piz/v1 par celui du cœur.

Simulation et recette

Les simulateurs dépendent de l’assemblage et de l’environnement. Une route de simulation disponible dans une pile locale n’est pas une route bancaire de production. Le portail ne démarre ni le simulateur PI ni le CBS simulé.

Les parcours Postman distinguent A — Simulateur PI, B — Cœur et C — API Business. Pour tester le cœur, commencez par B et choisissez l’environnement Local ou Sandbox adapté au scénario. Les résultats d’un simulateur ne constituent pas une homologation BCEAO.