> ## 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.

# Transaction lifecycle

> The three statuses of a LigdiCash transaction — pending, completed, notcompleted — and why a transaction can remain pending indefinitely.

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

| Status         | Meaning                                            |
| -------------- | -------------------------------------------------- |
| `pending`      | Transaction created, awaiting a definitive outcome |
| `completed`    | Payment confirmed successfully — final state       |
| `notcompleted` | Payment 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.

<Warning>
  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.
</Warning>

## `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).

```mermaid theme={null}
stateDiagram-v2
    [*] --> pending : Transaction created
    pending --> pending : Failed attempts, disputes in progress
    pending --> completed : Payment confirmed (final state)
    pending --> notcompleted : Cancellation confirmed (final state, rare)
```

## 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.

<Warning>
  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.
</Warning>

See [Securing the callback](/en/payment-api/callback/security) for the full re-verification pattern.

## Related pages

* [Securing the callback](/en/payment-api/callback/security) — re-verification pattern with `confirm`
* [Polling vs callback](/en/payment-api/status-verification/polling-vs-callback) — when to use one or the other
* [Response codes and statuses](/en/concepts/response-codes-and-statuses)