L’API LigdiCash fait circuler plusieurs identifiants dans les requêtes, les réponses et les callbacks. Ils ont des rôles distincts et ne sont pas interchangeables. ConfondreDocumentation Index
Fetch the complete documentation index at: https://developers.ligdicash.com/llms.txt
Use this file to discover all available pages before exploring further.
token et transaction_id, par exemple, est l’une des erreurs les plus fréquentes lors d’une première intégration.
Tableau de synthèse
| Identifiant | Généré par | Format | Où il apparaît | Rôle |
|---|---|---|---|---|
token | LigdiCash | Chaîne longue | Réponse création + callback | Appeler confirm |
request_id | LigdiCash | PXXXXXXXX | Page de paiement + callback | Référence courte affichable |
transaction_id | Le marchand | Libre | custom_data de la requête + callback + dashboard | Réconciliation marchand |
external_id | Le marchand | Libre | Champ invoice de la requête | Équivalent de transaction_id, syntaxe alternative |
Le token
Letoken est généré par LigdiCash à la création de chaque transaction. Il est retourné dans la réponse de création :
confirm pour vérifier le statut d’une transaction. Stockez-le en base dès la création.
Le request_id
Lerequest_id est un identifiant court généré par LigdiCash pour chaque transaction. Son format est PXXXXXXXX — par exemple P2756808232026.
Il est affiché sur la page de paiement LigdiCash et est présent dans le callback. Sa concision le rend facile à communiquer : un marchand peut l’afficher à son client comme référence de paiement, par exemple sur un reçu ou dans une interface de suivi.
Le transaction_id
Letransaction_id est un identifiant que vous générez côté marchand et que vous injectez dans le champ custom_data de votre requête. LigdiCash vous le retourne dans le callback et l’affiche dans votre dashboard parmi vos transactions payin et payout.
C’est le pivot de votre réconciliation : il fait le lien entre une transaction LigdiCash et votre propre système de commandes.
Le format est entièrement libre — référence commande, UUID, code court lisible par un client, etc.
Consultez Le pattern transaction_id pour les bonnes pratiques de format et d’utilisation.
L’external_id
L’external_id est l’équivalent direct du transaction_id — ils servent le même objectif. La différence est leur emplacement dans la requête : external_id est un champ du bloc invoice, tandis que transaction_id est injecté dans custom_data.
Les deux sont retournés dans le callback. Utilisez celui qui correspond le mieux à votre architecture — ils auront la même valeur dans les réponses de l’API.
Pages associées
- Le pattern transaction_id — format, cycle de vie, extraction dans le callback
- Sécuriser le callback — pourquoi re-vérifier avec le token stocké
- Codes de réponse et statuts
