Article technique
Premiers pas avec l'intégration d'une passerelle de paiement
Mettre en place une application de paiement opérationnelle implique de maîtriser au moins deux types d'intégration différents : d'une part, il faut savoir intégrer le matériel nécessaire (c'est-à-dire le lecteur de carte ainsi que l'équipement auquel il est connecté) ; d'autre part, il faut savoir s'interfacer avec un « back-end » de paiement, tel qu'une passerelle de paiement en ligne (l'entité qui « autorise » la transaction et la traite en vue du règlement).
Dans des articles précédents, j'ai longuement abordé la partie intégration matérielle de cette problématique, qui s'avère finalement assez accessible, car avec les lecteurs de cartes ID TECH, vous pouvez utiliser notre Universal SDK pour communiquer avec les appareils depuis un environnement de langage de haut niveau, ou opter pour une solution entièrement en JavaScript, si vous acceptez d'intégrer Node JS dans votre architecture. Dans les deux cas, la communication avec les appareils ID TECH n'est pas vraiment un obstacle majeur.
Mais la question demeure : une fois que le lecteur de carte bancaire a lu la puce ou la piste magnétique de la carte, comment transformer ces informations en une transaction approuvée ?
Vous connaissez vraisemblablement déjà le processeur de paiement qui traitera vos requêtes. Le véritable enjeu consiste alors à identifier le type de support SDK que votre processeur ou passerelle propose pour répondre aux demandes en ligne.
La plupart des passerelles et processeurs disposent d'un programme développeur ou d'un portail de développement en ligne permettant d'obtenir des SDK pour créer des applications de paiement. Ces SDK permettent généralement de concevoir des composants front-end et back-end pour accéder aux API de paiement du processeur. Ces API de paiement, à leur tour, permettent de soumettre des données MagStripe et/ou des données ICC (carte à puce) via le réseau à un processeur back-end, afin d'obtenir une autorisation en temps réel.
L'autorisation de paiement n'est en réalité qu'un des nombreux types de requêtes en ligne que vous devrez probablement prendre en charge. Certains autres types de requêtes sont présentés dans le tableau ci-dessous.
Type de requête
Description
Auth
Demander une autorisation de paiement
Conf
Confirmer une demande d'autorisation précédente
Offline
Régler une transaction EMV hors ligne
PreAuth
Vérifier la validité des informations de carte à l'aide d'un petit montant de transaction
Refund
Rembourser une transaction précédemment réglée
Test
Tester la connectivité avec le processeur
VoiceReferralNotification
Notifier le processeur du résultat d'une demande de référence vocale
Void
Utilisé pour annuler une transaction qui n'a pas encore été réglée
En étudiant la documentation SDK de votre processeur de paiement, vous constaterez qu'un grand nombre de codes de résultat et/ou de codes d'erreur différents s'appliquent à chaque type de transaction. Comment tester l'ensemble de ces erreurs potentielles ? Réponse : la plupart des processeurs disposent d'un mécanisme permettant de définir le montant en centimes d'une transaction à une valeur spéciale afin de déclencher une erreur particulière dans un environnement sandbox de test. (Par exemple, si le code d'erreur pour Montant Trop Élevé est 1243, le SDK pourrait vous permettre de déclencher cette erreur spécifique en soumettant une transaction de test d'un montant de 12,43 $.) Consultez la documentation SDK de votre fournisseur pour plus de détails.
De nombreux processeurs de paiement proposent des solutions précertifiées (semi-intégrées) « in app » qui permettent d'acheminer les données de carte chiffrées directement vers le back-end, de manière plus ou moins transparente, en maintenant votre application de paiement hors du « périmètre PCI », tandis que d'autres supposent que vous prendrez en charge vous-même les questions de « périmètre ». Dans ce dernier cas, vous enverrez probablement les données de carte chiffrées via le réseau vers votre propre application serveur, protégée par un pare-feu, où (à l'aide d'un HSM) vous déchiffrerez les données de carte avant de les transmettre à un acquéreur ou à une passerelle.
UN EXEMPLE CONCRET
Passons des considérations générales à la réalité concrète de l'intégration avec un back-end de paiement.
Cet exemple particulier ne s'appliquera évidemment pas à tous les cas (aucun exemple unique ne le peut), mais il devrait vous donner un aperçu de ce que vous êtes susceptible de rencontrer lors de l'intégration avec un back-end.
Dans ce cas, j'ai eu pour mission de créer une application de démonstration de « terminal virtuel » qui envoie des données de transaction au serveur de test CreditCall afin d'obtenir une autorisation en temps réel pour les transactions EMV. CreditCall dispose d'une API de serveur back-end accessible via HTTPS grâce à leur ChipDNA Direct API, qui peut à son tour être « développé » à l'aide d'un SDK en Java, C++, Perl ou d'autres langages. J'ai choisi la version Java.
Sur le site ChipDNA Direct , j'ai créé un compte développeur et j'ai rapidement reçu (par e-mail) des identifiants me permettant d'accéder au serveur de test CreditCall. J'ai également téléchargé le SDK Java de CreditCall et commencé à examiner le code d'exemple. Je souhaitais en particulier apprendre à soumettre des transactions EMV pour autorisation. Par chance, l'un des fichiers d'exemple, ExampleAuthEMV.java, illustrait exactement le type de code dont j'avais besoin.
Je me suis mis au travail en rédigeant deux classes Java : une classe servlet pour gérer les requêtes HTTP provenant d'un front-end basé sur navigateur, ainsi qu'une classe « worker » pour transmettre les données du navigateur (obtenues par le servlet) vers le back-end CreditCall. La première a abouti à environ 250 lignes de Java ; la seconde, à 92 lignes.
Je ne vais pas présenter le code de la classe servlet, car il s'agit d'un code servlet Java assez standard, à ceci près qu'il récupère des valeurs TLV (soumises en tant que valeurs de champs de formulaire via AJAX) et les insère dans un objet java.util.Hashtable à l'exécution. Cette Hashtable est ensuite transmise à la méthode statique authorize() de ma classe worker. La classe worker utilise les classes utilitaires (bibliothèques) du SDK ChipDNA Direct de CreditCall pour créer un objet com.creditcall.Request, qui est ensuite confié à un objet Client, lequel appelle à son tour le serveur CreditCall. Voici le code :
Ce code est si court et explicite qu'il ne nécessite guère de commentaire supplémentaire. Ce qui est remarquable, c'est que les classes CreditCall Request et Client se chargent de générer les documents XML nécessaires qui sont finalement envoyés au serveur CreditCall. En tant que développeur, vous n'avez jamais à voir, manipuler, analyser ou vous soucier du XML brut (comme il se doit).
Notez que vous devez renseigner vos identifiants de compte de test aux lignes 18 et 19. (Les identifiants affichés ci-dessus sont fictifs. N'essayez pas d'utiliser ce code tel quel !) La ligne 69 est l'endroit où vous définissez l'URL du point de terminaison CreditCall. La ligne 72 émet l'appel HTTPS sortant proprement dit.
Le serveur CreditCall n'est pas particulièrement exigeant quant aux tags TLV que vous envoyez dans vos données de transaction, du moment que vous incluez ceux qui contiennent les données essentielles de la carte (par exemple : les tags 5A et 57 pour un EMV contact ; le tag 56 pour le sans-contact ; ainsi que 9F26 et 9F27, contenant les informations du cryptogramme). En réponse à vos données EMV, le serveur CreditCall retourne généralement des TLV pour les tags 8A, 89 et 91, et éventuellement 71 ou 72 (si des scripts doivent être transmis à la carte à puce). Le code d'autorisation recherché se trouve dans le tag 89.
Par tâtonnements successifs, j'ai constaté que l'application serveur CreditCall n'est pas prompte à refuser une transaction au seul motif que la carte présente un cryptogramme AAC. (Vous pouvez déterminer le type de cryptogramme en inspectant les bits de poids fort du tag 9F27 : des zéros indiquent un AAC, soit un refus.) Ce comportement n'est pas surprenant, car la recommandation de la carte n'est que cela : une recommandation. La décision finale d'accepter ou de refuser une transaction EMV appartient généralement à l'acquéreur. La carte peut être — et l'est souvent — mise en minorité.
Comme vous pouvez le constater, on apprend quantité de détails intéressants sur EMV en expérimentant avec ces éléments. Rien ne vaut une autorisation en conditions réelles pour valider le code d'une application de paiement !
Vous souhaitez en savoir plus sur les transactions EMV ? Consultez notre page Development Home sur la base de connaissances ID TECH. Téléchargez notre livre blanc sur le développement EMV. Ou appelez l'un de nos experts au numéro gratuit pour démarrer avec un kit d'évaluation :