¿Está preguntando cómo realizar la verificación 3D sin almacenar el número de tarjeta o si el proceso que describió cumple con PCI?

Si es el primero, probablemente sea mejor preguntarle directamente a su proveedor de la pasarela de pago para asegurarse de hacerlo correctamente, o proporcionar un enlace a la documentación para que pueda recibir ayuda técnica.

Si es lo último, dependerá de tu situación. ¿Qué SAQ eres y en qué nivel? ¿O estás haciendo un RoC? Si apunta a SAQ A, entonces tiene razón, no puede tocar ese PAN en absoluto. Si va a buscar SAQ A-EP, puede quedarse sin mantenerlo en el navegador temporalmente. Si sucede en su servidor, entonces es SAQ D. En otras palabras, depende del alcance que esté dispuesto a asumir.

Técnicamente, puedes hacerlo con un iframe y / o ajax si tienes que hacer un redireccionamiento completo de la página.

Toda esta situación suena mal.

El flujo típico de una compra o transacción de un usuario en este tipo de entorno sería el siguiente:

• El sitio del proveedor llama a la API de un proveedor de pagos y le pasa los detalles de la transacción: ID del proveedor, nombre e identificador del producto, desglose de los costos, nombre y dirección del cliente, si se conoce, y algunas veces otra información técnica como el objetivo de redireccionamiento.
• La API del proveedor de pagos devuelve la URL de una página de pago para esta transacción.
• El proveedor muestra la página de pago al usuario, ya sea a través de la redirección o en un iframe. Consulte las pautas de Visa para obtener más información sobre los métodos compatibles. Tenga en cuenta que este formulario y su contenido nunca llegan al servidor o la infraestructura del proveedor; son alojados directamente por el proveedor de pago.
• El usuario completa el formulario y ahora contiene los detalles de la tarjeta de crédito que requieren manejo en línea con PCI DSS.
• El formulario se publica en el proveedor de pagos. Estos datos nunca llegan directamente al proveedor, ya que hacerlo significaría que su infraestructura estaría dentro del alcance de las PCI DSS y tendría que ser directamente compatible, negando todo el propósito de un proveedor de pagos externo.
• El proveedor de pagos valida los detalles e intenta tomar los fondos.
• Si el banco del cliente requiere 3D Secure o una función similar, se produce otro redireccionamiento para una validación adicional.
• Si la verificación de 3D Secure fue exitosa, el proveedor de pagos realiza el pago con la tarjeta y retiene los fondos para transferirlos al proveedor.
• El proveedor de pagos puede:
  • en el caso de un método de redireccionamiento, redirige el navegador del usuario a la página de finalización del proveedor junto con un estado de firma criptográfica (comúnmente SAML) que demuestra al proveedor que el pago se realizó correctamente o no, o:
  • en el caso de un iframe o similar, la página externa del proveedor sondea un script que consulta la API del proveedor de pagos para verificar el estado de finalización. Una vez que se completa el pago, un mensaje firmado se devuelve al proveedor para demostrar que el pago se realizó correctamente o no.
• Los datos de estado generalmente incluirán algunos datos de la tarjeta, pero lo más importante es que el PAN se debe enmascarar para que ahora se considere un "PAN parcial" dentro de las pautas de PCI DSS, por lo que se lo coloca fuera del alcance de PCI.
• El proveedor ahora muestra una página de "gracias por comprar" y puede registrar la transacción como completada.

Existen variaciones en este procedimiento, pero la característica clave es que el PAN y CVV / CV2 (y otros campos confidenciales) nunca son procesados o retenidos por el vendedor. El proveedor de pagos se encarga de todo esto. Incluso cuando se utilizan características como "recordar mi tarjeta", la implementación habitual consiste en que el proveedor de pagos almacene el PAN completo, el proveedor en el PAN enmascarado y el ID de cliente almacenado en ambos lados para que el pago el proveedor puede cargar automáticamente la tarjeta sin que el proveedor necesite saber qué es el PAN.

Otro punto clave es el traspaso a 3D Secure o una funcionalidad similar. Si usted es el que se entrega a esa página, entonces usted es el proveedor de pagos y está absolutamente dentro del alcance de las PCI DSS. Tenga en cuenta que absolutamente puede ser el proveedor de pagos y el proveedor al mismo tiempo (tome Amazon, por ejemplo).

No hay contradicción entre la definición de cumplimiento de PCI y la función que proporciona 3D Secure.

La utilización de 3D Secure, un esquema de prevención de fraude, puede ser exigida a un comerciante como condición del contrato entre un comerciante y su banco adquirente. Este contrato le permite al comerciante cobrar las tarjetas de crédito y proporcionarlas al banco, a veces a través de un procesador de pagos, para emitir cargos contra los fondos que ingresan en la cuenta bancaria del comerciante.

El contrato también incluye disposiciones que requieren que el comerciante cumpla con todas las reglas, para gobernanza, arquitectura, desarrollo y demás, producidas por el consorcio PCI. Esto es lo que significa ser compatible con PCI: adherirse, de forma auditable, a todas las reglas producidas por el consorcio.

