Padrão de Pagamento EMVCo com QR Code Explicado

A maioria dos artigos sobre pagamentos com QR code trata a especificação técnica como uma nota de rodapé. Explicam como é um pagamento QR da perspectiva do usuário e depois pulam diretamente para "escanear e pagar". Isso deixa uma lacuna significativa para qualquer pessoa que precise implementar, certificar ou auditar um fluxo de pagamento QR. Aqui está o que o padrão de pagamento EMVCo QR realmente especifica: a estrutura do payload, os dois modos operacionais, os objetos de dados que carregam as informações do comerciante e da transação, e por que a promessa de interoperabilidade funciona no nível técnico. **A Especificação EMV de QR Code para Sistemas de Pagamento (EMV QRCPS) define um formato de payload Tag-Comprimento-Valor que codifica credenciais de pagamento em um QR code de forma que qualquer leitor compatível, qualquer banco, carteira ou rede de pagamento, possa interpretar sem SDKs proprietários.**

O Que É a EMVCo e Por Que Domina Este Espaço

A EMVCo é o organismo de padrões técnicos de propriedade conjunta de American Express, Discover, JCB, Mastercard, UnionPay e Visa. Fundada em 1999 para gerenciar o padrão de cartão com chip EMV que substituiu as faixas magnéticas globalmente, chegou ao QR code depois: publicou a primeira versão da especificação do Modo Apresentado pelo Comerciante (MPM) em julho de 2017 e a especificação do Modo Apresentado pelo Consumidor (CPM) em setembro de 2018. Ambas foram atualizadas para v1.1 em novembro de 2020. A especificação de QR code não tem royalties. A EMVCo disponibiliza ambos os documentos publicamente em seu site, o que é uma das razões pela qual a adoção aconteceu rapidamente: as autoridades de pagamento nacionais podiam construir trilhos domésticos sobre o padrão sem custos de licenciamento. A EMVCo não opera uma rede de pagamentos. Publica a camada de interoperabilidade, o formato de dados comum que diferentes redes concordam em usar para que o app bancário de um consumidor possa interpretar o QR de um comerciante independentemente de qual banco emitiu a conta do comerciante.

Os Dois Modos: MPM e CPM

O padrão de pagamento EMVCo QR define dois fluxos fundamentalmente diferentes, cada um com seu próprio documento de especificação.

Modo Apresentado pelo Comerciante (MPM)

No MPM, o comerciante gera e exibe o QR code. O consumidor o escaneia com seu app de pagamento. O QR codifica a identidade do comerciante, o destino de pagamento e opcionalmente o valor da transação e a moeda. O MPM suporta dois subtipos:

• MPM estático — Um único QR code impresso ou exibido permanentemente. Identifica o comerciante, mas não inclui um valor. O consumidor insere o valor em seu app. Adequado para pequenos comerciantes, feirantes, prestadores de serviços.
• MPM dinâmico — Um QR gerado por transação, tipicamente pelo sistema de ponto de venda. Inclui um valor específico, moeda e frequentemente uma referência de pedido do comerciante. O app do consumidor preenche o valor automaticamente. Necessário para terminais não assistidos, e-commerce e varejo de alto volume.

Modo Apresentado pelo Consumidor (CPM)

No CPM, o consumidor gera um QR code — geralmente um token de uso único — e o exibe na tela do telefone. O terminal do comerciante (um scanner óptico ou um dispositivo POS equipado com câmera) o lê. O QR do consumidor contém credenciais de pagamento tokenizadas, não o número real do cartão. As transações CPM são autorizadas online usando a infraestrutura existente da rede de cartões. A especificação CPM foi construída sobre os modelos de segurança do cartão com chip EMV: o token incorporado no QR CPM é análogo ao criptograma gerado por um chip durante uma transação sem contato. O CPM é mais comum em supermercados, sistemas de transporte e redes de fast-food onde o comerciante opera hardware de escaneamento fixo.

Dimensão	MPM	CPM
Quem exibe o QR	Comerciante	Consumidor
Quem escaneia	Consumidor (câmera do celular)	Comerciante (scanner POS)
Vida útil do QR	Estático (reutilizável) ou dinâmico (por transação)	Sempre dinâmico (token de uso único)
Valor no QR	Opcional (MPM estático) ou incluído (MPM dinâmico)	Não no QR — liquidado pela rede
Uso principal	Varejo P2M, pagamento de contas, remessas	Supermercados, transporte, POS assistido
Hardware necessário (comerciante)	Apenas tela de exibição	Scanner óptico ou câmera
Adoção global	Dominante	Em crescimento (foco APAC)

