Litiges PayPal après une boutique compromise
Des clients ont payé un tiers, ou contestent un débit après un checkout sale. Documentez, prévenez PayPal par le canal adéquat, ne remboursez pas « dans le vide » sans constat. Le dossier sert aussi à votre banque et à l'assurance.
Des clients ont payé un tiers. Documentez, prévenez PayPal, ne remboursez pas « dans le vide » sans constat. Le dossier sert aussi à votre banque.
Trois litiges qui ne se ressemblent pas
(1) Le client a payé sur une fausse page : l'argent n'est jamais arrivé chez vous, ou un sosie a encaissé. (2) Le client a payé chez le vrai PayPal, mais un skimmer a aussi vu sa carte : le débit est légitime côté boutique, la fraude carte viendra plus tard via la banque. (3) Un attaquant a utilisé VOTRE compte PayPal (changement d'email, nouveaux utilisateurs, redirection d'encaissement). Les trois se mélangent dans la bouche des gens (« PayPal hacké »). Triez avant d'écrire au support.
Pour (1), votre CMS peut montrer des commandes « en attente » : n'expédiez pas. Pour (2), les paiements Dashboard / historique PayPal sont réels : traitez la vente, et le volet cartes à part. Pour (3), c'est un incident compte, 2FA et users, en plus du site.
Cadre technique : paiement redirigé, skimmer, webhooks.
Ce que PayPal verra dans votre compte
Transactions abouties chez eux, réclamations, chargebacks, parfois l'URL de retour configurée, les IPN. Ils ne voient pas un JS sur votre page PrestaShop. « Notre risque est nominal » n'innocente pas votre HTML. Inversement, un pic de réclamations « article non reçu » peut n'être que de la fraude acheteur classique — le constat site tranche.
Exportez l'historique de la fenêtre (CSV). Croisez avec les commandes CMS. Les trous (commande CMS sans txn PayPal, txn sans commande) racontent la redirect ou le webhook tourné.
Ne pas rembourser au hasard
Attendez le constat : qui a encaissé, quelle URL, quelle fenêtre. Un avoir CMS sans mouvement PayPal ne rembourse personne. Un refund PayPal sur une txn réelle, c'est de l'argent. Documentez chaque geste (id de transaction, motif). L'assurance et le comptable vous le redemanderont.
Les messages clients : un modèle unique (fenêtre, de surveiller les relevés, ticket interne) évite dix versions contradictoires. Que dire.
Preuves à rassembler avant le premier message
Captures d'URL, HTML checkout, fenêtre de dates, liste des txn, export commandes, ticket hébergeur si abus, constat si vous en avez un. Canal : centre de résolutions + support business / security, pas un tweet. Gardez les IDs de cas.
Si des clients ont payé un sosie, PayPal peut parfois aider sur LEUR réclamation acheteur — ce n'est pas votre remboursement vendeur. Orientez-les sans promettre un résultat.
- CSV PayPal + export CMS, même fenêtre.
- Captures barre d'adresse.
- Liste des URL de notification actuelles.
IPN, webhooks et URL de retour
L'IPN / les webhooks PayPal disent à la boutique « payé ». Une URL tournée crée des commandes fantômes ou empêche les vraies de passer. Vérifiez dans le compte PayPal (et dans le module CMS) après chaque incident. Tournez les secrets. Webhooks.
Les `return` / `cancel` URLs du bouton : si elles pointent vers un hôte tiers, le client « revient » chez le pirate après paiement. Corrigez en même temps que le checkout.
Compte PayPal pris vs site pris
Users secondaires, changement d'email de contact, nouvel IBAN / carte de payout, applications tierces connectées : c'est le compte. Mot de passe, 2FA, révocation des apps, appel au support compte compromis. Le site peut être propre et le compte sale — et l'inverse.
Les identifiants PayPal dans un module CMS (Client ID / Secret) se rollent comme des clés Stripe. Un secret dans un zip de staging a fuité. Compte SMTP / secrets CMS — même réflexe, autre secret.
Chargebacks carte et réclamations PayPal
Deux tuyaux, délais différents. Une carte saisie sur un skimmer puis utilisée ailleurs fera un chargeback banque, parfois des mois après. Gardez le constat : il sert de contexte, rarement de « win » automatique. Ne construisez pas une défense « 3-D Secure donc impossible » — 3-D Secure.
Répondez dans les délais PayPal même si le dossier technique n'est pas clos : « incident en cours, pièces à suivre, voici ce qui est déjà établi » vaut mieux qu'un silence.
Aligner le discours clients / PayPal / banque
Même fenêtre, même niveau de certitude (« possible » vs « établi »). Un client à qui vous dites « aucune fuite » et un ticket PayPal qui dit « skimmer probable » vous explose au visage. Banque, CNIL / données.
Pour un constat à joindre aux cas, créez un espace.
- Type de litige tranché (sosie / skimmer / compte).
- Aucune expédition sans txn réelle chez vous.
- IPN et secrets relus.
- Discours unique sur la fenêtre.