Post tecnico
Sviluppare per EMV, Parte II
Nella Parte I di questo post, abbiamo parlato delle transazioni EMV e di come sono strutturate. Abbiamo visto che:
- A differenza delle transazioni MSR (banda magnetica), una transazione EMV avviene in più fasi.
- La maggior parte dello scambio di dati tra la carta con chip e il lettore avviene a livello di kernel , al di fuori del controllo della logica applicativa.
- I risultati della transazione vengono restituiti in TLV ("tag").
- Un crittogramma (un dato univoco di 8 byte prodotto dalla carta, tramite una chiave privata nota esclusivamente alla carta) viene generato prima della fase di Completamento della transazione; un secondo crittogramma viene prodotto dopo la chiamata per completare la transazione.
- Il crittogramma viene restituito dalla carta nel tag 9F26 (un tag definito da EMVCo, non un tag proprietario ID TECH).
In genere, il primo crittogramma (insieme a qualsiasi altro dato TLV richiesto dal processore back-end) viene pacchettizzato e inviato al processore in tempo reale, tramite rete, per ottenere un codice di autorizzazione (nel tag 89), prima di avviare la chiamata per iniziare la fase di Completamento. È responsabilità del cliente eseguire la richiesta di autorizzazione online (poiché né il lettore né il nostro SDK si occupano di questa parte), utilizzando le API web del proprio gateway. La maggior parte dei gateway dispone di propri SDK per semplificare questa operazione.
Il gateway (o "processore back-end") risponderà alla richiesta di autorizzazione con i tag 89, 8A, 91 e, facoltativamente, 71 o 72. Per completare la transazione, questi TLV dovranno essere passati al metodo emv_completeTransaction() dell'Universal SDK. Il codice riceverà notifica dei risultati tramite una callback. Nella callback si otterrà un riferimento ai dati della transazione, che includerà un insieme di TLV. Tra questi sarà presente il secondo e ultimo crittogramma (citato in precedenza), che si troverà nuovamente nel tag 9F26.
Tipi di crittogrammi
Il crittogramma restituito nel tag 9F26 è opaco: non è possibile determinarne il tipo mediante un'ispezione diretta. Tuttavia, è possibile esaminare il tag 9F27 (restituito anch'esso insieme a 9F26) per identificare il tipo di crittogramma ricevuto. Il nibble superiore di 9F27 contiene le informazioni necessarie. I bit possono essere interpretati come segue (informazioni tratte da EMV Book 3):
In linea generale, 9F27 assumerà un valore esadecimale di 80, 40 o 00, che corrisponde rispettivamente ad ARQC, TC o AAC. Questi valori indicano, nell'ordine: "vai online," "approvato" o "rifiutato."
È importante comprendere che questi valori rappresentano soltanto il suggerimentodella carta. Non sempre tale suggerimento è vincolante. Ad esempio, la carta è tenuta a restituire un AAC nel secondo crittogramma (in fase di Completamento) se il crittogramma originale era ARQC ma l'applicazione di pagamento non è riuscita ad andare online. L'AAC, in questo caso, non implica automaticamente il rifiuto della transazione; tale decisione spetta all'autorità online (in ultima istanza, all'emittente). Nello scenario EMV speciale noto come Quick Chip (o Faster EMV), si otterrà sempre un AAC, poiché la richiesta online avviene in un momento successivo. Non è un problema! La transazione può comunque essere inviata per il regolamento. Il suggerimento della carta è semplicemente suggerimento. La decisione finale spetta all'autorità online.
Si noti che negli Stati Uniti (considerato un mercato esclusivamente online), nel primo crittogramma si otterrà quasi sempre un ARQC. Un'eccezione si verifica quando la carta è scaduta o quando esiste un altro motivo per cui la transazione deve essere rifiutata immediatamente; in tal caso, è teoricamente possibile ricevere un AAC già dopo la prima richiesta "Gen AC".
Acquisizione dei dati TLV
Nell'Universal SDK, che gestisce automaticamente la comunicazione con il lettore ID TECH tramite USB, RS-232, Bluetooth, jack audio o Ethernet (a seconda del tipo di lettore), tutte le comunicazioni relative alle transazioni da e verso il lettore sono asincrone. Ciò significa che è necessario registrare nell'SDK una o più routine di callback personalizzate per "ricevere le risposte" dal lettore. Le istruzioni per eseguire questa operazione sono fornite non solo nella documentazione dell'SDK, ma anche nel codice di esempio incluso. L'utilizzo dei callback non ha nulla di misterioso. Si consiglia di dedicare del tempo allo studio del codice di esempio dell'SDK per comprendere il flusso operativo.
L'aspetto fondamentale da tenere a mente è che una transazione EMV si svolge per fasi e, al termine di ciascuna fase, vengono restituiti TLV diversi. Un malinteso comune è che tutti i tag necessari vengano forniti in un'unica soluzione al termine della fase di Completamento. Non è così. Sarà necessario raccogliere i TLV in ogni fase.
Quali tag è possibile aspettarsi in ogni fase? Ecco i tag più comuni, suddivisi per fase di transazione:
Avvio transazione:
4F
50
57
5A
5F20
5F24
5F25
5F2D
5F34
84
9F20
DFEE12
DFEE23
Autentica Transazione:
95
9B
9F02
9F03
9F10
9F13
9F26
9F27
9F34
9F36
9F37
9F4D
9F4F
Transazione completata:
95
99
9B
9F02
9F03
9F10
9F13
9F26
9F27
9F34
9F36
9F37
9F4D
9F4F
9F5B
Quasi tutti questi sono tag EMVCo standard definiti dal settore. Quelli che iniziano con 'DF' sono tag proprietari ID TECH. Per un elenco completo dei tag proprietari ID TECH e dei relativi significati, fare riferimento al documento 80000503-001, ID TECH TLV Tag Reference Guide, disponibile per il download nella nostra Knowledge Base.
Il tag cercato non è presente nell'elenco? Nessun problema. È possibile utilizzare l'Universal SDK per richiedere tag aggiuntivi al momento della transazione. I dettagli relativi a questa procedura sono descritti non solo nella documentazione dell'SDK, ma anche nel nostro white paper su EMV Transactions with the Universal SDK.
Quali tag vengono cifrati?
Se il lettore è stato sottoposto a key injection con la cifratura attivata, il contenuto dei tag contenenti dati sensibili verrà cifrato. Questo vale ovviamente per qualsiasi tag contenente dati di traccia (ad es. il tag 57) o dati PAN (5A). Per l'elenco completo dei tag cifrati, consultare il documento 80000502-001-F, ID TECH Encrypted Data Output. Se si utilizza un'unità demo (con una chiave demo iniettata), è possibile decifrare i dati manualmente tramite il nostro strumento online. In linea generale, tuttavia, non dovrebbe mai essere necessario decifrare i dati autonomamente nel codice in produzione , poiché i dati verranno trasmessi direttamente al proprio elaboratore.
La cifratura è un argomento vasto. Non la approfondiremo ulteriormente in questa sede, ma per chi desidera saperne di più, si consiglia di consultare i nostri articoli precedenti sull'argomento.
Hai delle domande?
A questo punto, probabilmente hai molte domande. Nessun problema! Abbiamo tantissime risorse gratuite disponibili per te nel nostro Knowledge Base, e se hai ancora domande, i nostri tecnici sono a portata di telefono.