If I touch card holder data in any way, I need PCI DSS v3.0 SAQ A-EP
certification
No, non è vero . Se si toccano i dati del titolare della carta, è necessario SAQ B, C o D. Il SAQ A (e A-EP) è solo per i commercianti che "non toccano, elaborano o memorizzano i dati dei titolari di carta" come per il tuo link convenzionato .
The popular libary card.io makes it easy for the user to put in their
credit card numbers, but I will always "touch" the data if I use this
library
Una corretta. L'uso di card.io sembra non renderlo idoneo per SAQ A o A-EP.
Dico "appare" perché il sito di card.io dice "card.io non memorizza o trasmette numeri di carta di credito". Ma è una specie di crock: scattano una foto e la trasformano in dati PAN per la tua applicazione. Che l'applicazione deve archiviare o trasmettere, altrimenti non c'era motivo di scansionarla. Se si scannerizzava una card con card.io e si cancellavano immediatamente i dati dalla memoria senza leggerli, probabilmente si eseguiva ancora il controllo di PAN di 'elaborazione' dati ed essere soggetti al DSS.
Quindi è un po 'fuorviante dire che "non memorizzare o trasmettere numeri di carta di credito" senza dire "ma se ci usi, lo farai, punto".
Now, my understanding is that because of this, every application that
uses card.io has to be certified PCI DSS 3 SAQ A-EP from 1st January,
2015
No, ogni commerciante che utilizza card.io dovrà essere certificato SAQ C o D, proprio come avrebbe dovuto fare in passato con DSS 2.0.
L'unica eccezione possibile potrebbe essere se hai scritto e distribuito un'applicazione di pagamento che ha utilizzato card.io e inviato i dati PAN direttamente al tuo processore su un iFrame ospitato da A-EP approvato. Grande! Puoi fare il SAQ A-EP! Ma probabilmente dovresti ottenere la certificazione PA-DSS per la tua applicazione per farlo funzionare. Non penso che sia un buon compromesso.
so does this mean that many applications out there may not be certified any more if they haven't upgraded to ...-EP?
Le applicazioni non certificano sotto i questionari SAQ, commercianti fanno. Qualsiasi commerciante che utilizza card.io in passato non si sarebbe qualificato per il SAQ A in passato, e non sarà idoneo per A o A-EP ora.
Il vero cambiamento che rappresenta A-EP è per i commercianti che, in DSS 2.0, si sono qualificati per SAQ A con soluzioni non-iFrame (Javascript o reindirizzamento trasparente). SAQ A-EP disegna una linea arbitraria e illogica e dice che iFrame è più sicuro di quei due. I commercianti che usano Javascript o reindirizzamento trasparente finiranno in un SAQ A-EP più grande (139 domande) mentre quelli che usano iFrame possono rimanere in SAQ A (14 domande). Detto questo, la linea che è stata tracciata è così illogica che mi aspetto di vedere la continua ridefinizione andare avanti.