Passer au contenu principal

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.

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 :
FluxIntervalle recommandéRaison
Payin (redirect ou sans redirect)3 à 5 secondesLa confirmation opérateur arrive souvent en quelques secondes après l’action du client
Payout30 à 60 secondesLes 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.
FluxMax tentatives recommandéesDurée totale approx.
Payin10 à 1540 à 75 secondes
Payout105 à 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?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