Skip to main content
On a payout (money going out to a customer wallet or a mobile money account), LigdiCash sends two POST requests to your 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

​
string
Result code. "00" = success. Any other value indicates an error.
​
string
Payout status: "completed", "pending", or "notcompleted". Base your business logic on this field — see Response codes and statuses.
​
string
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.
​
string
Payout amount in XOF, encoded as a string (e.g. "100").
​
string
Same as amount. Both fields coexist in all LigdiCash responses.
​
string
Root identifier of the payout. Equal to the external_id you provided at creation — use it to match the callback with your business transaction.
​
string
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.
​
integer
Numeric identifier of the recipient operator (e.g. 12 for Moov Africa Burkina).
​
string
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").
​
string
URL of your callback_url receiving this payload. LigdiCash writes the destination URL here — useful for diagnostics.
​
string
HTTP method used to deliver the callback. Usually empty.
​
string
Textual label of the result. Empty on success.
​
array
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, the custom_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

The format of the amount, montant, and operator_id fields differs between payin and payout. If you parse the payload with a typed schema, plan for these differences or cast the values server-side.

​
Possible statuses