Delimite el verdadero perímetro de pago
Mapée la ruta del comprador desde la página de producto hasta la confirmación. Marque la entrada de tarjeta, redirecciones, iframes, scripts, APIs, complementos, gestores de etiquetas, redes de entrega de contenido y cuentas de administrador que puedan influir en ello. Incluya registros relacionados, herramientas de soporte y analítica. Esto es un registro inicial para su proveedor o evaluador, no una decisión de cumplimiento.
Registre el dominio que sirve cada elemento de la página de pago. PCI SSC indica que la elegibilidad para SAQ A requiere que todos los elementos de la página de pago se originen únicamente en proveedores de servicios conformes con PCI DSS y ninguno en el sitio del comerciante. Para SAQ A-EP, cada elemento puede originarse en el comerciante o en ese proveedor, pero no en otra fuente. Todos los demás criterios siguen aplicando.
Un repositorio puede pasar por alto inyecciones del gestor de etiquetas y configuraciones de plataforma. Revise scripts, iframes, dominios y encabezados en una sesión de navegador normal del checkout.
Revise logs, analítica y flujos de trabajo de soporte para campos de pago. Nunca use datos reales de tarjeta en tickets de prueba o evidencias compartidas.
Reduzca la exposición con un modelo de pago explicable
Cuando sea práctico, utilice una integración en la que un proveedor conforme con PCI DSS recoja los datos de tarjeta en lugar de que su aplicación los reciba o almacene. Una redirección totalmente alojada por el proveedor suele ser más simple que un formulario personalizado, pero campos embebidos e iframes aún pueden permitir que su sitio afecte el pago. Documente la integración real en lugar de confiar en la etiqueta “alojado”.
Evite retener números de cuenta primarios, códigos de seguridad, capturas de pantalla de errores de checkout o detalles de pago copiados a menos que un diseño aprobado lo requiera. El cifrado ayuda a proteger los datos, pero la PCI SSC advierte que el cifrado por sí solo generalmente no excluye un entorno del alcance. Confirme el manejo de tokens, claves, webhooks, reembolsos y responsabilidades con el proveedor y los evaluadores calificados.
Conserve la guía de integración, información de responsabilidades, documentación de cumplimiento relevante y el proceso de notificación de cambios junto con su registro de arquitectura.
No añada experimentos de marketing, herramientas de reproducción, widgets de chat ni bibliotecas opcionales sin un propietario nombrado y revisión de lo que pueden acceder.
Controle scripts, etiquetas y encabezados
El código de navegador de terceros puede introducir cambios no controlados, ejecución arbitraria de código y divulgación a otras partes. Mantenga un inventario del checkout con el dominio de cada script, su propósito, propietario, aprobación y ubicación de carga. Incluya reglas del gestor de etiquetas y código cargado por proveedores, no solo archivos del árbol de código fuente.
PCI SSC se centra en scripts autorizados, integridad, monitorización de manipulaciones y encabezados HTTP que afectan la seguridad. Apruebe una línea base, restrinja cambios, detecte diferencias e investigue. Una Política de Seguridad de Contenidos (CSP) puede restringir las fuentes de recursos. Donde sea adecuado, pruébela en modo report-only antes de hacerla efectiva. CSP es defensa en profundidad, no un reemplazo del desarrollo seguro o la revisión.
Subresource Integrity puede rechazar un script externo cambiado, pero necesita una configuración de cross-origin compatible y puede romperse tras actualizaciones del proveedor.
Limite los roles de publicación, requiera autenticación fuerte, revise la capacidad de código personalizado y conserve una pista de auditoría.
Limite el acceso y haga los cambios en checkout recuperables
Separe la publicación de contenido rutinaria del código del checkout, la administración del proveedor de pago, el hosting, DNS y la gestión de etiquetas. Use cuentas nombradas, privilegio mínimo y autenticación multifactor donde esté soportada. Revise accesos tras cambios de rol y elimine ex empleados, proveedores y agencias. La aplicabilidad exacta de PCI DSS depende del entorno, pero reducir privilegios compartidos y permanentes reduce el riesgo.
Use un proceso de lanzamiento para el checkout: propietario nombrado, revisión, pruebas cuando sea posible, método de rollback y verificación post-lanzamiento en navegador. Pruebe rutas de éxito y fallo, redirecciones y comportamiento móvil. Status Is UP apoya la preparación proactiva del lanzamiento, la optimización del rendimiento y la planificación de rollback alrededor de releases; no determina el cumplimiento de PCI DSS.
Conserve credenciales, códigos de respaldo e instrucciones de rollback en sistemas aprobados con control de acceso; nunca en tickets, capturas de pantalla o repositorios públicos.
Después del lanzamiento, compare los scripts, dominios y encabezados visibles en el navegador con el inventario aprobado.
Actualice la pila y verifique el resultado
Mantenga un inventario de la plataforma de comercio, plugins, temas, componentes de servidor, bibliotecas, SDKs de pago, plantillas de etiquetas y servicios que afectan el checkout. Suscríbase a avisos críticos de proveedores. NIST describe la gestión de parches como identificar, priorizar, adquirir, instalar y verificar actualizaciones. Registre el cambio, pruebe el recorrido de pago y confirme qué se ha desplegado.
Establezca una vía de emergencia para problemas de alto riesgo y una ventana de mantenimiento para cambios rutinarios. Priorice componentes expuestos del checkout, pero no parchee a ciegas en producción y rompa pagos. Use un enfoque de rollback probado y la guía de releases del proveedor. Un componente desactualizado sin propietario conocido es un riesgo a resolver.
Conserve el advisory, la decisión de riesgo, el resultado de la prueba, el registro de despliegue y la verificación final juntos.
Conserve evidencia y use ayuda calificada
Conserve diagramas, información de responsabilidades del proveedor, la justificación de elegibilidad para SAQ, inventarios de scripts y encabezados, revisiones de acceso, aprobaciones, resultados de pruebas, cambios y contactos de proveedores en una ubicación controlada. Actualícelos cuando cambien la arquitectura, la propiedad, los scripts o los proveedores. La evidencia debe ayudar a un revisor autorizado sin exponer datos de tarjeta, secretos o registros de clientes.
Su adquirente o la marca de pago establece las expectativas de validación aplicables. PCI SSC identifica a los Qualified Security Assessors como organizaciones independientes calificadas para realizar evaluaciones PCI DSS y a los Approved Scanning Vendors como proveedores externos de escaneo calificados bajo requisitos aplicables. Busque ayuda calificada para checkout personalizado, alcance poco claro, sospecha de compromiso o selección de SAQ.
Conserve el modelo de checkout, propietarios técnicos, contactos de escalación, fecha de última revisión y enlaces a evidencias juntos.