Prévisualiser les frais d'un pay-in
Calcule les frais et le workflow d'un pay-in sans créer de transaction. Mêmes gardes d'autorisation que `POST /v1/pay-in` ; aucun `otp`/`redirectUrls` n'est requis ici, `workflowType` indique s'ils le seront sur l'appel réel. Sur un canal à plusieurs PSP, un numéro jamais vu peut se voir assigner durablement un couple de providers dès cet appel (dispatch MSISDN sticky) — un pay-in réel sur ce numéro produirait de toute façon la même affectation.
Clé d'API de l'organisation, envoyée en Authorization: Bearer sk_live_… (sk_test_… sur le serveur Sandbox). Il n'existe aucun header X-API-Key.
In: header
Query Parameters
1 <= length1 <= length0 < valueResponse Body
application/json
application/json
application/json
application/json
application/json
application/json
curl -X GET "https://example.com/v1/pay-in/preview?phoneNumber=string¤cyCode=string&amount=1"{ "success": true, "data": { "feeProvider": 0, "feeAz54": 0, "feeTotal": 0, "amountCredited": 0, "workflowType": "provider_auth" }}Encaisser un paiement mobile money POST
Sur le serveur Production, déclenche une sollicitation réelle (push, USSD ou SMS) vers le numéro du payeur ; sur Sandbox, l'issue est pilotée par les deux derniers chiffres du numéro (cf. [numéros de test](/docs/numeros-de-test)). La réponse `200` signifie « demande acceptée », jamais « payé » : l'issue est poussée par le webhook sortant, et se relit sur `GET /v1/transactions/by-id/{transactionId}` avec l'`id` renvoyé ici — cf. [réconciliation](/docs/reconciliation).
Consulter le reçu public d'une transaction GET
Reçu destiné au payeur, adressable par `orderId` seul, sans authentification. Plafonné à 10 requêtes/min par `orderId` **et** 20/min par IP, sous un plafond global commun à tous les appelants : ce n'est pas un endpoint de polling serveur. Il ne porte ni cause d'échec, ni frais.