Consulter le reçu public d'une transaction
Reçu destiné au payeur, adressable par `orderId` seul, sans authentification. Plafonné à 5 requêtes/min par `orderId` **et** 20/min par IP dans un seau partagé entre tous les marchands : ce n'est pas un endpoint de polling serveur. Il ne porte ni cause d'échec, ni frais.
/v1/transactions/{orderId}Path Parameters
orderId fourni à la création de la transaction.
^[A-Za-z0-9_-]+$1 <= length <= 100Response Body
application/json
application/json
application/json
application/json
curl -X GET "https://example.com/v1/transactions/string"{ "success": true, "data": { "orderId": "string", "amount": 0, "currency": "string", "phoneNumber": "string", "operatorCode": "string", "operatorName": "string", "status": "string", "type": "string", "createdAt": "2019-08-24T14:15:22Z", "completedAt": "2019-08-24T14:15:22Z", "description": "string", "email": "string", "merchantName": "string" }}Envoyer un paiement mobile money POST
Deux issues selon qui appelle. Une clé d'API **exécute toujours directement** le payout (`200`) : elle contourne le circuit d'approbation interne à l'organisation, au même titre qu'elle contourne le RBAC. Un jeton de session sans la permission d'approbation crée un **brouillon** `pending_approval` (`201`), qui devra être validé depuis le tableau de bord — cas hors du périmètre d'une intégration serveur.
Créer un secret de signature POST
Sans secret **actif**, aucune notification n'est émise — le pay-in réussit et vous n'en saurez rien. Le secret n'est affiché qu'à cette réponse. Créer un secret n'invalide pas les précédents ; la révocation se fait depuis le tableau de bord et n'est pas exposée par clé d'API.