Por lo tanto, el uso de 3D Secure puede ser un componente, una parte, del cumplimiento de PCI.

Ahora, las reglas de PCI se aplican a lo que se denomina sistemas "de alcance". Cualquier sistema que tenga cualquier tipo de visibilidad para los datos de la tarjeta durante cualquier período de tiempo está sujeto a las reglas de PCI, y cualquier sistema que tenga visibilidad de red, para ciertas definiciones de visibilidad, para aquellos sistemas dentro del alcance con visibilidad de la tarjeta también están dentro del alcance.

PCI es como el embarazo, no hay medio camino. Si los sistemas ven una tarjeta, entonces están dentro del alcance y se requiere el cumplimiento de estas reglas.

PCI es también como una enfermedad, se propaga. Si los sistemas ven una tarjeta, está dentro del alcance, y todos los sistemas que pueden ver el sistema que ve una tarjeta también están dentro del alcance.

Nuevamente, en lo que estás describiendo, no hay contradicción. Las aplicaciones que se ejecutan en los sistemas que usted controla pueden ver las tarjetas. Esos sistemas y aplicaciones están en alcance. Fin de la historia.

Normalmente, las API de pago se dividen en 3 categorías:

1. página de pago alojada en el lado del comerciante y enviada al comerciante
2. página de pago alojada en el lado comercial y solo datos de la tarjeta enviados al proveedor de pago (generalmente a través de un SDK de JavaScript)
3. página de pago alojada en el lado del proveedor de pagos y enviada al proveedor de pagos, el comerciante recibe una notificación sobre la autorización exitosa

Suponiendo que el proveedor de pagos no haya cometido un gran error, debería estar completamente fuera del alcance de las PCI DSS con las opciones 2 y amp; 3.

Con la opción 2 no está en el ámbito de PCI DSS, nunca usa datos de tarjetas de crédito, sino un token temporal o permanente asignado a la transacción (como e4baf901-252b-4818-b826-7f89cad884db ) por el SDK de JavaScript del procesador de pagos. Aparte de esto, el flujo de trabajo de 3ds es exactamente como la opción 1, es solo que sus solicitudes de API tienen un atributo pan_token y no un atributo pan . Vea la API de campos alojados en Braintree como ejemplo enlace

Con la opción 3 no está en el ámbito de PCI DSS, realmente no hace nada, simplemente redirige a su cliente al proveedor de pagos o abre la página del proveedor de pagos en un iframe o algo así, Aquí hay un ejemplo de este tipo de API: enlace

Con la opción 1

Esa es una historia diferente, sí, usted está en el alcance de PCI DSS, sí, necesita tener un certificado válido, dependiendo de la región en que se realicen las pruebas de PEN, tener una organización segura y todas las demás "cosas malas", políticas de contraseña, saltar host para conexión, red segura (y preferiblemente segmentada), asegúrese de que los registros no muestren nada, "denegar todas" las configuraciones de red, hacer auditorías anuales, etc., etc., etc.

Si sigue este camino (y realmente no entiendo por qué debería hacerlo, por favor, no lo haga) al menos puede evitar tener un HSM y preocuparse por las claves de cifrado, etc., lo que significa que no debe almacenar datos PCI DSS. a un disco duro.

Normalmente, la solución más sencilla para evitar esto es almacenar los datos de la tarjeta de crédito en memcache con una política de caducidad de 1 hora o menos (15 minutos funcionan para todas las implementaciones que hice hasta ahora). El truco es no escribirlo en el disco (es por eso que no se redisezca en la mayoría de las implementaciones, por ejemplo), pero un almacén de memoria como memcache es un juego justo. Solo asegúrate de que las claves de acceso sean algo grandes y seguras, como un uuid (es decir, e4baf901-252b-4818-b826-7f89cad884db ).

No siempre fue así en la práctica ...

Históricamente, las compañías de pago han sido muy laxas con respecto al cumplimiento con PCI DSS del comerciante, la única diferencia práctica entre "base de datos de PAN" y "ningún PAN que haya tocado el sistema" fue "cuántas preguntas tiene su cuestionario de autoevaluación" (PCI DSS SAQ para comerciantes).

Solo en casos muy especiales cuando se identificó a un comerciante como punto de venta común para tarjetas robadas, el comerciante se vio obligado a hacerlo, muy a regañadientes y con mucha "comprensión" por parte de las compañías de tarjetas de crédito de someterse al cumplimiento de PCI DSS lvl2 / lvl1 auditoría.

Sin embargo, esto está cambiando debido a una serie de infracciones, y al menos en algunas regiones (como SEE Europa), las compañías de pago ahora están insistiendo en una migración de la opción 1 a todos los comerciantes que no tienen un PCI DSS completo. Certificado de cumplimiento (no solo un ejercicio de marcado "X" en un cuestionario SAQ).