Comment vérifier un paiement avant de livrer ?
Confirmez le statut côté serveur via l’API et les webhooks, ne vous fiez jamais à la seule redirection navigateur.
Le client peut fermer le navigateur, perdre le réseau ou atteindre votre success_url avant la fin du traitement lomi. surtout en mobile money et avec les cartes 3D Secure. La redirection est un indice UX, pas une preuve de paiement.
Ne livrez pas sur la seule redirection
N’expédiez pas, ne débloquez pas de contenu et ne marquez pas une facture payée uniquement à partir des paramètres de success_url ou du JavaScript client. Vérifiez toujours côté serveur.
Ordre de vérification recommandé
- Webhook: lomi. envoie un POST HTTPS quand la transaction atteint un état final (préféré pour les rails asynchrones).
- Lecture API:
GET /transactions/{id}ou liste filtrée lorsque vous avez l’identifiant issu de la session checkout ou de la charge. - Tableau de bord: opérations manuelles et support ; pas pour l’automatisation en production.
Checkout hébergé
Après le paiement du client :
- Stockez votre
order_idinterne dans lesmetadatade la session checkout à la création. - Sur
success_url, affichez un état « traitement en cours »-pas « payé »-jusqu’à confirmation backend. - À réception de
transaction.completed(ou de votre type d’événement), faites correspondremetadata.order_idpuis livrez.
Voir Machine à états du paiement et Gestion des webhooks.
Charges directes (Wave, MTN, carte)
| Rail | Quand vérifier |
|---|---|
| Wave (live) | Après approbation dans l’app Wave, webhook ou polling transaction |
| MTN MoMo (live) | Démarre en PENDING ; vérifier avant livraison |
| MTN / Wave (test) | Peut se compléter immédiatement ; vérifier quand même côté serveur en tests |
| Carte | Après confirmation client_secret ; gérer requires_action |
Idempotence à la livraison
Votre handler (worker webhook ou poll API) doit être idempotent : traiter deux fois le même transaction_id ou le même id d’événement webhook ne doit pas livrer en double. Stockez les IDs d’événements traités ou utilisez des contraintes sur order_id + status = fulfilled.
Checklist
-
success_urlaffiche « en attente » jusqu’à confirmation serveur - Le endpoint webhook vérifie
X-Lomi-Signaturesur le corps brut - La livraison n’a lieu que si
transaction_statusestcompleted - Remboursements et litiges ont un chemin d’annulation
Voir aussi
Quelle intégration de paiement choisir ?
Choisissez entre checkout hébergé, liens de paiement, demandes de paiement, charges directes, abonnements, extensions ecommerce et composants UI.
Cycle de vie des paiements et reversements
Comment les statuts encaissement et décaissement s’articulent, liens vers la machine à états, soldes et webhooks.