az54
Ouvrir le tableau de bord
API docsAPI Reference
V1Pay inPreview

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.

GET/v1/pay-in/preview

Authorization

AuthorizationBearer <token>

Clé d'API de l'organisation, envoyée en Authorization: Bearer sk_live_…. Il n'existe aucun header X-API-Key.

In: header

Query Parameters

phoneNumber*string
Length1 <= length
currencyCode*string
Length1 <= length
amount*number
Range0 < value
operatorCode?string

Response 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&currencyCode=string&amount=1"
{  "success": true,  "data": {    "feeProvider": 0,    "feeAz54": 0,    "feeTotal": 0,    "amountCredited": 0,    "workflowType": "provider_auth"  }}

Encaisser un paiement mobile money POST

Déclenche une sollicitation réelle (push, USSD ou SMS) vers le numéro du payeur. Il n'existe pas d'environnement de test. La réponse `200` signifie « demande acceptée », jamais « payé » : l'issue est livrée par le webhook sortant.

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.