Reprendre les mentions « paiement sécurisé » après un incident
Ne remettez les badges « paiement 100 % sécurisé » qu'une fois le tunnel audité. Un pictogramme rassurant sur un checkout encore sale est un problème de confiance — et parfois de publicité trompeuse. La home peut attendre ; le HTML de paiement, non.
Ne les remettez qu'une fois le tunnel audité. Un badge rassurant sur un checkout encore sale est un problème de confiance, et parfois de publicité trompeuse.
Ce que le badge promet, concrètement
Pour un client, « paiement sécurisé » veut dire : je peux taper ma carte ici sans qu'un tiers la lise. Ce n'est pas « nous avons un certificat », ni « nous avons 3DS », ni « nous sommes sur Shopify ». Si votre HTML charge un script inconnu, le badge ment. Après un incident, le mensonge est daté : vous saviez qu'il y avait un doute. Un juge ou un reviewer PCI lira la date du bandeau d'incident et la date du badge remis : un recouvrement des deux est un problème de com, pas un détail de thème.
Les logos Visa / Mastercard / PSP ont des règles d'usage. Un logo PSP alors que le module est un clone, c'est plus qu'un problème de com. Paiement redirigé.
Pourquoi le retirer le temps du doute
Cohérence avec le bandeau « paiement indisponible » : on ne peut pas les deux. Réduction du risque « publicité trompeuse » / DGCCRF si un client se plaint. Signal interne : tant que le badge n'est pas là, personne au marketing ne « rouvre le checkout dans le footer » par oubli. Boutique fermée.
Ce n'est pas le cadenas HTTPS
Le cadenas dit que le transit est chiffré jusqu'au serveur qui termine TLS. Un skimmer chiffre aussi vers le pirate. Renouveler Let's Encrypt ne justifie pas de remettre le badge. Même discours que pour Chrome « site trompeur » : le cert n'est pas le contenu. Site trompeur.
3-D Secure n'autorise pas le slogan
Relire 3-D Secure et skimmer. Un footer « protégé par 3DS » pendant que `custom.js` écoute les champs est exactement le message à ne pas envoyer aux clients ni au SAQ. PCI.
Quand le remettre : une checklist courte
HTML checkout relu (privé, mobile, Search Console). Plus de hop hors PSP. Modules officiels. Clés et webhooks tournés. Caches vides. Un paiement de test abouti. Constat écrit (même interne). Alors seulement, badges et phrase sobre : « paiement traité par [PSP] » plutôt que « 100 % inviolable ».
Les pages CMS « Notre sécurité » se relisent : datez une mise à jour, retirez les superlatifs. Une page de 2019 qui dit « jamais d'incident » devient fausse.
- Tunnel testé propre.
- Phrase factuelle (nom du PSP), pas magique.
- Page « sécurité » datée et exacte.
Publicité, CGV, et pages « sécurité »
Ads et visuels Shopping avec le badge : pause le temps du doute, comme le checkout. Les CGV qui promettent une « sécurité maximale » : faites relire si vous communiquez largement. Ce n'est pas de la paranoïa juridique ; c'est aligner le papier et le HTML.
Marketplaces et emails transactionnels
Un email « votre paiement est 100 % sécurisé » envoyé pendant la fenêtre se retourne. Coupez les automations. Les marketplaces ont leurs propres badges : ne les copiez pas en home comme preuve que VOTRE tunnel l'est. Flux market.
Si quelqu'un a déjà screenshot le badge
Un client mécontent sortira la capture. Votre défense n'est pas « le badge était générique ». C'est : fenêtre, coupe, constat, message d'information. Tenez ce dossier. Que dire. Créer un compte pour l'audit tunnel avant de recoller les logos.
- Badges down pendant le doute.
- Remise après checklist, formulation sobre.
- Pubs et emails alignés.
- Page sécurité remise à jour.