PCI DSS 4.0 en ecommerce: qué exige hoy tu checkout

Durante años, cumplir con PCI DSS en un ecommerce se sentía como un trámite anual: el adquirente mandaba un cuestionario, alguien de sistemas lo contestaba y el tema desaparecía hasta el año siguiente. Si la tienda usaba una pasarela con página de pago alojada o un iframe, la conclusión casi siempre era la misma: "la tarjeta no pasa por nosotros, así que casi nada nos aplica".

Eso cambió. Los ataques de e-skimming —código malicioso que se inyecta en la página de pago y copia los datos de la tarjeta desde el navegador del cliente, antes de que lleguen a la pasarela— crecieron lo suficiente como para que el PCI Security Standards Council, el organismo que mantiene el estándar, reforzara las reglas sobre las páginas de pago. Desde el 31 de marzo de 2025 son obligatorios los requisitos de PCI DSS 4.0 que obligan a controlar cada script que corre en el checkout y a vigilar que nadie lo modifique. Es decir: aunque la tarjeta nunca toque tu servidor, tu página sí puede ser la puerta de entrada.

En WolfSellers implementamos y damos soporte a tiendas en Adobe Commerce (antes Magento) en México, y la seguridad del checkout es parte del alcance de cada proyecto, no un anexo. Esta guía explica qué es PCI DSS y a quién le aplica, qué cambió con la versión 4.0, cuáles son los dos requisitos que cambian el checkout, qué cuestionario de autoevaluación te toca según cómo integraste tu pasarela, qué resuelve Adobe Commerce de fábrica y qué te sigue tocando a ti.

Una aclaración necesaria: esto no sustituye a un evaluador de seguridad calificado (QSA) ni a tu adquirente, que son quienes determinan tu nivel y la forma de validar tu cumplimiento. Aquí explicamos qué debe soportar la plataforma y cómo lo implementamos.

---

Qué es PCI DSS y a quién le aplica

PCI DSS (Payment Card Industry Data Security Standard) es el estándar de seguridad que definen las marcas de tarjetas a través del PCI Security Standards Council. No es una ley mexicana: es una obligación contractual. Te la exige tu adquirente —el banco o la empresa que te permite aceptar tarjetas— porque a él se la exigen las redes.

Le aplica a cualquier comercio que acepte pagos con tarjeta, incluso si subcontrata todo el manejo de la tarjeta a una pasarela. Lo que cambia según tu caso no es si te aplica, sino cuánto de él te aplica y cómo lo demuestras:

• El nivel del comercio. Las marcas clasifican a los comercios en niveles según su volumen anual de transacciones. Los de mayor volumen validan con un reporte de cumplimiento elaborado por un evaluador calificado (QSA); los demás, normalmente con un cuestionario de autoevaluación (SAQ). Tu adquirente te dice en qué nivel estás.
• El tipo de cuestionario. Hay varios SAQ, y cuál te toca depende de cómo capturas la tarjeta. Es la decisión técnica con más impacto en tu carga de cumplimiento, y la vemos más abajo.

Tampoco hay que confundirlo con la protección de datos personales. PCI DSS protege los datos de la tarjeta; la LFPDPPP regula todos los datos personales de tus clientes. Son obligaciones distintas y se cumplen en paralelo. Explicamos la segunda en nuestra nota sobre protección de datos en ecommerce en México.

Qué cambió con PCI DSS 4.0 y qué fechas importan

PCI DSS 4.0 se publicó en 2022 con un periodo de transición largo: muchos requisitos nuevos se marcaron "a futuro", recomendados pero no obligatorios, para dar tiempo a implementarlos. Esa transición ya terminó.

Para un ecommerce, los requisitos a futuro que más cambian el trabajo son dos: el 6.4.3 y el 11.6.1. Los dos atacan el mismo problema, el e-skimming, desde dos ángulos.

Los dos requisitos que cambian el checkout: 6.4.3 y 11.6.1

El e-skimming funciona porque la página de pago de una tienda moderna carga muchos scripts: analítica, administradores de etiquetas, chat, pruebas A/B, píxeles de publicidad, reseñas. Basta con que uno de ellos se comprometa —en tu servidor o en el de un proveedor— para que el atacante lea lo que el cliente teclea. Los dos requisitos cierran esa puerta así:

Dos consecuencias prácticas que conviene entender desde el principio:

1. El inventario no es un documento, es un proceso. Cada vez que marketing agrega una etiqueta o un proveedor actualiza su script, el inventario cambia. Si no hay un flujo de aprobación, el inventario se desactualiza en semanas.
2. La página de pago es la que ve el cliente, no la de tu repositorio. Un script cargado desde un administrador de etiquetas no aparece en tu código, pero sí en el navegador. Por eso el 11.6.1 exige revisar la página como la recibe el navegador.

