Estándar de Pago EMVCo con Código QR Explicado

La mayoría de los artículos sobre pagos con código QR tratan la especificación técnica como una nota al pie. Explican cómo se ve un pago QR desde la perspectiva del usuario y luego saltan directamente a "escanear y pagar". Eso deja una brecha significativa para cualquiera que realmente necesite implementar, certificar o auditar un flujo de pago QR. Aquí está lo que el estándar de pago EMVCo QR realmente especifica: la estructura del payload, los dos modos operativos, los objetos de datos que transportan la información del comerciante y la transacción, y por qué la promesa de interoperabilidad funciona a nivel técnico. **La Especificación EMV de Código QR para Sistemas de Pago (EMV QRCPS) define un formato de payload Tag-Longitud-Valor que codifica credenciales de pago en un código QR de manera que cualquier lector compatible, cualquier banco, billetera o red de pago, pueda analizar sin SDKs propietarios.**

Qué es EMVCo y Por Qué Domina Este Espacio

EMVCo es el organismo de estándares técnicos de propiedad conjunta de American Express, Discover, JCB, Mastercard, UnionPay y Visa. Fundado en 1999 para gestionar el estándar de tarjeta chip EMV que reemplazó las bandas magnéticas a nivel global, llegó al código QR después: publicó la primera versión de la especificación de Modo Presentado por el Comerciante (MPM) en julio de 2017 y la especificación de Modo Presentado por el Consumidor (CPM) en septiembre de 2018. Ambas se actualizaron a v1.1 en noviembre de 2020. La especificación de código QR no tiene regalías. EMVCo pone ambos documentos a disposición pública en su sitio web, lo que es una razón por la que la adopción ocurrió rápidamente: las autoridades de pago nacionales podían construir sistemas locales sobre el estándar sin costos de licencia. EMVCo no opera una red de pago. Publica la capa de interoperabilidad, el formato de datos común que las diferentes redes acuerdan usar para que la app bancaria de un consumidor pueda analizar el QR de un comerciante independientemente del banco que emitió la cuenta del comerciante.

Los Dos Modos: MPM y CPM

El estándar de pago EMVCo QR define dos flujos fundamentalmente diferentes, cada uno con su propio documento de especificación.

Modo Presentado por el Comerciante (MPM)

En MPM, el comerciante genera y muestra el código QR. El consumidor lo escanea con su app de pago. El QR codifica la identidad del comerciante, el destino de pago y opcionalmente el importe de la transacción y la moneda. MPM soporta dos subtipos:

• MPM estático — Un único código QR impreso o mostrado permanentemente. Identifica al comerciante pero no incluye un importe. El consumidor introduce el importe en su app. Adecuado para pequeños comerciantes, puestos de mercado, proveedores de servicios.
• MPM dinámico — Un QR generado por transacción, típicamente por el sistema de punto de venta. Incluye un importe específico, moneda y a menudo una referencia de pedido del comerciante. La app del consumidor pre-rellena el importe. Necesario para terminales desatendidos, e-commerce y retail de alto volumen.

Modo Presentado por el Consumidor (CPM)

En CPM, el consumidor genera un código QR — generalmente un token de un solo uso — y lo muestra en la pantalla de su teléfono. El terminal del comerciante (un escáner óptico o un dispositivo POS equipado con cámara) lo lee. El QR del consumidor contiene credenciales de pago tokenizadas, no el número real de su tarjeta. Las transacciones CPM se autorizan en línea usando la infraestructura existente de la red de tarjetas. La especificación CPM se construyó sobre los modelos de seguridad de la tarjeta chip EMV: el token embebido en el QR CPM es análogo al criptograma generado por un chip durante una transacción sin contacto. CPM es más común en supermercados, sistemas de transporte y cadenas de comida rápida donde el comerciante opera hardware de escaneo fijo.

Dimensión	MPM	CPM
Quién muestra el QR	Comerciante	Consumidor
Quién escanea	Consumidor (cámara del teléfono)	Comerciante (escáner POS)
Vida útil del QR	Estático (reutilizable) o dinámico (por transacción)	Siempre dinámico (token de un solo uso)
Importe en el QR	Opcional (MPM estático) o incluido (MPM dinámico)	No en QR — liquidado por la red
Uso principal	Retail P2M, pago de facturas, remesas	Supermercados, transporte, POS atendido
Hardware requerido (comerciante)	Solo pantalla	Escáner óptico o cámara
Adopción global	Dominante	En crecimiento (enfoque APAC)

