Skip to main content

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.

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

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

Main fields

response_code
string
Result code. "00" = success. Any other value indicates an error.
status
string
Payout status: "completed", "pending", or "notcompleted". Base your business logic on this field — see Response codes and statuses.
token
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.
amount
string
Payout amount in XOF, encoded as a string (e.g. "100").
montant
string
Same as amount. Both fields coexist in all LigdiCash responses.
transaction_id
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.
external_id
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.
operator_id
integer
Numeric identifier of the recipient operator (e.g. 12 for Moov Africa Burkina).
operator_name
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").
url
string
URL of your callback_url receiving this payload. LigdiCash writes the destination URL here — useful for diagnostics.
url_method
string
HTTP method used to deliver the callback. Usually empty.
response_text
string
Textual label of the result. Empty on success.
custom_data
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

FieldPayinPayout
tokenAlways empty ("")Filled (payout JWT)
amount / montantInteger (4200)String ("100")
operator_idString ("11")Integer (12)
customerPayer’s numberAbsent
customer_detailsFilled (firstname, lastname, email, phone)Absent
custom_dataPopulated array (your fields + LigdiCash)Often empty ([])
Root transaction_idConcatenation of valueof_customdataEqual to external_id
date, wiki, request_id, oreference, descriptionPresentAbsent
url, url_methodAbsentPresent
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

statusMeaningRecommended action
completedPayout finalized successfullyConfirm on the business side, notify the user
pendingProcessing in progressWait, expect a new callback, or query confirm
notcompletedPayout failedConsult the confirm response for details, notify the requester