Article technique
Développer pour EMV, Partie II
Dans Partie I de cet article, nous avons abordé les transactions EMV et leur structure. Nous avons vu que :
- Contrairement aux transactions MSR (magstripe), une transaction EMV se déroule en plusieurs étapes.
- La majeure partie des échanges entre la carte à puce et le lecteur s'effectue au niveau du noyau , en dehors du contrôle de la logique applicative.
- Les résultats des transactions sont retournés sous forme de TLV (« tags »).
- Un cryptogramme (une donnée unique de 8 octets produite par la carte à l'aide d'une clé privée connue d'elle seule) est généré avant l'étape de finalisation de la transaction ; un second cryptogramme est produit après l'appel pour finaliser la transaction.
- Le cryptogramme est retourné par la carte dans le tag 9F26 (un tag défini par EMVCo, et non un tag propriétaire ID TECH).
En général, vous regroupez le premier cryptogramme (ainsi que toutes les autres données TLV requises par votre processeur back-end) pour les envoyer au processeur, en temps réel et par le réseau, afin d'obtenir un code d'autorisation (dans le tag 89), avant d'émettre l'appel pour démarrer la phase de Finalisation. Il vous incombe d'effectuer la demande d'autorisation en ligne (car ni le lecteur ni notre SDK ne se chargent de cette étape), en utilisant les API web de votre passerelle. La plupart des passerelles proposent leurs propres SDK pour faciliter cette partie.
La passerelle (ou « processeur back-end ») répondra à votre demande d'autorisation avec les tags 89, 8A, 91 et, éventuellement, 71 ou 72. Pour finaliser la transaction, vous transmettrez ces TLV à la méthode emv_completeTransaction() du SDK universel. Votre code sera notifié des résultats via un rappel (callback). Dans ce callback, vous obtiendrez un handle vers les données de la transaction, qui incluront un ensemble de TLV. Parmi ces TLV figurera le second et dernier cryptogramme (mentionné ci-dessus), qui sera — une fois encore — contenu dans le tag 9F26.
Types de cryptogrammes
Le cryptogramme retourné dans le tag 9F26 est opaque. Il n'est pas possible de déterminer, en l'inspectant directement, de quel type de cryptogramme il s'agit. En revanche, vous pouvez examiner le tag 9F27 (qui est également retourné avec le 9F26) pour identifier le type de cryptogramme reçu. Le quartet de poids fort du tag 9F27 contient l'information nécessaire. Les bits peuvent être interprétés comme suit (cette information provient de EMV Book 3):
En règle générale, le tag 9F27 prendra une valeur hexadécimale de 80, 40 ou 00, correspondant respectivement à ARQC, TC ou AAC. Ces valeurs signifient respectivement « aller en ligne », « approuvé » ou « refusé ».
Il est important de comprendre que ces valeurs ne représentent que la décision de la carte en matière de conseil. Ce conseil n'est pas toujours contraignant. Par exemple, la carte est tenue de retourner un AAC dans le second cryptogramme (lors de la Completion) si le cryptogramme d'origine était un ARQC, mais que l'application de paiement n'a pas pu se connecter en ligne. Dans ce cas, l'AAC ne signifie pas automatiquement que votre transaction est refusée ; cette décision appartient à l'autorité en ligne (l'émetteur, en dernier ressort). Dans le scénario EMV particulier connu sous le nom de Quick Chip (ou Faster EMV), vous obtiendrez toujours un AAC, car la demande en ligne intervient ultérieurement. Ce n'est pas un problème ! Vous pouvez tout de même soumettre la transaction pour règlement. Le conseil de la carte est simplement conseil. C'est l'autorité en ligne qui prend la décision finale.
Notez qu'aux États-Unis (considérés comme un marché exclusivement en ligne), vous obtiendrez presque systématiquement un ARQC dans le premier cryptogramme. Une exception à cette règle serait le cas d'une carte expirée ou toute autre raison nécessitant un refus immédiat de la transaction, auquel cas vous pourriez (théoriquement) recevoir un AAC après la première requête « Gen AC ».
Obtention des données TLV
Dans le Universal SDK, qui se charge pour vous des communications avec votre lecteur ID TECH via USB, RS-232, Bluetooth, prise audio ou Ethernet (selon le type de lecteur), toutes les communications liées aux transactions entre l'application et le lecteur sont asynchrones. Cela signifie que vous devez enregistrer une ou plusieurs routines de rappel (callbacks) personnalisées auprès du SDK afin de « recevoir les réponses » du lecteur. Les instructions à cet effet sont fournies non seulement dans la documentation du SDK, mais également dans le code d'exemple fourni avec celui-ci. L'utilisation des callbacks n'a rien de mystérieux. Nous vous recommandons de consacrer un peu de temps à l'étude du code d'exemple du SDK afin de comprendre le déroulement du processus.
L'essentiel à retenir est qu'une transaction EMV se déroule en plusieurs phases, et que vous récupérez différents TLV à la fin de chacune d'elles. Une idée reçue courante consiste à penser que vous obtiendrez d'un seul coup tous les tags dont vous pourriez avoir besoin, à la fin de la phase de Completion. Ce n'est pas le cas. Vous constaterez que vous devez collecter les TLV à chaque phase.
Quels tags peut-on attendre à chaque phase ? Voici les tags les plus courants, par phase de transaction :
Démarrage de la transaction :
4F
50
57
5A
5F20
5F24
5F25
5F2D
5F34
84
9F20
DFEE12
DFEE23
Authentifier la transaction :
95
9B
9F02
9F03
9F10
9F13
9F26
9F27
9F34
9F36
9F37
9F4D
9F4F
Transaction complète :
95
99
9B
9F02
9F03
9F10
9F13
9F26
9F27
9F34
9F36
9F37
9F4D
9F4F
9F5B
La quasi-totalité de ces éléments sont des tags EMVCo standard définis par l'industrie. Ceux qui commencent par « DF » sont des tags propriétaires ID TECH. Pour une liste complète des tags propriétaires ID TECH et leur signification, veuillez consulter le document 80000503-001, ID TECH TLV Tag Reference Guide, disponible en téléchargement sur notre Base de connaissances.
Le tag dont vous avez besoin n'apparaît pas ? Pas de problème. Vous pouvez utiliser le SDK universel pour demander des tags supplémentaires au moment de la transaction. Les détails à ce sujet sont décrits non seulement dans la documentation du SDK, mais aussi dans notre livre blanc sur les EMV Transactions with the Universal SDK.
Quels tags sont chiffrés ?
Si votre lecteur a fait l'objet d'une injection de clé avec le chiffrement activé, le contenu des tags contenant des données sensibles sera chiffré. Cela inclut évidemment tous les tags contenant des données de piste (par ex. le tag 57) ou des données PAN (5A). Pour la liste complète des tags chiffrés, consultez document 80000502-001-F, ID TECH Encrypted Data Output. Si vous utilisez une unité de démonstration (injectée avec une clé de démonstration), vous pouvez déchiffrer les données manuellement à l'aide de notre outil en ligne. En règle générale, cependant, vous ne devriez jamais avoir besoin de déchiffrer les données vous-même dans le code de production , car vous transmettrez les données directement à votre prestataire de traitement.
Le chiffrement est un sujet vaste. Nous n'en parlerons pas davantage pour l'instant, mais si vous souhaitez en savoir plus, consultez nos articles précédents à ce sujet.
Vous avez des questions ?
À ce stade, vous avez probablement de nombreuses questions. Pas de panique ! Nous mettons à votre disposition une multitude de ressources gratuites sur notre Base de connaissances, et si vous avez encore des questions, nos techniciens sont disponibles à tout moment par téléphone.