¿Los campos de tarjeta de la pasarela lo resuelven todo?

No. Los campos de tarjeta alojados por la pasarela (que aparecen dentro de una ventana incrustada en tu página y servida por el proveedor de pagos) dejan los datos de la tarjeta fuera del alcance de tu servidor y del código de tu página y, por eso, reducen mucho el alcance del PCI DSS. Pero la página que los rodea sigue siendo tuya, y ahí puede ocurrir el ataque: un formulario falso antes del verdadero, el cambio de la ventana por otra, un botón que lleva a otro sitio. El propio PCI Security Standards Council dice que la página que incrusta el formulario del proveedor sigue dentro del alcance.

Qué resuelven los campos alojados

En este modelo, los campos de número, vencimiento y código de seguridad no forman parte de tu página: viven en una pequeña ventana incrustada (un iframe) cuyo contenido llega desde la dirección del proveedor. El navegador aísla los contenidos de direcciones distintas, así que el código que se ejecuta en tu página (incluido un código malicioso) no puede leer lo que el cliente escribe dentro de esa ventana. Los datos van directo al proveedor.

Es una ventaja real. Pasan menos datos por la tienda, se aplican menos requisitos y muchos comercios pueden usar el cuestionario de autoevaluación más sencillo, el SAQ A, si cumplen sus criterios de elegibilidad. Si usas campos alojados, sigue usándolos. La clave es no confundir reducir el alcance con eliminar el riesgo.

Dónde sigue el riesgo

La guía del PCI SSC sobre seguridad de la página de pago, de marzo de 2025, es clara: incrustar el formulario de un tercero no saca por completo del alcance a la página que lo muestra, ni vuelve inaplicables los requisitos 6.4.3 y 11.6.1. El comercio responde por los scripts de esa página y, cuando un script crea la ventana, ese script también queda cubierto. En la práctica, el delincuente tiene varios caminos sin tocar los campos del proveedor:

• Un formulario falso antes del verdadero. En febrero de 2026, la firma de investigación Sansec informó del caso de una cadena de supermercados con presencia internacional cuyo formulario real era del proveedor de pagos. El código inyectado en la página de la tienda mostraba antes un formulario falso; el cliente escribía ahí, luego veía el formulario legítimo y volvía a escribir. Según Sansec, precisamente porque la tarjeta pasó a escribirse en formularios de los proveedores, los delincuentes prefieren ahora este tipo de superposición.
• Cambiar o tapar la ventana. Es tu página la que le dice al navegador desde dónde cargar la ventana de pago. Si se altera el código que lo hace, la ventana puede llegar desde una dirección parecida o quedar oculta bajo una capa idéntica.
• Desviar el botón. El botón de pagar y los pasos anteriores también son de tu página y pueden modificarse para llevar al cliente a otro lugar.
• Datos fuera de la ventana. Nombre, correo, teléfono y dirección suelen escribirse en tu página, no en la del proveedor.
• Sitios de una sola página. Cuando el navegador no recarga entre pasos, los scripts cargados al inicio de la visita siguen activos en el pago; la guía considera todas las vistas dentro del alcance.

Qué cambió en el SAQ A y qué sigue vigente

En enero de 2025, el PCI SSC quitó los requisitos 6.4.3 y 11.6.1 del SAQ A, pero añadió un criterio de elegibilidad: el comercio debe confirmar que su sitio no es susceptible a ataques de scripts que puedan afectar a sus sistemas de comercio electrónico. El Consejo subrayó que el cambio no elimina ni debilita los requisitos de fondo del PCI DSS.

En febrero de 2025, la FAQ 1588 aclaró que este criterio se aplica a las tiendas cuya página incrusta el formulario del proveedor, no a las que redirigen al cliente al sitio del proveedor. Hay dos maneras de cumplirlo: aplicar técnicas como las de los requisitos 6.4.3 y 11.6.1 para proteger la página de scripts que buscan datos de cuenta, por cuenta propia o con un tercero; u obtener del proveedor, que cumple el PCI DSS, la confirmación de que su solución incluye esa protección para la página del comercio, siempre que se implemente según sus instrucciones. Es decir, el cuestionario se acortó, pero la pregunta sobre tu página sigue ahí.

Checklist para quien usa campos alojados

• Pregunta a tu proveedor por escrito si su solución protege tu página contra scripts y en qué condiciones, y sigue sus instrucciones de implementación al pie de la letra.
• Trata como sensible la página que muestra el formulario. Deja en ella solo los scripts imprescindibles y sabe quién puede modificarla.
• Inventaría y vigila los scripts de esa página, tal como la recibe el navegador del cliente.
• Comprueba en la pantalla del comprador que la ventana de pago llega desde la dirección del proveedor y que no hay otro formulario de tarjeta antes o encima de ella.
• Protege lo que queda fuera de la ventana, como nombre, correo y dirección.
• Toma en serio los avisos de doble ingreso de la tarjeta.
• Confirma con tu adquirente qué cuestionario se aplica a tu tienda.

Proteside protege justamente la página que rodea los campos del proveedor: verifica, en el navegador del comprador, que el formulario mostrado es el legítimo y llega desde la dirección correcta, bloquea superposiciones y genera la evidencia de los requisitos 6.4.3 y 11.6.1. Conoce la protección para pagos con tarjeta y la solución de cumplimiento PCI DSS, y pruébalo gratis durante 14 días.