PCI DSS para el que construye

PCI DSS suele entrar a los proyectos como una nube: alguien dice “tenemos que cumplir PCI” y nadie sabe si eso son dos semanas o seis meses. La buena noticia es que el tamaño de esa carga la decide una sola decisión de arquitectura, y se toma al principio. La mala es que la decisión que suena más razonable —“hagamos nuestro propio formulario, para tener control”— es justamente la que multiplica el trabajo por diez.

Lo primero: PCI DSS no es una ley peruana

PCI DSS es un estándar de la industria de tarjetas, no una norma del Estado. En el Perú quien te lo va a exigir es tu adquirente o tu pasarela —Niubiz, Izipay, Culqi— como condición del contrato, no la SBS ni SUNAT.

Esto importa por dos razones prácticas. La primera: el interlocutor con quien negocias el alcance es comercial, no regulatorio — y suele tener criterios claros de qué acepta. La segunda: el incumplimiento no se manifiesta como una multa del Estado, sino como algo peor para un negocio digital: que te corten el servicio de cobro o que, tras un incidente, la responsabilidad caiga sobre ti.

La decisión que define todo: ¿toca la tarjeta tus servidores?

Todo el peso de tu cumplimiento depende de dónde vive el formulario que captura la tarjeta. Si lo entrega íntegramente un tercero validado —checkout alojado, iframe tokenizado o redirect— caes en el camino corto. Si tu web participa en entregar ese formulario, caes en uno mucho más largo.

Fíjate en el salto: la diferencia entre el primero y el segundo no es gradual. Basta con que el JavaScript que arma el formulario de tarjeta se sirva desde tu dominio —un “direct post”, un script propio que envía la tarjeta a un tercero— para pasar de la ruta más corta a unos 150 controles. Y si terminas almacenando, procesando o transmitiendo el número de tarjeta, el destino son unos 250.

Por eso, cuando escribimos sobre Culqi y Niubiz insistimos en que la tarjeta nunca toque tus servidores: no es una preferencia estética, es la diferencia entre un cuestionario corto y un proyecto de cumplimiento.

El cambio de 2025 que casi nadie contó

En enero de 2025 el PCI SSC actualizó el SAQ A y quitó los requisitos 6.4.3, 11.6.1 y 12.3.1 —los de gestión de scripts y detección de manipulación en la página de pago—. La versión de octubre de 2024 se retiró el 31 de marzo de 2025 y desde esa fecha rige la nueva.

Suena a alivio, y en parte lo es. Pero viene con un intercambio que conviene leer completo: la actualización subió el listón de elegibilidad. Para usar el SAQ A ahora hay que auto-declarar que el sitio no es susceptible a ataques de scripts que puedan afectar los sistemas de comercio electrónico — y eso se refiere a todo el sitio, no solo a la página de pago.

En otras palabras: se acortó el cuestionario, no la responsabilidad. Si tu sitio no puede sostener esa declaración, no calificas para el SAQ A y te toca A-EP o D, donde esos requisitos siguen aplicando en su totalidad. Y si eres proveedor de servicios de pago, 6.4.3 y 11.6.1 te siguen obligando igual.

Los niveles de comerciante no son lo que crees

Los niveles 1 a 4 se determinan por volumen de transacciones y definen cómo validas, no cuánto te exige el estándar. Ser nivel 4 significa que puedes usar un cuestionario en vez de un auditor certificado — no que apliquen menos requisitos de seguridad.

Es una confusión cara. Un comercio pequeño concluye “somos nivel 4, esto casi no nos aplica”, diseña sin cuidado y termina en SAQ D igualmente, solo que descubriéndolo tarde. El volumen decide la ceremonia de la validación; la arquitectura decide el trabajo.

Qué hacer en la práctica

Decide la arquitectura antes que el proveedor, confirma por escrito con tu adquirente qué cuestionario esperan de ti, y trata el inventario de scripts de tu sitio como parte del producto — no como un tema de seguridad aparte.

Cómo lo hacemos

Diseñamos integraciones de pago que se mantienen en el camino corto: tokenización, checkout del proveedor y ningún dato de tarjeta en tus servidores — sin sacrificar la experiencia.

Lo hemos hecho con Culqi y Niubiz en producción. Si estás definiendo cómo cobrar y quieres tomar esta decisión con la información completa —incluido lo que de verdad cuesta— hablemos antes de que la arquitectura quede fijada.

En resumen

El costo de cumplir PCI DSS no lo decide tu tamaño: lo decide si la tarjeta pasa por tus servidores. Delegar la captura en el checkout, el iframe o el redirect del proveedor te mantiene en el cuestionario más corto; servir tú el formulario te lleva a unos 150 controles, y almacenar datos de tarjeta a unos 250. El cambio de 2025 quitó tres requisitos del SAQ A pero elevó la elegibilidad —ahora declaras por todo el sitio, no solo por la página de pago—, así que no es una rebaja sino un cambio de forma. Y los niveles de comerciante definen cómo validas, no cuánto te exigen. Decide la arquitectura primero: es la única palanca que de verdad mueve el costo.

Una nota honesta: este artículo es orientación de ingeniería, no asesoría de cumplimiento. La fuente que manda es el repositorio oficial del PCI SSC y lo que te confirme tu adquirente por escrito.