flux de paiement ← retour à la référence paiements
Ma perspective sur les paiements: L’industrie des paiements est un écosystème complexe réunissant de nombreux acteurs — chacun opérant selon des normes mondialement reconnues telles que celles définies par l’ISO, EMVCo, les fournisseurs de portefeuilles électroniques (Wallet Providers) et les régulateurs. Ce qui m’intéresse, c’est de comprendre cet environnement de bout en bout, et comment ces normes façonnent l’expérience réelle d’un paiement.

Cette page est ma manière de regrouper et d’organiser les connaissances fondées sur les standards que j’ai acquises au fil des années. Les extraits et schémas présentés ici sont des synthèses conceptuelles issues de spécifications publiques et de bonnes pratiques du secteur.

Synthèse

  • Après des échanges entre une carte EMV et un terminal, un cryptogramme est créé avant que la transaction soit envoyée en ligne à l'émetteur pour autorisation. Comment ce cryptogramme est-il généré ?
  • Dans les transactions par jeton, l'émetteur ne peut pas valider le cryptogramme du jeton — seul le réseau le peut. Alors qu'est-ce que l'émetteur « valide » exactement quand il autorise la transaction ?
  • Les achats via portefeuille mobile commencent par une demande au réseau de paiement de générer un cryptogramme (TAVV) + ECI. Si le cryptogramme est généré par le réseau, comment une transaction peut-elle être refusée pour échec de validation du cryptogramme ?
~4 minutes de lecture 19 November, 2025
flux de paiement par carte
Card-based payment flow diagram

Figure 1 – bref aperçu: Le schéma illustre le flux de communication lors des transactions EMV, qu’elles soient **contact** ou **sans contact**, lorsqu’une carte est insérée ou approchée d’un terminal de paiement.
Pendant une transaction, des messages sont échangés de manière séquentielle entre chaque participant au flux, et chaque étape nécessite un accord mutuel avant de passer à la suivante.
La majorité des cartes à puce EMV actuellement sur le marché utilisent le Cryptogram Version 18 (CVN18), précédé historiquement par le CVN10. Chaque message suit une spécification définie qui détermine la structure des éléments de données. Un message contient généralement plusieurs champs, et les principales différences entre les transactions en contact et sans contact se trouvent dans : - le POS Entry Mode (ISO Champ 22), et - la présence du Form Factor Indicator (Tag 9F6E) au sein du Champ 55 (données ICC).
La version du cryptogramme (CVN) indique l’algorithme utilisé par la carte pour générer le cryptogramme. La valeur du CVN est indiquée dans le Tag 9F10 – Issuer Application Data, l’un des tags standards du Champ 55.

flux de paiement par token
Token-based payment flow diagram

Figure 2 – Bref aperçu: Ce flux met en avant les principes essentiels de la tokenisation des cartes de paiement et les transactions réalisées à partir d’un token de paiement. Les portefeuilles numériques tels que Apple Pay (SE), Samsung Pay (HCE), Google Pay (HCE), ainsi que les portefeuilles HCE propres aux émetteurs, permettent d’initier une transaction depuis un appareil mobile via la technologie NFC. Beaucoup de ces portefeuilles s’étendent également aux objets connectés : Apple Watch, Garmin, Swatch, etc., permettant des paiements à travers une variété de facteurs de forme.
Tout comme pour une transaction contact — où les données proviennent du profil de la carte, dans une transaction tokenisée, les données proviennent du profil du token stocké dans le portefeuille.
Un cryptogramme basé sur le token lié à l’appareil (device-bound) est ensuite généré à l’aide de clés cryptographiques stockées :
- dans l’élément sécurisé (SE) des portefeuilles SE, - ou dans le cloud pour les portefeuilles HCE.

La version du cryptogramme des portefeuilles SE diffère de celle des portefeuilles HCE, et seul le réseau de paiement peut valider le cryptogramme basé sur un token. Le cryptogramme garantit l’intégrité des données propres à la transaction.

SE: Secure Element
HCE: Host Card Emulation
NFC: Near Field Communication

flux de paiement pour achats intégrés (in-app)
In-app purchase payment flow diagram

Figure 3 – Bref aperçu: Ce flux illustre la séquence d’interactions lorsqu’un porteur effectue un achat dans l’application marchande en utilisant, par exemple, le bouton1 : « Buy with [nom du portefeuille xPay] »In-App
Il s’agit d’un achat in-app, car l’application du marchand a intégré les API de paiement in-app du fournisseur de portefeuille, permettant l’utilisation de tokens actifs stockés dans le portefeuille de l’appareil ou dans le cloud.

Au début de la transaction, le marchand doit demander un cryptogramme basé sur un token auprès du réseau de paiement, en soumettant les éléments de données requis via une requête API. Le réseau de paiement utilise ces informations pour générer un cryptogramme et renvoyer la valeur ECI (Electronic Commerce Indicator) correspondante (généralement ECI 05, 06 ou 07).

Le cryptogramme généré pour une transaction in-app est appelé TAVV — Token Authentication Verification Value. Il est unique à chaque transaction. L’algorithme permettant de générer le TAVV appartient au réseau de paiement, et seul le réseau peut le valider. Si la transaction contient un TAVV valide, le réseau la transmettra à l’émetteur pour autorisation. Si le TAVV est compromis, il échouera à la validation — la transaction sera alors refusée en STIP, et selon la configuration du BIN, l’émetteur pourra recevoir un Avis d’autorisation STIP (message 0120).

ECI 05 (Visa) or 02 (MC): Authentifié
ECI 06 (Visa) or 01 (MC): Authentification tentée
ECI 07 (Visa) or 00(MC): Non authentifié
STIP: Stand-In Processing
BIN: Bank Institution Number
0120: Un type de message appelé Avis, envoyé par le réseau aux émetteurs selon la configuration du BIN.

1 source: apple pay marketing guidelines