Norme de Paiement EMVCo par QR Code Expliquée

La plupart des articles sur les paiements par QR code traitent la spécification technique comme une note de bas de page. Ils expliquent à quoi ressemble un paiement QR du point de vue de l'utilisateur, puis passent directement à « scanner et payer ». Cela laisse un fossé important pour quiconque doit réellement implémenter, certifier ou auditer un flux de paiement QR. Voici ce que la norme de paiement EMVCo QR spécifie réellement : la structure du payload, les deux modes opérationnels, les objets de données qui transportent les informations du commerçant et de la transaction, et pourquoi la promesse d'interopérabilité fonctionne au niveau technique. **La Spécification EMV de QR Code pour les Systèmes de Paiement (EMV QRCPS) définit un format de payload Tag-Longueur-Valeur qui encode les identifiants de paiement dans un QR code de sorte que tout lecteur conforme, toute banque, tout portefeuille ou réseau de paiement, puisse l'analyser sans SDK propriétaire.**

Ce qu'est EMVCo et Pourquoi il Domine cet Espace

EMVCo est l'organisme de normes techniques détenu conjointement par American Express, Discover, JCB, Mastercard, UnionPay et Visa. Fondé en 1999 pour gérer la norme de carte à puce EMV qui a remplacé les bandes magnétiques à l'échelle mondiale, il s'est tourné vers les QR codes plus tard : EMVCo a publié la première version de la spécification du Mode Présenté par le Commerçant (MPM) en juillet 2017 et la spécification du Mode Présenté par le Consommateur (CPM) en septembre 2018. Les deux ont été mises à jour vers v1.1 en novembre 2020. La spécification QR code est libre de droits. EMVCo met les deux documents à disposition publiquement sur son site, ce qui est l'une des raisons pour lesquelles l'adoption s'est produite rapidement : les autorités de paiement nationales pouvaient construire des rails domestiques sur la norme sans frais de licence. EMVCo n'opère pas un réseau de paiement. Il publie la couche d'interopérabilité, le format de données commun que les différents réseaux s'accordent à utiliser pour que l'application bancaire d'un consommateur puisse analyser le QR d'un commerçant quelle que soit la banque qui a émis le compte du commerçant.

Les Deux Modes : MPM et CPM

La norme de paiement EMVCo QR définit deux flux fondamentalement différents, chacun avec son propre document de spécification.

Mode Présenté par le Commerçant (MPM)

En MPM, le commerçant génère et affiche le QR code. Le consommateur le scanne avec son application de paiement. Le QR encode l'identité du commerçant, la destination de paiement et optionnellement le montant de la transaction et la devise. Le MPM supporte deux sous-types :

• MPM statique — Un seul QR code imprimé ou affiché en permanence. Il identifie le commerçant mais n'inclut pas de montant. Le consommateur saisit le montant dans son application. Adapté aux petits commerçants, marchands, prestataires de services.
• MPM dynamique — Un QR généré par transaction, typiquement par le système de point de vente. Inclut un montant spécifique, une devise et souvent une référence de commande du commerçant. L'application du consommateur pré-remplit le montant. Requis pour les terminaux sans surveillance, l'e-commerce et la grande distribution.

Mode Présenté par le Consommateur (CPM)

En CPM, le consommateur génère un QR code — généralement un jeton à usage unique — et l'affiche sur l'écran de son téléphone. Le terminal du commerçant (un scanner optique ou un appareil POS équipé d'une caméra) le lit. Le QR du consommateur contient des identifiants de paiement tokenisés, pas le numéro réel de sa carte. Les transactions CPM sont autorisées en ligne en utilisant l'infrastructure existante du réseau de cartes. La spécification CPM a été construite sur les modèles de sécurité de la carte à puce EMV : le jeton incorporé dans le QR CPM est analogue au cryptogramme généré par une puce lors d'une transaction sans contact. Le CPM est plus courant dans les supermarchés, les systèmes de transport et les chaînes de restauration rapide où le commerçant dispose d'un matériel de scan fixe.

Dimension	MPM	CPM
Qui affiche le QR	Commerçant	Consommateur
Qui scanne	Consommateur (caméra du téléphone)	Commerçant (scanner POS)
Durée de vie du QR	Statique (réutilisable) ou dynamique (par transaction)	Toujours dynamique (jeton à usage unique)
Montant dans le QR	Optionnel (MPM statique) ou inclus (MPM dynamique)	Pas dans le QR — réglé par le réseau
Usage principal	Commerce P2M, paiement de factures, virements	Supermarchés, transports, POS assisté
Matériel requis (commerçant)	Écran d'affichage seulement	Scanner optique ou caméra
Adoption mondiale	Dominante	En croissance (focus APAC)

Structure du Payload TLV — Comment les Données sont Encodées

Les payloads MPM et CPM utilisent tous deux le même schéma d'encodage sous-jacent : Tag-Longueur-Valeur (TLV). Maîtriser TLV suffit pour implémenter, analyser ou valider tout payload QR EMVCo.

Le Schéma d'Encodage

Chaque élément de données dans le payload est représenté comme une chaîne en trois parties :

• Tag — 2 caractères numériques identifiant l'objet de données (ex : 00 pour l'Indicateur de Format du Payload)
• Longueur — 2 caractères numériques spécifiant la longueur en octets de la valeur (ex : 02 signifie que 2 caractères suivent)
• Valeur — Le contenu réel, exactement autant de caractères que la Longueur le spécifie

