Pourquoi les webhooks sont importants
Mises à jour en temps réel
Recevez l’état des paiements sans interroger chaque transaction en continu.
Finalisation fiable
Confirmez le statut final,
success ou failed, avant d’exécuter une commande.Sécurité opérationnelle
Gérez les retries de manière idempotente pour éviter les doubles traitements.
Champs du payload webhook
| Champ | Description |
|---|---|
event | Type d’événement, par exemple payment.completed ou payment.failed |
clientId | Votre identifiant client Payfonte |
data.status | Statut de transaction, success, failed ou pending |
data.reference | Référence de transaction Payfonte |
data.externalReference | Référence fournie par le marchand, si elle existe |
data.amount | Montant de transaction en sous-unités |
data.charge | Frais de transaction appliqués |
data.provider | Slug ou nom du provider utilisé |
data.channel | Canal de paiement, par exemple card ou mobile-money |
data.user | Métadonnées client, nom, e-mail, téléphone si disponibles |
payment.completed
Vérification de signature, obligatoire
Chaque webhook inclut :- L’en-tête
x-webhook-signature - Une valeur HMAC
sha512du corps brut de la requête, signée avec votreclient-secret
client-secret depuis Settings -> API Keys/Webhooks.
Modèle de traitement idempotent
Détecter les doublons
Utilisez
reference + status, ou un identifiant de livraison si disponible, pour identifier les événements déjà traités.Vérifier la transaction si nécessaire
Pour les flux critiques, vérifiez le statut du paiement depuis votre backend avant la finalisation.
Priorité des URL webhook
Payfonte utilise les URL webhook dans cet ordre :- L’URL passée dans la requête checkout ou direct-charge via
webhook - L’URL webhook configurée sur l’intégration provider
- L’URL webhook configurée dans les paramètres du dashboard
Problèmes fréquents
| Problème | Cause probable | Correctif |
|---|---|---|
| Traitement webhook en double | Pas de garde idempotente | Stockez reference + status déjà traités et ignorez les répétitions |
| Signature invalide | Mauvais secret ou corps modifié | Utilisez le bon client-secret et hashez le corps exact reçu |
| Mises à jour manquées | Timeout de l’endpoint ou réponse non 200 | Répondez vite avec 200 et déplacez la logique lourde vers un worker asynchrone |
| Événements du mauvais environnement | Configuration sandbox et production mélangée | Utilisez les bons endpoints et identifiants pour chaque environnement |
Documentation associée
Checkout standard
Flux par redirection avec finalisation webhook.
API Direct Charge
Flux de direct charge et gestion des actions.
Autorisation
Exigences sur les identifiants et les en-têtes.