En bref: conformité PCI DSS avec Stripe
- Stripe gère la conformité PCI DSS Niveau 1 pour le traitement de carte lui-même, ce qui explique que les marchands disent souvent qu'ils sont 'conformes PCI avec Stripe'. C'est vrai à moitié.
- Les marchands restent responsables des exigences PCI DSS 4.0.1 6.4.3 et 11.6.1 sur leur propre site même quand Stripe traite la carte. Elles couvrent l'inventaire des scripts et la détection d'altération des pages de paiement sur votre domaine.
- Stripe Elements minimise mais n'élimine pas le périmètre du marchand. Les marchands SAQ-A utilisant Stripe Elements doivent toujours satisfaire 6.4.3 et 11.6.1, et le palier gratuit cside couvre les deux.
Oui, Stripe détient la certification PCI DSS Niveau 1, le niveau le plus élevé disponible. Cette certification couvre l'infrastructure de Stripe. Elle ne couvre pas votre site web. Si votre page de paiement charge un script que vous contrôlez, analytics, chat en direct, gestion du consentement, tests A/B, deux exigences de PCI DSS 4.0.1 restent de votre responsabilité que Stripe ne peut pas satisfaire en votre nom : §6.4.3 et §11.6.1.
Ce que couvre réellement la conformité PCI de Stripe
Le statut de prestataire de services Niveau 1 de Stripe est vérifié chaque année par un évaluateur de sécurité qualifié (QSA) et inscrit sur le Registre mondial des prestataires de services Visa. La certification confirme que les centres de données, les systèmes de traitement des cartes et l'infrastructure interne de Stripe répondent aux normes PCI DSS.
Ce que cela couvre :
- La transmission et le stockage des données de carte au sein des systèmes de Stripe
- Les iframes Stripe Checkout et Elements, qui se chargent depuis le domaine certifié PCI de Stripe
- Les SDK mobiles et Terminal de Stripe
Ce que cela ne couvre pas :
- Le JavaScript exécuté sur vos pages web dans les navigateurs de vos clients
- Les scripts d'analytics, de chat, de consentement ou tout autre script tiers sur les pages qui redirigent vers un formulaire de paiement
- Vos en-têtes de sécurité HTTP ou configurations de cookies
La limite, c'est les serveurs de Stripe. Votre page de paiement, celle qui collecte ou redirige les données de carte, s'exécute dans les navigateurs de vos clients, et cette surface vous appartient.
Comment être conforme en utilisant Stripe
Les produits de Stripe sont conçus pour gérer les données de carte sensibles de manière sécurisée, réduisant ainsi la portée de vos responsabilités PCI DSS :
- Stripe Checkout et Elements : Ces outils utilisent des champs de paiement hébergés, garantissant que les informations de paiement sensibles sont transmises directement aux serveurs validés PCI DSS de Stripe sans toucher vos serveurs.
- SDK mobiles et Terminal : Les SDK de Stripe pour les paiements mobiles et en personne envoient également les informations sensibles directement à Stripe, minimisant votre périmètre PCI.
| Intégration Stripe | SAQ requis | Raison |
|---|---|---|
| Stripe Checkout (page de paiement hébergée) | SAQ A | Aucune donnée de titulaire de carte ne touche votre serveur |
| Stripe Elements (champs intégrés)* | SAQ A* | Elements transmet les données de manière sécurisée à Stripe* |
| Stripe.js v2 avec interface personnalisée | SAQ A-EP* | Votre frontend affecte la sécurité des transactions |
| API directe (données de carte sur votre serveur) | SAQ D | Vous stockez, traitez et/ou transmettez des données de carte |
*Vous devez maintenant surveiller les dépendances sur les pages de paiement, voir ci-dessous.
- Si vous utilisez Stripe Checkout (page de paiement hébergée), vous êtes éligible au SAQ A.
- Si vous utilisez Stripe Elements (champs intégrés qui envoient les données directement à Stripe), vous êtes éligible au SAQ A.
- Si vous utilisez les SDK mobiles ou Terminal de Stripe, les données de paiement sont traitées de manière sécurisée par Stripe, vous maintenant dans le SAQ A.
- Si vous collectez et stockez des données de titulaire de carte ou utilisez une intégration API directe, vous devez compléter le SAQ D et mettre en œuvre tous les contrôles PCI.
Si vous êtes éligible au SAQ A, vos responsabilités PCI DSS sont minimales car Stripe gère les données de carte sensibles.
Si vous nécessitez le SAQ A-EP ou le SAQ D, vous assumez plus de responsabilités pour sécuriser les transactions.
Quelles exigences PCI DSS Stripe ne couvre pas
PCI DSS 4.0.1 a introduit deux exigences ciblant la couche navigateur, toutes deux obligatoires depuis le 31 mars 2025 :
Exigence 6.4.3, Autorisation des scripts sur les pages de paiement
Vous devez tenir un inventaire documenté de chaque script autorisé à s'exécuter sur vos pages de paiement. Pour chaque script, vous avez besoin d'une méthode permettant de confirmer son intégrité, que le code n'a pas été modifié depuis votre dernière vérification. Cela s'applique aux scripts propriétaires comme aux scripts tiers (analytics, chat de support, outils de tests A/B).
Exigence 11.6.1, Détection des modifications des en-têtes HTTP
Vous devez déployer un mécanisme qui détecte les modifications non autorisées des en-têtes de sécurité HTTP et des attributs de cookies sur vos pages de paiement et génère des alertes.
Stripe n'a aucune visibilité sur ces scripts ou ces en-têtes. Les deux exigences concernent ce qui se passe dans les navigateurs de vos clients sur votre page web, une surface entièrement en dehors de l'environnement de Stripe.
La mise à jour de janvier 2025 du PCI Security Standards Council sur le SAQ A l'a confirmé : même les marchands utilisant Stripe Checkout entièrement hébergé doivent satisfaire §6.4.3 et §11.6.1 si leur flux de paiement passe par une page chargeant des scripts externes. Consultez notre analyse de la mise à jour SAQ A de janvier 2025 pour plus de détails.
Surveillance des scripts pour la conformité SAQ A
Selon la mise à jour de janvier 2025, le Conseil des normes de sécurité PCI a souligné l'importance de surveiller les dépendances. Cela inclut les scripts propriétaires et tiers sur les sites web.
Un moniteur côté client satisfait §6.4.3 et §11.6.1 en s'exécutant dans les navigateurs de vos clients, en inventoriant chaque script à chaque visite de la page de paiement et en alertant lorsqu'un script change ou qu'un nouveau apparaît. cside surveille les scripts et les en-têtes HTTP dans les navigateurs des visiteurs réels, y compris les charges utiles conditionnelles qui semblent propres aux scanners mais s'activent en trafic de production.
Veuillez trouver la documentation de Stripe concernant PCI DSS ici.
Lecture connexe : notre guide de conformité PCI DSS 6.4.3 et 11.6.1 · les responsabilités PCI DSS partagées d'Adyen
Déterminez votre niveau de conformité PCI
| Niveau | Critères | Exigence de validation |
|---|---|---|
| Niveau 1 | Plus de 6 millions de transactions annuelles | Audit complet sur site par un QSA + SAQ D |
| Niveau 2 | 1 à 6 millions de transactions annuelles | SAQ A, SAQ A-EP ou SAQ D + Attestation de conformité (AOC) |
| Niveau 3 | 20 000 à 1 million de transactions en ligne annuelles | SAQ A, SAQ A-EP ou SAQ D + Attestation de conformité (AOC) |
| Niveau 4 | Moins de 20 000 transactions en ligne OU jusqu'à 1 million de transactions totales | SAQ A, SAQ A-EP ou SAQ D + Attestation de conformité (AOC) |
- Niveau 1 = Doit effectuer un ROC (évaluation PCI DSS complète avec rapport complet de conformité par QSA)
- Niveau 2 = Doit effectuer au moins un SAQ avec attestation QSA ou ISA tierce
- Niveau 3 = Doit effectuer un SAQ
- Niveau 4 = Optionnel
L'Attestation de Conformité PCI DSS pour les marchands Stripe
L'Attestation de Conformité PCI DSS (AoC) pour un marchand Stripe est un document qu'un QSA (ou un signataire interne autorisé sous SAQ) produit à la fin d'un cycle d'évaluation, indiquant à quel niveau SAQ le marchand se qualifie et que tous les contrôles applicables sont en place. Pour la plupart des marchands e-commerce Stripe, cela signifie une attestation SAQ A (page de paiement entièrement externalisée) ou SAQ A-EP (checkout hébergé sur le site du marchand).
Le point opérationnel important est que l'AoC de Stripe couvre Stripe. Elle ne couvre pas le marchand. Même en utilisant Stripe Elements ou Checkout, le marchand conserve une obligation d'AoC parce que la page de paiement s'exécute sur le domaine du marchand et que le marchand est responsable des scripts chargés sur cette page au titre de 6.4.3 et 11.6.1. Les équipes achats enterprise demandent fréquemment les deux AoC lors de l'onboarding fournisseur.
cside fournit la piste de preuves qui soutient l'AoC SAQ A ou SAQ A-EP du marchand lui-même : inventaire continu des scripts, surveillance d'intégrité et preuves 6.4.3 / 11.6.1 prêtes pour l'audit qu'un QSA peut extraire sans précipitation.
Identifiez votre type d'intégration et la documentation requise
Complétez le SAQ approprié Une fois que vous avez identifié le bon SAQ en fonction de votre méthode d'intégration, complétez-le minutieusement. Stripe fournit un assistant PCI dans votre tableau de bord pour vous guider.
Soumettez votre documentation Après avoir complété le SAQ, soumettez-le avec toute attestation de conformité (AOC) ou rapport de conformité (ROC) requis à Stripe pour examen.
Maintenez une conformité continue La conformité PCI nécessite une surveillance continue. Vérifiez régulièrement votre inventaire de scripts, tenez votre SAQ à jour et surveillez les en-têtes de la page de paiement pour détecter les modifications non autorisées.
Le même écart entre la certification du processeur et l'obligation du marchand s'applique lors de l'utilisation d'Adyen ou de PayPal et Braintree comme processeur de paiement.