Un payload est une concaténation plate de gauche à droite de ces triplets. Il n'y a pas de délimiteur entre les éléments — l'analyseur avance en lisant le tag, en lisant la longueur, en consommant exactement ces octets comme valeur, puis en répétant. Exemple : 000201 se décode en Tag 00, Longueur 02, Valeur 01. C'est l'Indicateur de Format du Payload, et 01 est la seule valeur valide (indiquant la version 1 du format EMVCo QRCPS).

Objets de Données MPM Principaux

Tag	Nom du Champ	Présence	Notes
00	Indicateur de Format du Payload	Obligatoire	Toujours 01
01	Méthode d'Initiation du Point	Conditionnel	11 = statique, 12 = dynamique
02-25	Informations de Compte du Commerçant (international)	Au moins 1 requis	Réservé pour Visa, Mastercard, JCB, etc.
26-51	Informations de Compte du Commerçant (domestique)	Optionnel	Schémas domestiques (PromptPay, PIX, etc.)
52	Code de Catégorie du Commerçant	Obligatoire	MCC ISO 18245 (ex : 5411 pour épicerie)
53	Devise de la Transaction	Obligatoire	ISO 4217 numérique (ex : 978 pour EUR)
54	Montant de la Transaction	Conditionnel	Requis pour QR dynamique ; omis en statique
58	Code Pays	Obligatoire	ISO 3166-1 alpha-2 (ex : FR, TH)
59	Nom du Commerçant	Obligatoire	Max. 25 caractères
60	Ville du Commerçant	Obligatoire	Max. 15 caractères
61	Code Postal	Optionnel
62	Modèle de Champ de Données Supplémentaires	Optionnel	TLV imbriqué : numéro de facture, libellé magasin, ID terminal, etc.
63	CRC	Obligatoire	Somme de contrôle CRC-16/CCITT de l'intégralité du payload incluant l'en-tête du Tag 63

Objets TLV Imbriqués

Certains tags contiennent des objets composés où le champ de valeur est lui-même une chaîne TLV. Le Tag 62 (Modèle de Champ de Données Supplémentaires) est l'exemple le plus courant. Ses sous-tags incluent 01 (Numéro de Facture), 02 (Numéro de Mobile), 03 (Libellé Magasin), 04 (Numéro de Fidélité), 05 (Libellé de Référence), 06 (Libellé Client), 07 (Libellé Terminal), 08 (Objet de la Transaction), 09 (Demande de Données Supplémentaires du Consommateur). Un analyseur doit gérer correctement à la fois le TLV plat et le TLV imbriqué. Un bug d'implémentation courant est de traiter l'intégralité du payload comme plat — ce qui fonctionne jusqu'à ce qu'un objet composé apparaisse, moment où l'analyseur mal-interprète les limites de tag des champs suivants.

Validation de la Somme de Contrôle

Le Tag 63 est toujours le dernier élément. La somme de contrôle couvre l'intégralité de la chaîne du payload incluant le préfixe 6304 du Tag 63 lui-même, mais pas la valeur de la somme de contrôle de 4 caractères qui suit. L'algorithme est CRC-16 avec le polynôme 0x1021 (variante CCITT-FALSE). Toute implémentation conforme doit rejeter les payloads qui échouent cette vérification.

QR EMVCo vs Systèmes de Paiement QR Propriétaires

Avant 2017, le paysage des paiements QR était un patchwork de systèmes incompatibles. Comprendre le contraste clarifie exactement ce que la norme EMVCo a résolu, et ce qu'elle n'a pas résolu.

WeChat Pay et Alipay (Chine)

