Every LigdiCash API response — whether success or failure — contains a wiki field with a URL pointing to the sub-codes documentation for the endpoint you called. This field is your main entry point to understand the exact cause of a response_code: "01".
Wiki URLs by endpoint
| Endpoint | Wiki URL |
|---|
POST /pay/v01/redirect/checkout-invoice/create | https://client.ligdicash.com/wiki/createInvoice |
GET /pay/v01/redirect/checkout-invoice/confirm | https://client.ligdicash.com/wiki/confirmInvoice |
POST /pay/v01/straight/checkout-invoice/create | https://client.ligdicash.com/wiki/createInvoice |
POST /pay/v01/withdrawal/create | https://client.ligdicash.com/wiki/createWithdrawal |
POST /pay/v01/straight/payout | https://client.ligdicash.com/wiki/createStraightWithdrawal |
POST /pay/v01/withdrawal/confirm | https://client.ligdicash.com/wiki/confirmInvoice |
The wiki URL is always returned in the response, even on success. You don’t need to hardcode it in your application — read it directly from the wiki field of the response.
Wiki page format
The wiki page returns a data structure in PHP var_dump format listing all possible sub-codes for that endpoint:
array:2 [▼
0 => array:2 [▶]
1 => array:3 [▼
"code" => "01"
"description" => "There is an error"
"subcodes" => array:N [▼
0 => array:2 [▼
"code" => "Echec (Code00)"
"description" => "Authentification failure"
]
1 => array:2 [▼
"code" => "Echec (Code01)"
"description" => "Merchant Payout not activated"
]
...
]
]
]
Each entry in subcodes corresponds to a possible value of response_text and its English description.
Backend usage pattern
The recommended approach is to fetch the wiki page only when response_code === "01", to enrich your logs and build a message suited to your end user.
async function handleLigdicashError(data) {
if (data.response_code !== "01") return;
// Fetch the wiki page to decode the sub-code
let wikiDescription = data.response_text; // fallback
try {
const wikiRes = await fetch(data.wiki);
const wikiText = await wikiRes.text();
// Extract the sub-code description (parse as needed)
// Example: find the line containing data.response_text
wikiDescription = parseWikiDescription(wikiText, data.response_text);
} catch (e) {
// The wiki is optional — don't block if unavailable
}
logger.error({
event: "ligdicash_error",
subcode: data.response_text, // e.g. "Echec (Code00)"
description: wikiDescription, // e.g. "Authentification failure"
wiki_url: data.wiki,
});
return {
userMessage: buildUserMessage(data.response_text),
technicalCode: data.response_text,
};
}
Building user-facing messages
The response_text (Echec (CodeXX)) is a technical code and must never be shown directly to the end user. Build a mapping in your application:
const USER_MESSAGES = {
"Echec (Code00)": "Your API credentials are invalid. Check your Apikey and authorization token.",
"Echec (Code01)": "This operation is not enabled on your account. Contact LigdiCash support.",
// Add other sub-codes following the /en/errors/sub-codes page
};
function buildUserMessage(subcode) {
return USER_MESSAGES[subcode] ?? "An error occurred. Please retry or contact support.";
}
Keep this mapping in external configuration (database, JSON file) rather than hardcoded, so you can update it without redeployment if LigdiCash adds new sub-codes.
Monitoring integration
In production, enrich your alerts with the wiki sub-code:
// Example with a monitoring system like Sentry / Datadog
if (data.response_code === "01") {
monitoring.captureEvent({
message: `LigdiCash payment rejected: ${data.response_text}`,
level: "error",
tags: {
ligdicash_subcode: data.response_text,
ligdicash_wiki: data.wiki,
endpoint: "createInvoice",
},
});
}
Related pages