Estrutura do Payload TLV — Como os Dados São Codificados

Tanto os payloads MPM quanto CPM usam o mesmo esquema de codificação subjacente: Tag-Comprimento-Valor (TLV). Se você domina TLV, consegue implementar, analisar ou validar qualquer payload QR da EMVCo.

O Esquema de Codificação

Cada elemento de dados no payload é representado como uma string de três partes:

• Tag — 2 caracteres numéricos identificando o objeto de dados (ex: 00 para o Indicador de Formato do Payload)
• Comprimento — 2 caracteres numéricos especificando o comprimento em bytes do valor (ex: 02 significa que seguem 2 caracteres)
• Valor — O conteúdo real, exatamente tantos caracteres quanto o Comprimento especifica

Um payload é uma concatenação plana da esquerda para a direita dessas triplas. Não há delimitador entre elementos — o analisador avança lendo a tag, lendo o comprimento, consumindo exatamente esses bytes como valor e depois repetindo. Exemplo: 000201 decodifica como Tag 00, Comprimento 02, Valor 01. Este é o Indicador de Formato do Payload, e 01 é o único valor válido (indicando a versão 1 do formato EMVCo QRCPS).

Objetos de Dados MPM Principais

Tag	Nome do Campo	Presença	Notas
00	Indicador de Formato do Payload	Obrigatório	Sempre 01
01	Método de Iniciação do Ponto	Condicional	11 = estático, 12 = dinâmico
02-25	Informações de Conta do Comerciante (internacional)	Pelo menos 1 obrigatório	Reservado para Visa, Mastercard, JCB, etc.
26-51	Informações de Conta do Comerciante (doméstico)	Opcional	Esquemas domésticos (PromptPay, PIX, etc.)
52	Código de Categoria do Comerciante	Obrigatório	MCC ISO 18245 (ex: 5411 para mercado)
53	Moeda da Transação	Obrigatório	ISO 4217 numérico (ex: 986 para BRL)
54	Valor da Transação	Condicional	Obrigatório para QR dinâmico; omitido no estático
58	Código do País	Obrigatório	ISO 3166-1 alfa-2 (ex: BR, TH)
59	Nome do Comerciante	Obrigatório	Máx. 25 caracteres
60	Cidade do Comerciante	Obrigatório	Máx. 15 caracteres
61	Código Postal	Opcional
62	Modelo de Campo de Dados Adicionais	Opcional	TLV aninhado: número de conta, rótulo de loja, ID de terminal, etc.
63	CRC	Obrigatório	Checksum CRC-16/CCITT de todo o payload incluindo o cabeçalho da Tag 63

Objetos TLV Aninhados

Algumas tags contêm objetos compostos onde o campo de valor é em si uma string TLV. A Tag 62 (Modelo de Campo de Dados Adicionais) é o exemplo mais comum. Suas sub-tags incluem 01 (Número da Conta), 02 (Número de Celular), 03 (Rótulo da Loja), 04 (Número de Fidelidade), 05 (Rótulo de Referência), 06 (Rótulo do Cliente), 07 (Rótulo do Terminal), 08 (Finalidade da Transação), 09 (Solicitação de Dados Adicionais do Consumidor). Um analisador deve lidar corretamente tanto com TLV plano quanto aninhado. Um bug comum de implementação é tratar todo o payload como plano — o que funciona até que um objeto composto apareça, momento em que o analisador interpreta erroneamente os limites de tag dos campos seguintes.

Validação do Checksum

A Tag 63 é sempre o último elemento. O checksum cobre toda a string do payload incluindo o prefixo 6304 da Tag 63 em si, mas não o valor do checksum de 4 caracteres que se segue. O algoritmo é CRC-16 com o polinômio 0x1021 (variante CCITT-FALSE). Qualquer implementação compatível deve rejeitar payloads que falhem nessa verificação.

QR EMVCo vs Sistemas de Pagamento QR Proprietários

Antes de 2017, o cenário de pagamentos QR era um mosaico de sistemas incompatíveis. Entender o contraste esclarece exatamente o que o padrão EMVCo resolveu, e o que não resolveu.

WeChat Pay e Alipay (China)

