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.

A LigdiCash transaction does not go directly from “created” to “paid”. It moves through states that your system must know how to interpret. The behavior differs from what is usually found in other payment gateways — it is important to understand it well before designing your integration.

​
The three statuses

StatusMeaning
pendingTransaction created, awaiting a definitive outcome
completedPayment confirmed successfully — final state
notcompletedPayment failed or cancelled — final state

​
What pending really means

pending is the default state of every transaction at creation. It is also the state in which most transactions remain the longest — and sometimes indefinitely. Several failed payment attempts on the same transaction do not move it to notcompleted. A customer can enter an incorrect OTP multiple times: the transaction stays pending. There is no expiration delay on the LigdiCash side. A transaction can stay in pending for days after creation, for a simple reason: a customer may file a dispute with their mobile money operator, and the operator may validate or cancel the transaction several days later. LigdiCash waits for the definitive outcome before updating the status.
Never assume that a pending transaction is lost or expired. Do not recreate it automatically after a delay. Wait for the callback or query confirm before making a decision.

​
completed and notcompleted are final states

Once a transaction reaches completed or notcompleted, its status will not change again. notcompleted is rare — it indicates that a definitive negative outcome has been confirmed (operator cancellation, definitive rejection).

​
How to know the status

Two mechanisms let you track a transaction’s status: The callback — LigdiCash sends a notification to your callback_url when the status changes. This is the primary mechanism. The confirm endpoint — you can query LigdiCash at any time with the token stored at creation to get the current status.
Never update an order’s status based on the callback payload alone. Always call confirm with the token stored at creation to validate. Anyone who knows your callback URL could send a forged payload.
See Securing the callback for the full re-verification pattern.