Estructura del Payload TLV — Cómo Se Codifican los Datos

Tanto los payloads MPM como CPM usan el mismo esquema de codificación subyacente: Tag-Longitud-Valor (TLV). Si dominas TLV, puedes implementar, analizar o validar cualquier payload QR de EMVCo.

El Esquema de Codificación

Cada elemento de datos en el payload se representa como una cadena de tres partes:

• Tag — 2 caracteres numéricos que identifican el objeto de datos (p.ej., 00 para el Indicador de Formato de Payload)
• Longitud — 2 caracteres numéricos que especifican la longitud en bytes del valor (p.ej., 02 significa que siguen 2 caracteres)
• Valor — El contenido real, exactamente tantos caracteres como especifica la Longitud

Un payload es una concatenación plana de izquierda a derecha de estas tripletas. No hay delimitador entre elementos — el analizador avanza leyendo el tag, leyendo la longitud, consumiendo exactamente esos bytes como valor y luego repitiendo. Ejemplo: 000201 se decodifica como Tag 00, Longitud 02, Valor 01. Este es el Indicador de Formato de Payload, y 01 es el único valor válido (indicando la versión 1 del formato EMVCo QRCPS).

Objetos de Datos MPM Clave

Tag	Nombre del Campo	Presencia	Notas
00	Indicador de Formato de Payload	Obligatorio	Siempre 01
01	Método de Inicio de Punto	Condicional	11 = estático, 12 = dinámico
02-25	Información de Cuenta del Comerciante (internacional)	Al menos 1 requerido	Reservado para Visa, Mastercard, JCB, etc.
26-51	Información de Cuenta del Comerciante (doméstico)	Opcional	Esquemas domésticos (PromptPay, PIX, etc.)
52	Código de Categoría del Comerciante	Obligatorio	MCC ISO 18245 (p.ej., 5411 para alimentación)
53	Moneda de la Transacción	Obligatorio	ISO 4217 numérico (p.ej., 986 para BRL)
54	Importe de la Transacción	Condicional	Requerido para QR dinámico; omitido en estático
58	Código de País	Obligatorio	ISO 3166-1 alfa-2 (p.ej., BR, TH)
59	Nombre del Comerciante	Obligatorio	Máx. 25 caracteres
60	Ciudad del Comerciante	Obligatorio	Máx. 15 caracteres
61	Código Postal	Opcional
62	Plantilla de Campo de Datos Adicionales	Opcional	TLV anidado: número de factura, etiqueta de tienda, ID de terminal, etc.
63	CRC	Obligatorio	Checksum CRC-16/CCITT de todo el payload incluyendo la cabecera del Tag 63

Objetos TLV Anidados

Algunos tags contienen objetos compuestos donde el campo de valor es en sí mismo una cadena TLV. El Tag 62 (Plantilla de Campo de Datos Adicionales) es el ejemplo más común. Sus sub-tags incluyen 01 (Número de Factura), 02 (Número de Móvil), 03 (Etiqueta de Tienda), 04 (Número de Fidelidad), 05 (Etiqueta de Referencia), 06 (Etiqueta de Cliente), 07 (Etiqueta de Terminal), 08 (Propósito de la Transacción), 09 (Solicitud de Datos Adicionales del Consumidor). Un analizador debe manejar correctamente tanto TLV plano como anidado. Un bug común de implementación es tratar todo el payload como plano — lo que funciona hasta que aparece un objeto compuesto, momento en el que el analizador malinterpreta los límites de tag de los campos siguientes.

Validación del Checksum

El Tag 63 es siempre el último elemento. El checksum cubre toda la cadena del payload incluyendo el prefijo 6304 del Tag 63 en sí, pero no el valor del checksum de 4 caracteres que sigue. El algoritmo es CRC-16 con el polinomio 0x1021 (variante CCITT-FALSE). Cualquier implementación compatible debe rechazar los payloads que no superen esta comprobación.

QR EMVCo vs Sistemas de Pago QR Propietarios

Antes de 2017, los pagos QR eran un mosaico de sistemas incompatibles. Entender el contraste aclara exactamente qué resolvió el estándar EMVCo, y qué no.

WeChat Pay y Alipay (China)

