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 checklist couvre les points critiques à valider avant d’ouvrir votre intégration aux clients finaux. Parcourez-la dans l’ordre — chaque section s’appuie sur la précédente.

​
Sécurité

L’Apikey et l’Auth Token ne doivent apparaître ni dans le code JavaScript du navigateur, ni dans une app mobile, ni dans un dépôt Git public.
  • Variables d’environnement serveur uniquement (process.env, .env non commité)
  • .gitignore inclut le fichier .env
  • Pas de clé dans les logs applicatifs
  • Pas de clé dans les réponses d’API retournées au frontend
Ne jamais faire confiance au payload reçu dans le callback — il peut être forgé. Appelez toujours /confirm avec le token stocké à la création.
  • Le handler de callback appelle /checkout-invoice/confirm avant toute action métier
  • Le token utilisé pour confirm est celui stocké à la création (pas le token du callback)
  • Un payload malformé ou avec un transaction_id inconnu est ignoré silencieusement
  • Voir Sécurisation du callback
LigdiCash doit pouvoir atteindre votre endpoint de callback depuis Internet.
  • URL accessible depuis une IP externe (pas localhost ou IP privée)
  • HTTPS recommandé (HTTP accepté par LigdiCash, mais déconseillé en production)
  • Pas de règle firewall bloquant les IPs LigdiCash
  • Si whitelisting requis : contactez le support LigdiCash pour obtenir les IPs à autoriser (max 3 IPs par projet)
Un transaction_id séquentiel (1, 2, 3…) permet à un attaquant d’énumérer vos transactions.
  • Utilisez un UUID v4 ou un ID préfixé avec suffixe aléatoire (txn_ + timestamp + aléatoire)
  • Voir Pattern transaction_id

​
Technique

  • customer est vide ("") dans tous les exemples de payin redirect
  • cancel_url pointe vers la page d’annulation, return_url vers la page de succès (pas inversé)
  • L’URL de paiement s’ouvre dans le même onglet, un nouvel onglet ou un popup — jamais dans une iframe
  • Le frontend vérifie le statut réel via le backend après retour sur return_url (la redirection n’est pas une preuve de paiement)
  • external_id et otp sont vides ("") dans les requêtes où ils ne sont pas utilisés
  • Le mode d’authentification (OTP USSD / SMS / Approbation) est correctement documenté dans l’UX pour chaque opérateur
  • Pour le mode OTP SMS : la requête initiale est soumise avec otp: "", puis re-soumise avec l’OTP reçu
  • Pour le mode Approbation (Moov) : le callback est la seule confirmation — pas de polling insuffisant
  • Le handler est idempotent (deux appels avec le même transaction_id n’exécutent la logique qu’une fois)
  • Les deux formats de callback sont gérés (application/json et application/x-www-form-urlencoded)
  • Voir Idempotence du callback et Parser custom_data
  • La transaction est créée en base avant l’appel à LigdiCash
  • Le token LigdiCash est stocké dès la création de la facture
  • Les logs d’entrée et de sortie (requêtes LigdiCash + callbacks reçus) sont conservés
  • Voir Architecture recommandée
  • Un job périodique vérifie les transactions restées pending depuis plus de quelques minutes
  • Le polling s’arrête après un délai raisonnable (ex : 24h) — les transactions ne passent jamais automatiquement en notcompleted
  • Le polling utilise le token stocké à la création, pas un token issu du callback

​
Payout (si applicable)

  • Le client destinataire possède un compte LigdiCash (requis pour /withdrawal/create)
  • La sémantique de top_up_wallet est correctement implémentée : 1 = fonds dans le wallet, 0 = virement automatique vers le mobile money lié
  • Le numéro de téléphone est au format 22670XXXXXXX (sans +, sans espaces)
  • L’endpoint /straight/payout est utilisé (pas /withdrawal/create) pour les destinataires sans compte LigdiCash

​
Business et opérationnel

  • Le compte marchand LigdiCash est actif et vérifié (KYC complété)
  • Le projet API est en mode production (pas de compte de test)
  • Les opérateurs souhaités sont activés sur le projet API (vérifiez dans le dashboard)
  • Visa activé séparément si vous en avez besoin (contrat spécifique)
  • Chaque code d’erreur LigdiCash est mappé à un message lisible par l’utilisateur
  • L’utilisateur est informé clairement si son paiement échoue, avec une invitation à réessayer
  • Voir Erreurs courantes
  • Votre callback_url a été testée en conditions réelles
  • Vous avez un groupe d’intégration Microsoft Teams LigdiCash pour les urgences en production
  • Si whitelisting IP requis : les IPs de votre serveur ont été transmises au support technique LigdiCash

​
Tests pré-production

Avant le go-live, effectuez au moins un test de bout en bout pour chaque flux que vous intégrez.
ScénarioÀ tester
Paiement réussiLe statut passe à completed, la commande est confirmée
Paiement annulé par l’utilisateurLa cancel_url est atteinte, la commande reste pending puis expire
Callback reçu deux foisLa logique métier n’est exécutée qu’une fois
Transaction toujours pending après 10 minLe polling de fallback la met à jour correctement
Clé API invalideL’erreur est capturée et loggée, l’utilisateur voit un message générique
LigdiCash n’a pas d’environnement sandbox distinct. Les tests sont effectués avec un compte de test réel fourni par l’équipe LigdiCash pendant la période d’intégration. Contactez developper@ligdicash.com pour obtenir un accès de test.

​
Pages associées