Processeur de paiement détecté

Ce que vérifie ce contrôle

Scanne la page à la recherche d’empreintes de processeurs de paiement — sources de script, origines d’iframe, globales JS — et remonte quel processeur (le cas échéant) gère le checkout. C’est informatif. Mais sa présence relève la mise sur chaque contrôle de sécurité ailleurs dans l’audit.

Pourquoi c’est important

Si nous détectons un processeur de paiement, vous prenez des détails de carte dans la session de l’utilisateur. Cela vous met dans le périmètre PCI DSS, et sur les sites en juridiction PSD2 dans le périmètre Strong Customer Authentication. Les contrôles suivants deviennent non négociables plutôt que sympas à avoir :

• HTTPS sur votre site — PCI DSS 4.2.1 exige TLS pour toute page impliquée dans la transmission de données de carte.
• Activer HSTS — empêche les attaques par downgrade qui retirent TLS des soumissions de checkout.
• Attributs de cookies sécurisés — Secure; HttpOnly; SameSite=Lax sur les cookies de session bloque le vol de token via XSS et CSRF.
• Protection clickjacking — X-Frame-Options / CSP frame-ancestors empêchent les attaquants d’encadrer votre checkout dans leur domaine pour voler les clics.

Sur un site marketing, des en-têtes de sécurité faibles sont une mauvaise forme. Sur un site qui prend des paiements, c’est une brèche qui attend et un risque d’audit.

Comment corriger

Ce contrôle est informatif, donc l’action dépend de ce qui a été détecté.

Heuristiques de détection, pour référence. MetricSpot empreinte :

• Stripe — <script src="https://js.stripe.com/v3/">, window.Stripe, iframes depuis js.stripe.com.
• PayPal — <script src="https://www.paypal.com/sdk/js">, data-paypal-button, paypal.Buttons.
• Adyen — src de script checkoutshopper-live.adyen.com, window.AdyenCheckout.
• Braintree — js.braintreegateway.com, window.braintree.
• Square — web.squarecdn.com, Square.payments.
• Mollie — js.mollie.com, Mollie(profileId).
• Razorpay — checkout.razorpay.com, window.Razorpay.
• Paddle — cdn.paddle.com, Paddle.Setup.
• Lemon Squeezy — app.lemonsqueezy.com, LemonSqueezy.Setup.

Choisissez un mode d’intégration qui réduit le périmètre PCI. Tous les grands processeurs offrent trois intégrations de checkout, en ordre du périmètre PCI le plus haut au plus bas :

1. API directe (détails carte bruts postés sur votre serveur) — PCI DSS SAQ D, ~300 contrôles. À éviter sauf si vous avez une équipe conformité.
2. Champs embarqués (Stripe Elements, Braintree Hosted Fields, Adyen Components) — les champs de carte sont iframés depuis le processeur ; votre serveur ne touche jamais le PAN. PCI DSS SAQ A-EP, ~140 contrôles.
3. Redirection / Checkout hébergé (Stripe Checkout, PayPal Smart Buttons, Paddle, Lemon Squeezy) — l’utilisateur est redirigé vers une page hébergée par le processeur. PCI DSS SAQ A, ~20 contrôles.

Pour la plupart des sites SaaS et ecommerce, le checkout hébergé est le bon défaut. Paddle et Lemon Squeezy vont plus loin en agissant comme Merchant of Record — ils gèrent la TVA UE, la sales tax US et les chargebacks. Vous abandonnez quelques points de pourcentage de marge et récupérez des semaines de travail de conformité.

Strong Customer Authentication (3DS). Si vous vendez à des clients UE/UK et utilisez des intégrations API directe ou champs embarqués, vous devez déclencher 3D Secure sur les transactions sans exemption reconnue. Stripe, Adyen et Braintree exposent tous les flags setup_future_usage / authentication_required. Testez avec les cartes de challenge 3DS côté émetteur dans le sandbox de chaque processeur avant le lancement.

Set minimal d’en-têtes de sécurité pour toute page incluant un processeur de paiement :

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'; ...
Referrer-Policy: strict-origin-when-cross-origin
Set-Cookie: session=...; Secure; HttpOnly; SameSite=Lax

Voir activer HSTS, protection clickjacking, referrer policy et attributs de cookies sécurisés pour chacun en détail.

Questions fréquentes

Nous utilisons Stripe Checkout (hébergé). PCI s’applique-t-il toujours ?

Oui — mais au plus bas périmètre (SAQ A). Vous auto-attestez annuellement que votre site n’inclut que du code de redirection/iframe contrôlé par Stripe, que vos serveurs ne voient jamais les données de carte et que votre site est servi en TLS avec des chiffrements à jour. Stripe fournit un template SAQ A pré-rempli. Le checkout hébergé ne supprime pas PCI ; il le rend assez petit pour tenir sur une seule page.

Pourquoi MetricSpot signale-t-il un processeur de paiement sur une page sans checkout évident ?

Deux cas courants : une page de tarifs qui charge js.stripe.com pour un bouton « Acheter maintenant », ou un widget footer « Donner via PayPal ». Le script est chargé sur tout le site même si le checkout n’arrive que sur une route. C’est toujours dans le périmètre — toute page qui charge du code SDK de paiement est dans le périmètre PCI pour cette page. Chargez le SDK en lazy uniquement sur la route de checkout pour réduire le périmètre.

Apple Pay ou Google Pay changent-ils les exigences ?

Ils réduisent la friction, pas les exigences. Les tokens Apple Pay et Google Pay passent par votre processeur existant (Stripe, Adyen, Braintree), et votre périmètre PCI reste au niveau SAQ que dicte votre mode d’intégration. Le SCA est automatiquement satisfait parce que le wallet lui-même est un facteur d’authentification fort — Visa et Mastercard le traitent comme une exemption d’authentification déléguée.