Prévisualiser les frais d'un payout
Calcule les frais et le solde résiduel d'un payout sans créer de transaction ni réserver de fonds. Mêmes gardes d'autorisation que `POST /v1/pay-out` : `PAYOUT_INITIATE` est exigé quel que soit l'appelant ; un jeton de session doit en plus avoir vérifié sa 2FA, hors de portée d'une clé d'API.
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-out/preview?phoneNumber=string¤cyCode=string&amount=1"{ "success": true, "data": { "feeProvider": 0, "feeAz54": 0, "feeTotal": 0, "amountDebited": 0, "balanceBefore": 0, "balanceAfter": 0, "insufficient": true, "walletProvisioned": true }}Envoyer un paiement mobile money POST
Deux issues selon la portée de qui appelle, clé d'API ou jeton de session : avec `PAYOUT_APPROVE` en plus de `PAYOUT_INITIATE`, le payout s'exécute directement (`200`) ; sans `PAYOUT_APPROVE`, l'appel dépose un **brouillon** `pending_approval` (`201`), à valider par un tiers habilité depuis le tableau de bord avant dispatch — une clé d'API sans `PAYOUT_APPROVE` produit donc aussi ce brouillon, au même titre qu'un rôle `accountant`. Sur Sandbox, l'issue suit le même catalogue de numéros que le pay-in (cf. [numéros de test](/docs/numeros-de-test)).
Connaître le plafond de pay-out de votre compte GET
Plus gros pay-out que `POST /v1/pay-out` accepterait maintenant dans une devise, et la règle qui le fixe. Lecture indicative : le plafond est vérifié de nouveau à la création du pay-out, et un autre pay-out peut le consommer entre les deux appels. Mêmes gardes d'autorisation que `GET /v1/pay-out/preview` : `PAYOUT_INITIATE` est exigé quel que soit l'appelant.