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.

Reference page listing the most frequent mistakes made when integrating hosted payin. Each pitfall describes the observed symptom, the cause, and the correction to apply.
Symptom: the LigdiCash payment page only shows one operator, or none, while several are available in your region.Cause: if the customer field contains a phone number, LigdiCash filters the page to only show operators compatible with that number. The other operators are hidden.Fix: always send customer: "" in the invoice creation request.
{
  "commande": {
    "invoice": {
      "customer": "",
      ...
    }
  }
}
The customer_firstname, customer_lastname, and customer_email fields can be filled without affecting the display of operators. Only customer (the phone number) is involved.
Symptom: the iframe stays empty, or the browser console shows an error like Refused to display … in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'.Cause: LigdiCash deliberately blocks the loading of its payment page in an <iframe>. This is a security measure against clickjacking, not a bug.Fix: open the payment URL in a real navigation context.
ModeImplementation
Same tabwindow.location.href = url
New tabwindow.open(url, '_blank')
Popupabout:blank pattern (see below)
Native mobileNative iOS / Android WebView
See Redirect the customer for the full implementations.
Symptom: orders are fulfilled without a real payment, or the order state is wrong after cancellation.Cause: return_url and cancel_url are simply browser redirects. Anyone who knows the URL can navigate to it directly — they are not proof of payment status.Fix: in both cases (return_url and cancel_url), always verify the real transaction status by calling confirm server-side before making any business decision.
JavaScript
// Whether arriving via return_url or cancel_url
const confirmation = await callBackend("/verify-payment", { token });

if (confirmation.status === "completed") {
  showSuccess();
} else {
  showFailure();
}
Never infer payment status from the redirect URL. The only reliable status is the one returned by the confirm endpoint.
Symptom: reconciliation with your order fails, or you confirm the wrong transaction.Cause: the token present in the callback payload is different from the token returned at invoice creation. Both let you call confirm, but only the creation token lets you link the response to your merchant-side order.Fix: store the token returned by the create endpoint in your database as soon as the invoice is created, and use it preferentially to call confirm.
JavaScript
// At creation
const { token, response_text } = await createInvoice(order);
await db.save({ orderId, token, paymentUrl: response_text });

// In the callback handler or after return_url
const { token } = await db.findByOrderId(orderId);
const confirmation = await confirmPayment(token);
See The transaction_id pattern for the recommended reconciliation strategy.
Symptom: the user lands on the success page after cancelling, or on the cancellation page after a successful payment.Cause: the two fields are easily confused. The older LigdiCash documentation even had them swapped in its examples.Fix:
  • return_url → URL where LigdiCash redirects after a successful payment
  • cancel_url → URL where LigdiCash redirects after a cancellation
{
  "actions": {
    "return_url": "https://myapp.com/payment/success",
    "cancel_url": "https://myapp.com/payment/cancel",
    "callback_url": "https://myapp.com/api/callback/ligdicash"
  }
}
Whatever the landing URL, always verify the real status with confirm server-side before showing a final result to the user.