Module Stripe PrestaShop officiel ou « trouvé » : la différence après incident

Ce que « officiel » veut dire, concrètement

La fiche PrestaShop Addons (ou le dépôt Stripe documenté pour votre branche), un zip dont le hash correspond, un changelog, un support. Pas un Drive, pas « je te l'envoie », pas un pack « tous les modules 1.6 ». Officiel, c'est un circuit que vous pouvez reciter dans un constat.

Même l'officiel se met à jour. Une version Addons de 2019 sur un 1.7 d'aujourd'hui n'est plus un argument. Comparez le numéro, pas le logo.

Stripe, de son côté, voit des clés et des webhooks. Il ne voit pas le JavaScript de votre page paiement. Un Dashboard calme n'innocente pas un module local trafiqué.

Ce que « trouvé » veut dire, concrètement

Nulled, cracked, « version complète gratuite », zip WhatsApp de l'agence précédente. Ces archives sont un vecteur classique : le module marche, le backdoor ou le skimmer est déjà là. Vous n'avez pas été « piraté plus tard ». Vous avez installé la porte.

Après incident, réinstaller cette même archive « pour que le paiement revienne » est le geste qui referme la boucle. On jette le zip, on prend l'officiel, ou on change de module maintenu.

Nous ne disons pas comment reconnaître un payload. Nous disons : si la provenance n'est pas Addons / Stripe, on ne la remet pas. Comparez les fichiers à l'officiel ; tout écart non expliqué sort.

Comparer sans réinstaller tout de suite

Copie hors serveur d'abord. Isoler le tunnel si les clients peuvent encore payer (module off, ou étape coupée). Puis comparaison du dossier `/modules/stripe*` (le nom varie) au zip officiel de la même branche. Notez les fichiers en trop, les dates, les tailles aberrantes.

Ne « mettez pas à jour par-dessus » un nulled : vous mélangez des restes. Désinstallez proprement selon PrestaShop, posez l'officiel, retrouvez les réglages depuis le Dashboard (clés), pas depuis un backup du module sale.

Les overrides du thème peuvent charger un JS de paiement à côté du module. Relisez le thème. PrestaShop piraté.

Le checkout a tourné : qui prévenir

Si un skimmer ou un module douteux a pu voir des saisies, Stripe (support / incident), et selon le constat les clients concernés. Les dates, l'URL du checkout, le fait que le module n'était pas Addons : c'est du factuel. Stripe et boutique pirate, informer la banque.

La notification données dépend du risque, pas du logo sur le bouton. Un module nulled qui n'exfiltrait que des emails n'est pas le même dossier qu'un skimmer de PAN. Le constat tranche.

Ne dites pas publiquement « aucune carte n'a été vue » tant que l'analyse n'est pas close. Un démenti trop tôt se retourne.

Réinstaller : quelle archive, quel ordre

Site propre (fichiers cœur, autres modules, employés). Accès tournés. Puis module officiel, clés restreintes, webhook neuf. Tester une transaction à 1 € sur un CB de test. Puis seulement rouvrir le tunnel réel.

Inverser (remettre Stripe avant la fermeture) offre un checkout « qui marche » avec une porte encore ouverte. Les clients paient. L'attaquant aussi, à sa façon.

Sur un 1.6 / 1.7 obsolète, l'officiel actuel peut ne plus supporter votre branche. C'est un argument de migration, pas une excuse pour le zip Discord.

• Zip Addons / Stripe, pas le Drive.
• Nouvelles clés, ancien restrict / delete.
• Webhook signé, URL que vous contrôlez.

Clés Stripe, webhooks, et le Dashboard

Révoquez les clés inconnues, les restricted keys trop larges, les webhooks vers des hôtes que vous ne reconnaissez pas. Un attaquant n'a pas toujours besoin du module : une clé `sk_` dans un `.env` ou un fichier de config suffit. `.env`.

Activez les alertes Dashboard (nouveaux webhooks, nouvelles clés). C'est de la surveillance hors WordPress.

Un utilisateur Dashboard invité (l'agence) se révoque comme un employé PrestaShop. Même oubli, autre liste.

PrestaShop obsolète et module à jour

Un Stripe officiel récent sur un 1.6 non maintenu ne ferme pas les CVE du cœur. Il évite juste d'ajouter une porte dans le module. Les deux sujets coexistent. Ne les fusionnez pas dans un seul slogan « on a mis Stripe à jour, c'est bon ».

Si Addons ne propose plus votre branche, vous êtes déjà dans le plan de sortie. Le nulled n'est pas un pont. C'est une planche pourrie.

Un autre PSP officiellement supporté peut être un pont temporaire — officiel, documenté, pas un « module miracle » du forum.

Décider sans racheter un zip douteux

Ce soir : isoler le paiement si le doute est sérieux, copier, comparer. Pas de réinstall de l'archive WhatsApp. Pas de refonte « pour changer de PSP » dans la même nuit.

Le devis doit dire si la revue du module de paiement est incluse. Sur une boutique, elle devrait l'être. Un forfait « fichiers WordPress » sur un Presta, non.

Déclarer le site : précisez PrestaShop, la branche, et « module Stripe hors Addons » si c'est le cas. Ça change l'ordre de la première heure.