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.

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

EndpointWiki URL
POST /pay/v01/redirect/checkout-invoice/createhttps://client.ligdicash.com/wiki/createInvoice
GET /pay/v01/redirect/checkout-invoice/confirmhttps://client.ligdicash.com/wiki/confirmInvoice
POST /pay/v01/straight/checkout-invoice/createhttps://client.ligdicash.com/wiki/createInvoice
POST /pay/v01/withdrawal/createhttps://client.ligdicash.com/wiki/createWithdrawal
POST /pay/v01/straight/payouthttps://client.ligdicash.com/wiki/createStraightWithdrawal
POST /pay/v01/withdrawal/confirmhttps://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:
Node.js
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:
Node.js
// 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",
    },
  });
}