Webhooks Stripe, PayPal ou Prestashop détournés
Une URL de notification changée envoie les événements de paiement ailleurs. Les commandes « marchent » encore : c'est pour ça que c'est silencieux. Vérifiez les endpoints chez Stripe, PayPal, PrestaShop, WooCommerce après chaque incident — et tournez les secrets.
Une URL de notification changée envoie les événements ailleurs. Vérifiez les endpoints après chaque incident. C'est silencieux : les commandes « marchent » encore.
Ce qu'un webhook fait (et pourquoi on l'oublie)
Le PSP appelle votre URL pour dire « payé », « remboursé », « litige ». La boutique met à jour la commande. Si l'URL pointe vers un tiers, le tiers apprend vos ventes (emails, montants, parfois plus) et peut répondre 200 : chez vous, rien ne change, ou un attaquant rejoue un faux « payé ». Le checkout client, lui, a l'air normal. D'où l'angle mort : on relit le JS, pas les Developers → Webhooks.
Ce n'est pas un skimmer. C'est un canal d'événements. Les deux se cumulent. Stripe, PayPal.
Les symptômes : pending éternel, ou commandes fantômes
Vrais paiements Dashboard, commandes CMS « en attente » : l'URL ne répond plus ou n'est plus la vôtre. Commandes « payées » sans txn : quelqu'un pousse de faux événements, ou un IPN tourné + un script qui force le statut. Croisez CSV PSP et export CMS sur 7 jours. Les trous datent le début.
Où lire l'URL réelle, pas celle « qu'on croit »
Toujours chez le PSP (source de vérité), puis dans le module CMS (peut diverger). Une doc interne « https://www.marque.fr/module/stripe/webhook » de 2021 ne vaut rien. Copiez l'URL affichée aujourd'hui, ouvrez-la (attention : certains endpoints GET se déclenchent — préférez lire la config sans frapper). Hôte encore le vôtre ? Chemin encore le module officiel ?
Plusieurs endpoints (un par événement, un par boutique, un Zapier). Listez-les tous. Un Zap abandonné vaut un employé fantôme.
- Liste complète côté PSP.
- Même liste côté CMS / Zapier / Make.
- Aucun hôte que vous ne pouvez pas nommer.
Secrets, signatures, et replay
Chaque endpoint a un secret de signature (`whsec_`, IPN cert, etc.). S'il a fuité (wp-config, option, git), un tiers forge des événements. Roll le secret, mettez à jour le CMS le même jour. Vérifiez que le module VALIDE vraiment la signature (certains zips « stripe » l'ignorent). Un endpoint qui accepte tout POST est une porte de commandes fantômes.
Les retries PSP : après correctif, un burst d'anciens événements peut arriver. C'est normal ; surveillez les doublons.
Stripe, PayPal, PSP banque : trois écrans
Stripe : Developers → Webhooks, journaux de livraison (code HTTP, URL). PayPal : notifications / webhooks / IPN historique. Banque : « URL de notification » dans le back-office marchand, parfois un seul champ facile à rater. Faites les trois si vous avez les trois. Informer la banque si l'URL banque avait bougé : ils doivent le savoir.
CMS : Woo, Presta, Magento
Woo : Réglages → Avancé → Webhooks + les URLs Stripe plugin. Presta : config module + parfois `ps_configuration`. Magento : config payment + cron qui « pull » au lieu de push. Les clés REST qui CRÉENT des webhooks : révoquez-les. Clés Woo, clés Magento.
SSRF et l'URL qui vise l'interne
Un attaquant qui peut changer l'URL vers `http://169.254.169.254/` ou une IP interne vise le cloud / le panel. Moins fréquent qu'un exfil vers leur serveur, plus grave. Si vous voyez une URL RFC1918, coupez, traitez comme incident infra, pas « juste un webhook ». Voir aussi SSRF webhook CMS.
Après : roll, logs, et double endpoint
Un seul endpoint prod, secret neuf, module officiel, logs PSP exportés (rétention courte). Un endpoint de debug personnel (ngrok du freelance) : mort. Relire à J+7. Créer un compte si CMS et PSP racontent deux URLs différentes et que personne n'ose trancher.
- URLs PSP = vos hôtes nommés.
- Secrets rollés, signature vérifiée.
- Zapier / Make inventoriés.
- CSV txn vs CMS recollé.
Commandes déjà mal statutées : ne pas « tout passer payé »
Après recollement, la tentation est de passer en masse les pending à « payé » pour expédier le retard. Croisez d'abord le CSV PSP. Un pending sans txn est une commande non payée — ou un client qui a payé le sosie. Un « payé » CMS sans txn est un fantôme : n'expédiez pas. PayPal.
Les retries de webhook après roll du secret peuvent créer des doublons (deux fois « payé », deux mails). Surveillez 24 h, dédoublonnez à la main les cas. Un script « replay all events » sans idempotence empire.
Documentez l'URL ancienne (celle du tiers) dans le constat : elle sert au PSP et parfois à une plainte. Ne la « pingez » pas depuis votre bureau pour voir ce qu'il y a derrière.