Un système de réservation qui encaisse : Stripe et les webhooks

Un site qui « existe » et un site qui « rapporte », ce n'est pas le même métier. Le premier affiche des informations. Le second encaisse de l'argent, confirme des commandes et ne se trompe jamais sur l'état d'un paiement. Sur des projets comme Nameste, c'est cette deuxième partie qui demande le plus de soin.

Le vrai sujet : l'état du paiement

Quand un client clique sur « payer », plein de choses peuvent arriver. Il paie et tout va bien. Il paie mais ferme l'onglet avant le retour. Sa carte est refusée. Le réseau coupe. Le paiement réussit côté banque mais l'utilisateur ne revient jamais sur votre site.

Si vous décidez de l'état de la commande uniquement sur la page de retour, vous vous trompez tôt ou tard. La page de retour, c'est pour l'expérience utilisateur. La vérité sur le paiement vient d'ailleurs.

Les webhooks, source de vérité

C'est là que les webhooks Stripe entrent en jeu. Plutôt que de croire le navigateur, on écoute Stripe directement : un événement checkout.session.completed arrive sur le serveur quand le paiement est réellement confirmé, indépendamment de ce que fait l'utilisateur.

Client → Stripe Checkout → (paiement) → Stripe envoie un webhook → serveur
                                                     ↓
                                       commande passée en "payée"

Le serveur écoute, vérifie la signature de l'événement (pour être sûr que ça vient bien de Stripe), puis met la commande à jour. L'utilisateur peut fermer son onglet : la commande est quand même enregistrée correctement.

Vérifier la signature, toujours

Un webhook, c'est une URL publique. N'importe qui peut lui envoyer une fausse requête « paiement réussi ». Sans vérification, on offre des commandes gratuites au premier curieux venu.

Stripe signe chaque événement. Le serveur recalcule la signature avec une clé secrète et compare. Si ça ne correspond pas, on refuse. C'est non négociable : un endpoint de webhook de paiement sans vérification de signature, c'est une porte ouverte.

L'effet sur le business

Une fois ce socle posé, le reste suit : confirmations automatiques, moins de réservations fantômes grâce à l'acompte payé en ligne, et un tableau de bord pour suivre commandes et paiements sans toucher au code.

Le déclic, c'est de comprendre que la réservation en ligne n'est pas un formulaire, c'est une machine à états qui doit rester juste même quand l'utilisateur fait n'importe quoi.

Ce que j'en retiens

Traiter le paiement comme une partie critique du système, pas comme une case à cocher en fin de tunnel. Les webhooks, la vérification de signature et les états de commande explicites ne sont pas du luxe : c'est le minimum pour qu'un site « rapporte » vraiment.

Si vous voulez transformer un site vitrine en canal de vente, écrivez-moi ou jetez un œil à qui je suis.