In genere le API di pagamento rientrano in 3 categorie:

1. pagina di pagamento ospitata sul lato commerciante e inviata al commerciante
2. pagina di pagamento ospitata sul lato commerciante e solo i dati delle carte inviati al fornitore di pagamenti (in genere tramite un SDK JavaScript)
3. pagina di pagamento ospitata sul lato del fornitore di servizi di pagamento e inviata al fornitore di servizi di pagamento, il commerciante riceve una notifica dopo l'autorizzazione riuscita

Supponendo che il fornitore di servizi di pagamento non abbia rovinato tutto alla grande, si dovrebbe essere completamente fuori dallo scopo PCI DSS dalle opzioni 2 & 3.

Con l'opzione 2 non sei nello scope PCI DSS, non usi mai i dati della carta di credito, ma un token permanente o temporaneo assegnato alla transazione (come e4baf901-252b-4818-b826-7f89cad884db ) dall'SDK JavaScript del Processore di pagamento. Oltre a questo, il flusso di lavoro 3ds è esattamente come l'opzione 1, è solo che le tue richieste API hanno un pan_token e non un pan attributo. Vedi API dei campi ospitati su Braintree come esempio link

Con l'opzione 3 non sei in ambito PCI DSS, non fai nulla, devi solo reindirizzare il tuo client al provider di pagamento o aprire la pagina del provider di pagamento in un iframe o qualcosa del genere, ecco un esempio di questo tipo di API: link

Con l'opzione 1

Questa è una storia diversa, sì, si è in ambito PCI DSS, sì è necessario disporre di un certificato valido, a seconda della regione eseguire test PEN, avere un'organizzazione protetta e tutte le altre "cose cattive", politiche password, saltare host per connessione, rete protetta (e preferibilmente segmentata), assicurarsi che i registri non mostrino nulla, "neghi tutto", configurazioni di rete, controlli annuali ecc ecc ecc.

Se segui questa strada (e davvero non capisco perché dovresti, per favore, non farlo) almeno puoi evitare di avere un HSM e preoccuparti delle chiavi di crittografia, ecc., il che significa che non devi memorizzare i dati PCI DSS su un disco rigido.

In genere, la soluzione più semplice per evitarlo è archiviare i dati della carta di credito in memcache con una politica di scadenza di 1 ora o meno (15 minuti per tutte le implementazioni che ho fatto finora). Il trucco è di non scriverlo sul disco (è per questo che non vengono ridisegnati nella maggior parte delle implementazioni, ad esempio), ma un archivio di memoria come memcache è un gioco leale. Assicurati che le chiavi di accesso siano qualcosa di grande e sicuro, come un uuid (cioè e4baf901-252b-4818-b826-7f89cad884db ).

Non è sempre stato così in pratica ...

Storicamente, le società di pagamento sono state molto scarse per quanto riguarda la conformità PCI DSS dei commercianti, l'unica differenza pratica tra "database pieno di PAN" e "nessun PAN che abbia mai toccato il sistema" era "quante domande ha il questionario di autovalutazione" (SAQ PCI DSS per i commercianti).

Solo in casi molto particolari, quando un commerciante è stato identificato come punto vendita comune per le carte rubate, il commerciante è stato costretto, molto molto riluttante e con molta "comprensione" da parte delle società delle carte di credito a sottoporsi alla conformità PCI DSS lvl2 / lvl1 revisione contabile.

Tuttavia sta cambiando a causa di una serie di violazioni, e almeno in alcune regioni (come SEE Europe), le società di pagamento stanno ora insistendo su una migrazione dall'opzione 1 a tutti i commercianti che non dispongono di un PCI DSS completo certificato di conformità (non solo un esercizio di marcatura "X" in un questionario SAQ).

Stai chiedendo come eseguire la verifica 3D senza memorizzare il numero della carta o se la procedura che hai descritto è conforme allo standard PCI?

Se è il primo, probabilmente è meglio chiedere direttamente al fornitore del gateway di pagamento di assicurarsi di farlo correttamente o di fornire un collegamento alla documentazione in modo da poter essere aiutato in modo tecnico.

Se è il secondo, dipenderà dalla tua situazione. Che SAQ sei e quale livello? O stai facendo un RoC? Se stai mirando a SAQ A hai ragione, non puoi toccarlo affatto, se stai per SAQ A-EP puoi farlo frugare temporaneamente nel browser. Se succede sul tuo server, allora è SAQ D. In altre parole, dipende dall'ambito che sei disposto ad assumere.

Tecnicamente potresti riuscire a farlo con iframe e / o ajax se devi eseguire un reindirizzamento a pagina intera.

L'intera situazione sembra sbagliata.

Il flusso tipico di un acquisto o transazione di un utente in questo tipo di ambiente sarebbe il seguente:

