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.