Ce qu'Adyen couvre face à ce qui reste à votre charge
Adyen, comme tout processeur PCI DSS de niveau 1, atteste le code qui s'exécute à l'intérieur de sa propre iframe. Il n'atteste pas la page qui l'encadre. Les exigences 6.4.3 et 11.6.1 de la norme PCI DSS 4.0.1 régissent les scripts de votre page de paiement dans le navigateur du consommateur, et la plupart de ces scripts sont les vôtres. La frontière de propriété des scripts est le bord de la frame d'Adyen, et elle se déplace selon l'intégration Adyen que vous déployez.
« Nous utilisons Adyen » indique à votre QSA où les données de carte sont traitées. Cela ne lui dit pas ce que votre gestionnaire de balises, votre outil d'analytique, votre outil de consentement et votre chargeur de SDK font dans le navigateur pendant qu'un acheteur saisit une carte. Cet article relie cette frontière à chaque type d'intégration Adyen afin que vous sachiez précisément quels scripts Adyen vous décharge et lesquels vous devez inventorier, autoriser et surveiller vous-même.
La frontière selon le type d'intégration Adyen
Adyen propose plusieurs intégrations front-end, et chacune trace la frontière de l'iframe à un endroit différent. Plus les champs de carte se trouvent à l'intérieur d'une frame servie par Adyen, moins le chemin des données de paiement vous appartient, mais les scripts environnants de la page vous appartiennent dans tous les cas.
| Intégration Adyen | Où s'affichent les champs de carte | SAQ habituel | Adyen possède (son iframe) | Vous possédez au titre de 6.4.3 / 11.6.1 |
|---|---|---|---|---|
| Hosted Payment Pages (redirection) | Domaine d'Adyen, redirection complète | SAQ A | La saisie de carte et la page hébergée | Les scripts de la page depuis laquelle vous redirigez |
| Drop-in | Iframe Adyen, montée par le SDK Adyen | SAQ A | La saisie de carte dans la frame Drop-in | Le chargeur du SDK + tous les autres scripts de la page parente |
| Components (Custom Card) | Iframes Adyen par champ | SAQ A | Chaque frame de champ de saisie hébergé | Le chargeur du SDK, le JS de mise en page, tous les scripts environnants |
| API uniquement (serveur à serveur) | Votre propre DOM, aucune iframe Adyen | SAQ D | Rien côté client | Le formulaire entier et chaque script capable de le lire |
Le schéma est constant. La responsabilité d'Adyen s'arrête à la bordure de l'iframe. Le chargeur qui récupère et monte le SDK Adyen est votre script, servi depuis votre origine, et il est dans le périmètre. Tout ce qui l'entoure également.
Hosted Payment Pages : le plus léger, mais pas nul
Une redirection complète vers une page de paiement hébergée par Adyen est le cas le plus propre pour les données de carte. Le PAN est saisi sur le domaine d'Adyen, il ne touche donc jamais votre DOM. C'est le scénario SAQ A classique.
Le piège consiste à supposer que « redirection » signifie « aucun périmètre côté client ». La page depuis laquelle vous redirigez, votre panier ou votre page de démarrage du paiement, exécute toujours vos scripts et fait toujours partie du parcours de paiement du client. Un script altéré à cet endroit peut superposer un faux formulaire de carte avant la redirection, ou réécrire la cible de la redirection vers un processeur usurpé. Depuis la modification du SAQ A de janvier 2025, l'éligibilité elle-même dépend de la confirmation que votre page de paiement n'est pas vulnérable aux attaques par scripts, de sorte que les pages que vous contrôlez nécessitent toujours un récit défendable concernant leurs scripts.
Drop-in et Components : la lacune la plus fréquente
Drop-in et Components sont les choix de la plupart des équipes, et c'est là que la frontière est le plus mal interprétée. Adyen sert les véritables champs de saisie de carte à l'intérieur d'une iframe, ce qui maintient le PAN hors de votre DOM et permet le SAQ A. Très bien. Mais pour afficher cette frame, votre page charge le SDK Adyen Web et exécute un script de chargement que vous avez écrit et que vous hébergez. Ce chargeur est un script de page de paiement au titre de 6.4.3, sans exception.
Tout autour se trouve le reste de votre tunnel de paiement : Google Tag Manager, l'analytique, le session replay, le chat, la gestion du consentement, les SDK de lutte contre la fraude et tout ce que le marketing a déployé au dernier sprint. Aucun de ces éléments n'appartient à Adyen. Tous s'exécutent dans le même contexte de navigateur que la frame Adyen, sur votre origine, et n'importe lequel d'entre eux peut être compromis par une attaque de la chaîne d'approvisionnement via un script tiers.
L'incident Polyfill[.]io de 2024 est la version concrète de ce risque : un unique script tiers de confiance intégré sur plus de 490 000 sites a été rendu malveillant du jour au lendemain et a servi du code de redirection et de skimming à des pages de paiement (Sansec, 2024). Un marchand sur Adyen Drop-in dont les champs de carte étaient parfaitement isolés restait exposé, parce que le code malveillant arrivait par la propre page du marchand, et non par l'iframe d'Adyen.
API uniquement : la frontière disparaît
Une intégration en API uniquement, de serveur à serveur, supprime entièrement l'iframe Adyen. Vous collectez les données de carte dans votre propre formulaire, dans votre propre DOM, et vous les envoyez à Adyen depuis votre serveur. Il n'y a aucune isolation côté client, c'est pourquoi ce chemin vous place généralement dans le SAQ D avec l'ensemble de contrôles le plus lourd.
Pour 6.4.3 et 11.6.1, c'est le pire des cas. Chaque script de la page se trouve désormais sur le chemin direct des données de carte brutes au moment où elles sont saisies. L'inventaire, la justification écrite, la vérification d'intégrité et la détection d'altération que vous devez fournir ne protègent plus la page autour d'une iframe sûre ; ils protègent le champ de carte lui-même. Un seul script injecté ou modifié peut lire le PAN depuis le champ de saisie à chaque frappe et l'exfiltrer. La plupart des équipes qui choisissent l'API uniquement le font pour le contrôle du tunnel de paiement, et elles héritent en contrepartie de toute la charge de surveillance côté navigateur.
Ce qu'exigent 6.4.3 et 11.6.1, quelle que soit l'intégration
Le type d'intégration déplace la frontière, mais les deux contrôles ne vous quittent jamais. Ils sont devenus obligatoires le 31 mars 2025 (PCI Security Standards Council, PCI DSS v4.0.1).
- Inventoriez chaque script de la page de paiement (6.4.3). Répertoriez chaque script qui se charge dans le navigateur sur votre flux de paiement, y compris le chargeur du SDK Adyen et chaque balise tierce, en indiquant par écrit la raison de sa présence.
- Autorisez avant le déploiement (6.4.3). Approuvez chaque script et chaque modification. Une balise non examinée déclenchée par un outil marketing échoue à elle seule à cette exigence.
- Confirmez l'intégrité (6.4.3). Vérifiez que chaque script autorisé n'a pas été modifié sans approbation.
- Détectez les altérations et alertez (11.6.1). Mettez en place un mécanisme de détection des changements qui alerte en cas de modification non autorisée des scripts de la page de paiement et des en-têtes HTTP ayant un impact sur la sécurité, évalués tels qu'ils sont reçus par le navigateur du consommateur au moins tous les sept jours ou selon votre analyse de risque ciblée.
- Conservez des preuves qui résistent à un audit (6.4.3 / 11.6.1). Conservez les versions des scripts, les approbations et l'historique des modifications afin qu'un QSA voie des enregistrements, et non des affirmations.
Aucune de ces exigences n'est satisfaite par Adyen, parce qu'aucune d'elles ne concerne l'endroit où les données de carte sont traitées. Elles concernent ce qui s'exécute dans le navigateur, et le navigateur est la moitié qu'Adyen vous rend.
Comment cside couvre la moitié qu'Adyen vous laisse
La version manuelle, un tableur de scripts plus une comparaison hebdomadaire de captures d'écran, se brise dès qu'un gestionnaire de balises injecte des scripts de façon dynamique, ce qui est la norme sur un véritable tunnel de paiement Adyen. Elle produit aussi le type de preuves auxquelles les auditeurs se méfient.
cside PCI Shield est conçu pour la tranche exacte qu'Adyen ne couvre pas :
- Inventaire et justification automatisés (6.4.3). cside découvre chaque script de la page de paiement, y compris le chargeur du SDK Adyen et toutes les balises tierces, construit l'inventaire et enregistre l'autorisation et la justification au même endroit.
- Intégrité et détection d'altération en temps réel (11.6.1). cside surveille en continu les scripts et les en-têtes HTTP ayant un impact sur la sécurité, et alerte en cas de modification non autorisée, au lieu d'échantillonner via une tâche cron hebdomadaire en espérant que rien n'est passé entre les mailles.
- Preuves prêtes pour l'audit. cside archive chaque version de script avec son historique complet, de sorte que vous remettez à un QSA des enregistrements probants qui correspondent proprement au côté marchand de la répartition des responsabilités.
cside ne remplace pas Adyen. Adyen sort les données de carte du périmètre à l'intérieur de son iframe ; cside couvre les scripts de la page parente que 6.4.3 et 11.6.1 vous laissent, quelle que soit l'intégration que vous exécutez.
Pour aller plus loin sur cside
- Peut-on utiliser Adyen pour la conformité PCI DSS ?
- Stripe vous rend-il conforme à la norme PCI ? Ce que 6.4.3 et 11.6.1 exigent encore
- Guide de conformité côté client de la norme PCI DSS 4.0.1
- cside PCI Shield
Au 2026-06-18, considérez ce document comme une orientation opérationnelle, et non comme un conseil juridique. Confirmez le libellé exact des contrôles et votre éligibilité au SAQ auprès de votre QSA, de votre conseil juridique ou du responsable des risques.
