Article technique
Développer pour EMV, Partie II
Dans La première partie 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 se produit au niveau du kernel , en dehors du contrôle de la logique applicative.
- Les résultats de la transaction sont retournés sous forme de TLV (« tags »).
- Une cryptogram (un bloc de données unique de 8 octets généré par la carte à l'aide d'une clé privée connue d'elle seule) est produit avant l'étape de finalisation de la transaction ; un second cryptogram est produit après l'appel permettant de finaliser la transaction.
- Le cryptogramme est renvoyé par la carte dans le tag 9F26 (un tag défini par EMVCo, non un tag propriétaire ID TECH).
En règle générale, vous allez regrouper le premier cryptogramme (ainsi que toute autre donnée TLV requise par votre processeur back-end) pour l'envoyer au processeur, en temps réel, via le réseau, afin d'obtenir un code d'autorisation (dans le tag 89), avant de lancer 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 s'en chargent à votre place), en utilisant les API web de votre passerelle de paiement. La plupart des passerelles disposent de leurs propres SDK pour faciliter cette étape.
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 callback. Dans ce callback, vous obtiendrez un accès aux données de la transaction, qui contiendront un ensemble de TLV. Parmi ces TLV figurera le second et dernier cryptogramme (mentionné précédemment), lequel — à nouveau — sera présent dans le tag 9F26.
Types de cryptogrammes
Le cryptogramme renvoyé dans le tag 9F26 est opaque. Il n'est pas possible, en l'inspectant directement, de déterminer de quel type de cryptogramme il s'agit. Vous pouvez toutefois examiner le tag 9F27 (également renvoyé avec le tag 9F26) pour identifier le type de cryptogramme reçu. Le quartet de poids fort (nibble supérieur) du tag 9F27 contient l'information nécessaire. Les bits peuvent être interprétés comme suit (information issue de EMV Book 3):
De manière 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 recommandationde la carte. Cette recommandation n'est pas toujours contraignante. Par exemple, la carte peut obligatoire de retourner un AAC dans le second cryptogramme (à la Complétion) si le cryptogramme original é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 (en définitive, l'émetteur). 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 recommandation. L'autorité en ligne prend la décision finale.
Notez qu'aux États-Unis (considéré comme un marché exclusivement en ligne), vous obtiendrez presque toujours 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) obtenir un AAC après la première demande « Gen AC ».
Récupération des données TLV
Dans l'Universal SDK, qui prend en charge la communication 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 votre application et le lecteur sont asynchrones. Cela signifie que vous devez enregistrer une ou plusieurs fonctions de rappel (callbacks) personnalisées auprès du SDK afin de « recevoir les réponses » du lecteur. Les instructions à ce sujet sont fournies non seulement dans la documentation du SDK, mais également dans les exemples de code fournis avec celui-ci. L'utilisation des callbacks n'a rien de mystérieux. Nous vous recommandons de consacrer du temps à l'étude des exemples de code du SDK pour bien comprendre le déroulement du processus.
L'essentiel à retenir est qu'une transaction EMV se déroule en plusieurs phases, et que vous recevez différents TLV à l'issue de chacune d'elles. Une idée reçue fréquente est que vous obtiendrez simplement tous les tags souhaités en une seule fois, à la fin de la phase de Complétion. Ce n'est pas le cas. Vous devrez collecter les TLV à chaque phase.
Quels tags pouvez-vous espérer obtenir à chaque phase ? Voici les tags les plus courants, par phase de transaction :
Démarrer 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
Presque tous ces éléments sont des tags standard définis par EMVCo. Ceux qui commencent par « DF » sont des tags propriétaires ID TECH. Pour une liste complète des tags propriétaires ID TECH et de leur signification, veuillez consulter le document 80000503-001, ID TECH TLV Tag Reference Guide, disponible en téléchargement sur notre Base de connaissances.
Vous ne trouvez pas le tag dont vous avez besoin ? Pas de problème. Vous pouvez utiliser le Universal SDK pour demander des tags supplémentaires au moment de la transaction. Les détails de cette procédure sont décrits non seulement dans la documentation du SDK, mais également 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é et que le chiffrement est 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 le document 80000502-001-F, ID TECH Encrypted Data Output. Si vous utilisez une unité de démonstration (injectée avec une clé de démo), vous pouvez déchiffrer les données manuellement à l'aide de notre outil en ligne. En règle générale, vous ne devriez jamais avoir besoin de déchiffrer les données vous-même dans votre code de production , puisque vous transmettrez les données directement à votre processeur de paiement.
Le chiffrement est un vaste sujet. Nous n'en parlerons pas davantage pour l'instant, mais si vous souhaitez en savoir plus, consultez nos articles précédents à ce sujet.
Des questions ?
À ce stade, vous avez probablement de nombreuses questions. Pas d'inquiétude ! De nombreuses ressources gratuites sont à votre disposition sur notre Base de connaissances, et si vous avez encore des questions, nos techniciens ne sont qu'à un coup de fil.