WeChat Pay et Alipay utilisent des formats QR propriétaires appartenant respectivement à Tencent et Ant Group. Les deux supportent des flux équivalents au CPM et au MPM, mais le format du payload n'est pas spécifié publiquement. Un scanner conçu pour Alipay ne peut pas analyser un QR WeChat Pay et vice versa. En Chine, la plupart des terminaux de paiement supportent les deux via des SDK matériels fournis par chaque réseau. Aucun n'est nativement EMVCo, bien qu'Alipay et WeChat Pay aient construit des couches d'adaptation compatibles EMVCo pour l'acceptation internationale des commerçants.

UPI (Inde)

L'Interface de Paiements Unifiée de l'Inde utilise un format QR basé sur URI : upi://pay?pa=marchand@banque&pn=NomMarchand&am=100&cu=INR. Ceci est défini par NPCI, pas par EMVCo. Le BharatQR — le QR interopérable basé sur les cartes en Inde — suit bien EMVCo MPM et est compatible avec Visa, Mastercard et RuPay simultanément dans un seul code.

PIX (Brésil)

Le QR PIX au Brésil est une implémentation directe de EMVCo MPM v1.1, avec un objet d'Informations de Compte du Commerçant spécifique au PIX dans la plage de tags domestiques (Tag 26). La Banque centrale du Brésil a imposé une norme unique pour tous les PSP. C'est le cas de succès canonique d'adoption d'EMVCo. Une banque centrale a imposé la spécification, et l'interopérabilité réelle est arrivée dès le premier jour, sans négociation entre banques.

PromptPay (Thaïlande)

