El cumplimiento PCI para e-commerce es uno de los ámbitos en que los comerciantes cometen más errores de valoración. Muchos creen que usar Stripe, PayPal o un gateway de pago conocido les exime automáticamente de toda obligación PCI DSS. La realidad es más matizada: el tipo de integración elegido determina qué SAQ se aplica y cuántos controles recaen sobre el comerciante. Entender esta distinción permite reducir al mínimo el perímetro de cumplimiento eligiendo la arquitectura correcta desde el principio.
Checkout e-commerce y PCI DSS: qué se activa cuando aceptas tarjetas
Cualquier tienda online que acepte pagos con tarjeta activa las obligaciones PCI DSS para el comerciante. La pregunta no es si se aplican las obligaciones, sino cuáles y en qué medida. Todo depende de cómo fluyen los datos de tarjeta durante el checkout. Si el navegador del cliente envía los datos de tarjeta directamente a los servidores del comerciante (aunque sea solo un instante), el comerciante está sujeto a las obligaciones más extensas del SAQ D, con más de 200 controles que satisfacer. Si en cambio los datos de tarjeta nunca llegan a los servidores del comerciante porque el formulario de pago está alojado por el proveedor, el comerciante puede cualificar para el SAQ A, mucho más sencillo.
Existe una vía intermedia representada por el enfoque SAQ A-EP: el comerciante usa JavaScript del proveedor para recoger los datos de tarjeta directamente en el navegador del cliente, sin que los datos transiten por los servidores del comerciante. Esto reduce el ámbito respecto al SAQ D, pero requiere igualmente más controles que el SAQ A, incluida la gestión de la seguridad del servidor web y del código JavaScript de las páginas de checkout. Con el PCI DSS v4, el requisito sobre los scripts de las páginas de pago ha complicado aún más la posición de los comerciantes SAQ A-EP.
Las opciones de integración y su impacto en el SAQ
Las principales opciones de integración para un e-commerce son tres, ordenadas de mayor a menor carga en términos de PCI DSS. La primera es el checkout nativo: el comerciante desarrolla y gestiona internamente el formulario de introducción de datos de tarjeta. Esto conlleva el SAQ D con el perímetro de cumplimiento más amplio. La segunda opción son los hosted fields o JavaScript injection: el proveedor inyecta campos de entrada en la página del comerciante que recogen los datos de tarjeta directamente en el navegador y los envían al proveedor. Esto lleva al SAQ A-EP con un ámbito intermedio. La tercera y menos gravosa opción es la redirección hacia una hosted payment page: el usuario abandona el sitio del comerciante para completar el pago en una página alojada por el proveedor, y regresa después de la confirmación. Esta arquitectura permite el SAQ A.
La tokenización añade un nivel adicional de protección en cualquier escenario. Cuando un proveedor de tokenización certificado intercepta el PAN antes de que llegue a los sistemas del comerciante y devuelve un token no reversible, el comerciante nunca posee datos de tarjeta sensibles. El token puede almacenarse libremente para usos futuros (renovaciones de suscripción, pedidos recurrentes) sin que ello conlleve obligaciones adicionales de seguridad relativas a los datos de tarjeta, porque el token no tiene valor fuera del sistema del proveedor que lo gestiona.
Cómo PCI Proxy EU elimina el ámbito PCI de tu e-commerce
Con PCI Proxy EU, el checkout del comerciante nunca ve los datos de tarjeta. El formulario de pago es gestionado por la infraestructura certificada PCI DSS Level 1 de PCI Proxy EU, que intercepta el PAN y devuelve al comerciante un token antes de que ningún dato sensible llegue a los servidores de la tienda online. Esto lleva al comerciante directamente al SAQ A, eliminando la necesidad de vulnerability scanning trimestral de los servidores, penetration test extensos, gestión de certificados y políticas de control de acceso específicas para el CDE.
La ventaja operativa es significativa también para las tiendas que gestionan pedidos recurrentes o suscripciones. El token almacenado por el comerciante puede usarse para cargar las tarjetas futuras sin que el comerciante conozca nunca el PAN original. Este escenario, antes complejo de gestionar en cumplimiento con el PCI DSS, se vuelve lineal con un proveedor de tokenización: el comerciante solicita al proveedor que procese un cargo utilizando el token, y el proveedor usa el PAN que custodia en su propio vault certificado. El comerciante nunca ve el dato sensible y mantiene el perímetro SAQ A en todas las fases del ciclo de vida del cliente.
Preguntas frecuentes
¿Si uso Stripe o PayPal ya cumplo el PCI DSS?
Depende de la integración. Si usas la redirección hacia la checkout page de Stripe o PayPal, tu ámbito se reduce al SAQ A. Si usas sus API o sus elementos JavaScript con formularios alojados en tu dominio, tu ámbito es SAQ A-EP. Si has integrado directamente las API pasando los datos de tarjeta a través de tu servidor, estás en SAQ D. Usar un gateway conocido no equivale automáticamente a cumplir el estándar: lo que cuenta es la arquitectura de la integración.
¿Un iframe de pago alojado reduce mi ámbito?
Sí, si el iframe se carga desde un dominio del proveedor y los datos de tarjeta no transitan por los servidores del comerciante. En este caso la calificación habitual es SAQ A. Atención sin embargo: si el comerciante tiene JavaScript personalizado que se ejecuta en la misma página del iframe y podría teóricamente acceder a los datos, el PCI Council podría considerar que el comerciante debe completar el SAQ A-EP en lugar del SAQ A. Verifica siempre con tu adquirente la clasificación correcta.
Tengo una tienda WooCommerce: ¿qué debo hacer?
WooCommerce por sí mismo no determina tu ámbito PCI: lo que cuenta es qué gateway de pago usas y cómo lo has integrado. Si usas la redirección hacia una hosted payment page de tu proveedor, puedes completar el SAQ A. Si usas plugins que recogen datos de tarjeta directamente en el checkout de WooCommerce y los pasan vía API, tu ámbito es más amplio. Revisa la documentación de tu plugin de pago y, si es necesario, migra a una solución con formulario alojado.
Cero datos de tarjeta en tu e-commerce significa SAQ A, cumplimiento simplificado y clientes más seguros. Descubre PCI Proxy EU.