• Il sito del fornitore chiama un'API del fornitore di servizi di pagamento, passando i dettagli della transazione: ID del fornitore, nome del prodotto e identificatore, scomposizione dei costi, nome e indirizzo del cliente se noti, e talvolta altre informazioni tecniche come il target di reindirizzamento.
• L'API del provider di pagamento restituisce l'URL di una pagina di pagamento per questa transazione.
• Il venditore visualizza la pagina di pagamento per l'utente, tramite reindirizzamento o in un iframe. Consulta le linee guida Visa per maggiori informazioni sui metodi conformi. Nota che questo modulo e i suoi contenuti mai raggiungono il server o l'infrastruttura del fornitore; sono direttamente ospitati dal provider di pagamento.
• Il modulo viene compilato dall'utente e ora contiene i dati della carta di credito che richiedono la gestione in linea con PCI DSS.
• Il modulo viene inviato al fornitore di servizi di pagamento. Questi dati non raggiungono mai direttamente il fornitore, perché fare ciò significherebbe che la loro infrastruttura rientrerebbe nell'ambito di PCI DSS e avrebbe bisogno di essere direttamente conforme, annullando l'intero scopo di un fornitore di servizi di pagamento di terze parti.
• Il fornitore di servizi di pagamento convalida i dettagli e tenta di prelevare i fondi.
• Se la banca del cliente richiede 3D Secure o una funzionalità simile, si verifica un altro reindirizzamento per una convalida aggiuntiva.
• Se la verifica di 3D Secure ha avuto esito positivo, il fornitore di pagamento accetta il pagamento dalla carta e detiene i fondi per il trasferimento al fornitore.
• Il fornitore di servizi di pagamento:
  • nel caso di un metodo di reindirizzamento, reindirizza il browser dell'utente alla pagina di completamento del fornitore insieme a uno stato con firma crittografica (comunemente SAML) che dimostra al fornitore che il pagamento è riuscito o non è riuscito, oppure;
  • nel caso di un iframe o simile, la pagina esterna del fornitore esegue il polling di uno script che interroga l'API del provider di pagamento per verificare lo stato di completamento. Una volta completato il pagamento, un messaggio firmato viene restituito al fornitore per dimostrare che il pagamento è andato a buon fine o fallito.
• I dati di stato di solito includono alcuni dati di carte, ma la maggior parte in modo critico il PAN deve essere mascherato in modo che sia ora considerato un "PAN parziale" all'interno delle linee guida PCI DSS, rendendolo quindi fuori dall'ambito PCI.
• Il venditore ora visualizza una pagina di ringraziamento per l'acquisto e può registrare la transazione come completata.

Ci sono delle differenze su questa procedura, ma la caratteristica chiave è che PAN e CVV / CV2 (e altri campi sensibili) non sono mai effettivamente elaborati o trattenuti dal venditore. Il fornitore di pagamenti gestisce tutto questo. Anche quando sono in uso funzionalità come "ricorda la mia scheda", la normale implementazione prevede di avere il PAN completo memorizzato dal provider di pagamento, il PAN mascherato memorizzato dal venditore e un ID cliente memorizzato su entrambi i lati che li unisce insieme in modo che il pagamento il fornitore può ricaricare automaticamente la carta senza che il venditore debba sapere che cos'è il PAN.

Un altro punto chiave è il passaggio a 3D Secure o funzionalità simili. Se tu sei quello che si consegna a quella pagina, allora sei il fornitore di servizi di pagamento e sei assolutamente all'interno dell'ambito PCI DSS. Tieni presente che puoi assolutamente essere il fornitore di servizi di pagamento e del fornitore allo stesso tempo (ad esempio, prendi Amazon).

Non c'è contraddizione tra la definizione di conformità PCI e la funzione fornita da 3D Secure.

L'utilizzo di 3D Secure, uno schema di prevenzione delle frodi, può essere richiesto a un commerciante come condizione del contratto tra un commerciante e la sua banca acquirente. Questo contratto consente al commerciante di raccogliere le carte di credito e di fornirle alla banca, a volte tramite un responsabile del pagamento, per emettere addebiti, i cui fondi vanno sul conto bancario del commerciante.

Questo contratto include anche disposizioni che richiedono al commerciante di rispettare tutte le regole - per la governance, l'architettura, lo sviluppo e così via - prodotte dal consorzio PCI. Questo è ciò che significa essere conformi PCI - aderire, in modo verificabile, a tutte le regole prodotte dal consorzio.

Quindi, l'uso di 3D Secure può essere un componente, una parte, della conformità PCI.

Ora, le regole PCI si applicano a quelli che vengono chiamati sistemi "nell'ambito". Qualsiasi sistema che abbia una qualche visibilità sui dati delle carte per un certo periodo di tempo è soggetto alle regole PCI, e anche tutti i sistemi che hanno visibilità della rete, per alcune definizioni di visibilità, a quei sistemi in-scope con visibilità delle carte sono anch'essi in-scope.

Il PCI è come una gravidanza - non esiste un mezzo. Se i sistemi vedono una carta, allora sono nel campo di applicazione e è richiesta l'adesione a queste regole.

Anche il PCI è come una malattia - si diffonde. Se i sistemi vedono una scheda, è inclusa nella portata e tutti i sistemi che possono vedere il sistema che vede una scheda sono anch'essi in ambito.

Ancora una volta, in ciò che stai descrivendo, non c'è contraddizione. Le applicazioni in esecuzione su sistemi che controlli possono vedere le carte. Quei sistemi e applicazioni sono nella portata. Fine della storia.