Les QR codes PromptPay sont EMVCo MPM v1.1 avec une application spécifique au PromptPay dans la plage de tags domestiques. La Banque de Thaïlande a publié le profil national de la spécification EMVCo, étendant la structure d'informations de compte du commerçant domestique pour accueillir le système d'identification proxy de PromptPay (numéro de téléphone ou numéro d'identité national comme destination de paiement).

Système	Format	Basé sur EMVCo	Interopérable
PIX (Brésil)	EMVCo MPM v1.1	Oui	Oui — tous les PSP brésiliens obligatoire
PromptPay (Thaïlande)	EMVCo MPM v1.1	Oui	Oui — lien transfrontalier avec PayNow (SG) depuis 2024
PayNow / SGQR (Singapour)	EMVCo MPM v1.1	Oui	Oui — 27+ schémas dans un seul autocollant SGQR
DuitNow (Malaisie)	EMVCo MPM v1.1	Oui	Oui — corridors ASEAN régionaux actifs
BharatQR (Inde)	EMVCo MPM v1.1	Oui	Oui — Visa, Mastercard, RuPay, Amex
UPI QR (Inde)	Format URI de NPCI	Non	Dans l'écosystème UPI uniquement
WeChat Pay (Chine)	Propriétaire (adaptateur existe)	Non	Dans l'écosystème WeChat uniquement
Alipay (Chine)	Propriétaire (adaptateur existe)	Non	Dans l'écosystème Alipay uniquement
QRIS (Indonésie)	EMVCo MPM v1.1	Oui	Oui — tous les portefeuilles électroniques indonésiens

Adoption par Pays et Déploiement Régional

EMVCo ne suit pas les statistiques de déploiement de manière centralisée, mais les rapports des banques centrales nationales fournissent des données claires. Brésil : PIX a traité 42 milliards de transactions en 2023 (rapport annuel de la Banque centrale du Brésil, mars 2024). Les QR codes sont la principale méthode d'initiation de paiement des commerçants. Tous les PSP agréés au Brésil sont légalement tenus de prendre en charge PIX QR. Thaïlande : PromptPay comptait 74,8 millions de comptes enregistrés au troisième trimestre 2024 (données statistiques de la Banque de Thaïlande), dans un pays de 70 millions d'habitants. Le lien QR transfrontalier avec Singapour (PayNow-PromptPay) a été lancé en 2024. Singapour : SGQR consolide 27 schémas de paiement dans un seul autocollant QR EMVCo MPM v1.1, en intégrant techniquement plusieurs objets d'Informations de Compte du Commerçant (un par schéma) dans le même payload. Un QR imprimé couvre toutes les applications de paiement qu'un consommateur pourrait utiliser. Inde : UPI a dépassé 10 milliards de transactions mensuelles en 2024 (données publiées par NPCI). Bien que le QR UPI ne soit pas nativement EMVCo, NPCI a développé des liens QR transfrontaliers utilisant des formats compatibles EMVCo avec Singapour, la France, les EAU, Maurice et le Népal. Indonésie : Bank Indonesia a imposé le QRIS basé sur EMVCo MPM en 2020. En 2024, plus de 53 millions de commerçants étaient enregistrés sur QRIS, le plus grand déploiement de QR marchands en Asie du Sud-Est par nombre. Europe : L'adoption européenne a été plus lente. L'Initiative Européenne de Paiements (EPI) et son produit de portefeuille Wero (lancé en Allemagne, France et Belgique en 2024) développent des flux de paiement QR, mais le paiement sans contact par carte reste dominant.

Ce Que Cela Signifie Pour les Développeurs de Produits Adjacents aux Paiements

Si vous construisez un produit qui lit, génère ou valide des QR codes dans un contexte de paiement, mais que vous n'êtes pas le processeur de paiements, voici les implications pratiques.

Lecture des Payloads QR EMVCo

L'analyse d'un payload QR EMVCo MPM nécessite un analyseur TLV capable de gérer à la fois les objets plats et imbriqués. Vérifiez le CRC en premier. Un CRC qui ne correspond pas signifie que les données sont corrompues et toute analyse en aval est sans signification. Des implémentations open source existent en Java, JavaScript, Python et Swift. Les documents de spécification EMVCo sont disponibles publiquement sur emvco.com sans frais.

Génération de Payloads QR EMVCo

La génération de payload MPM statique est simple : assembler les tags obligatoires, ajouter des objets d'Informations de Compte du Commerçant spécifiques au schéma de paiement, calculer le CRC et encoder la chaîne résultante en QR code. Le MPM dynamique nécessite que votre système POS ou passerelle de paiement injecte le Tag 54 (montant) et les sous-champs du Tag 62 (ID terminal, référence de commande) par transaction. Le format du QR code est le standard ISO/IEC 18004 — la spécification EMVCo définit le contenu du payload, pas l'encodage du symbole QR. Un générateur de QR code gère le symbole ; une bibliothèque EMVCo gère la chaîne du payload.

Certification et Conformité

EMVCo propose un Programme d'Approbation de Type pour les QR Codes. Les produits implémentant MPM ou CPM peuvent obtenir l'approbation de type EMVCo, qui est exigée par certaines autorités de paiement nationales comme condition préalable au déploiement. Le processus implique la validation de vecteurs de test par rapport aux documents de cas de test publiés (EMVCo QRC Test Cases v1.0, publié en août 2022).

Limites de la Norme

La spécification QR d'EMVCo est une norme de format de payload. Elle ne spécifie pas le protocole d'autorisation utilisé pour déplacer l'argent. Cela se passe sur les rails existants du réseau de cartes ou les réseaux interbancaires domestiques. Le QR est le mécanisme d'initiation ; l'architecture de compensation et de règlement est hors périmètre. Si vous construisez un outil de réconciliation ou un moniteur de transactions, vous devrez toujours intégrer séparément l'API de chaque réseau.

Quand la Norme EMVCo Ne S'Applique Pas

Tous les QR codes de paiement ne sont pas des QR EMVCo. Connaître les limites évite un travail d'implémentation inutile. Si un commerçant affiche un QR code qui encode une simple URL HTTPS pointant vers une page de paiement hébergée, ce n'est pas un payload EMVCo. C'est un QR d'URL avec un lien de paiement. La plupart des petites entreprises d'e-commerce utilisent ce modèle via Stripe, Square ou PayPal. Si vous implémentez des transferts peer-to-peer au sein d'un écosystème de portefeuille fermé, vous n'avez pas besoin d'EMVCo. La spécification vise l'acceptation des commerçants et l'interopérabilité entre réseaux. Disons-le clairement : la spécification EMVCo est bien conçue pour ce qu'elle fait. La séparation des plages de tags entre schémas internationaux et domestiques est le genre de décision qui semble évidente rétrospectivement, mais qui a nécessité une vraie coordination entre réseaux concurrents. La plupart des comités de normalisation de paiements ne produisent pas quelque chose d'aussi utilisable.

Comment QR Nova s'Intègre dans ce Paysage

QR Nova génère des QR codes standard ISO/IEC 18004, le symbole visuel qui encode toute chaîne que vous fournissez. Les QR codes de paiement EMVCo utilisent le même symbole QR visuel. Ce qui les distingue, c'est la chaîne de payload TLV à l'intérieur. Les deux préoccupations sont clairement séparables : un générateur de QR code gère le symbole, une bibliothèque EMVCo gère la structure de données. Les QR codes dynamiques tels que définis par QR Nova, des codes dont l'URL de destination peut être mise à jour après impression, sont distincts du MPM dynamique au sens EMVCo. La terminologie se chevauche ; la mécanique est différente. Pour les cas d'usage de paiement, c'est la définition EMVCo qui prévaut.