Intégrations et événements
Webhooks de réservation : traiter les événements sans doubler une vente
Un paiement, une confirmation fournisseur et une annulation peuvent arriver par des chemins différents. Un événement reçu n’est pas encore un dossier cohérent : il faut l’authentifier, l’enregistrer, le dédupliquer et le rapprocher de l’état réel.
Réponse directe
Un webhook signale un changement, il ne clôt pas le dossier
Une plateforme peut envoyer un événement quand le paiement est confirmé, puis une autre source confirme ou refuse la prestation. Enregistrer immédiatement « voyage confirmé » au premier signal crée une promesse prématurée. Le dossier doit distinguer demande reçue, paiement, confirmation fournisseur, documents émis et notification au voyageur.
La documentation Stripe sur les webhooks décrit la possibilité de livraisons répétées et d’événements reçus hors ordre. La méthode reste valable pour toute intégration événementielle, avec les garanties propres à chaque partenaire.
Séparer réception, validation et action métier
- Vérifier l’origine et l’intégrité selon le mécanisme documenté par le partenaire.
- Enregistrer l’identifiant, le type, l’objet concerné et l’heure de réception.
- Accuser réception rapidement, puis traiter dans une file contrôlée.
- Dédupliquer la livraison et vérifier que l’action métier n’a pas déjà été appliquée.
- Relire l’état courant de l’objet si l’événement est incomplet ou ancien.
La clé de déduplication doit couvrir la livraison répétée. Pour certaines sources, deux événements distincts peuvent parler de la même action ; il faut alors contrôler aussi l’objet et le type d’événement. La clé métier de réservation ou de remboursement doit rester stable à travers les relances.
Modéliser les états et les désaccords
| Signal reçu | Contrôle nécessaire | État prudent |
|---|---|---|
| Paiement accepté | Prestation confirmée ? | À rapprocher |
| Réservation fournisseur confirmée | Montant et prestation concordants ? | Confirmée si contrôle passé |
| Annulation demandée | Fournisseur et paiement mis à jour ? | En traitement |
| Remboursement reçu | Montant et dossier associés ? | Rapproché si complet |
Un événement inconnu ou incohérent doit rester observable, sans écraser un état confirmé plus récent. Prévoyez un outil de rejeu et un rapprochement périodique entre le système local et la source.
Une recette avec des événements difficiles
Livrez deux fois la même notification, inversez l’ordre de paiement et de confirmation, coupez la réponse du fournisseur, puis renvoyez un événement ancien après une annulation. Vérifiez le nombre de dossiers, de paiements et de messages envoyés. Aucun rejeu ne doit créer une vente supplémentaire ou effacer l’historique d’une correction.
Une matrice événement → contrôle → transition autorisée, accompagnée d’un journal consultable et d’une procédure de rapprochement.
Suivre les retards et les états orphelins
Comptez les événements reçus, appliqués, ignorés comme doublons et placés en erreur. Alertez sur une file qui vieillit ou sur un paiement sans dossier confirmé. Préservez dans le journal les références utiles au support, mais limitez les données personnelles conservées. Une revue périodique doit comparer les états locaux aux sources externes même lorsque tous les webhooks semblent avoir été reçus.
Questions fréquentes
Questions utiles avant de décider
Peut-on créer la réservation à chaque événement de paiement réussi ?
Non. La même notification peut être livrée plusieurs fois. Associez l’événement à une opération identifiée et rendez l’action métier idempotente.
Les événements arrivent-ils toujours dans l’ordre ?
Il ne faut pas le supposer. Le traitement doit savoir retrouver l’état courant auprès de la source et gérer un événement ancien ou manquant.
Que faire si le fournisseur ne répond plus ?
Conservez l’événement, placez le dossier dans un état vérifiable, relancez de façon contrôlée et faites remonter les cas qui exigent une intervention humaine.
