Définissez la véritable frontière de paiement
Cartographiez le parcours de l’acheteur depuis la page produit jusqu’à la confirmation. Indiquez le point de saisie de la carte, les redirections, les frames, les scripts, les API, les plugins, les gestionnaires de balises, les réseaux de distribution de contenu et les comptes administrateur qui peuvent l’influencer. Incluez les logs, outils de support et analytics associés. Ceci constitue un enregistrement initial pour votre prestataire ou évaluateur, ce n’est pas une décision de conformité.
Enregistrez le domaine servant chaque élément de la page de paiement. Le PCI SSC indique que l’éligibilité au SAQ A exige que tous les éléments de la page de paiement proviennent uniquement de prestataires conformes au PCI DSS et qu’aucun élément ne provienne du site marchand. Pour le SAQ A-EP, chaque élément peut provenir du marchand ou d’un tel prestataire, mais pas d’une autre source. Tous les autres critères s’appliquent toujours.
Un dépôt de code peut omettre les injections du gestionnaire de balises et les paramètres de plateforme. Passez en revue scripts, frames, domaines et en-têtes lors d’une session de checkout normale dans le navigateur.
Examinez logs, analytics et workflows de support pour les champs de paiement. N’utilisez jamais de données réelles de carte dans des tickets de test ou des preuves partagées.
Réduisez l’exposition avec un modèle de paiement explicable
Dans la mesure du possible, utilisez une intégration où un prestataire conforme au PCI DSS collecte les données de carte plutôt que votre application ne les reçoive ou les stocke. Une redirection complète vers le prestataire est souvent plus simple qu’un formulaire personnalisé, mais des champs intégrés et des iframes peuvent néanmoins laisser votre site affecter le paiement. Documentez l’intégration réelle plutôt que de vous fier à l’étiquette « hébergé ».
Évitez de conserver les numéros de compte primaires, les codes de sécurité, des captures d’écran d’erreurs de checkout ou des détails de paiement copiés, sauf si une conception approuvée l’exige. Le chiffrement protège les données, mais le PCI SSC souligne que le chiffrement seul ne suffit généralement pas à exclure un environnement du périmètre. Confirmez la gestion des tokens, clés, webhooks, remboursements et responsabilités avec le prestataire et les réviseurs qualifiés.
Conservez le guide d’intégration, les informations de responsabilité, la documentation de conformité pertinente et le processus de notification de changement avec votre dossier d’architecture.
N’ajoutez pas d’expériences marketing, d’outils de replay, de widgets de chat ou de bibliothèques optionnelles sans propriétaire nommé et revue de ce à quoi ils peuvent accéder.
Maîtrisez scripts, balises et en-têtes
Le code tiers exécuté dans le navigateur peut introduire des changements incontrôlés, une exécution arbitraire de code et des divulgations vers d’autres parties. Tenez un inventaire du checkout avec le domaine de chaque script, son but, son propriétaire, son approbation et son emplacement de chargement. Incluez les règles du gestionnaire de balises et le code chargé par les fournisseurs, pas seulement les fichiers de l’arbre source.
Le PCI SSC met l’accent sur les scripts autorisés, l’intégrité, la détection des altérations et les en-têtes HTTP impactant la sécurité. Approuvez un socle de référence, restreignez les changements, détectez les différences et enquêtez. Une Content Security Policy (CSP) peut restreindre les sources de ressources. Le cas échéant, testez-la en mode report-only avant de l’appliquer. La CSP est une défense en profondeur, pas un substitut au codage sécurisé ou à la revue.
Subresource Integrity peut rejeter un script externe modifié, mais nécessite une configuration cross-origin compatible et peut casser après des mises à jour du fournisseur.
Limitez les rôles de publication, exigez une authentification forte, vérifiez la capacité de code personnalisé et conservez une piste d’audit.
Limitez les accès et rendez les changements de checkout récupérables
Séparez la publication de contenu courante du code de checkout, de l’administration du prestataire de paiement, de l’hébergement, du DNS et de la gestion des balises. Utilisez des comptes nommés, le principe du moindre privilège et l’authentification multi‑facteurs lorsque disponible. Passez en revue les accès après un changement de rôle et supprimez les anciens employés, prestataires et agences. L’applicabilité exacte du PCI DSS dépend de l’environnement, mais réduire les privilèges partagés et permanents diminue le risque.
Utilisez un processus de déploiement pour le checkout : propriétaire nommé, revue, tests quand possible, méthode de rollback et vérification post-déploiement dans le navigateur. Testez les chemins de succès et d’échec, les redirections et le comportement mobile. Status Is UP supporte la préparation proactive au lancement, l’optimisation des performances et la planification des rollback autour des releases ; il ne détermine pas la conformité PCI DSS.
Conservez identifiants, codes de secours et instructions de rollback dans des systèmes d’accès approuvés et contrôlés, jamais dans des tickets, captures d’écran ou dépôts publics.
Après une mise en production, comparez les scripts visibles par le navigateur, les domaines et les en-têtes avec l’inventaire approuvé.
Mettez à jour la pile et vérifiez le résultat
Tenez un inventaire de la plateforme commerce, des plugins, thèmes, composants serveurs, librairies, SDKs de paiement, modèles de balises et services qui affectent le checkout. Abonnez‑vous aux avis critiques des fournisseurs. Le NIST décrit la gestion des correctifs comme l’identification, la priorisation, l’acquisition, l’installation et la vérification des mises à jour. Enregistrez le changement, testez le parcours de paiement et confirmez ce qui est déployé.
Définissez une voie d’urgence pour les problèmes à haut risque et une fenêtre de maintenance pour les changements de routine. Priorisez les composants de checkout exposés, mais ne patchez pas aveuglément en production au risque de casser les paiements. Utilisez une méthode de rollback testée et suivez les consignes de déploiement du prestataire. Un composant obsolète sans propriétaire identifié est un risque à résoudre.
Conservez ensemble l’avis, la décision de risque, le résultat de test, l’enregistrement de déploiement et la vérification finale.
Conservez les preuves et faites appel à une aide qualifiée
Conservez diagrammes, informations de responsabilité du prestataire, justification d’éligibilité SAQ, inventaires de scripts et d’en-têtes, revues d’accès, approbations, résultats de test, changements et contacts fournisseurs dans un emplacement contrôlé. Rafraîchissez-les lors d’un changement d’architecture, de propriété, de scripts ou de prestataires. Les preuves doivent aider un réviseur autorisé sans exposer de données de carte, secrets ou enregistrements clients.
Votre acquéreur ou la marque de paiement fixe les attentes de validation applicables. Le PCI SSC identifie les Qualified Security Assessors comme des organisations indépendantes qualifiées pour effectuer des évaluations PCI DSS et les Approved Scanning Vendors comme des prestataires qualifiés de scans externes sous les exigences applicables. Recherchez une aide qualifiée pour les checkout personnalisés, un périmètre incertain, une compromission suspectée ou le choix du SAQ.
Conservez le modèle de checkout, les propriétaires techniques, les contacts d’escalade, la date de dernière revue et les liens vers les preuves.