Article technique
Premiers pas avec l'intégration d'une passerelle de paiement
Mettre en place une application de paiement implique de savoir gérer au moins deux types d'intégration différents : tout d'abord, il faut savoir intégrer le matériel nécessaire (c'est-à-dire le lecteur de carte et l'équipement auquel il est connecté) ; ensuite, il faut savoir s'interfacer avec un « back-end » de paiement, tel qu'une passerelle de paiement en ligne (l'entité qui « valide » la transaction et la traite en vue du règlement).
Dans des articles précédents, j'ai largement abordé l'aspect 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 êtes prêt à intégrer Node JS dans votre architecture. Dans un cas comme dans l'autre, communiquer avec les appareils ID TECH ne présente pas de difficulté majeure.
Mais la question demeure : une fois que le lecteur de carte de crédit a lu la puce ou la piste magnétique de la carte, comment transformer ces informations en une transaction approuvée ?
Vous savez probablement déjà quel processeur de paiement traitera vos requêtes. Le vrai enjeu consiste donc à déterminer quel type de support SDK votre processeur ou passerelle propose pour l'exécution des requêtes en ligne.
La plupart des passerelles ou processeurs disposent d'un programme développeur ou d'un portail de développement en ligne, où vous pouvez obtenir des SDK pour créer des applications de paiement. Ces SDK vous permettent généralement de développer une combinaison de composants front-end et back-end pour accéder aux API de paiement du processeur. Ces API de paiement permettent à leur tour 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 parmi plusieurs types de requêtes en ligne que vous devrez probablement prendre en charge. Certains de ces 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
Hors ligne
Régler une transaction EMV hors ligne
PreAuth
Vérifier la validité des informations de la carte à l'aide d'un montant de transaction minime
Remboursement
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
Annulation
Utilisée 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 codes d'erreur différents s'appliquent à chaque type de transaction. Comment tester l'ensemble de ces types d'erreurs possibles ? La 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 de bac à sable de test. (Par exemple, si le code d'erreur pour « Montant trop élevé » est 1243, le SDK peut 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 « intégrées à l'application » (semi-intégrées) précertifiées qui permettent d'acheminer les données de carte chiffrées directement vers le back-end, de manière quasiment transparente, maintenant ainsi votre application de paiement hors du « périmètre PCI ». D'autres, en revanche, supposent que vous prendrez en charge vous-même les questions de périmètre ; dans ce cas, vous enverrez probablement les données de carte chiffrées vers votre propre serveur applicatif, protégé par un pare-feu, où — avec l'aide d'un HSM — vous déchiffrerez les données de carte avant de les transmettre à un acquéreur ou à une passerelle de paiement.
UN EXEMPLE CONCRET
Passons de la vue d'ensemble à la réalité : voyons ce que signifie concrètement 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'avais pour mission de concevoir une application de démonstration de « terminal virtuel » permettant d'envoyer 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 Web de 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 les exemples de code. 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 traiter les requêtes HTTP provenant d'une interface web, ainsi qu'une classe « worker » chargée de transmettre les données du navigateur (récupérées par le servlet) vers le back-end CreditCall. La première représentait environ 250 lignes de Java ; la seconde, 92 lignes.
Je ne présenterai pas le code de la classe servlet, car il s'agit essentiellement d'un code servlet Java 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 place 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 CreditCall ChipDNA Direct pour créer un objet com.creditcall.Request, qui est ensuite remis à 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 commentaires supplémentaires. 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 de CreditCall. En tant que développeur, vous n'avez jamais à voir, manipuler, analyser ni 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 indiqué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 déclenche l'appel HTTPS sortant.
Le serveur CreditCall n'est pas particulièrement exigeant quant aux tags TLV que vous envoyez dans vos données de transaction, à condition d'inclure ceux qui contiennent les données essentielles de la carte (par exemple : les tags 5A et 57 pour les transactions EMV par contact ; le tag 56 pour les transactions sans contact ; ainsi que 9F26 et 9F27, contenant les informations de 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.
À force d'essais et d'erreurs, j'ai constaté que l'application serveur CreditCall n'est pas prompte à refuser une transaction simplement parce 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. La valeur zéro correspond à un AAC, c'est-à-dire 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'approuver 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 énormément de détails intéressants sur EMV en expérimentant avec ces outils. 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 en numéro gratuit pour démarrer avec un kit d'évaluation :