Passer au contenu principal

Documentation Index

Fetch the complete documentation index at: https://developers.ligdicash.com/llms.txt

Use this file to discover all available pages before exploring further.

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

ChampPayinPayout
tokenToujours vide ("")Rempli (JWT du payout)
amount / montantEntier (4200)Chaîne ("100")
operator_idChaîne ("11")Entier (12)
customerNuméro du payeurAbsent
customer_detailsRenseigné (firstname, lastname, email, phone)Absent
custom_dataTableau peuplé (vos champs + LigdiCash)Souvent vide ([])
transaction_id à la racineConcaténation des valueof_customdataÉgal à external_id
date, wiki, request_id, oreference, descriptionPrésentsAbsents
url, url_methodAbsentsPré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

statusSignificationAction recommandée
completedPayout finalisé avec succèsConfirmer côté métier, notifier l’utilisateur
pendingTraitement en coursPatienter, attendre un nouveau callback ou interroger confirm
notcompletedPayout échouéConsulter la réponse confirm pour le détail, notifier le demandeur

Pages associées