LigdiCash expose des endpointsDocumentation Index
Fetch the complete documentation index at: https://developers.ligdicash.com/llms.txt
Use this file to discover all available pages before exploring further.
confirm qui permettent d’interroger l’état d’une transaction à partir du token obtenu à la création. Cette vérification active est le complément indispensable du callback : elle vous permet de réconcilier votre base de données lorsque le callback n’est pas disponible, a été manqué, ou doit être re-vérifié pour des raisons de sécurité.
Endpoints disponibles
| Flux | Méthode | Endpoint | Paramètre |
|---|---|---|---|
| Payin (redirect & sans redirect) | GET | /pay/v01/redirect/checkout-invoice/confirm | token |
| Payout | GET | /pay/v01/withdrawal/confirm/ | withdrawalToken |
Le même endpoint
confirm est utilisé pour le payin avec redirection et le payin sans redirection. La différence est dans le moment où vous l’appelez, pas dans l’endpoint lui-même.Valeurs de status
Quel que soit le flux, la réponse confirm contient un champ status avec trois valeurs possibles :
status | Signification | Action recommandée |
|---|---|---|
completed | Transaction finalisée avec succès | Honorer la commande ou confirmer le paiement |
pending | En attente de traitement côté opérateur | Patienter et rappeler, ou attendre le callback |
notcompleted | Transaction non aboutie (annulée ou échouée) | Proposer de réessayer ou notifier l’utilisateur |
Quand appeler confirm
Il y a trois situations où vous devez appeler confirm :
1. Après la redirection vers return_url (payin redirect)
Quand le client revient sur votre site après le paiement, votre frontend déclenche un appel à votre backend, qui appelle confirm avec le token stocké à la création. Ne jamais appeler confirm directement depuis le navigateur — vos clés API seraient exposées.
2. Dans votre handler de callback (tous les flux)
Avant d’honorer une commande suite à un callback, re-vérifiez systématiquement avec confirm. N’importe qui connaissant l’URL de votre endpoint peut envoyer un faux payload — la re-vérification est la seule garantie.
3. En polling de secours (callback indisponible ou en retard)
Si le callback n’est pas disponible dans votre environnement de développement, ou s’il tarde à arriver en production, interrogez confirm à intervalles réguliers jusqu’à obtenir un statut terminal (completed ou notcompleted).
Le polling est un filet de sécurité, pas la stratégie principale. Consultez Polling vs callback pour choisir la bonne approche selon votre contexte.
Token de création vs token du callback
Pages de référence
- Vérifier le statut — payin redirect — référence complète, champs de réponse et payloads réels
- Vérifier le statut — payin sans redirect — spécificités du flux sans redirection
- Vérifier le statut — payout — endpoint
withdrawal/confirm - Polling vs callback — choisir la bonne stratégie
- Recommandations — intervalles, timeouts, pattern hybride
- Callback — sécurisation — pourquoi toujours re-vérifier avec
confirm