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 regroupe les questions les plus fréquentes posées par les développeurs et les équipes business qui intègrent LigdiCash. Pour aller plus loin, chaque réponse renvoie vers la documentation détaillée.

​
Compte et accès

Téléchargez l’application mobile LigdiCash (App Store / Play Store) et créez votre compte depuis l’app. Vous devrez ensuite fournir les documents requis dans le cadre du KYC et signer un contrat de partenariat avec votre Partner Manager.Voir Protocole d’intégration pour le détail des étapes.
Vous n’avez pas à créer vous-même votre projet API. Après la signature du contrat, c’est l’équipe technique LigdiCash qui crée et active votre projet. Vos clés Apikey et API_TOKEN sont ensuite disponibles dans le Dashboard.Voir Projet API et Authentification.
Oui, mais chaque projet API fait l’objet d’un contrat distinct. Si vous avez plusieurs applications ou pays à couvrir, discutez-en avec votre Partner Manager avant de démarrer une nouvelle intégration.
LigdiCash ne propose pas d’environnement sandbox distinct à ce jour. Les tests se font en production avec de vraies transactions. Renseignez-vous auprès de votre Partner Manager pour connaître les modalités de test disponibles.Contact : developper@ligdicash.com

​
Intégration technique

  • Avec redirection : le client est envoyé vers une page de paiement hébergée par LigdiCash. Intégration simple, UI gérée par LigdiCash, mais moins de contrôle.
  • Sans redirection : le marchand gère entièrement l’interface et soumet le paiement via API. Plus de contrôle sur l’UX, mais intégration plus complexe et spécifique à chaque opérateur.
Voir Vue d’ensemble de l’API de paiement pour le tableau de décision.
Non. LigdiCash bloque l’affichage de sa page dans une iframe. Vous devez ouvrir le lien dans le même onglet, un nouvel onglet, un popup, ou une WebView native (applications mobiles).Voir Pièges courants du payin redirect.
Si vous renseignez un numéro de téléphone dans customer, LigdiCash filtre la page de paiement pour n’afficher que les opérateurs correspondant à ce numéro, masquant les autres options. Laissez customer: "" pour que votre client puisse choisir librement son opérateur.Voir Pièges courants du payin redirect.
Les navigateurs bloquent les popups ouverts en dehors d’un événement utilisateur direct. Le pattern recommandé est d’ouvrir window.open('about:blank') au moment du clic utilisateur (avant le await fetch), puis de naviguer vers l’URL de paiement une fois la réponse reçue.Voir Rediriger le client.
Le token présent dans le callback est différent du token retourné à la création. Ne vous y fiez pas pour retrouver votre commande. La méthode fiable est d’injecter votre propre identifiant de commande dans custom_data à la création, puis de le retrouver via keyof_customdata === "transaction_id" dans le callback.Voir Le pattern transaction_id et Parser custom_data.
C’est le comportement normal de LigdiCash. Pour chaque événement, deux requêtes POST sont envoyées à votre URL callback : une en application/x-www-form-urlencoded et une en application/json. Le contenu est identique. Implémentez une logique de déduplication (vérifier si la transaction est déjà traitée en base avant d’agir).Voir Idempotence du callback.
Ne faites jamais confiance au payload reçu sans vérification. N’importe qui connaissant l’URL de votre callback peut envoyer un faux payload. Après réception, re-vérifiez toujours le statut en appelant l’endpoint confirm avec le token que vous avez stocké lors de la création de la facture.Voir Sécurisation du callback.
L’endpoint GET /pay/v01/withdrawal/confirm/ s’appelle en GET avec le token en query string. Il y a une incohérence dans la documentation actuelle.Voir Vérifier le statut d’un payout.
  • /withdrawal/create : envoie vers le wallet LigdiCash du destinataire. L’argent peut rester dans le wallet (top_up_wallet: 1) ou être automatiquement viré vers son mobile money lié (top_up_wallet: 0).
  • /straight/payout : envoie directement vers le numéro mobile money, sans wallet intermédiaire. Plus lent, mais ne nécessite pas que le destinataire ait un compte LigdiCash.