SAQ A, A-EP o D: qué cuestionario te toca según tu integración

La forma en que integraste tu pasarela decide cuánto de PCI DSS tienes que demostrar. La regla general:

El cambio de enero de 2025 al SAQ A merece atención porque desconcertó a muchos equipos. El PCI Security Standards Council quitó del SAQ A los requisitos 6.4.3 y 11.6.1 (y el 12.3.1, el análisis de riesgo asociado), pero agregó un criterio de elegibilidad: el comercio debe confirmar que su sitio no es susceptible a ataques de scripts que puedan afectar sus sistemas de ecommerce.

En la práctica, según la aclaración que publicó el propio Consejo, hay dos formas de cumplir ese criterio si usas un formulario de pago embebido (un iframe):

1. Protegerte tú mismo, o con un tercero, usando técnicas como las del 6.4.3 y el 11.6.1.
2. Obtener confirmación de tu procesador de pagos, si cumple con PCI DSS, de que su solución embebida incluye protección contra ataques de scripts cuando se implementa según sus instrucciones.

El criterio no aplica si rediriges al cliente fuera de tu sitio para pagar o si subcontratas por completo la función de pago. Moraleja: "uso iframe" ya no equivale a "no tengo que hacer nada". Pídele a tu proveedor esa confirmación por escrito, o implementa los controles.

Qué resuelve Adobe Commerce y qué te toca a ti

Adobe Commerce incorporó controles pensados para PCI DSS 4.0. A partir de la versión 2.4.7, según sus notas de versión:

• Política de seguridad de contenido (CSP) en modo restrict en las páginas de pago. La configuración predeterminada de CSP para las páginas de pago del storefront y del Admin es ahora restrict, que bloquea lo que no está en la lista permitida; el resto del sitio queda en report-only, que solo reporta. Antes de 2.4.7, todas las páginas estaban en report-only.
• Un proveedor de nonce para permitir de forma controlada los scripts en línea que la CSP bloquearía.
• Integridad de subrecursos (SRI). Adobe Commerce genera hashes de integridad para los archivos JavaScript que viven en el sistema de archivos local, aplicados por defecto en las páginas de pago. No cubre scripts remotos de terceros, que siguen siendo tu responsabilidad.

Si tu tienda usa Adobe Commerce en la infraestructura en la nube de Adobe, el modelo de responsabilidad compartida divide el trabajo: Adobe mantiene la certificación PCI de la infraestructura y los servicios de la plataforma, y el comercio es responsable del cumplimiento de su aplicación personalizada —código propio, extensiones, integraciones de terceros— y de sus procesos, incluidos los escaneos de vulnerabilidades con un proveedor aprobado (ASV).

La advertencia más importante: no desactives la CSP ni el SRI para "arreglar" un checkout que dejó de funcionar. Cuando algo se rompe después de activar el modo restrict, casi siempre es un script que nadie tenía inventariado. La solución es decidir si ese script debe estar ahí y, si debe, autorizarlo en la política; no apagar la protección.

El problema real: los scripts de terceros en la página de pago

En las auditorías que hacemos, la conversación difícil casi nunca es sobre el código de la tienda. Es sobre todo lo que se fue agregando al checkout con los años: una etiqueta de conversión de una campaña que ya terminó, un chat que nadie usa en ese paso, una herramienta de mapas de calor instalada para un estudio de hace dos años.

Cada uno de esos scripts es un riesgo y un pendiente de cumplimiento. El principio que aplicamos es simple: la página de pago debe cargar solo lo indispensable para cobrar y medir la conversión. En concreto:

1. Quitar del checkout todo script sin justificación vigente. Es el control más barato y el que más reduce el riesgo.
2. Gobernar el administrador de etiquetas. Una herramienta como un administrador de etiquetas permite inyectar scripts sin pasar por el código. Si carga en la página de pago, sus publicaciones deben tener un flujo de aprobación, o conviene excluir esas páginas de su alcance.
3. Preferir la versión fija de cada script cuando el proveedor la ofrece, para poder asegurar su integridad con un hash; cuando no existe, limitar su origen con la CSP y cubrirlo con el monitoreo del 11.6.1.
4. Asignar un dueño al inventario, con una regla clara: nada entra a la página de pago sin aprobación de seguridad.

Plan de trabajo: cómo llevar un checkout a PCI DSS 4.0

Este es el orden en que lo trabajamos con nuestros clientes:

