Finis les interrogations en boucle. KODA déclenche un webhook de paiement vérifié dès qu'un paiement mobile money aboutit, et la commande se confirme en temps réel.
— lectures
La meilleure expérience de paiement est celle qui se confirme toute seule. Personne n'apprécie le silence gênant où un client patiente au comptoir, ou sur une page de paiement, pendant que quelqu'un plisse les yeux sur un téléphone pour décider si l'argent est vraiment arrivé. KODA supprime entièrement ce silence : au lieu de vous demander si un paiement est réel, KODA l'annonce à votre système à l'instant où il l'est, via un webhook de paiement vérifié signé. La commande part, le billet s'émet, la place se libère — automatiquement.
La configuration est légère. Vous ajoutez un endpoint de webhook sur votre serveur et enregistrez son URL auprès de KODA. À partir de là, chaque paiement qui se vérifie — par n'importe laquelle des Five Ways to Accept & Verify Mobile Money (One Engine), pas seulement l'API — délivre un événement à cet endpoint à l'instant où la référence correspond au SMS de confirmation de l'opérateur. Il n'y a aucune file à vider ni aucun calendrier à régler ; l'événement arrive quand la vérité arrive.
C'est la pièce qui vous permet d'arrêter l'interrogation en boucle. Interroger en boucle, c'est marteler un endpoint toutes les quelques secondes en demandant « est-ce fini ? », ce qui gaspille des requêtes, ajoute de la latence et laisse tout de même un écart entre l'aboutissement du paiement et le moment où votre système le remarque. Un webhook inverse cela : KODA connaît déjà l'instant précis où un paiement est confirmé, il vous pousse donc simplement ce fait. Votre paiement en ligne réagit en temps réel plutôt qu'au rythme d'un minuteur.
Les webhooks s'associent naturellement à l'The Mobile Money Verification API (3 Endpoints, No Telco Deal) pour former un flux entièrement automatisé. Votre serveur crée l'intention, le client paie et soumet sa référence, le moteur la vérifie, et le webhook boucle la boucle en indiquant à votre backend d'honorer la commande. Vous écrivez la logique métier une seule fois — accorder l'accès, envoyer la marchandise, expédier le reçu par e-mail — et elle s'exécute toute seule pour chaque vente future.
La sécurité n'est pas ici une réflexion après coup. Chaque endpoint de webhook reçoit son propre secret de signature, de sorte que votre serveur peut confirmer qu'un événement entrant provient réellement de KODA et n'a pas été falsifié par un attaquant qui aurait deviné votre URL. Les événements sont cloisonnés par marchand, les livraisons sont journalisées, et les charges utiles peuvent être rejouées pour le débogage. Le schéma de signature exact et les étapes de vérification sont documentés sur la page KODA API for developers.
Ce mécanisme de webhook est ce qui alimente discrètement la porte 3, la commande qui se confirme elle-même. Lorsque l'application KODA Sentinel sur le téléphone du marchand lit un SMS entrant de l'opérateur et qu'il correspond à une commande en attente, le webhook se déclenche sans aucun humain dans la boucle — le schéma décrit dans Auto-Verify Every Payment with the KODA Sentinel App. Un client peut payer à minuit et recevoir son téléchargement avant même que vous n'ayez regardé votre téléphone.
Cela compte pour les marchands africains parce que la confiance et la rapidité s'opposent souvent. Le choix prudent est d'attendre et de vérifier ; le choix qui remporte la vente est de livrer vite. Les webhooks vous permettent d'avoir les deux — la livraison n'a lieu qu'après une vraie vérification, mais cette vérification est instantanée, de sorte que le client ne ressent jamais l'attente. Vous cessez de choisir entre prudence et conversion.
Une erreur fréquente est de construire votre logique d'exécution pour qu'elle fasse confiance au message « paiement envoyé » du client ou à une capture d'écran, puis de rattraper les échecs à la main plus tard. Ce travail de rapprochement est exactement ce qui dévore les soirées d'une petite équipe. Si l'exécution est au contraire conditionnée à un webhook vérifié, le problème de rapprochement disparaît en grande partie, car rien n'est expédié qui n'ait d'abord été confirmé par rapport au relevé propre de l'opérateur et verrouillé contre la réutilisation.
La fiabilité fait aussi partie de la conception. Un webhook n'est utile que s'il arrive réellement, c'est pourquoi les livraisons sont réessayées en cas d'échec et chaque tentative est enregistrée, ce qui signifie qu'une brève panne de votre côté ne perd pas silencieusement un paiement confirmé. Lorsque votre endpoint revient en ligne, l'événement l'attend toujours. Et comme chaque référence vérifiée est verrouillée pour toujours dans le moteur, une livraison réessayée ne peut jamais honorer une commande deux fois par accident — votre gestionnaire peut traiter en toute sécurité le même identifiant d'événement comme idempotent.
En dessous, chaque événement est signé, rejouable et inscrit dans le même registre verrouillé que vous pouvez inspecter depuis la console How KODA verifies mobile money payments, de sorte que votre flux automatisé et vos contrôles manuels concordent toujours. Que le paiement soit arrivé par l'API, par un message WhatsApp ou par l'application Sentinel lisant un SMS, la même forme de webhook parvient à votre serveur, de sorte que vous n'écrivez votre logique d'exécution qu'une seule fois. Configurez votre premier endpoint sur la page KODA API for developers après avoir fait Get started with KODA free, pointez-le vers votre gestionnaire d'exécution, et laissez vos commandes commencer à se confirmer toutes seules. La version anglaise est Get a Webhook the Moment a Payment Is Verified.
KODA envoie à votre serveur un webhook signé à l'instant où la vérification réussit — sans interrogation en boucle. Voir la référence KODA API for developers.
Chaque endpoint a son propre secret de signature pour que vous puissiez vérifier l'authenticité, et les événements sont cloisonnés par marchand. Détails sur KODA API for developers.
Vérifiez votre premier paiement gratuitement → · ← tous les articles