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

# Status verification — Overview

> How and when to verify the status of a LigdiCash transaction — payin or payout — at any time.

LigdiCash exposes `confirm` endpoints that let you query the state of a transaction from the token obtained at creation. This active verification is the essential complement to the callback: it lets you reconcile your database when the callback is unavailable, was missed, or must be re-verified for security reasons.

## Available endpoints

| Flow                    | Method | Endpoint                                     | Parameter         |
| ----------------------- | ------ | -------------------------------------------- | ----------------- |
| Payin (hosted & direct) | `GET`  | `/pay/v01/redirect/checkout-invoice/confirm` | `token`           |
| Payout                  | `GET`  | `/pay/v01/withdrawal/confirm/`               | `withdrawalToken` |

<Note>
  The same `confirm` endpoint is used for hosted payin and direct payin. The difference is in when you call it, not in the endpoint itself.
</Note>

## `status` values

Whatever the flow, the `confirm` response contains a `status` field with three possible values:

| `status`       | Meaning                                              | Recommended action                         |
| -------------- | ---------------------------------------------------- | ------------------------------------------ |
| `completed`    | Transaction finalized successfully                   | Fulfill the order or confirm the payment   |
| `pending`      | Awaiting operator processing                         | Wait and re-poll, or wait for the callback |
| `notcompleted` | Transaction did not go through (cancelled or failed) | Offer to retry or notify the user          |

## When to call `confirm`

There are three situations where you must call `confirm`:

**1. After the redirect to `return_url` (hosted payin)**

When the customer returns to your site after payment, your frontend triggers a call to your backend, which calls `confirm` with the token stored at creation. Never call `confirm` directly from the browser — your API keys would be exposed.

**2. In your callback handler (all flows)**

Before fulfilling an order following a callback, always re-verify with `confirm`. Anyone who knows your endpoint URL can send a forged payload — re-verification is the only guarantee.

<Warning>
  Never fulfill an order based on the callback payload alone. Always call `confirm` with the **token stored at creation** before triggering your business logic.
</Warning>

**3. As fallback polling (callback unavailable or delayed)**

If the callback is unavailable in your development environment, or if it is slow to arrive in production, poll `confirm` at regular intervals until you get a terminal status (`completed` or `notcompleted`).

<Note>
  Polling is a safety net, not the primary strategy. See [Polling vs callback](/en/payment-api/status-verification/polling-vs-callback) to choose the right approach for your context.
</Note>

## Creation token vs callback token

<Warning>
  The `token` received in the callback payload is **different** from the token returned at creation. Both technically let you call `confirm`, but only the **creation token** lets you reconcile with your merchant-side order. Always store the creation token in your database as soon as the invoice is created.
</Warning>

## Reference pages

* [Verify the status — hosted payin](/en/payment-api/hosted-payin/verify-status) — full reference, response fields, and real payloads
* [Verify the status — direct payin](/en/payment-api/direct-payin/verify-status) — specifics of the direct payin flow
* [Verify the status — payout](/en/payment-api/payout/verify-status) — `withdrawal/confirm` endpoint
* [Polling vs callback](/en/payment-api/status-verification/polling-vs-callback) — choosing the right strategy
* [Recommendations](/en/payment-api/status-verification/recommendations) — intervals, timeouts, hybrid pattern
* [Callback — security](/en/payment-api/callback/security) — why always re-verify with `confirm`