WeChat Pay y Alipay usan formatos QR propietarios propiedad de Tencent y Ant Group respectivamente. Ambos soportan flujos equivalentes a CPM y MPM, pero el formato de payload no está especificado públicamente. Un escáner construido para Alipay no puede analizar un QR de WeChat Pay y viceversa. En China, la mayoría de los terminales de pago soportan ambos a través de SDKs de hardware proporcionados por cada red. Ninguno es nativo de EMVCo, aunque Alipay y WeChat Pay han construido capas adaptadoras compatibles con EMVCo para la aceptación de comerciantes internacionales.

UPI (India)

La Interfaz de Pagos Unificada de India usa un formato QR basado en URI: upi://pay?pa=comerciante@banco&pn=NombreComercio&am=100&cu=INR. Esto lo define NPCI, no EMVCo. BharatQR — el QR interoperable basado en tarjetas de India — sí sigue EMVCo MPM y es compatible con Visa, Mastercard y RuPay simultáneamente en un solo código.

PIX (Brasil)

El QR de PIX en Brasil es una implementación directa de EMVCo MPM v1.1, con un objeto de Información de Cuenta del Comerciante específico de PIX en el rango de tags domésticos (Tag 26). El Banco Central do Brasil mandató un único estándar para todos los PSPs. Este es el caso de éxito canónico de adopción de EMVCo. Un banco central mandató la especificación, y la interoperabilidad genuina llegó desde el primer día sin negociación entre bancos.

PromptPay (Tailandia)

Los códigos QR de PromptPay son EMVCo MPM v1.1 con una aplicación específica de PromptPay en el rango de tags domésticos. El Banco de Tailandia publicó el perfil nacional de la especificación EMVCo, extendiendo la estructura de información de cuenta del comerciante doméstico para acomodar el sistema de identificación proxy de PromptPay (número de teléfono o DNI nacional como destino de pago).

Sistema	Formato	Basado en EMVCo	Interoperable
PIX (Brasil)	EMVCo MPM v1.1	Sí	Sí — todos los PSPs brasileños obligatorio
PromptPay (Tailandia)	EMVCo MPM v1.1	Sí	Sí — enlace transfronterizo con PayNow (SG) desde 2024
PayNow / SGQR (Singapur)	EMVCo MPM v1.1	Sí	Sí — 27+ esquemas en un solo adhesivo SGQR
DuitNow (Malasia)	EMVCo MPM v1.1	Sí	Sí — corredores ASEAN regionales activos
BharatQR (India)	EMVCo MPM v1.1	Sí	Sí — Visa, Mastercard, RuPay, Amex
UPI QR (India)	Formato URI de NPCI	No	Solo dentro del ecosistema UPI
WeChat Pay (China)	Propietario (adaptador existe)	No	Solo dentro del ecosistema WeChat
Alipay (China)	Propietario (adaptador existe)	No	Solo dentro del ecosistema Alipay
QRIS (Indonesia)	EMVCo MPM v1.1	Sí	Sí — todas las billeteras electrónicas indonesias

Adopción por País y Despliegue Regional

EMVCo no rastrea estadísticas de despliegue de forma centralizada, pero los informes de los bancos centrales nacionales proporcionan datos claros. Brasil: PIX procesó 42 mil millones de transacciones en 2023 (informe anual del Banco Central do Brasil, marzo de 2024). Los códigos QR son el método principal de iniciación de pago de comerciantes. Todos los PSPs con licencia en Brasil están legalmente obligados a soportar PIX QR. Tailandia: PromptPay tenía 74,8 millones de cuentas registradas en el tercer trimestre de 2024 (datos estadísticos del Banco de Tailandia), en un país de 70 millones de habitantes. El enlace QR transfronterizo con Singapur (PayNow-PromptPay) se lanzó en 2024. Singapur: SGQR consolida 27 esquemas de pago en un único adhesivo QR EMVCo MPM v1.1, técnicamente embebiendo múltiples objetos de Información de Cuenta del Comerciante (uno por esquema) en el mismo payload. Un QR impreso cubre todas las apps de pago que un consumidor pueda usar. India: UPI superó 10 mil millones de transacciones mensuales en 2024 (datos publicados por NPCI). Aunque el QR de UPI no es EMVCo nativo, NPCI ha desarrollado enlaces QR transfronterizos usando formatos compatibles con EMVCo con Singapur, Francia, EAU, Mauricio y Nepal. Indonesia: El Banco de Indonesia mandató QRIS basado en EMVCo MPM en 2020. En 2024, más de 53 millones de comerciantes estaban registrados en QRIS, el mayor despliegue de QR de comerciantes del Sudeste Asiático por número. Europa: La adopción europea ha sido más lenta. La Iniciativa Europea de Pagos (EPI) y su producto de billetera Wero (lanzado en Alemania, Francia y Bélgica en 2024) están desarrollando flujos de pago QR, pero el pago sin contacto con tarjeta sigue siendo dominante.