Voir Payout — Introduction.
Il existe quatre modes selon l’opérateur :
  • OTP USSD — le client génère un OTP en composant un code USSD avant que vous ne soumettiez. Une seule requête API.
  • USSD Push — vous soumettez avec otp: "", l’opérateur envoie un écran USSD push au client qui valide avec son PIN. Une seule requête API.
  • USSD guidé — vous soumettez avec otp: "", l’opérateur envoie un SMS avec les instructions et un code USSD à composer. Une seule requête API.
  • OTP SMS — vous soumettez d’abord avec otp: "", l’opérateur envoie un OTP par SMS, vous re-soumettez avec l’OTP saisi. Deux requêtes API.
Voir Modes de validation pour le détail des flux et des UX recommandées.

​
Sécurité

  • Ne jamais exposer Apikey et Auth Token côté client (navigateur, application mobile).
  • Toujours faire les appels LigdiCash depuis votre backend.
  • Utiliser des variables d’environnement, jamais des constantes dans le code source.
  • Régénérer les clés immédiatement en cas de compromission depuis le Dashboard.
Voir Architecture recommandée.
Connectez-vous au Dashboard LigdiCash et régénérez vos clés immédiatement. Mettez à jour vos variables d’environnement en production. Auditez vos logs pour détecter des transactions non autorisées. Contactez developper@ligdicash.com si vous suspectez une fraude.
Deux mécanismes combinés :
  1. Déduplication du callback : avant de traiter un callback, vérifiez en base si le transaction_id a déjà été traité.
  2. Re-vérification systématique : appelez l’endpoint confirm avec le token de création pour valider l’état réel, plutôt que de vous fier au payload callback reçu.
Voir Idempotence du callback et Sécurisation du callback.

​
Business et opérationnel

LigdiCash couvre le Burkina Faso, la Côte d’Ivoire, le Mali, le Niger, le Bénin, le Togo, le Sénégal, la Guinée Conakry et la RD Congo. Les opérateurs supportés incluent Orange Money, Moov Africa, MTN Mobile Money, Wave, Airtel Money, Vodacom, Africell, YAS, Zamani et le Wallet LigdiCash.Voir Opérateurs supportés pour le tableau complet.
L’API LigdiCash utilise toujours le XOF, quelle que soit la devise locale du pays du client. Cela vaut également pour la RD Congo et la Guinée Conakry, dont les devises nationales ne sont pas le XOF — LigdiCash gère la conversion en interne. Les montants sont toujours des entiers (le XOF n’a pas de décimales).Pour des devises étrangères comme le dollar ou l’euro, c’est au marchand d’effectuer la conversion en XOF avant d’appeler l’API.Voir Devises et montants.
Les limites varient selon l’opérateur et le pays. Contactez votre Partner Manager ou consultez le Dashboard pour les limites en vigueur sur votre compte.Voir Opérateurs supportés.
Les conditions de reversement (fréquence, délai, seuil minimum) sont définies dans votre contrat de partenariat. Contactez votre Partner Manager pour les détails.
Un plugin officiel est disponible. Installez-le manuellement depuis votre Dashboard WooCommerce, configurez vos clés API et le comportement du callback, et vous êtes prêt.Voir SDK WordPress / WooCommerce.
Oui. LigdiCash propose des SDK officiels pour PHP, Python, JavaScript/Node.js, Dart/Flutter et un plugin WooCommerce.Voir Vue d’ensemble des SDK.
Le passage en production suit un processus formel :
  1. Vous complétez votre intégration et vos tests sur le compte temporaire.
  2. L’équipe technique LigdiCash effectue des tests de validation de votre intégration.
  3. Un procès-verbal (PV) est signé entre vous et LigdiCash pour officialiser la fin de l’intégration.
  4. L’équipe technique active votre projet de production. Seules vos clés changent — le code reste identique.
Consultez aussi la checklist technique pour préparer votre intégration avant la validation.Voir Checklist de mise en production.