Sources : documentation Cloudflare (Security rules, options de l'action Skip, IP Access rules, Bot Fight Mode, Security Events), code des modules Payplug PrestaShop, WooCommerce, Magento 2 et Sylius.
En bref : une règle d'exception WAF posée sur l'adresse de notification, avec tous les composants ignorés, débloque la grande majorité des cas. Sur le plan Free de Cloudflare, Bot Fight Mode demande une étape supplémentaire, parce qu'aucune règle ne peut le neutraliser.
Les libellés cités dans cet article sont ceux du tableau de bord Cloudflare en anglais.
Le symptôme
Vous recevez un mail Erreur de notification pour vos commandes, environ vingt-cinq minutes après le paiement. Dans le portail Payplug, la ligne de la transaction affiche un code de réponse 403. Vos commandes restent en attente de paiement dans votre CMS.
Le paiement, lui, est encaissé normalement : seule la transmission vers votre site a échoué. Rien n'est à rembourser, et les commandes concernées se débloquent en mettant leur statut à jour.
Après le premier envoi, Payplug renvoie la notification jusqu'à cinq fois, toutes les cinq minutes. Passé ce délai, elle n'est plus rejouée : la dernière tentative a lieu environ vingt-cinq minutes après le paiement, et c'est elle qui déclenche le mail d'erreur.
Vérifier que le blocage vient bien de Cloudflare
Consultez les logs d'accès et les logs d'erreur de votre serveur (disponibles auprès de votre hébergeur) : une notification récente, en indiquant l'identifiant du paiement (pay_...). Deux signes ne trompent pas :
- la réponse porte l'en-tête
Server: cloudflareet un identifiantCF-RAY; - son contenu est une page de challenge Cloudflare, titrée
Just a moment..., ou une page de blocage Cloudflare.
Un 403 sans ces éléments vient d'ailleurs : pare-feu applicatif de votre hébergement, module de sécurité de votre CMS, règle serveur. Cet article ne s'applique pas.
Créer la règle d'exception
1. Relever l'adresse de notification
Elle dépend de votre plateforme.
| Plateforme | Adresse de notification |
|---|---|
| PrestaShop | /module/payplug/ipn |
| WooCommerce | /wc-api/PayplugGateway |
| Magento 2 | /payplug_payments/payment/ipn |
| Sylius | /payplug/ipn |
Sur WooCommerce, cette forme suppose les permaliens activés. Sans permaliens, l'adresse devient /?wc-api=PayplugGateway et le filtre sur le chemin ne fonctionne pas : il faut alors filtrer sur l'URI complète.
En cas de doute, lisez l'adresse directement dans Cloudflare. Ouvrez Security > Analytics, onglet Events, et filtrez sur le champ User Agent avec la valeur PayPlug-IPN, qui est l'agent utilisateur de nos serveurs de notification. Les requêtes affichées portent le chemin exact à reprendre.
2. Créer la règle
- Dans le tableau de bord Cloudflare, ouvrez la page Security rules.
- Choisissez Create rule > Custom rules.
- Nommez la règle, par exemple
Payplug IPN. - Dans l'expression, choisissez le champ URI Path, l'opérateur contains, et saisissez le chemin relevé à l'étape 1.
- Dans Choose action, choisissez Skip.
- Cochez la totalité des composants proposés : All remaining custom rules, All rate limiting rules, All managed rules, All Super Bot Fight Mode rules, Zone Lockdown, User Agent Blocking, Browser Integrity Check, Hotlink Protection, Security Level, Rate limiting rules (Previous version), Managed rules (Previous version).
- Laissez Log matching requests activé. C'est ce qui rend la règle visible dans Events pour la suite du diagnostic.
- Déployez la règle.
- Placez-la en première position dans la liste des custom rules. Une règle Skip ne neutralise que les règles situées après elle.
Déployez la règle sur la zone qui reçoit réellement les notifications. Si votre boutique répond sur www, c'est cette zone qui compte.
3. Vérifier
Passez une commande de test, ou attendez la suivante. Si vous ne recevez plus de mail Erreur de notification et que le portail affiche un code de réponse 200 sur la transaction, c'est réglé.
Cette règle ne couvre pas tout
Deux mécanismes Cloudflare échappent à l'action Skip, quelles que soient les cases cochées.
Bot Fight Mode, disponible sur le plan Free, tourne en dehors du moteur de règles : les actions Skip, Bypass et Allow n'ont aucun effet sur lui. Il envoie un challenge aux requêtes qu'il identifie comme automatisées, ce que sont nos notifications par nature.
Les IP Access rules ne sont jamais ignorées par une règle Skip. Une entrée en Block ou en Managed Challenge qui attrape nos serveurs bloquera les notifications malgré la règle d'exception.
Si le blocage persiste
Confirmer le composant responsable
Demandez à Payplug l'identifiant CF-RAY d'une notification en échec récente. Dans Cloudflare, ouvrez Security > Analytics, onglet Events, ajoutez un filtre Ray ID avec cette valeur, et lisez la colonne Service : elle nomme le produit qui a pris la décision.
Sur le plan Free, les événements de sécurité ne sont conservés que vingt-quatre heures. Faites cette recherche le jour même.
Si la colonne Service indique Bot Fight Mode
Trois options, de la moins invasive à la plus lourde.
Autoriser les IP de nos serveurs de notification. Bot Fight Mode ne se déclenche pas lorsqu'une IP Access rule correspond d'abord à la requête. Ouvrez la page Security rules, choisissez Create rule > IP access rules, saisissez l'IP dans IP, IP range, country name, or ASN, choisissez l'action Allow, puis Create. Une entrée par IP :
52.17.55.154 52.209.87.92 54.77.126.191
Cette autorisation ne concerne que ces trois adresses et ne change rien au reste de votre trafic.
Désactiver Bot Fight Mode. Ouvrez la page Security Settings, filtrez sur Bot traffic, et passez Bot fight mode sur off. La protection tombe alors pour l'ensemble du site : si votre site subit du trafic automatisé agressif, planifiez l'opération et surveillez la charge.
Passer sur un plan Pro. Super Bot Fight Mode, lui, tourne dans le moteur de règles et se neutralise par une règle Skip.
Problèmes courants
| Symptôme | Origine probable | Que faire |
|---|---|---|
Le mail d'erreur continue après la règle, et la réponse contient une page Just a moment...
|
Bot Fight Mode, sur le plan Free | Autoriser les IP du Notifier en IP Access rule, ou désactiver Bot Fight Mode |
Aucune requête sur PayPlug-IPN dans Events
|
L'expression de la règle ne correspond pas au chemin réel, ou la zone n'est pas la bonne | Relever à nouveau le chemin et la zone à l'étape 1 |
Le 403 ne porte ni CF-RAY ni Server: cloudflare
|
Pare-feu de l'hébergement ou module de sécurité du CMS | Voir avec votre hébergeur ou votre agence |
Pourquoi cette exception ne fragilise pas votre site
Notre module ne fait pas confiance au contenu de la notification. Il récupère le paiement depuis l'API Payplug, en HTTPS authentifié, avant de toucher quoi que ce soit à la commande. Une fausse notification envoyée à cette adresse ne produit donc aucun effet, même si le WAF la laisse passer.
Apple Pay, un sujet distinct
La vérification du domaine Apple Pay passe par un autre mécanisme, avec ses propres adresses IP. Elle se traite dans l'article "Comment whitelister les IPs Apple pay sur votre compte Cloudflare".
Si rien de tout cela ne débloque
Contactez le support Payplug avec ces quatre éléments :
- l'identifiant du paiement (
pay_...) et sa date ; - l'identifiant
CF-RAYde la notification en échec ; - une capture de Events filtré sur ce Ray ID, colonne Service visible ;
- une capture de la règle d'exception ouverte, composants cochés visibles.