Lo Que Esto Significa Para Desarrolladores de Productos Adyacentes a Pagos

Si estás construyendo un producto que lee, genera o valida códigos QR en un contexto de pago, pero no eres el procesador de pagos, estas son las implicaciones prácticas.

Leer Payloads QR EMVCo

Analizar un payload QR EMVCo MPM requiere un analizador TLV que maneje tanto objetos planos como anidados. Comprueba el CRC primero. Un CRC que no coincide significa que los datos están corruptos y cualquier análisis posterior no tiene sentido. Las implementaciones de código abierto existen en Java, JavaScript, Python y Swift. Los documentos de especificación de EMVCo están disponibles públicamente en emvco.com sin costo.

Generar Payloads QR EMVCo

La generación de payload MPM estático es sencilla: ensamblar los tags obligatorios, añadir objetos de Información de Cuenta del Comerciante específicos del esquema de pago, calcular el CRC y codificar la cadena resultante como código QR. El MPM dinámico requiere que tu sistema POS o pasarela de pago inyecte el Tag 54 (importe) y los sub-campos del Tag 62 (ID de terminal, referencia de pedido) por transacción. El formato del código QR es el estándar ISO/IEC 18004 — la especificación EMVCo define el contenido del payload, no la codificación del símbolo QR. Un generador de código QR maneja el símbolo; una biblioteca EMVCo maneja la cadena del payload.

Certificación y Cumplimiento

EMVCo ofrece un Programa de Aprobación de Tipo para Códigos QR. Los productos que implementan MPM o CPM pueden obtener la aprobación de tipo de EMVCo, que es requerida por algunas autoridades de pago nacionales como precondición para el despliegue. El proceso implica la validación de vectores de prueba contra los documentos de casos de prueba publicados (EMVCo QRC Test Cases v1.0, publicado en agosto de 2022).

Límites del Estándar

La especificación QR de EMVCo es un estándar de formato de payload. No especifica el protocolo de autorización usado para mover dinero. Eso ocurre sobre los carriles existentes de la red de tarjetas o redes interbancarias domésticas. El QR es el mecanismo de iniciación; la arquitectura de compensación y liquidación está fuera del alcance. Si estás construyendo una herramienta de conciliación o un monitor de transacciones, aún necesitarás integrar con la API de cada red por separado.

Cuándo el Estándar EMVCo No Aplica

No todos los códigos QR de pago son QR de EMVCo. Conocer los límites evita trabajo de implementación desperdiciado. Si un comerciante muestra un código QR que codifica una URL HTTPS sencilla que apunta a una página de pago alojada, ese no es un payload EMVCo. Es un QR de URL con un enlace de pago. La mayoría de los pequeños negocios de e-commerce usan este patrón a través de Stripe, Square o PayPal. Si estás implementando transferencias peer-to-peer dentro de un ecosistema de billetera cerrado, no necesitas EMVCo. La especificación apunta a la aceptación de comerciantes y la interoperabilidad entre redes. Vale la pena decirlo claramente: la especificación EMVCo está bien diseñada para lo que hace. La separación del rango de tags entre esquemas internacionales y domésticos es el tipo de decisión que parece obvia en retrospectiva, pero que requirió coordinación real entre redes competidoras. La mayoría de los comités de estándares de pago no producen algo tan utilizable.

Cómo Encaja QR Nova en Este Panorama

QR Nova genera códigos QR estándar ISO/IEC 18004, el símbolo visual que codifica cualquier cadena que proporciones. Los códigos QR de pago EMVCo usan el mismo símbolo QR visual. Lo que los distingue es la cadena de payload TLV en el interior. Las dos preocupaciones son separables de forma limpia: un generador de código QR maneja el símbolo, una biblioteca EMVCo maneja la estructura de datos. Los códigos QR dinámicos tal como los define QR Nova, códigos donde la URL de destino puede actualizarse después de imprimir, son distintos del MPM dinámico en el sentido de EMVCo. La terminología se superpone; la mecánica es diferente. Para casos de uso de pago, la definición de EMVCo es la que gobierna.