Qué cubre Adyen frente a lo que sigue siendo tuyo
Adyen, como cualquier procesador de Nivel 1 de PCI DSS, certifica el código que se ejecuta dentro de su propio iframe. No certifica la página que lo enmarca. Los requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0.1 rigen los scripts de tu página de pago en el navegador del consumidor, y la mayoría de esos scripts son tuyos. El límite de propiedad de scripts es el borde del marco de Adyen, y se desplaza según qué integración de Adyen implementes.
"Usamos Adyen" le dice a tu QSA dónde se procesan los datos de la tarjeta. No le dice qué están haciendo tu gestor de etiquetas, tu analítica, tu herramienta de consentimiento y tu cargador del SDK en el navegador mientras un comprador escribe una tarjeta. Este artículo asigna ese límite a cada tipo de integración de Adyen para que sepas con precisión qué scripts te quita Adyen de encima y cuáles tienes que inventariar, autorizar y monitorizar tú.
El límite según el tipo de integración de Adyen
Adyen ofrece varias integraciones de front-end, y cada una dibuja el límite del iframe en un lugar distinto. Cuanto más adentro de un marco servido por Adyen estén los campos de la tarjeta, menos parte del camino de los datos de pago es tuya, pero los scripts de la página que la rodea son tuyos en todos los casos.
| Integración de Adyen | Dónde se renderizan los campos de la tarjeta | SAQ habitual | Adyen controla (su iframe) | Tú controlas según 6.4.3 / 11.6.1 |
|---|---|---|---|---|
| Hosted Payment Pages (redirección) | Dominio de Adyen, redirección completa | SAQ A | La entrada de la tarjeta y la página alojada | Los scripts de la página desde la que rediriges |
| Drop-in | iframe de Adyen, montado por el SDK de Adyen | SAQ A | La entrada de la tarjeta dentro del marco Drop-in | El cargador del SDK + todos los demás scripts de la página principal |
| Components (Custom Card) | Un iframe de Adyen por campo | SAQ A | Cada marco de campo de entrada alojado | El cargador del SDK, el JS de maquetación y todos los scripts circundantes |
| Solo API (servidor a servidor) | Tu propio DOM, sin iframe de Adyen | SAQ D | Nada del lado del cliente | Todo el formulario y cada script que pueda leerlo |
El patrón es constante. La responsabilidad de Adyen termina en el borde del iframe. El cargador que obtiene y monta el SDK de Adyen es tu script, servido desde tu propio origen, y está dentro del alcance. Y también todo lo que lo rodea.
Hosted Payment Pages: el caso más ligero, pero no nulo
Una redirección completa a una página de pago alojada por Adyen es el caso más limpio para los datos de la tarjeta. El PAN se introduce en el dominio de Adyen, así que nunca toca tu DOM. Este es el escenario clásico de SAQ A.
La trampa está en suponer que "redirección" significa "sin alcance del lado del cliente". La página desde la que rediriges, tu página de carrito o de inicio de checkout, sigue ejecutando tus scripts y sigue siendo parte del recorrido de pago del cliente. Un script manipulado ahí puede superponer un formulario de tarjeta falso antes de la redirección, o reescribir el destino de la redirección hacia un procesador suplantado. Desde el cambio del SAQ A de enero de 2025, la propia elegibilidad depende de confirmar que tu página de pago no es susceptible a ataques basados en scripts, así que las páginas que controlas siguen necesitando una historia defendible sobre sus scripts.
Drop-in y Components: la brecha más común
Drop-in y Components son donde aterriza la mayoría de los equipos, y donde peor se interpreta el límite. Adyen sirve los campos reales de la tarjeta dentro de un iframe, lo que mantiene el PAN fuera de tu DOM y permite el SAQ A. Bien. Pero para renderizar ese marco, tu página carga el Adyen Web SDK y ejecuta un script cargador que tú escribiste y alojas. Ese cargador es un script de la página de pago según 6.4.3, sin excepción.
A su alrededor está el resto de tu checkout: Google Tag Manager, analítica, grabación de sesiones, chat, gestión del consentimiento, SDK de fraude y lo que sea que marketing publicó el último sprint. Nada de eso es de Adyen. Todo se ejecuta en el mismo contexto del navegador que el marco de Adyen, en tu propio origen, y cualquiera de ellos puede verse comprometido a través de un ataque a la cadena de suministro de scripts de terceros.
El incidente de Polyfill[.]io de 2024 es la versión concreta de este riesgo: un único script de terceros de confianza incrustado en más de 490 000 sitios se volvió malicioso de la noche a la mañana y sirvió código de redirección y skimming a páginas de pago (Sansec, 2024). Un comercio con Adyen Drop-in y campos de tarjeta perfectamente aislados quedaba igualmente expuesto, porque el código malicioso entró en la propia página del comercio, no en el iframe de Adyen.
Solo API: el límite desaparece
Una integración solo API, de servidor a servidor, elimina el iframe de Adyen por completo. Recoges los datos de la tarjeta en tu propio formulario, en tu propio DOM, y los envías a Adyen desde tu servidor. No hay ningún aislamiento del lado del cliente, por lo que este camino suele dejarte en el SAQ D con el conjunto de controles más pesado.
Para 6.4.3 y 11.6.1 este es el peor caso. Cada script de la página está ahora en el camino directo de los datos en bruto de la tarjeta a medida que se escriben. El inventario, la justificación por escrito, la verificación de integridad y la detección de manipulación que debes mantener ya no protegen la página que rodea a un iframe seguro; protegen el propio campo de la tarjeta. Un único script inyectado o modificado puede leer el PAN de la entrada con cada pulsación y exfiltrarlo. La mayoría de los equipos que eligen solo API lo hacen por el control del checkout, y heredan toda la carga de monitorización del lado del navegador como precio.
Qué exigen 6.4.3 y 11.6.1, sea cual sea la integración
El tipo de integración mueve el límite, pero los dos controles nunca dejan de ser tuyos. Pasaron a ser obligatorios el 31 de marzo de 2025 (PCI Security Standards Council, PCI DSS v4.0.1).
- Inventaria cada script de la página de pago (6.4.3). Enumera cada script que se carga en el navegador en tu flujo de pago, incluidos el cargador del SDK de Adyen y cada etiqueta de terceros, con una razón por escrito de por qué está ahí.
- Autoriza antes de publicar (6.4.3). Aprueba cada script y cada cambio. Una etiqueta sin revisar disparada por una herramienta de marketing ya incumple esto por sí sola.
- Confirma la integridad (6.4.3). Verifica que cada script autorizado no ha sido alterado sin aprobación.
- Detecta la manipulación y alerta (11.6.1). Ejecuta un mecanismo de detección de cambios que alerte ante la modificación no autorizada de los scripts de la página de pago y de los encabezados HTTP que afectan la seguridad, evaluados tal como los recibe el navegador del consumidor al menos cada siete días o según tu análisis de riesgo dirigido.
- Conserva evidencia que sobreviva a una auditoría (6.4.3 / 11.6.1). Conserva las versiones de los scripts, las aprobaciones y el historial de cambios para que un QSA vea registros, no afirmaciones.
Ninguno de estos lo satisface Adyen, porque ninguno trata de dónde se procesan los datos de la tarjeta. Tratan de lo que se ejecuta en el navegador, y el navegador es la mitad que Adyen te devuelve.
Cómo cubre cside la mitad que Adyen te deja
La versión manual, una hoja de cálculo de scripts más una comparación semanal de capturas, se rompe en cuanto un gestor de etiquetas inyecta scripts de forma dinámica, que es lo normal en un checkout real de Adyen. Además produce el tipo de evidencia de la que los auditores desconfían.
cside PCI Shield está construido para la porción exacta que Adyen no cubre:
- Inventario y justificación automatizados (6.4.3). cside descubre cada script de la página de pago, incluidos el cargador del SDK de Adyen y todas las etiquetas de terceros, construye el inventario y registra la autorización y la justificación en un solo lugar.
- Integridad y detección de manipulación en tiempo real (11.6.1). cside monitoriza los scripts y los encabezados HTTP que afectan la seguridad de forma continua y alerta ante cambios no autorizados, en lugar de muestrear con un cron semanal y confiar en que nada se haya colado.
- Evidencia lista para auditoría. cside archiva cada versión de cada script con su historial completo, para que le entregues a un QSA registros forenses que encajan limpiamente con el lado del comercio en el reparto de responsabilidades.
cside no reemplaza a Adyen. Adyen saca los datos de la tarjeta del alcance dentro de su iframe; cside cubre los scripts de la página principal que 6.4.3 y 11.6.1 dejan en tus manos, sea cual sea la integración que ejecutes.
Más lecturas sobre cside
- ¿Puedes usar Adyen para PCI DSS?
- ¿Stripe te hace cumplir con PCI? Lo que 6.4.3 y 11.6.1 aún exigen
- Guía de cumplimiento del lado del cliente de PCI DSS 4.0.1
- cside PCI Shield
A fecha de 2026-06-18, trata esto como una guía operativa, no como asesoramiento legal. Confirma el texto exacto de los controles y tu elegibilidad para el SAQ con tu QSA, tu asesor jurídico o el responsable de riesgos.
