application bancaire mobile de l’émetteur

Figure 1 – Bref aperçu : Dans les écosystèmes bancaires digitaux modernes, les institutions financières proposent une application bancaire mobile permettant aux clients d’effectuer un large éventail d’opérations directement depuis leurs appareils mobiles. Pour accélérer le go-to-market (GTM) des fonctionnalités nécessitant un effort d’ingénierie important, les émetteurs peuvent choisir d’intégrer des SDK tiers qui abstraient des flux complexes et réduisent la charge en ressources.
Par exemple, implémenter le Push Provisioning pour les principaux fournisseurs de portefeuilles numériques (Apple, Google, Samsung) nécessite généralement que l’émetteur examine et intègre trois spécifications API distinctes. En utilisant un SDK, l’application bancaire de l’émetteur peut s’appuyer sur un nombre réduit d’APIs pour implémenter la fonctionnalité requise, ce qui simplifie l’intégration. Comme l’application bancaire affiche des données sensibles de la carte, les données en clair ne peuvent pas être échangées entre le SDK de l'application bancaire de l'émetteur et les APIs du SDK tiers. Pour protéger les données du porteur, une clé de chiffrement¹ est utilisée afin de chiffrer les champs sensibles tels que le PAN, la date d’expiration et le CVV2 avant transmission.

SDK: Software Development Kit
Push Provisioning: Fonctionnalité des fournisseurs de portefeuilles permettant aux porteurs de cartes d’envoyer (push) les informations de leur carte (PAN, date d’expiration, etc.) depuis l’application de l’émetteur vers les portefeuilles xPay.
Encryption key: Clé composée d’une clé API et d’un secret partagé, utilisée pour chiffrer les données sensibles (PAN, date d’expiration, CVV2).
PAN: Primary Account Number. Numéro à 16 chiffres identifiant une carte de paiement physique ou numérique.
CVV2: Code de vérification de carte. Code à 3 chiffres imprimé au dos de la carte, utilisé lors du provisioning et pour certaines transactions e-commerce.

Documentations publiques:
1. Visa's VDE SDK Push Provisioning
2. Mastercard's Push Provisioning to Wallet
3. Mastercard's Google Pay Push Provisioning Sequence Diagram

Figure 2 – Bref aperçu : Dans les marchés où les portefeuilles xPay ne sont pas disponibles, ou pour des raisons de restrictions réglementaires, les émetteurs peuvent choisir de développer leur propre portefeuille NFC sous marque émetteur. Dans cette configuration, l’émetteur devient le Token Requestor et est identifié par un Token Requestor ID (TRID) unique. Une plage spécifique des BINs de l’émetteur est configurée dans les systèmes du réseau de paiement afin de supporter la tokenisation des cartes de l’émetteur.

Un portefeuille émetteur nécessite deux implémentations majeures :
1. L’implémentation Token Requestor, et
2. L’implémentation émetteur

Lorsqu’un portefeuille xPay est utilisé, le fournisseur xPay assure les responsabilités du Token Requestor et fournit une interface prête à l’emploi. L’interface fournie facilite l’intégration, permettant à l’émetteur de se concentrer uniquement sur l’implémentation émetteur.
À l’inverse, un portefeuille émetteur doit s’intégrer avec plusieurs parties :
1. les APIs du fournisseur de Token Gateway Service,
2. les APIs de tokenisation du réseau de paiement pour le Token Requestor, et
3. les APIs de tokenisation du réseau pour l’émetteur.
Bien que l’implémentation d’un portefeuille émetteur soit complexe, elle constitue la première étape pour être platform-ready pour la tokenisation.

Les portefeuilles émetteurs ont principalement été implémentés comme portefeuilles HCE et utilisent des Limited Use Keys (LUKs) pour générer des cryptogrammes liés à l’appareil (device-bound cryptograms). Les LUKs sont des clés dynamiques avec un ensemble de paramètres qui contrôlent leur durée de vie. Lorsque l’un de ces paramètres est dépassé, le réseau de paiement génère une nouvelle LUK et notifie le portefeuille de l’émetteur afin qu’il la récupère, ou bien le portefeuille peut notifier le réseau de paiement pour en générer une nouvelle si le paramètre device-LUK est dépassé. Le portefeuille émetteur charge ensuite la nouvelle LUK sur l’appareil et l’utilise pour générer les cryptogrammes pour les paiements futurs.

Lors de l’installation du portefeuille émetteur, le porteur est authentifié et un processus d’ID&V (Identity Verification) est effectué. Une fois authentifié, l’appareil est enregistré et le portefeuille récupère et affiche les représentations visuelles numériques des cartes (card arts) de l’émetteur. Chaque représentation visuelle numérique des cartes (card art) représente une carte associée à un PAN. La carte doit être tokenisée avant d'être utilisée pour les paiements NFC. La tokenisation suit le parcours vert (green path) retournant le code réponse 00 (Approved) pour la TAR – Token Activation Request, car le porteur a déjà complété une vérification d’identité rigoureuse (ID&V) lors de l’installation du portefeuille et après s’y être connecté.

Cryptogramme lié à l’appareil : Cryptogramme généré par le portefeuille à partir des éléments de données de l’appareil, du portefeuille et du token HCE qu’il contient.
Parcours vert : Parmi plusieurs parcours (vert, jaune, orange, rouge), chacun détermine la manière dont un token sera créé selon les paramètres de risque. Un parcours vert signifie qu’aucune vérification d’identité supplémentaire n’est requise ; le token doit être créé et activé immédiatement.
Code réponse : Code renvoyé par l’émetteur ou le réseau de paiement en STIP dans une réponse.
TAR : Token Activation Request. Message ISO 0100 utilisé pour l’activation du token.

¹ plus d’infos: RFC 7516 - json web encryption (jwe)