Lors d’un payout (sortie d’argent vers un wallet client ou un compte mobile money), LigdiCash envoie deux requêtes POST à votreDocumentation Index
Fetch the complete documentation index at: https://developers.ligdicash.com/llms.txt
Use this file to discover all available pages before exploring further.
callback_url — une en application/json, une en application/x-www-form-urlencoded. Les deux contiennent les mêmes données. Cette page détaille la structure JSON et les différences avec le payload payin.
Exemple complet
Champs principaux
Code de résultat.
"00" = succès. Toute autre valeur indique une erreur.Statut du payout :
"completed", "pending" ou "notcompleted". Basez votre logique métier sur ce champ — voir Codes de réponse et statuts.Jeton JWT lié à ce callback payout. Ne vous y fiez pas pour identifier la transaction — utilisez le token stocké à la création du payout pour appeler Vérifier le statut.
Montant du payout en XOF, encodé en chaîne de caractères (ex :
"100").Identique à
amount. Les deux champs coexistent dans toutes les réponses LigdiCash.Identifiant racine du payout. Égal à l’
external_id que vous avez fourni à la création — utilisez-le pour rapprocher le callback de votre transaction métier.Identifiant fourni par le marchand à la création du payout. Reflète la valeur que vous avez passée dans le corps de la requête
/withdrawal/create ou /straight/payout.Identifiant numérique de l’opérateur destinataire du payout (ex :
12 pour Moov Africa Burkina).Nom de l’opérateur destinataire (ex :
"MOOV AFRICA BURKINA"). Pour un payout vers wallet LigdiCash, ce champ est préfixé par "LigdiCash " (ex : "LigdiCash ORANGE BURKINA").URL de votre
callback_url qui reçoit ce payload. LigdiCash y inscrit l’URL de destination — utile pour les diagnostics.Méthode HTTP utilisée pour la livraison du callback. Généralement vide.
Libellé textuel du résultat. Vide en cas de succès.
Données personnalisées du payout. Souvent vide (
[]) — voir la section suivante. Si peuplé, suit la même structure que dans le payin : tableau d’objets { keyof_customdata, valueof_customdata, datecreation_customdata }.Le champ custom_data en payout
Contrairement au payin, lecustom_data du payout est souvent vide ([]). Vous ne devez donc pas vous appuyer dessus pour rapprocher le callback de votre transaction métier — utilisez transaction_id ou external_id à la racine du payload.
Si vous avez fourni un
custom_data à la création du payout, il sera renvoyé sous la forme d’un tableau peuplé d’objets { keyof_customdata, valueof_customdata, datecreation_customdata }, exactement comme pour le payin. Voir Parser custom_data.Différences avec le payload payin
| Champ | Payin | Payout |
|---|---|---|
token | Toujours vide ("") | Rempli (JWT du payout) |
amount / montant | Entier (4200) | Chaîne ("100") |
operator_id | Chaîne ("11") | Entier (12) |
customer | Numéro du payeur | Absent |
customer_details | Renseigné (firstname, lastname, email, phone) | Absent |
custom_data | Tableau peuplé (vos champs + LigdiCash) | Souvent vide ([]) |
transaction_id à la racine | Concaténation des valueof_customdata | Égal à external_id |
date, wiki, request_id, oreference, description | Présents | Absents |
url, url_method | Absents | Présents |
Statuts possibles
status | Signification | Action recommandée |
|---|---|---|
completed | Payout finalisé avec succès | Confirmer côté métier, notifier l’utilisateur |
pending | Traitement en cours | Patienter, attendre un nouveau callback ou interroger confirm |
notcompleted | Payout échoué | Consulter la réponse confirm pour le détail, notifier le demandeur |
Pages associées
- Payload Payin — anatomie complète du payload payin
- Parser custom_data — gérer le tableau quand il est peuplé
- Sécurisation du callback — re-vérification avec
confirm - Vérifier le statut payout — endpoint de re-vérification
