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

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.

​

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

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.

​

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 — re-vérification différée

async function reVerifierTransactionExpirée(token) {
  const res = await fetch(
    `https://app.ligdicash.com/pay/v01/redirect/checkout-invoice/confirm/?invoiceToken=${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 — choisir la bonne stratégie
• Callback — sécurisation — re-vérification avec confirm
• Callback — idempotence — déduplication des deux requêtes
• Modes de validation — OTP USSD, OTP SMS, approbation
• Codes de réponse et statuts — référence complète