Stripe et site piraté : ce qu'il faut dire à Stripe
Si un skimmer a pu voir des cartes sur votre checkout, prévenez Stripe avec la fenêtre de dates. Ils peuvent marquer des paiements, poser des questions, parfois limiter le compte. Un silence « pour ne pas affoler » se retourne. Voici quoi envoyer, et quoi tourner chez vous.
Si un skimmer a pu voir des cartes, prévenez Stripe avec la fenêtre de dates. Ils peuvent marquer des paiements. Un silence « pour ne pas affoler » se retourne.
Ce que Stripe a besoin d'entendre
Des faits : vous opérez tel compte Stripe (ID `acct_`), tel site, tel intervalle où un HTML de checkout sale ou une redirection hors Stripe est établi, volume approximatif de sessions / paiements, ce qui a été coupé, un constat ou des captures. Pas un roman, pas « on pense que peut-être ». S'il n'y a pas de doute cartes (défacement home sans toucher au tunnel), dites-le aussi : un ticket honnête vaut mieux qu'un silence, et mieux qu'une panique inventée.
S'il y a doute cartes, ne minimisez pas « on ne stocke pas les CB ». Stripe le sait. Le skimmer lit le navigateur. Phrase utile : champs carte potentiellement exposés sur notre page entre telle et telle date ; paiement ensuite éventuellement passé chez vous / ou non.
Joignez l'URL du script ou de la fausse page si vous l'avez. Ça accélère leur qualification. Cadre boutique : PrestaShop, Magento, WooCommerce skimmer.
Fenêtre de dates : comment la caler
Début : premier indice datable (HTML Search Console, cache, premier client, log d'écriture du JS). Fin : coupure du script / de la redirect + purge des caches +, idéalement, retest propre. Si vous ne savez pas le début, donnez la borne haute honnête (ex. « présent au moins depuis le dump du 12, inconnu avant ») plutôt qu'une date marketing trop courte.
Cette fenêtre part aussi à la banque et aux clients. Alignez les trois discours. Informer la banque, clients.
Le canal incident, pas le chat grand public
Support Stripe via le Dashboard, formulaire d'incident / security, l'email de votre account manager si vous en avez un. Le chat « why is my payout delayed » n'est pas le bon tiroir. Gardez le numéro de ticket. Relancer toutes les heures n'accélère pas ; un complément factuel (nouveau HTML, date de purge) si.
Si le compte Stripe lui-même a été pris (changement de bank account, nouveaux business users, clés créées), c'est un second incident : 2FA, users Dashboard, mot de passe, toutes les clés. Ce n'est plus seulement le site.
Clés, restricted keys et webhooks
Developers → API keys : roll `sk_live`, archivez les anciennes, tournez les restricted keys. Un `sk_live` dans un plugin, un `.env` du staging, un Zapier, un wp-config, un prestataire : tous les consommateurs doivent recevoir la nouvelle, ou être coupés. Une clé oubliée dans un staging vaut un employé fantôme.
Webhooks : chaque endpoint, URL encore la vôtre, secret tourné. Un endpoint vers un tiers reçoit `payment_intent.succeeded` en silence. Webhooks détournés. Les journaux d'événements Stripe aident à voir les appels échoués / vers une URL inconnue (historique limité : exportez tôt).
Connect / comptes liés : si vous êtes plateforme, le périmètre s'élargit. Dites-le dans le ticket.
- Toutes les clés live rollées.
- Webhooks listés, secrets tournés.
- Users Dashboard et 2FA relus.
Ce que Stripe voit (et ne voit pas)
Stripe voit les paiements qui arrivent chez eux, les métadonnées, les webhooks qu'ils envoient, Radar. Ils ne voient pas un JS sur votre page qui copie la carte avant Checkout / Elements, ni une fausse page hors de leur domaine. « Nos logs sont clean » est compatible avec un skimmer chez vous. Ne le prenez pas pour un feu vert HTML.
Inversement, des charges frauduleuses (cartes volées ailleurs) existent sans skimmer. Le HTML sale + un pic de disputes oriente ; un seul des deux, pas de conclusion unique.
Radar, disputes et « account hacked »
Un pic de `fraudulent` / `unrecognized` après un skimmer est attendu, avec délai. Documentez pour chaque dispute ce que vous savez (fenêtre, constat) plutôt que de contester en masse à l'aveugle. Stripe peut demander un SAQ ou des pièces — PCI-DSS.
Si quelqu'un a pris le Dashboard et a créé des paiements / changé le payout, dites « account compromise » clairement, en plus du site. Les deux se traitent ensemble, preuves séparées.
Votre checkout vs le Dashboard
Checkout Stripe hébergé (redirection vers `checkout.stripe.com`) réduit la surface de champs sur votre HTML. Ça n'annule pas une redirect amont vers un clone, ni une clé volée qui crée des sessions vers un `success_url` pirate. Relisez la chaîne complète. Elements / Payment Element : surface plus large sur votre domaine — le HTML compte davantage.
Les plugins CMS (Woo, Presta, Magento) : comparez à l'officiel, révoquez les clés du plugin, recollez les nouvelles après nettoyage. Un plugin nulled avec une « clé Stripe » déjà dedans est un incident à part.
Après le ticket : ce qui reste à vous
Nettoyer le site, informer selon le constat, CNIL si dû (fuite), clients, banque. Stripe ne le fait pas à votre place. Ils peuvent limiter les payouts le temps des questions : prévoyez la trésorerie, ce n'est pas une rançon, c'est leur risque.
Pour un constat HTML + clés à joindre au ticket, créez un espace.
- Ticket Stripe factuel, fenêtre écrite.
- Clés et webhooks tournés.
- HTML checkout propre avant de rouvrir.
- Discours aligné banque / clients.