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

# Vérification de statut — Vue d'ensemble

> Comment et quand vérifier le statut d'une transaction LigdiCash — payin ou payout — à tout moment.

LigdiCash expose des endpoints `confirm` qui permettent d'interroger l'état d'une transaction à partir du token obtenu à la création. Cette vérification active est le complément indispensable du callback : elle vous permet de réconcilier votre base de données lorsque le callback n'est pas disponible, a été manqué, ou doit être re-vérifié pour des raisons de sécurité.

## Endpoints disponibles

| Flux                             | Méthode | Endpoint                                     | Paramètre         |
| -------------------------------- | ------- | -------------------------------------------- | ----------------- |
| Payin (redirect & sans redirect) | `GET`   | `/pay/v01/redirect/checkout-invoice/confirm` | `token`           |
| Payout                           | `GET`   | `/pay/v01/withdrawal/confirm/`               | `withdrawalToken` |

<Note>
  Le même endpoint `confirm` est utilisé pour le payin avec redirection et le payin sans redirection. La différence est dans le moment où vous l'appelez, pas dans l'endpoint lui-même.
</Note>

## Valeurs de `status`

Quel que soit le flux, la réponse `confirm` contient un champ `status` avec trois valeurs possibles :

| `status`       | Signification                                | Action recommandée                              |
| -------------- | -------------------------------------------- | ----------------------------------------------- |
| `completed`    | Transaction finalisée avec succès            | Honorer la commande ou confirmer le paiement    |
| `pending`      | En attente de traitement côté opérateur      | Patienter et rappeler, ou attendre le callback  |
| `notcompleted` | Transaction non aboutie (annulée ou échouée) | Proposer de réessayer ou notifier l'utilisateur |

## Quand appeler `confirm`

Il y a trois situations où vous devez appeler `confirm` :

**1. Après la redirection vers `return_url` (payin redirect)**

Quand le client revient sur votre site après le paiement, votre frontend déclenche un appel à votre backend, qui appelle `confirm` avec le token stocké à la création. Ne jamais appeler `confirm` directement depuis le navigateur — vos clés API seraient exposées.

**2. Dans votre handler de callback (tous les flux)**

Avant d'honorer une commande suite à un callback, re-vérifiez systématiquement avec `confirm`. N'importe qui connaissant l'URL de votre endpoint peut envoyer un faux payload — la re-vérification est la seule garantie.

<Warning>
  N'honorez jamais une commande sur la seule foi du payload de callback. Appelez toujours `confirm` avec le **token stocké à la création** avant de déclencher votre logique métier.
</Warning>

**3. En polling de secours (callback indisponible ou en retard)**

Si le callback n'est pas disponible dans votre environnement de développement, ou s'il tarde à arriver en production, interrogez `confirm` à intervalles réguliers jusqu'à obtenir un statut terminal (`completed` ou `notcompleted`).

<Note>
  Le polling est un filet de sécurité, pas la stratégie principale. Consultez [Polling vs callback](/api-paiement/verification-statut/polling-vs-callback) pour choisir la bonne approche selon votre contexte.
</Note>

## Token de création vs token du callback

<Warning>
  Le `token` reçu dans le payload du callback est **différent** du token retourné à la création. Les deux permettent techniquement d'appeler `confirm`, mais seul le **token de création** vous permet de faire la réconciliation avec votre commande côté marchand. Stockez toujours le token de création en base de données dès la création de la facture.
</Warning>

## Pages de référence

* [Vérifier le statut — payin redirect](/api-paiement/payin-redirect/verifier-statut) — référence complète, champs de réponse et payloads réels
* [Vérifier le statut — payin sans redirect](/api-paiement/payin-sans-redirect/verifier-statut) — spécificités du flux sans redirection
* [Vérifier le statut — payout](/api-paiement/payout/verifier-statut) — endpoint `withdrawal/confirm`
* [Polling vs callback](/api-paiement/verification-statut/polling-vs-callback) — choisir la bonne stratégie
* [Recommandations](/api-paiement/verification-statut/recommandations) — intervalles, timeouts, pattern hybride
* [Callback — sécurisation](/api-paiement/callback/securisation) — pourquoi toujours re-vérifier avec `confirm`