Anatomie du payload — Payout

Détail du payload reçu lors d’un callback payout : structure, champs et différences avec le payload payin.

Lors d’un payout (sortie d’argent vers un wallet client ou un compte mobile money), LigdiCash envoie deux requêtes POST à votre 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

{
  "response_code": "00",
  "token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpZF9maW5hbmNlIjoiMTIzNTU4NDgxIiwic3RhcnRfZGF0ZSI6IjIwMjYtMDUtMTEgMTY6Mjc6MzUrMDAiLCJleHBpcnlfZGF0ZSI6MTc3ODYwMzI1NX0.FTaklFJy5DmovqVuwQz6avjNpJuzoh-XehziELBrh84",
  "response_text": "",
  "status": "completed",
  "custom_data": [],
  "operator_id": 12,
  "operator_name": "MOOV AFRICA BURKINA",
  "url": "https://monapp.com/api/callback/ligdicash",
  "url_method": "",
  "transaction_id": "502d36d2086249118198d06780b1c9fd",
  "external_id": "502d36d2086249118198d06780b1c9fd",
  "montant": "100",
  "amount": "100"
}

​

Champs principaux

response_code · string

Code de résultat. "00" = succès. Toute autre valeur indique une erreur.

status · string

Statut du payout : "completed", "pending" ou "notcompleted". Basez votre logique métier sur ce champ — voir Codes de réponse et statuts.

token · string

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.

amount · string

Montant du payout en XOF, encodé en chaîne de caractères (ex : "100").

montant · string

Identique à amount. Les deux champs coexistent dans toutes les réponses LigdiCash.

transaction_id · string

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.

external_id · string

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.

operator_id · integer

Identifiant numérique de l’opérateur destinataire du payout (ex : 12 pour Moov Africa Burkina).

operator_name · string

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 · string

URL de votre callback_url qui reçoit ce payload. LigdiCash y inscrit l’URL de destination — utile pour les diagnostics.

url_method · string

Méthode HTTP utilisée pour la livraison du callback. Généralement vide.

response_text · string

Libellé textuel du résultat. Vide en cas de succès.

custom_data · array

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, le custom_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

Le format des champs amount, montant et operator_id diffère entre payin et payout. Si vous parsez le payload avec un schéma typé, prévoyez ces différences ou caster les valeurs côté serveur.

​

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