card.io y PCI DSS v3.0

4

He investigado durante bastante tiempo, pero no puedo encontrar una respuesta a esta pregunta:

Si toco los datos del titular de la tarjeta de alguna manera, necesito la certificación PCI DSS v3.0 SAQ A-EP, que es bastante compleja de obtener. Por lo tanto, la gran popularidad de las páginas de pago alojadas: al usarlas, solo necesito PCI DSS v3.0 SAQ A (sin EP). Para una referencia rápida, consulte enlace

La popular biblioteca card.io facilita que el usuario ingrese sus números de tarjeta de crédito, pero siempre "tocaré "los datos si uso esta biblioteca, antes de reenviarlos a algún servicio web seguro para la tokenización.

Ahora, entiendo que debido a esto, todas las aplicaciones que usan card.io tienen que estar certificadas como PCI DSS 3 SAQ A-EP a partir del 1 de enero de 2015, por lo que esto significa que muchas aplicaciones pueden no estar certificadas ¿Más si no se han actualizado a ...- EP? ¿O me estoy perdiendo información importante aquí?

    
pregunta user37088 19.03.2015 - 14:52
fuente

1 respuesta

7
  

Si toco los datos del titular de la tarjeta de alguna manera, necesito PCI DSS v3.0 SAQ A-EP   certificación

No, eso no es cierto . Si toca los datos del titular de la tarjeta, necesita SAQ B, C o D. El SAQ A (y A-EP) es solo para los comerciantes que "no tocan, procesan ni almacenan datos del titular de la tarjeta" según su Enlace personalizado .

  

El popular libary card.io facilita al usuario poner en su   números de tarjeta de crédito, pero siempre "tocaré" los datos si uso esta   biblioteca

Correcto. El uso de card.io parece hacer que no seas elegible para SAQ A o A-EP.

Digo "aparece" porque el sitio de card.io dice "card.io no almacena ni transmite números de tarjetas de crédito". Pero eso es una especie de tontería: toman una foto y la convierten en datos PAN para su aplicación. Que su aplicación debe almacenar o transmitir, de lo contrario no tendría sentido escanearla. Si escanea una tarjeta con card.io e inmediatamente borra los datos de la memoria sin leerla, es probable que todavía esté en conflicto con el "procesamiento" PAN. datos y estar sujeto al DSS.

Por lo tanto, es un poco engañoso decir que "no almacenan ni transmiten números de tarjetas de crédito" sin decir "pero si nos usa, lo estará haciendo, punto".

  

Ahora, mi entendimiento es que debido a esto, cada aplicación que   usa card.io tiene que ser certificado PCI DSS 3 SAQ A-EP a partir del 1 de enero,   2015

No, todo comerciante que use card.io deberá estar certificado como SAQ C o D, como lo habría hecho en el pasado bajo DSS 2.0.

La única excepción posible sería si usted escribiera y distribuyera una aplicación de pago que utilizara card.io y enviara los datos de PAN directamente a su procesador a través de un iFrame hospedado A-EP aprobado. ¡Genial! ¡Puedes hacer el SAQ A-EP! Pero es probable que tenga que obtener la certificación PA-DSS para que su aplicación funcione. No creo que sea un buen intercambio.

  

¿significa esto que muchas aplicaciones no estarán certificadas más si no se han actualizado a ...- EP?

Aplicaciones no se certifican bajo las SAQ, comerciantes lo hacen. Cualquier comerciante que utilizara card.io en el pasado no habría calificado para SAQ A en el pasado, y no calificará para A o A-EP ahora.

El cambio real que representa A-EP es para los comerciantes que, bajo DSS 2.0, calificaron para SAQ A con soluciones que no son iFrame (Javascript o redireccionamiento transparente). SAQ A-EP dibuja una línea arbitraria e ilógica y dice que iFrame es más seguro que esos dos. Los comerciantes que usan Javascript o redireccionamiento transparente terminarán en un SAQ A-EP más grande (139 preguntas), mientras que los que usan iFrame pueden permanecer en SAQ A (14 preguntas). Dicho esto, la línea que se ha trazado es tan ilógica que espero ver una redefinición continua avanzando.

    
respondido por el gowenfawr 19.03.2015 - 15:32
fuente

Lea otras preguntas en las etiquetas