On a payout (money going out to a customer wallet or a mobile money account), LigdiCash sends two POST requests to yourDocumentation 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 — one in application/json, one in application/x-www-form-urlencoded. Both contain the same data. This page details the JSON structure and the differences with the payin payload.
Full example
Main fields
Result code.
"00" = success. Any other value indicates an error.Payout status:
"completed", "pending", or "notcompleted". Base your business logic on this field — see Response codes and statuses.JWT token linked to this payout callback. Do not rely on it to identify the transaction — use the token stored at payout creation to call Verify the status.
Payout amount in XOF, encoded as a string (e.g.
"100").Same as
amount. Both fields coexist in all LigdiCash responses.Root identifier of the payout. Equal to the
external_id you provided at creation — use it to match the callback with your business transaction.Identifier provided by the merchant when creating the payout. Reflects the value you passed in the body of the
/withdrawal/create or /straight/payout request.Numeric identifier of the recipient operator (e.g.
12 for Moov Africa Burkina).Recipient operator name (e.g.
"MOOV AFRICA BURKINA"). For a payout to a LigdiCash wallet, this field is prefixed with "LigdiCash " (e.g. "LigdiCash ORANGE BURKINA").URL of your
callback_url receiving this payload. LigdiCash writes the destination URL here — useful for diagnostics.HTTP method used to deliver the callback. Usually empty.
Textual label of the result. Empty on success.
Custom data for the payout. Often empty (
[]) — see the next section. If populated, follows the same structure as in the payin: array of { keyof_customdata, valueof_customdata, datecreation_customdata } objects.The custom_data field in payout
Unlike payin, thecustom_data of a payout is often empty ([]). You should therefore not rely on it to match the callback with your business transaction — use transaction_id or external_id at the root of the payload.
If you provided a
custom_data when creating the payout, it will be returned as an array populated with { keyof_customdata, valueof_customdata, datecreation_customdata } objects, exactly like in the payin. See Parse custom_data.Differences with the payin payload
| Field | Payin | Payout |
|---|---|---|
token | Always empty ("") | Filled (payout JWT) |
amount / montant | Integer (4200) | String ("100") |
operator_id | String ("11") | Integer (12) |
customer | Payer’s number | Absent |
customer_details | Filled (firstname, lastname, email, phone) | Absent |
custom_data | Populated array (your fields + LigdiCash) | Often empty ([]) |
Root transaction_id | Concatenation of valueof_customdata | Equal to external_id |
date, wiki, request_id, oreference, description | Present | Absent |
url, url_method | Absent | Present |
Possible statuses
status | Meaning | Recommended action |
|---|---|---|
completed | Payout finalized successfully | Confirm on the business side, notify the user |
pending | Processing in progress | Wait, expect a new callback, or query confirm |
notcompleted | Payout failed | Consult the confirm response for details, notify the requester |
Related pages
- Payin payload — full anatomy of the payin payload
- Parse custom_data — handle the array when it is populated
- Securing the callback — re-verification with
confirm - Verify the payout status — re-verification endpoint