WeChat Pay e Alipay usam formatos QR proprietários de propriedade da Tencent e Ant Group respectivamente. Ambos suportam fluxos equivalentes a CPM e MPM, mas o formato do payload não é especificado publicamente. Um scanner construído para Alipay não pode interpretar um QR do WeChat Pay e vice-versa. Na China, a maioria dos terminais de pagamento suporta ambos por meio de SDKs de hardware fornecidos por cada rede. Nenhum é nativo da EMVCo, embora Alipay e WeChat Pay tenham construído camadas adaptadoras compatíveis com EMVCo para aceitação internacional de comerciantes.

UPI (Índia)

A Interface de Pagamentos Unificada da Índia usa um formato QR baseado em URI: upi://pay?pa=comerciante@banco&pn=NomeComerciante&am=100&cu=INR. Isso é definido pela NPCI, não pela EMVCo. O BharatQR — o QR interoperável baseado em cartões da Índia — segue o EMVCo MPM e é compatível com Visa, Mastercard e RuPay simultaneamente em um único código.

PIX (Brasil)

O QR do PIX no Brasil é uma implementação direta do EMVCo MPM v1.1, com um objeto de Informações de Conta do Comerciante específico do PIX no intervalo de tags domésticos (Tag 26). O Banco Central do Brasil determinou um único padrão para todos os PSPs. Este é o caso de sucesso canônico de adoção da EMVCo. Um banco central determinou a especificação, e a interoperabilidade genuína chegou desde o primeiro dia sem negociação entre bancos.

PromptPay (Tailândia)

Os QR codes do PromptPay são EMVCo MPM v1.1 com uma aplicação específica do PromptPay no intervalo de tags domésticos. O Banco da Tailândia publicou o perfil nacional da especificação EMVCo, estendendo a estrutura de informações de conta do comerciante doméstico para acomodar o sistema de identificação proxy do PromptPay (número de telefone ou CPF como destino de pagamento).

Sistema	Formato	Baseado na EMVCo	Interoperável
PIX (Brasil)	EMVCo MPM v1.1	Sim	Sim — todos os PSPs brasileiros obrigatório
PromptPay (Tailândia)	EMVCo MPM v1.1	Sim	Sim — link transfronteiriço com PayNow (SG) desde 2024
PayNow / SGQR (Singapura)	EMVCo MPM v1.1	Sim	Sim — 27+ esquemas em um único adesivo SGQR
DuitNow (Malásia)	EMVCo MPM v1.1	Sim	Sim — corredores ASEAN regionais ativos
BharatQR (Índia)	EMVCo MPM v1.1	Sim	Sim — Visa, Mastercard, RuPay, Amex
UPI QR (Índia)	Formato URI da NPCI	Não	Somente dentro do ecossistema UPI
WeChat Pay (China)	Proprietário (adaptador existe)	Não	Somente dentro do ecossistema WeChat
Alipay (China)	Proprietário (adaptador existe)	Não	Somente dentro do ecossistema Alipay
QRIS (Indonésia)	EMVCo MPM v1.1	Sim	Sim — todas as carteiras eletrônicas indonésias

Adoção por País e Implantação Regional

A EMVCo não rastreia estatísticas de implantação centralmente, mas os relatórios dos bancos centrais nacionais fornecem dados claros. Brasil: O PIX processou 42 bilhões de transações em 2023 (relatório anual do Banco Central do Brasil, março de 2024). Os QR codes são o principal método de iniciação de pagamento de comerciantes. Todos os PSPs licenciados no Brasil são legalmente obrigados a suportar o QR do PIX. Tailândia: O PromptPay tinha 74,8 milhões de contas registradas no terceiro trimestre de 2024 (dados estatísticos do Banco da Tailândia), em um país de 70 milhões de habitantes. O link QR transfronteiriço com Singapura (PayNow-PromptPay) foi lançado em 2024. Singapura: O SGQR consolida 27 esquemas de pagamento em um único adesivo QR EMVCo MPM v1.1, tecnicamente incorporando múltiplos objetos de Informações de Conta do Comerciante (um por esquema) no mesmo payload. Um QR impresso cobre todos os apps de pagamento que um consumidor possa usar. Índia: O UPI ultrapassou 10 bilhões de transações mensais em 2024 (dados publicados pela NPCI). Embora o QR do UPI não seja EMVCo nativo, a NPCI desenvolveu links QR transfronteiriços usando formatos compatíveis com EMVCo com Singapura, França, EAU, Maurício e Nepal. Indonésia: O Banco da Indonésia determinou o QRIS baseado no EMVCo MPM em 2020. Em 2024, mais de 53 milhões de comerciantes estavam registrados no QRIS, a maior implantação de QR de comerciantes do Sudeste Asiático por número. Europa: A adoção europeia tem sido mais lenta. A Iniciativa Europeia de Pagamentos (EPI) e seu produto de carteira Wero (lançado na Alemanha, França e Bélgica em 2024) estão desenvolvendo fluxos de pagamento QR, mas o pagamento sem contato com cartão continua dominante.

