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

# Recommandations de vérification

> Intervalles de polling, timeouts, stratégie hybride et gestion des transactions en pending — les bonnes pratiques pour un suivi fiable.

Cette page rassemble les bonnes pratiques opérationnelles pour vérifier le statut des transactions LigdiCash de façon fiable, sans surcharger l'API ni laisser de transactions orphelines.

## Intervalle de polling recommandé

L'intervalle optimal dépend du type de transaction :

| Flux                              | Intervalle recommandé | Raison                                                                                 |
| --------------------------------- | --------------------- | -------------------------------------------------------------------------------------- |
| Payin (redirect ou sans redirect) | **3 à 5 secondes**    | La confirmation opérateur arrive souvent en quelques secondes après l'action du client |
| Payout                            | **30 à 60 secondes**  | Les payouts sont traités par batch côté opérateur — poller trop vite est inutile       |

<Warning>
  Ne descendez pas en dessous de 3 secondes entre deux appels `confirm`. Un polling trop agressif peut déclencher des limites de débit côté LigdiCash et dégrader la fiabilité de vos intégrations.
</Warning>

## Timeouts — quand abandonner le polling

Fixez un nombre maximum de tentatives plutôt qu'un délai absolu : cela vous donne un contrôle précis sur le nombre d'appels API générés.

| Flux   | Max tentatives recommandées | Durée totale approx. |
| ------ | --------------------------- | -------------------- |
| Payin  | 10 à 15                     | 40 à 75 secondes     |
| Payout | 10                          | 5 à 10 minutes       |

Au-delà du timeout, la transaction reste techniquement `pending` côté LigdiCash — elle n'est pas annulée. Le callback peut encore arriver. Adoptez la logique suivante :

1. **Marquez la transaction comme `expiré` dans votre base** (statut applicatif, pas LigdiCash).
2. **Informez l'utilisateur** que le traitement est en cours et qu'il sera notifié.
3. **Continuez à écouter le callback** — s'il arrive, re-vérifiez avec `confirm` et mettez à jour.

## Stratégie hybride — callback principal + polling de fallback

```
1. Créer la transaction → stocker le token et status = "pending"
2. Configurer un callback_url accessible depuis internet
3. À la réception du callback :
     → Appeler confirm avec le token de création
     → Mettre à jour votre base
4. Si le callback n'arrive pas après 2 minutes :
     → Déclencher un polling de fallback (job asynchrone)
     → 10 tentatives, toutes les 5 secondes
5. Si polling timeout :
     → Marquer "expiré" en base
     → Continuer à traiter le callback s'il arrive tard
```

<Tip>
  Déclenchez le polling de fallback depuis un job de fond (cron, queue worker) — pas depuis le thread de la requête HTTP initiale. Cela évite de bloquer l'utilisateur pendant l'attente.
</Tip>

## Gérer les transactions en `pending`

Une transaction reste `pending` tant que l'opérateur n'a pas rendu sa décision finale. Plusieurs situations expliquent un `pending` prolongé :

* **Mode approbation (Moov Africa)** — le client doit confirmer sur son application mobile, ce qui peut prendre plusieurs minutes.
* **OTP expiré** — le client n'a pas saisi l'OTP à temps. La transaction restera `pending` puis passera en `notcompleted` après expiration.
* **Congestion réseau opérateur** — rare, mais possible lors de pics de trafic.
* **Payout en attente de fonds** — si le solde du compte marchand est insuffisant au moment de l'initiation.

Pour chaque transaction encore `pending` après votre timeout de polling, conservez le token en base et planifiez une re-vérification différée (exemple : +30 min, +2h, +24h) avant de la considérer définitivement perdue.

```javascript JavaScript — re-vérification différée theme={null}
async function reVerifierTransactionExpirée(token) {
  const res = await fetch(
    `https://app.ligdicash.com/pay/v01/redirect/checkout-invoice/confirm?token=${token}`,
    {
      headers: {
        Apikey: process.env.LIGDICASH_API_KEY,
        Authorization: `Bearer ${process.env.LIGDICASH_API_TOKEN}`,
        Accept: "application/json",
      },
    }
  );
  const data = await res.json();

  if (data.status === "completed") {
    await mettreAJourCommande(token, "payée");
  } else if (data.status === "notcompleted") {
    await mettreAJourCommande(token, "échouée");
  }
  // Si toujours "pending", laisser le job planifié pour la prochaine vérification
}
```

## Pages associées

* [Polling vs callback](/api-paiement/verification-statut/polling-vs-callback) — choisir la bonne stratégie
* [Callback — sécurisation](/api-paiement/callback/securisation) — re-vérification avec `confirm`
* [Callback — idempotence](/api-paiement/callback/idempotence) — déduplication des deux requêtes
* [Modes de validation](/api-paiement/payin-sans-redirect/modes-validation) — OTP USSD, OTP SMS, approbation
* [Codes de réponse et statuts](/concepts/codes-reponse-statuts) — référence complète