Reçu public

GET /v1/transactions/{orderId} renvoie un reçu destiné au payeur, sans authentification. C'est de quoi afficher une page de confirmation, pas de quoi piloter une intégration.

Ce n'est pas une stratégie de production

Deux plafonds s'appliquent, cumulativement :

• 5 requêtes par minute par orderId ;
• 20 requêtes par minute par IP, dans un seau partagé entre tous les marchands.

Le second est le point bloquant : votre trafic de polling entre en concurrence avec celui de tout le monde. Ce n'est pas un réglage à négocier, c'est une défense contre l'énumération des orderId — sans elle, l'endpoint étant adressable par orderId seul, un tiers pourrait balayer les identifiants d'autrui.

Avec une clé d'API, la seule source d'issue est le webhook sortant.

Les données sont partielles et masquées

• phoneNumber est masqué : +225***0707.
• email est masqué, et absent si le payeur n'en a pas fourni.
• Le reçu ne porte ni la cause de l'échec, ni les frais.

description est en revanche renvoyé en entier : il est destiné à être lu par le payeur sur son reçu. N'y mettez rien que le porteur de l'orderId ne devrait pas voir.

Le 404 sur orderId ambigu est volontaire

Un orderId est unique par organisation, pas globalement. Deux marchands peuvent donc porter le même. Quand c'est le cas, cet endpoint — qui n'a qu'un orderId en main et aucune organisation à laquelle se rattacher — répond 404 NOT_FOUND plutôt que de choisir.

Ce n'est ni un bug, ni un état transitoire : servir un premier match exposerait les données d'une organisation à un tiers. Le comportement ne changera pas.

C'est aussi la raison de choisir un orderId non devinable : voir Idempotence.