Le paiement redirige vers une fausse page : couper tout de suite
Le bouton « Payer » envoie ailleurs que chez votre prestataire : lookalike, page « 3-D Secure » bidon, domaine inconnu. Coupez ce module ou cette étape tout de suite. Quelques heures sans paiement valent mieux que des cartes captées. Toute la boutique n'a pas besoin de tomber.
Coupez ce module ou cette étape, pas forcément toute la boutique. Quelques heures sans paiement valent mieux que des transactions captées.
Ce que « fausse page » veut dire concrètement
Le client quitte votre checkout (ou croit y rester) et saisit sa carte sur une page qui n'appartient pas à Stripe, PayPal, votre banque, Payplug, Adyen, Systempay. Le design copie souvent le vôtre ou celui de la banque. Le cadenas peut être vert : le certificat est au nom du domaine pirate, pas au vôtre. HTTPS ne tranche pas.
Ce n'est pas le même dossier qu'un JS skimmer qui reste sur votre URL — mais l'urgence est la même : plus personne ne doit y aboutir. Si les deux coexistent (redirect + JS), traitez la redirect en premier (elle est visible), puis le HTML. Skimmer WooCommerce, skimmer PrestaShop.
Un client vous envoie une capture : gardez-la, barre d'adresse visible. C'est la pièce que le PSP et la banque comprennent.
Noter l'URL avant de toucher quoi que ce soit
Hôte, chemin, query, éventuellement le POST. Reproduisez depuis un téléphone hors Wi-Fi bureau : certaines règles ne tirent que mobile ou hors IP d'admin. Si vous ne reproduisez pas, ce n'est pas « réglé » : c'est conditionnel.
Cherchez cette URL dans le code et la base (grep) après la copie du compte, pas avant : supprimer le fichier trop tôt fait disparaître la chaîne (module → URL). Vous en aurez besoin pour le constat.
Couper le chemin, pas forcément la vitrine
Désactivez le moyen de paiement ou l'étape qui redirige. Page « paiement temporairement indisponible ». Vitrine, SEO, fiches : ouverts. Faut-il fermer la boutique. En Black Friday, le même arbitrage, plus douloureux — Black Friday.
Si la fausse page est hébergée sur VOTRE domaine (`/pay/`, `/secure/`), retirez ce chemin ou répondez 410, en plus de couper le lien depuis le checkout. Phishing hébergé.
- Moyen de paiement fautif : off.
- URL frauduleuse sur votre hôte : retirée / 410.
- Catalogue : reste 200 si le reste est propre.
Où se règle la redirection
Module de paiement (config, `redirect URL`, fichier PHP). Règle serveur (`.htaccess`, Nginx). JavaScript `location` / `window.open` dans le thème. Plugin WordPress de « checkout custom ». Employé / admin qui a changé l'URL de retour. Webhook n'est pas une redirect client, mais vérifiez-le quand même — webhooks.
Sur PrestaShop / Magento / Woo : un module fantôme est le premier suspect. Désactivez, archivez le dossier, ne le « patcher » pas. PrestaShop ordre, Magento.
Distinguer un vrai PSP d'un clone
Les domaines officiels sont documentés chez le prestataire (et changent peu). Un `stripe-secure-pay.com` n'est pas Stripe. En cas de doute, ouvrez la doc officielle depuis un favori, pas depuis un lien dans un email « votre paiement ». PayPal a le même problème de clones.
Un vrai 3-D Secure s'ouvre chez la banque / le directory serveur, pas sur un `/3ds/` de votre thème inconnu. Si l'URL 3DS n'est pas celle de votre PSP / banque, c'est faux. 3-D Secure.
Commandes déjà passées sur le faux
Ces clients ont payé un tiers. Documentez (dates, montants, captures). Ne remboursez pas « pour faire taire » sans constat : vous payez deux fois et vous n'avez pas la carte. Passez par banque / PayPal / assurance. Litiges PayPal, informer la banque.
Dans le CMS, ces commandes peuvent être « en attente » ou « payées » selon que le pirate a aussi touché les statuts / webhooks. Ne les expédiez pas sans preuve de paiement chez VOTRE PSP.
Webhooks et retours de paiement
L'URL de « payment success » peut avoir été tournée vers le pirate (il confirme, vous croyez que c'est payé) ou cassée (vos vrais paiements restent pending). Vérifiez success / cancel / IPN / webhooks chez le PSP après avoir coupé la redirect client. Les deux canaux sont indépendants.
Les clés API qui permettent de créer une session de paiement vers un `success_url` pirate se révoquent. Stripe.
Rouvrir un seul moyen officiel
Un module officiel, test de bout en bout (carte de test), HTML et URL de redirection relus, caches vidés. Puis les autres moyens. Badges « paiement sécurisé » : après seulement — mentions.
Créer un compte si la chaîne de redirect n'est pas évidente (plusieurs modules, marketplace, headless).
- Plus aucun hop vers un hôte non PSP.
- Clients de la fenêtre documentés, pas remboursés à l'aveugle.
- Webhooks / success URL recollés.
- Un moyen de paiement testé propre.