iptables -A INPUT -p tcp --dport 443 -s 0.0.0.0/0 -j ACCEPT ne suffit jamais à garantir qu’un service tiers atteint correctement le serveur : c’est souvent l’inverse qui pose problème, quand un pare-feu a été durci après un audit de sécurité sans qu’on ait pensé à la liste des services externes légitimes. Sur une boutique WooCommerce fraîchement passée derrière un pare-feu applicatif plus strict, les paiements Stripe sont acceptés côté client mais la commande reste bloquée en statut « en attente » côté WordPress, indéfiniment.
Le paiement a pourtant bien eu lieu : le tableau de bord Stripe l’affiche comme réussi. Le problème ne vient pas de l’intégration du bouton de paiement ni de la configuration du compte marchand, mais d’un maillon plus discret, le webhook, qui est le seul canal par lequel Stripe informe le serveur qu’une transaction est confirmée.
Le rôle du webhook dans le flux de paiement
Le paiement se déroule côté navigateur du client, via l’API Stripe.js, sans jamais transiter directement par le serveur WordPress pour les données bancaires elles-mêmes. Une fois la transaction traitée, Stripe envoie une requête HTTP POST vers une URL de webhook configurée dans le tableau de bord (typiquement /wc-api/wc_stripe pour WooCommerce), qui met à jour le statut de la commande.
Si cette requête n’atteint jamais le serveur — bloquée par un pare-feu, un WAF ou une règle de géo-restriction trop agressive — WordPress n’a aucun moyen de savoir que le paiement a abouti. Aucune erreur applicative ne s’affiche, puisque le blocage se produit avant même que PHP ne soit sollicité.
Identifier le blocage
Les journaux du pare-feu (souvent /var/log/ufw.log ou les journaux d’un WAF comme ModSecurity) contiennent la trace du rejet, avec l’adresse IP source appartenant à une plage Stripe et un code de refus explicite. C’est le premier endroit à consulter avant de suspecter le code applicatif.
- Consulter les journaux du pare-feu au moment précis du paiement testé
- Comparer l’IP rejetée avec la liste officielle publiée par Stripe
- Vérifier qu’aucune règle de géo-blocage ne filtre les plages d’IP américaines par défaut
Méthode de vérification et correctif
Stripe publie et met à jour une liste d’adresses IP sortantes utilisées pour les webhooks, accessible via son API publique. Il faut autoriser explicitement ces plages dans le pare-feu, plutôt que d’ouvrir l’ensemble du port 443 à toutes les IP, ce qui annulerait l’intérêt du durcissement initial :
curl https://stripe.com/files/ips/ips_webhooks.json
Chaque IP retournée doit être ajoutée à la liste blanche du pare-feu ou du WAF, sur le port utilisé par le site (443 en HTTPS) et uniquement vers l’URL du webhook, pas sur l’ensemble du site :
ufw allow from 3.18.12.63 to any port 443 proto tcp
Une fois l’accès rétabli, il reste indispensable de vérifier la signature du webhook côté applicatif (via le secret de signature fourni par Stripe) pour s’assurer qu’ouvrir ces IP n’introduit pas de faille : la vérification de signature protège contre une requête falsifiée même depuis une IP autorisée.
Un pare-feu qui bloque un webhook de paiement ne produit jamais d’erreur visible côté client : c’est ce silence qui rend l’incident long à diagnostiquer si l’on ne pense pas à consulter les journaux du pare-feu en premier.
Ce que ça change pour la suite
La liste d’IP de Stripe évolue dans le temps ; une mise à jour manuelle du pare-feu à chaque changement est fragile. Une automatisation via un script cron qui récupère la liste officielle et met à jour les règles évite qu’un futur changement d’IP ne reproduise le même incident quelques mois plus tard.
En résumé
Un pare-feu trop strict qui bloque les rappels Stripe est une cause fréquente et sournoise de commandes bloquées, parce qu’elle ne laisse aucune trace côté applicatif. La solution passe par l’autorisation explicite des plages IP officielles de Stripe, combinée à une vérification systématique de la signature du webhook pour ne pas relâcher la sécurité obtenue par le durcissement initial.