O Que Isso Significa Para Desenvolvedores de Produtos Adjacentes a Pagamentos

Se você está construindo um produto que lê, gera ou valida QR codes em um contexto de pagamento, mas não é o processador de pagamentos, estas são as implicações práticas.

Leitura de Payloads QR EMVCo

Analisar um payload QR EMVCo MPM requer um analisador TLV que lide tanto com objetos planos quanto aninhados. Execute a verificação do CRC primeiro. Um CRC que não corresponde significa que os dados estão corrompidos e qualquer análise posterior não faz sentido. Implementações de código aberto existem em Java, JavaScript, Python e Swift. Os documentos de especificação da EMVCo estão disponíveis publicamente no emvco.com sem custo.

Geração de Payloads QR EMVCo

A geração de payload MPM estático é direta: montar as tags obrigatórias, adicionar objetos de Informações de Conta do Comerciante específicos do esquema de pagamento, calcular o CRC e codificar a string resultante como QR code. O MPM dinâmico requer que seu sistema POS ou gateway de pagamento injete a Tag 54 (valor) e os sub-campos da Tag 62 (ID do terminal, referência do pedido) por transação. O formato do QR code é o padrão ISO/IEC 18004 — a especificação EMVCo define o conteúdo do payload, não a codificação do símbolo QR. Um gerador de QR code lida com o símbolo; uma biblioteca EMVCo lida com a string do payload.

Certificação e Conformidade

A EMVCo oferece um Programa de Aprovação de Tipo para QR Codes. Produtos que implementam MPM ou CPM podem obter a aprovação de tipo da EMVCo, que é exigida por algumas autoridades de pagamento nacionais como pré-condição para implantação. O processo envolve a validação de vetores de teste contra os documentos de casos de teste publicados (EMVCo QRC Test Cases v1.0, publicado em agosto de 2022).

Limites do Padrão

A especificação QR da EMVCo é um padrão de formato de payload. Não especifica o protocolo de autorização usado para mover dinheiro. Isso ocorre sobre os trilhos existentes da rede de cartões ou redes interbancárias domésticas. O QR é o mecanismo de iniciação; a arquitetura de compensação e liquidação está fora do escopo. Se você está construindo uma ferramenta de reconciliação ou um monitor de transações, ainda precisará integrar com a API de cada rede separadamente.

Quando o Padrão EMVCo Não Se Aplica

Nem todo QR code de pagamento é um QR EMVCo. Conhecer os limites evita trabalho de implementação desperdiçado. Se um comerciante exibe um QR code que codifica uma URL HTTPS simples apontando para uma página de checkout hospedada, esse não é um payload EMVCo. É um QR de URL com um link de pagamento. A maioria das pequenas empresas de e-commerce usa esse padrão via Stripe, Square ou PayPal. Se você está implementando transferências peer-to-peer dentro de um ecossistema de carteira fechado, não precisa da EMVCo. A especificação visa a aceitação de comerciantes e a interoperabilidade entre redes. Vale dizer diretamente: a especificação EMVCo é bem projetada para o que faz. A separação do intervalo de tags entre esquemas internacionais e domésticos é o tipo de decisão que parece óbvia em retrospecto, mas que exigiu coordenação real entre redes concorrentes. A maioria dos comitês de padrões de pagamento não produz algo tão utilizável.

Como o QR Nova se Encaixa Nesse Cenário

O QR Nova gera QR codes padrão ISO/IEC 18004, o símbolo visual que codifica qualquer string que você fornecer. Os QR codes de pagamento EMVCo usam o mesmo símbolo QR visual. O que os distingue é a string de payload TLV dentro. As duas preocupações são claramente separáveis: um gerador de QR code lida com o símbolo, uma biblioteca EMVCo lida com a estrutura de dados. Os QR codes dinâmicos conforme definidos pelo QR Nova, códigos onde a URL de destino pode ser atualizada após a impressão, são distintos do MPM dinâmico no sentido EMVCo. A terminologia se sobrepõe; a mecânica é diferente. Para casos de uso de pagamento, a definição da EMVCo é a que governa.