Un valor de autenticación de 3-D Secure (3DS) no es el mismo dato que un código de verificación de tarjeta. La diferencia importa cuando una plataforma de pagos decide qué conservar después de la autorización; no significa que deba retener todos los campos de 3DS.
Para un operador, procesador o proveedor que integra 3DS, la decisión práctica consiste en vincular cada valor con un propósito definido, un sistema y unos roles que lo necesiten, y una regla de conservación que pueda revisarse. La clasificación de PCI DSS es un dato de entrada para ese diseño, no una política de almacenamiento completa.
PCI SSC distingue los valores 3DS de los datos de autenticación sensibles de PCI DSS
La FAQ 1603 del PCI SSC, publicada en septiembre de 2026, indica que los valores de autenticación 3DS no son datos de autenticación sensibles (SAD) a efectos de PCI DSS. La FAQ identifica como SAD de PCI DSS los datos completos de banda magnética, los códigos o valores de verificación de tarjeta y los PIN o bloques de PIN; PCI DSS prohíbe conservar SAD después de la autorización. También indica que PCI DSS no prohíbe conservar datos 3DS una vez finalizado el proceso de autorización. Consulte el texto completo de la FAQ del PCI SSC sobre valores de autenticación 3DS.
Es una declaración de clasificación acotada. «No lo prohíbe» no significa «debe almacenarse», «es seguro conservarlo indefinidamente» ni supone la aprobación de la evaluación de un comercio concreto. No elimina la prohibición independiente de conservar SAD después de la autorización ni resuelve las obligaciones de privacidad, contrato, marca de pago u otros controles de seguridad que puedan aplicarse a cada dato o flujo.
Conserve un valor solo para un flujo de pago definido
Un uso futuro documentado puede justificar la conservación de determinados datos 3DS. La guía de EMVCo para transacciones recurrentes y a plazos describe que un 3DS Requestor conserva el ID de transacción del Directory Server (DS) y/o del Access Control Server (ACS), junto con el valor de autenticación, para una autenticación 3RI posterior. El flujo técnico de EMVCo es un ejemplo acotado; no es una regla para conservar esos campos en cada pago o para cada cliente.
Para cada campo almacenado, registre la siguiente operación que lo utilizará y el componente responsable de ella. Mantenga la referencia de autenticación separada de la autorización del pago, el registro de liquidación y el asiento de la billetera. La guía de orquestación de pagos explica por qué esos estados son distintos en una integración de plataforma.
Defina el límite de datos, acceso y eliminación
Un registro de campos y propósitos permite que una persona revisora responda estas preguntas sin depender de una etiqueta vaga como «datos 3DS»:
| Decisión | Qué registrar |
|---|---|
| Dato | El valor o identificador específico, su origen y formato; no una carga 3DS genérica. |
| Propósito | El flujo de autenticación que lo necesita —por ejemplo, una solicitud 3RI posterior definida— y el servicio que lo consume. |
| Roles y copias | Qué comercio, 3DS Requestor, procesador o componente 3DS lo almacena o recibe; incluya réplicas, exportaciones de soporte y respaldos. No suponga que todo operador desempeña funciones de ACS, DS o 3DSS. |
| Acceso | Qué personas y servicios pueden leerlo o exportarlo y el motivo operativo de cada ruta. |
| Conservación y eliminación | El propósito, el disparador de revisión o vencimiento, la persona responsable y el proceso para eliminarlo de los almacenes activos y las copias posteriores. No invente un plazo universal. |
| Aplicabilidad | Las preguntas sobre marca de pago, proveedor, contrato, privacidad y evaluación que aún requieren una respuesta responsable. |
Si la organización realiza o proporciona funciones de ACS, DS o servidor 3DS (3DSS), el PCI SSC indica que debe confirmar con las marcas de pago pertinentes si se aplica el PCI 3DS Core Security Standard. El estándar está dirigido a entornos donde se realizan esas funciones; su alcance no coincide automáticamente con el alcance de PCI DSS de cada operador.
Mantenga la telemetría rutinaria separada de la carga útil
Trate como datos de pago controlados cualquier valor que se conserve para un flujo definido, aunque el PCI SSC no lo clasifique como SAD de PCI DSS. Un diseño prudente mantiene el valor sin procesar fuera de los registros ordinarios de aplicación, trazas, analítica y solicitudes de soporte, salvo que una necesidad operativa revisada lo requiera. Use una referencia de correlación limitada cuando baste para relacionar eventos y restrinja el sistema que contiene el valor original a los servicios y personas que lo necesitan.
Esta es una recomendación de ingeniería, no un nuevo requisito de PCI DSS. La guía de registro de seguridad y evidencia de auditoría explica cómo conservar registros útiles para una investigación sin copiar cargas sensibles a los registros generales.
Pruebe el ciclo de vida, no solo la respuesta 3DS
La aceptación debe recorrer toda la ruta de conservación. Por ejemplo, compruebe que una implementación de flujo recurrente solo envíe los campos necesarios para su siguiente autenticación documentada; que un flujo de un solo uso no acumule valores sin un propósito posterior; que un cambio de campo del proveedor no asigne silenciosamente el valor equivocado; que los registros y exportaciones rutinarios no expongan la carga sin procesar; y que el vencimiento del propósito active el proceso acordado de revisión y eliminación.
Pruebe también quién puede recuperar el campo almacenado, cómo queda registrado el acceso y si el registro de pago sigue distinguiendo la autenticación de la autorización y la liquidación. Estas comprobaciones permiten revisar la decisión sobre los datos de la plataforma; no certifican un sistema ni determinan el estado de cumplimiento de un comercio.
Si está definiendo una integración de plataforma o pagos, contacte a Wizards con los sistemas y el flujo que necesita conectar.
Preguntas frecuentes
¿Los valores de autenticación 3DS son datos de autenticación sensibles de PCI DSS?
No. La FAQ 1603 del PCI SSC indica que los valores de autenticación 3DS no son SAD de PCI DSS. Los SAD de PCI DSS incluyen datos completos de banda magnética, códigos o valores de verificación de tarjeta y PIN o bloques de PIN; PCI DSS prohíbe conservarlos después de la autorización.
¿PCI DSS exige almacenar un valor de autenticación 3DS?
No. El PCI SSC indica que PCI DSS no prohíbe conservar datos 3DS después de la autorización, pero eso no es una obligación de conservarlos. Defina un propósito específico, un límite de acceso y una regla de revisión o eliminación antes de guardarlos.
¿Cuándo puede un valor 3DS servir para una autenticación posterior?
EMVCo describe un flujo 3RI recurrente o a plazos en el que un 3DS Requestor conserva el ID de transacción del DS y/o del ACS y el valor de autenticación para una autenticación futura. El ejemplo se limita a ese flujo definido y no debe generalizarse a pagos no relacionados.
¿El PCI 3DS Core Security Standard se aplica a todos los operadores de iGaming?
No automáticamente. El PCI SSC describe el estándar para entornos que realizan funciones de ACS, DS o servidor 3DS y recomienda que esas entidades confirmen su aplicabilidad con las marcas de pago pertinentes. Un operador no debe deducir su alcance a partir de un artículo general.