1. Mapear las páginas de pago. Checkout, pasos de pago, confirmación y cualquier página donde se capture o se muestre información de pago, incluida la creación de pedidos desde el Admin.
2. Hacer el inventario de scripts tal como los ve el navegador, no solo los del repositorio, con su justificación y su responsable.
3. Confirmar la integración con la pasarela y el cuestionario que te toca. Si es iframe, pedir por escrito la confirmación de protección contra scripts o planear los controles propios.
4. Llevar Adobe Commerce a 2.4.7 o posterior, o planear el trabajo equivalente si la actualización no es inmediata, y probar el modo restrict en un ambiente de pruebas antes de producción.
5. Implementar el monitoreo del 11.6.1, al menos semanal, con alertas que lleguen a una persona con capacidad de actuar.
6. Cerrar el ciclo operativo: escaneos trimestrales con un proveedor aprobado, parches de seguridad al día y un proceso para que cualquier script nuevo pase por aprobación.

Errores frecuentes

1. Asumir que el iframe de la pasarela resuelve todo. Desde marzo de 2025 hay que demostrar protección contra scripts o tener la confirmación del procesador.
2. Desactivar la CSP para destrabar el checkout en lugar de autorizar el script correcto.
3. Inventariar solo el código propio y olvidar lo que inyecta el administrador de etiquetas.
4. Tratar el inventario como un documento anual en lugar de un proceso con aprobación.
5. Quedarse en versiones sin parches. Una tienda desactualizada es la puerta más común para inyectar scripts.
6. Confundir PCI DSS con la protección de datos personales. Son obligaciones distintas y hay que cumplir las dos.

Cómo lo hacemos en WolfSellers

Cuando un cliente nos pide preparar su checkout para PCI DSS 4.0, empezamos con un diagnóstico: páginas de pago, inventario real de scripts, tipo de integración con la pasarela, versión de Adobe Commerce y estado de parches. De ahí sale un plan priorizado que implementamos con nuestro equipo de ciberseguridad, y que después se sostiene con soporte y mantenimiento: parches al día, monitoreo de la página de pago y un proceso de aprobación para todo script nuevo.

Si además estás eligiendo o cambiando de pasarela, la forma de integrarla define buena parte de tu alcance PCI. Lo explicamos en nuestra guía de pasarelas de pago en México. Y si quieres una revisión de tu caso, puedes escribirnos.

---

Preguntas frecuentes sobre PCI DSS en ecommerce

¿Es obligatorio cumplir con PCI DSS en México?

No es una ley mexicana, pero sí una obligación contractual para cualquier comercio que acepte tarjetas: la exigen los adquirentes porque a ellos se la exigen las redes de tarjetas. Las consecuencias de no cumplir las define tu contrato con el adquirente y pueden ir desde multas hasta perder la capacidad de aceptar pagos con tarjeta, además del costo de un incidente si te roban datos.

Si uso el iframe de mi pasarela, ¿tengo que hacer algo de PCI DSS 4.0?

Sí. Con el SAQ A vigente desde el 31 de marzo de 2025, el comercio debe confirmar que su sitio no es susceptible a ataques de scripts. Según el PCI Security Standards Council, puedes cumplirlo implementando técnicas como las de los requisitos 6.4.3 y 11.6.1, o con la confirmación de tu procesador de pagos, si cumple con PCI DSS, de que su solución embebida incluye esa protección cuando se implementa según sus instrucciones. El criterio no aplica si rediriges al cliente fuera de tu sitio para pagar.

¿Cada cuánto hay que revisar los scripts de la página de pago?

El requisito 11.6.1 pide un mecanismo de detección de cambios que funcione al menos una vez por semana, o con la frecuencia que defina un análisis de riesgo específico. En la práctica recomendamos monitoreo automatizado continuo con alertas, porque un script comprometido puede robar tarjetas durante días antes de la siguiente revisión manual.

¿Adobe Commerce en la nube ya cumple con PCI DSS?

La infraestructura sí: Adobe mantiene la certificación PCI de la infraestructura y los servicios de la plataforma. Tu tienda no queda certificada en automático, porque el cumplimiento de tu aplicación —código propio, extensiones, integraciones y procesos— sigue siendo responsabilidad del comercio, según el modelo de responsabilidad compartida de Adobe.

¿Qué versión de Adobe Commerce necesito para PCI DSS 4.0?

A partir de Adobe Commerce 2.4.7, las páginas de pago usan por defecto una política de seguridad de contenido en modo restrict e integridad de subrecursos para el JavaScript local. En versiones anteriores esos controles se tienen que implementar de otra forma. En cualquier versión, mantener los parches de seguridad al día y controlar los scripts de terceros sigue siendo indispensable.

¿PCI DSS y la LFPDPPP son lo mismo?

No. PCI DSS es un estándar de la industria de tarjetas que protege los datos de pago; la LFPDPPP es la ley mexicana que regula todos los datos personales que trata una empresa privada. Un ecommerce en México tiene que cumplir las dos, con controles que se complementan.

Servicios relacionados

Si este tema es relevante para tu negocio, estos servicios de WolfSellers pueden ayudarte a implementarlo:

• Adobe Commerce
• Implementación Adobe Commerce
• Infraestructura Cloud