Última revisión: agosto de 2026 | Se aplica a: Gobiernos locales y entidades públicas que utilizan páginas de pago con tarjeta en línea, enlaces de pago o formularios de pago incrustados.
Lectura Rápida
¿Los formularios de pago incrustados afectan el cumplimiento de PCI?
Sí. Un formulario de pago incrustado o un iframe puede afectar las responsabilidades de cumplimiento de PCI de un gobierno local, incluso cuando el proveedor de pagos maneja la entrada de tarjetas y el procesamiento de transacciones. La página web controlada por la agencia alrededor del elemento de pago incrustado aún puede necesitar protección contra scripts no autorizados que podrían afectar la experiencia de pago. El enfoque de validación depende del entorno de pago completo de la agencia y los requisitos de su adquirente u otra entidad que haga cumplir el cumplimiento.
Una página de pago alojada, un enlace de pago seguro y un formulario de pago incrustado pueden parecer formas sencillas para que los residentes paguen en línea. No son lo mismo desde el punto de vista de la seguridad de los pagos.
La diferencia radica en dónde aparecen los campos de entrada de tarjetas y qué organización controla la página web que los rodea. Una redirección o un enlace de pago pueden enviar a los residentes a una página alojada por el proveedor. Un formulario de pago incrustado coloca el elemento de pago del proveedor dentro de una página web que su agencia controla. Esa distinción puede afectar los controles y la documentación que su agencia necesita mantener.
Páginas alojadas, enlaces de pago y formularios incrustados
Comience por identificar qué modelo de pago utiliza cada departamento. Los residentes deben tener una experiencia de pago sencilla, pero sus equipos de finanzas, TI y web deben comprender cómo se mueven los datos de pago detrás de escena.
| Modelo de pago | Lo que ve el residente | Lo que la agencia debe confirmar |
|---|---|---|
| Redirigir a una página de pago alojada | El residente hace clic en Pagar ahora y abandona el sitio web de la agencia para completar el pago en una página alojada por el proveedor. | Confirme que el enlace es correcto, la documentación del proveedor está actualizada y los sistemas de la agencia no recopilan datos de tarjetas. |
| Enlace de pago seguro | El residente recibe un enlace por SMS o correo electrónico e introduce la información de la tarjeta en una página alojada por el proveedor. | Confirme quién puede enviar enlaces de pago, qué información aparece en el mensaje y que el enlace apunta a un destino de proveedor aprobado. |
| Formulario de pago integrado o Iframe | Los campos de introducción de tarjeta aparecen dentro de una página web controlada por la agencia, incluso si el proveedor de pago entrega y aloja los campos. | Confirme qué scripts se ejecutan en la página de la agencia, quién puede cambiar la página y qué evidencia demuestra que está protegida contra ataques de scripts. |
Las páginas de pago alojadas y los enlaces de pago seguros pueden reducir el número de componentes controlados por la agencia en torno a la introducción de tarjetas. No eliminan la necesidad de comprender su flujo de pago o completar la validación PCI aplicable. Sin embargo, pueden simplificar los controles de página web que su agencia necesita administrar.
¿Qué es una página de pago de referencia?
Una página de pago de referencia es una página web controlada por la agencia que contiene un formulario de pago de terceros integrado. Un departamento de servicios públicos, por ejemplo, puede tener una página Pague su factura en el sitio web de la ciudad que carga un iframe de un proveedor de pago dentro de la página.
El proveedor de pago puede gestionar la introducción de tarjetas y el procesamiento de transacciones dentro de ese elemento integrado. La página web de la ciudad que la rodea aún puede cargar etiquetas de análisis, contenedores de gestión de etiquetas, widgets de chat, herramientas de accesibilidad, scripts de consentimiento de cookies y JavaScript personalizado.
Esa página circundante es importante porque un script malicioso o no autorizado podría alterar la experiencia del residente, interferir con el elemento de pago o intentar capturar información antes de que llegue al proveedor.
Ejemplo
Un sitio web de servicios públicos de la ciudad puede mostrar el saldo de un residente con un botón Pagar ahora. Si el botón envía al residente a una página de pago alojada por el procesador, el sitio de la ciudad no aloja los campos de introducción de tarjetas. Si los campos de pago aparecen dentro de un iframe en la página de servicios públicos de la ciudad, esa página debe tratarse como una página de pago de referencia y gestionarse en consecuencia.
¿Por qué importan los scripts en las páginas de pago?
La mayoría de los scripts de sitios web son legítimos. Soportan análisis, accesibilidad, comunicaciones, formularios y otras funciones normales del sitio web. El riesgo proviene de scripts innecesarios o no gestionados en páginas conectadas a la recopilación de pagos.
Los ataques de scripts en páginas de pago a menudo se denominan skimming de comercio electrónico o web skimming. Son diferentes de un skimmer físico conectado a un terminal de mostrador. En un ataque de web skimming, se agrega código malicioso a una página web o a una dependencia de terceros y se ejecuta en el navegador del residente.
Revisar los scripts que se ejecutan en páginas relacionadas con pagos
✓ Contenedores de gestores de etiquetas y todas las etiquetas implementadas a través de ellos
✓ Herramientas de análisis y comportamiento de visitantes
✓ Widgets de chat, asistentes virtuales y herramientas de comentarios
✓ Superposiciones de accesibilidad y herramientas de mejora del lado del navegador
✓ Scripts de gestión de consentimiento de cookies y privacidad
✓ Formularios web, herramientas de calendario, mapas, encuestas y medios incrustados
✓ Código personalizado agregado por un equipo interno, una agencia web o un proveedor de sistemas de facturación
Esto no significa eliminar todos los scripts de su sitio web. Significa que las páginas relacionadas con los pagos deben recibir un mayor nivel de disciplina. Mantenga los scripts con un propósito claro. Sepa quién los aprobó. Revise los cambios antes de publicarlos.
Cuándo puede aplicarse la actualización de SAQ A
El SAQ A puede aplicarse a algunas agencias gubernamentales locales que externalizan completamente las funciones de datos de tarjetas electrónicas a proveedores de pago que cumplen con PCI DSS. No se basa en si una organización es pública o privada. La elegibilidad depende de los canales de pago reales de la agencia, la implementación técnica y los requisitos de su adquirente u otra entidad encargada del cumplimiento.
Elegibilidad para SAQ A: un punto de partida práctico
Una agencia no debe asumir que califica para el SAQ A simplemente porque utiliza una página de pago alojada o un iframe. Como punto de partida práctico, una agencia que considere el SAQ A debería poder confirmar todo lo siguiente:
✓ Todas las funciones de datos de tarjetas electrónicas se externalizan por completo a proveedores de servicios externos que cumplen con PCI DSS.
✓ La agencia no almacena, procesa ni transmite electrónicamente datos de titulares de tarjetas en los sistemas o instalaciones de la agencia.
✓ La agencia solo conserva informes o recibos en papel con datos de cuentas, si los hay, y esos registros no se reciben electrónicamente.
✓ El proveedor de pagos y otros proveedores de servicios relevantes pueden proporcionar documentación de cumplimiento de PCI DSS actualizada para los servicios utilizados.
✓ La agencia cumple con los criterios de elegibilidad específicos de comercio electrónico que se aplican a su modelo de pago, incluido el criterio de ataque de script para formularios de pago incrustados de terceros aplicables.
✓ El adquirente de la agencia, el facilitador de pagos u otra entidad encargada del cumplimiento acepta el SAQ A como el método de validación apropiado.
Importante
Este es un resumen práctico, no un sustituto de los criterios de elegibilidad oficiales del SAQ A o del asesoramiento de su adquirente o un evaluador calificado. Si su agencia acepta tarjetas en un mostrador, ingresa datos de tarjetas a través de una terminal virtual, graba llamadas que contienen datos de tarjetas, almacena datos de tarjetas electrónicas o utiliza un sitio web que no cumple con todos los criterios de elegibilidad del SAQ A, puede aplicarse un enfoque de validación diferente.
Para las agencias que califican para SAQ A y utilizan un formulario de pago incrustado de terceros o un iframe, los criterios de elegibilidad de comercio electrónico actualizados son especialmente importantes. Las agencias que no cumplen con todos los criterios de elegibilidad de SAQ A pueden necesitar un enfoque de validación diferente, como SAQ A-EP o SAQ D, según lo indique su adquirente o programa de cumplimiento.
PCI SSC actualizó SAQ A para comerciantes de comercio electrónico en 2025. El cuestionario actualizado eliminó los Requisitos 6.4.3 y 11.6.1 de PCI DSS de SAQ A, pero agregó un criterio de elegibilidad para comerciantes de comercio electrónico con formularios o páginas de pago incrustados de terceros.
Para un comerciante elegible de SAQ A, el criterio requiere confirmación de que su sitio no es susceptible a ataques de scripts que podrían afectar el sistema de comercio electrónico. La FAQ 1588 de PCI SSC aclara que este criterio se aplica cuando una página web de comerciante incluye una página o formulario de pago incrustado, como un iframe. No se aplica a una simple redirección a un sitio de proveedor o a un enlace de pago que envía al pagador a una página alojada por el proveedor.
Para un formulario de pago incrustado aplicable, la FAQ 1588 describe dos caminos generales:
1. Utilizar controles que protejan la página de pago de referencia de ataques de scripts. Esto puede incluir mantener un inventario de scripts, autorizar scripts, admitir la integridad de los scripts y detectar cambios no autorizados.
2. Obtener confirmación del proveedor de pago o del proveedor de servicios de terceros que cumple con PCI DSS. El proveedor debe confirmar que, cuando su solución de pago incrustada se implementa de acuerdo con sus instrucciones, la solución incluye técnicas que protegen la página de pago de ataques de scripts.
Importante
La Declaración de Cumplimiento general de PCI DSS de un proveedor no es automáticamente lo mismo que una confirmación por escrito de que su solución de pago incrustada aborda el criterio de elegibilidad específico de ataque de scripts para la implementación de su agencia. Solicite documentación que se aplique al producto de pago exacto y al modelo de integración que utiliza.
Los requisitos 6.4.3 y 11.6.1 siguen siendo relevantes para las entidades y las rutas de validación donde se aplican. En lenguaje sencillo, estos controles se centran en saber qué scripts se ejecutan en las páginas de pago o de referencia de pago, confirmar que los scripts son legítimos y detectar cambios no autorizados que podrían afectar la seguridad del pago.
Lista de verificación de páginas de pago para entidades públicas
Utilice esta lista de verificación cuando su agencia tenga una página de pago incrustada o un iframe, esté rediseñando una página de pago o esté revisando un flujo de pago en línea existente.
Identificar todas las páginas relacionadas con pagos
✓ Páginas de pago de servicios públicos
✓ Páginas de pago de impuestos y tasas
✓ Páginas de pago de tribunales y multas
✓ Páginas de pago de permisos, licencias, recreación y registro
✓ Páginas de pago de cuotas escolares, matrículas, transporte y actividades
✓ Cualquier página específica del departamento que incruste un elemento de pago
Documentar el modelo de pago
Para cada página, documente si el residente es redirigido a una página de pago alojada, enviado a través de un enlace de pago o se le presenta un formulario de pago incrustado. Conserve una captura de pantalla y un diagrama simple del flujo de datos con el registro.
Scripts de inventario en páginas con formularios integrados
Por cada script que se cargue o ejecute en el navegador de un residente en una página de pago de referencia, registre:
✓ Nombre del script y dominio de origen
✓ Propósito comercial o técnico
✓ Propietario o departamento aprobador
✓ Si es código propio o de terceros
✓ Fecha de la última revisión
✓ Cómo confirma la agencia que sigue autorizado y sin cambios
Limitar el acceso a la edición de páginas
No todos los editores web necesitan permiso para modificar páginas de pago. Utilice el acceso basado en roles en el sistema de gestión de contenidos, mantenga actualizadas las cuentas administrativas y exija una revisión antes de que los cambios se publiquen en páginas con elementos de pago integrados.
Mantener la orientación del proveedor
Conserve las instrucciones de implementación del proveedor con el registro de la página de pago. Si el proveedor indica que su solución integrada proporciona protecciones contra ataques de scripts, conserve esa confirmación por escrito y la evidencia de que su agencia siguió los pasos de implementación requeridos.
Revisar después de cambios significativos
Vuelva a revisar la página después de cambiar el tema de su sitio web, el gestor de etiquetas, las herramientas de análisis, el banner de cookies, el proveedor de accesibilidad, la agencia web, el proveedor de pagos, la integración de facturación o la configuración de pagos integrados.
Preguntas para proveedores de pago y web
No deje los detalles técnicos a la suposición. Haga preguntas directas y conserve las respuestas en su archivo de gestión de proveedores.
Preguntas para su proveedor de pago
✓ ¿Está nuestro flujo de pago alojado, redirigido o integrado?
✓ Si está integrado, ¿se considera nuestra página de agencia una página de pago de referencia para esta implementación?
✓ ¿Puede proporcionar la documentación de cumplimiento PCI DSS actual para este producto de pago?
✓ ¿Nuestra implementación califica para SAQ A, o debemos validar a través de otro SAQ o proceso?
✓ Si SAQ A aplica, ¿puede proporcionar una confirmación por escrito que aborde el criterio de elegibilidad de ataque de scripts para la solución integrada?
✓ ¿Qué pasos de implementación se requieren para que esa confirmación sea aplicable?
✓ ¿Qué cambios en el sitio web, la plataforma de facturación o la integración requieren una nueva revisión?
✓ ¿Ofrece una página de pago alojada u opción de enlace de pago que se ajuste mejor a nuestros objetivos operativos y de cumplimiento?
Preguntas para su agencia web o equipo web interno
✓ ¿Qué scripts se ejecutan hoy en las páginas relacionadas con pagos?
✓ ¿Quién puede agregar o eliminar scripts a través del CMS, el gestor de etiquetas o el código del sitio?
✓ ¿Qué revisión se realiza antes de agregar un script a una página de pago de referencia?
✓ ¿Cómo se actualizan y supervisan los complementos de terceros y las bibliotecas de JavaScript?
✓ ¿Podemos producir un historial de cambios para la página de pago y sus scripts?
✓ ¿Estamos utilizando algún script o etiqueta que no sea necesario para la experiencia de pago?
Mantenga simple el control de cambios
Esto no significa que los pagos en línea deban ser más complicados. Significa que su agencia debe comprender cómo se construye cada canal de pago, saber qué proveedores están involucrados y aplicar controles de cambio más estrictos al pequeño número de páginas web conectadas a la recopilación de pagos.
Un Proceso Factible para Muchas Entidades Públicas
Paso 1. Marque las páginas relacionadas con pagos en el CMS. Mantenga una lista sencilla de URL y propietarios de páginas.
Paso 2. Exija la aprobación para los cambios de scripts. Finanzas, TI o el propietario de pagos designado deben revisar las adiciones a las páginas de pago integradas.
Paso 3. Documente el motivo de cada script. Si nadie puede explicar por qué está ahí, elimínelo o investigue antes de dejarlo en su lugar.
Paso 4. Utilice una comprobación de antes y después. Confirme que una actualización de la página no ha cambiado el elemento de pago aprobado, los scripts, las cabeceras o los enlaces de destino.
Paso 5. Conserve la evidencia. Guarde los tickets de cambio, los correos electrónicos de aprobación, las capturas de pantalla y la guía del proveedor en la carpeta de seguridad de pagos.
La buena gobernanza no requiere hacer todo manualmente
Una página alojada por el proveedor o una opción de enlace de pago seguro puede simplificar la experiencia de pago del residente y reducir el número de componentes controlados por la agencia en torno a la introducción de la tarjeta. El modelo adecuado depende de la experiencia del residente, la integración del sistema de facturación, las necesidades del departamento y los requisitos de validación de su agencia.
Preguntas frecuentes
¿Se aplica el SAQ A a las agencias de gobiernos locales?
Puede ser. El SAQ A no se limita a las empresas privadas, pero una entidad pública debe cumplir todos los criterios de elegibilidad del SAQ A. En general, eso significa que las funciones de datos de tarjetas electrónicas se externalizan por completo a terceros que cumplen con PCI DSS. El enfoque de validación correcto depende de los canales de pago de la agencia, la implementación técnica y la dirección de su adquirente u otra entidad que aplique el cumplimiento.
¿Hace que un iframe de pago sea responsable a nuestra agencia de todos los controles de PCI DSS?
No necesariamente. El alcance y los requisitos de validación dependen del flujo de pago completo y de los criterios que se aplican a su agencia. Un formulario integrado puede reducir el manejo directo de los datos de la tarjeta, pero también puede crear responsabilidades para la página de pago de referencia controlada por la agencia. Confirme el enfoque de validación apropiado con su adquirente, proveedor de pagos o evaluador calificado.
¿Se aplica esto si redirigimos a los residentes a una página de pago alojada por el proveedor?
PCI SSC afirma que el criterio de elegibilidad del SAQ A descrito en la Pregunta Frecuente 1588 se aplica a las páginas web de comerciantes de comercio electrónico que incluyen una página o formulario de pago de terceros integrado. No se aplica a una simple redirección a un sitio web del proveedor o a un enlace de pago que envía a un pagador a un sitio alojado por el proveedor. Otros requisitos de PCI DSS aún pueden aplicarse según su entorno.
¿Qué se considera un script en una página de pago de referencia?
Los scripts pueden incluir JavaScript personalizado, etiquetas de administrador de etiquetas, herramientas de análisis, widgets de chat, herramientas de accesibilidad, herramientas de consentimiento de cookies, bibliotecas de terceros y otro código del lado del navegador. La pregunta práctica es si el código se carga o se ejecuta en el navegador del residente en la página relacionada con el pago.
¿Puede nuestro proveedor de pagos encargarse de la protección contra ataques de scripts por nosotros?
La FAQ 1588 de PCI SSC describe un método por el cual un proveedor de pagos o un proveedor de servicios externo que cumple con PCI DSS confirma que su solución de pago integrada incluye técnicas que protegen la página de pago del comerciante contra ataques de scripts cuando se implementa según las instrucciones del proveedor. Solicite una confirmación por escrito que se aplique a su producto e implementación específicos, y luego conserve la evidencia de que siguió las instrucciones.
¿Quién debe participar en esta revisión?
Como mínimo, involucre al propietario del pago en finanzas o tesorería, al líder de TI o seguridad, y al equipo web o proveedor web. Incluya al departamento que posee la experiencia de pago, como servicios públicos, tribunales, impuestos, permisos o educación, cuando su sistema de facturación o flujo de trabajo de residentes esté involucrado.
¿Qué debemos hacer si no podemos explicar cómo se construye una página de pago?
Pausa antes de realizar cambios no relacionados en el sitio web. Pida al proveedor de pagos y al equipo web que documenten el flujo actual, identifiquen si la página está alojada, redirigida o incrustada, y enumeren los scripts que se ejecutan en cualquier página de pago de referencia controlada por la agencia. Esa línea de base apoyará el siguiente paso correcto.
Revise su flujo de pago en línea
Facilite la gestión de los pagos en línea.
IntelliPay ayuda a las entidades públicas a ofrecer opciones de pago a través de páginas alojadas, enlaces de pago, portales en línea, canales presenciales y flujos de trabajo del sistema de facturación. Hable con nuestro equipo sobre un enfoque que respalde una experiencia clara para el residente y un entorno de pago manejable para su agencia.
Hable con un consultor de pagosLectura Relacionada
Fuentes
Consejo de Normas de Seguridad de PCI: Actualizaciones de SAQ A
Consejo de Normas de Seguridad de PCI: Preguntas frecuentes 1588 y criterios de elegibilidad de SAQ A
Consejo de Normas de Seguridad de PCI: PCI DSS
Descargo de Responsabilidad
Este artículo tiene fines educativos generales únicamente y no constituye asesoramiento legal, de ciberseguridad o de cumplimiento. La elegibilidad para SAQ A y los requisitos de validación de PCI DSS dependen del entorno de pago de su agencia, el adquirente, los proveedores de servicios y el programa de marca de tarjetas. Su adquirente, facilitador de pagos, proveedor de pagos u otra entidad que aplique el cumplimiento determina el enfoque de validación aplicable. Consulte a esa entidad, a un evaluador de seguridad cualificado, a un asesor legal o a otro asesor cualificado sobre las obligaciones de su agencia. Revisado por última vez: agosto de 2026.
