O Que Realmente Acontece Quando Você Insere um Chip: O Fluxo da Transação EMV de Ponta a Ponta

💡 TL;DR (Too Long; Didn't Read)

A transação inteira em 90 segundos:

• Um pagamento com chip é uma conversa, não uma consulta. O terminal e o cartão trocam APDUs (pares comando/resposta) ao longo de cerca de dez fases, e cada fase altera um estado compartilhado que vive nas tags EMV.
• O cartão nunca diz "aprovado". Ele devolve um criptograma (TC, ARQC ou AAC) e deixa a decisão para o terminal — e, quando online, para o emissor.
• As cinco peças que você precisa saber nomear: seleção de aplicação, GET PROCESSING OPTIONS (que retorna o AIP e o AFL), READ RECORD (que busca os objetos de dados), autenticação de dados offline (SDA/DDA/CDA) e GENERATE AC (que produz o criptograma).
• Tudo o que vem depois nesta série — parsing de TLV, a decisão do TVR, o ARQC — é uma dessas fases vista de perto. Este artigo é o mapa; os demais são o terreno.

Insira um chip num caixa de loja e a coisa toda parece instantânea. Não é instantânea. Nos duzentos a quatrocentos milissegundos entre a inserção e o bipe, o terminal e o cartão executam uma negociação estruturada com pelo menos uma dúzia de trocas de mensagens, várias operações criptográficas e uma árvore de decisão capaz de mandar a transação para offline, para online ou direto para uma recusa. A maioria dos engenheiros que trabalha perto de pagamentos — construindo o aplicativo do POS, o host do adquirente, a pilha de autorização do emissor — nunca acompanhou essa negociação de ponta a ponta. Conhece sua fatia. Este artigo é a fatia inteira, em ordem, com os bytes reais.

Vou tracejar uma única transação com contato (a inserção, não a aproximação) porque contato é a professora mais limpa: é síncrona, as fases são explícitas, e os kernels contactless são essencialmente otimizações empilhadas sobre esta mesma espinha dorsal. Tudo aqui está definido nas EMV Integrated Circuit Card Specifications for Payment Systems, Books 1–4 (EMVCo). Vou citar o Book e a seção em vez de reproduzir o texto da especificação — as specs são protegidas por direitos autorais e nós não as redistribuímos; construímos ferramentas e conhecimento derivado sobre elas.

O modelo mental: uma conversa sobre APDUs

O cartão é um smartcard. Você fala com ele por APDUs — Application Protocol Data Units, definidos pela ISO/IEC 7816-4 e perfilados pelo EMV Book 1. Um APDU de comando é um cabeçalho (CLA INS P1 P2) mais dados opcionais; a resposta são dados opcionais mais uma status word de dois bytes SW1 SW2, onde 90 00 significa "OK" e 61 xx / 6C xx são os empurrõezinhos usuais de "há mais dados disponíveis / tamanho errado".

Segure duas ideias na cabeça durante todo o fluxo. Primeira: o terminal conduz. O cartão é reativo — ele responde perguntas, nunca se oferece. Segunda: o estado se acumula em tags. Todo valor relevante — o PAN, os flags de risco, o resultado da verificação, o criptograma — é um objeto de dados BER-TLV com uma tag bem conhecida. A transação é, na verdade, o terminal montando um retrato do cartão, tag por tag, até ter o suficiente para decidir.

Aqui está o fluxo em altitude antes de caminharmos por ele.

Agora a caminhada.

Fase 1 — Seleção da aplicação

O terminal precisa escolher qual aplicação de pagamento do cartão vai executar. Há dois caminhos de entrada. O método clássico PSE envia SELECT para o arquivo de diretório do Payment System Environment, 1PAY.SYS.DDF01:

→ 00 A4 04 00 0E 31 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
← 6F ... (FCI Template)  90 00

00 A4 04 00 é SELECT por nome de DF. O cartão devolve um template de File Control Information (tag 6F) que aponta para um diretório que o terminal pode ler para enumerar aplicações. O método moderno e mais robusto é a seleção sem PSE: o terminal simplesmente tenta os AIDs que suporta, do mais preferido ao menos, com SELECT por AID:

→ 00 A4 04 00 07 A0 00 00 00 03 10 10 00   (Visa crédito/débito)
← 6F ...  90 00

A0000000031010 é um Registered Application Provider Identifier mais um sufixo proprietário. O terminal monta uma lista de candidatas de aplicações suportadas por cartão e terminal, aplica prioridade (tag 87, Application Priority Indicator) e, se mais de uma qualificar e a confirmação do portador for exigida, pode apresentar uma escolha. A saída desta fase é um único AID selecionado e seu FCI — incluindo o PDOL (Processing Options Data Object List, tag 9F38) se o cartão quiser o contexto da transação de antemão.

O bug de integração mais comum vive exatamente aqui: terminais que fixam o PSE no código e capotam em cartões que só suportam a lista de AIDs, ou que ignoram o indicador de prioridade e selecionam um esquema co-badged que o lojista não pretendia. Seleção de aplicação é regra de negócio vestida de protocolo.

Fase 2 — Iniciar o processamento: GET PROCESSING OPTIONS

Com uma aplicação selecionada, o terminal emite o GET PROCESSING OPTIONS (GPO). Se o cartão informou um PDOL, o terminal precisa fornecer esses objetos de dados agora — coisas como o valor, o código do país do terminal, a moeda da transação, as capacidades do terminal e um Unpredictable Number (tag 9F37) recém-gerado. O PDOL é o cartão dizendo "antes de eu te contar como eu funciono, me conte sobre esta transação".

→ 80 A8 00 00 <Lc> 83 <len> <dados relacionados ao PDOL> 00
← 77 ... (AIP 82 + AFL 94)  90 00

A resposta carrega dois objetos de dados que guiam o resto da transação:

• AIP — Application Interchange Profile (tag 82, 2 bytes). Um campo de bits com as capacidades do cartão: ele suporta SDA, DDA, CDA? Há suporte a verificação do portador? O gerenciamento de risco do terminal deve ser executado? Há suporte a autenticação do emissor? (EMV Book 3, Anexo C.)
• AFL — Application File Locator (tag 94). Uma lista de entradas de 4 bytes informando ao terminal exatamente quais registros ler: um SFI (Short File Identifier), um primeiro e um último número de registro, e quantos desses registros são cobertos pela autenticação de dados offline.

O AIP é a declaração do cartão sobre o que ele pode fazer; o AFL é o índice do cartão sobre onde vivem seus dados. Nada mais na transação faz sentido até você ter os dois.

Fase 3 — Ler os dados da aplicação: READ RECORD

O terminal então percorre o AFL e emite um READ RECORD por registro:

→ 00 B2 01 0C 00      (registro 1, SFI 1 → P2 = (1<<3)|4 = 0x0C)
← 70 ... (AEF Data Template)  90 00

Os cinco bits superiores do P2 são o SFI; os três bits inferiores são 100 para significar "P1 é um número de registro". Cada resposta é um template 70 cheio dos objetos de dados que definem este cartão e esta conta: o Application PAN (tag 5A), o PAN Sequence Number (5F34), a validade (5F24), os CDOL1/CDOL2 (8C/8D), a CVM List (8E), o Certificate Authority Public Key Index (8F), os certificados de chave pública do emissor e do ICC (90, 9F46), e mais.

Dois desses merecem uma marcação agora porque conduzem fases posteriores. CDOL1 e CDOL2 são Card Risk Management Data Object Lists: são o cartão dizendo ao terminal exatamente quais tags, em qual ordem, ele quer receber no primeiro e no segundo comando GENERATE AC. E a CVM List é o conjunto ordenado de regras de verificação do portador que o cartão aceita. Você as está lendo agora; vai usá-las nas Fases 6 e 8. Para decodificar à mão qualquer uma dessas estruturas envelopadas em 70 você precisa fazer parsing de BER-TLV — que é a Parte 2 desta série, e a razão pela qual ela existe.

Fase 4 — Autenticação de Dados Offline

Aqui a transação deixa de ser escrituração e passa a ser criptografia. A Autenticação de Dados Offline (ODA) permite que o terminal verifique, sem contatar o emissor, que os dados estáticos do cartão são genuínos e, nos modos mais fortes, que o próprio cartão não é um clone. Qual método é executado depende do AIP e das capacidades do terminal:

• SDA (Static Data Authentication). O terminal valida uma assinatura sobre os dados estáticos do cartão usando uma cadeia de chaves RSA: a chave pública da CA do esquema (buscada pelo RID mais o CA PK Index na tag 8F) verifica o Issuer Public Key Certificate, que por sua vez valida o Signed Static Application Data. Prova que os dados são autênticos; não prova que o cartão é real. Clonável.
• DDA (Dynamic Data Authentication). Adiciona um par de chaves RSA no cartão. O terminal envia um desafio via INTERNAL AUTHENTICATE; o cartão assina. Um cartão clonado não consegue produzir a assinatura sem a chave privada, então o DDA derrota ataques simples de replay/clonagem.
• CDA (Combined DDA/Application Cryptogram). DDA fundido com a geração do criptograma no GENERATE AC, de modo que a assinatura dinâmica também cobre o criptograma. O mais forte e, hoje, a expectativa padrão.

A mecânica dessa cadeia RSA — recuperar a chave do emissor, checar o hash e o byte trailer BC, validar a validade do certificado — é um aprofundamento à parte. O que importa para o fluxo: a ODA seta bits no Terminal Verification Results (tag 95) se algo falha, e esses bits alimentam o motor de decisão da Parte 3.

Fases 5–7 — Restrições, verificação do portador, gerenciamento de risco

Três fases mais silenciosas rodam antes do criptograma, cada uma contribuindo para o mesmo veredicto acumulado.

Restrições de processamento checa se as versões da aplicação coincidem, se o Application Usage Control (tag 9F07) permite este tipo de transação (doméstica vs internacional, dinheiro vs bens) e se hoje cai dentro das datas de início de vigência e validade da aplicação. Falhas setam bits no TVR; não necessariamente interrompem a transação.

Verificação do portador percorre a CVM List (tag 8E) em ordem, avaliando a condição de cada regra contra a transação até que uma se aplique: PIN offline (em texto claro ou cifrado), PIN online, assinatura, CVM no dispositivo do consumidor (a biometria no celular) ou "nenhum CVM exigido". O resultado — qual método rodou e se teve sucesso — vai para o CVM Results (tag 9F34). É aqui que a divisão cultural "chip e PIN vs chip e assinatura" realmente vive: mesma especificação, prioridades diferentes na CVM List.

Gerenciamento de Risco do Terminal é a checagem de sanidade offline do próprio terminal, independente do cartão: o valor está acima do floor limit? Esta transação deveria ser empurrada para online por seleção aleatória? A checagem de velocidade (comparando o Application Transaction Counter do cartão com o Last Online ATC) sugere que muitas transações offline se acumularam? Cada preocupação, de novo, seta um bit no TVR.

Ao fim da Fase 7 o terminal detém um TVR (tag 95) totalmente populado e um TSI (Transaction Status Information, tag 9B) registrando quais funções foram executadas. Agora ele está pronto para pedir uma decisão ao cartão — mas a decisão é uma negociação, não uma ordem.

Fase 8 — O criptograma: GENERATE AC

O terminal executa a Terminal Action Analysis: compara o TVR com os Issuer Action Codes (Denial/Online/Default) e os Terminal Action Codes para formar uma proposta — aprovar offline, ir online ou recusar — e codifica essa proposta como o tipo de criptograma que solicita no primeiro GENERATE AC:

→ 80 AE 80 00 <Lc> <dados do CDOL1> 00     (P1 = 0x80 → solicita ARQC)
← 77 ... 9F27 (CID) 9F36 (ATC) 9F26 (AC) 9F10 (IAD)  90 00

O P1 solicita TC (0x40, aprovar offline), ARQC (0x80, ir online) ou AAC (0x00, recusar); somar 0x10 solicita CDA. O campo de dados é exatamente as tags do CDOL1 que o cartão pediu na Fase 3. O cartão então executa a Card Action Analysis — sua própria lógica de risco — e responde com um Cryptogram Information Data (tag 9F27) que declara qual criptograma ele efetivamente gerou. Crucialmente, o cartão pode rebaixar a solicitação do terminal. Peça um TC e o cartão ainda pode insistir num ARQC (forçar online) ou num AAC (recusar) se seu gerenciamento interno de risco discordar. O cartão não é um carimbo.

O criptograma em si — o Application Cryptogram (tag 9F26) — é um MAC calculado sob uma chave do cartão sobre os dados da transação, acompanhado do Application Transaction Counter (tag 9F36) e do Issuer Application Data (tag 9F10). Como esse MAC é derivado, e por que ele é a pedra angular antifraude de todo o sistema, é a Parte 4. Por ora: o cartão acabou de devolver uma afirmação criptográfica sobre esta transação que só o emissor pode verificar plenamente.

Fases 9–12 — Online, scripts, conclusão

Se o criptograma é um ARQC, o terminal não pode aprovar por conta própria; precisa ir online. O adquirente empacota os dados EMV — o criptograma e suas tags de apoio — no campo 55 do ISO 8583 e roteia a autorização ao emissor. (Esse envelope ISO 8583 e a ponte do campo 55 são assunto próprio, mais adiante nesta série.) O emissor valida o ARQC, toma a decisão de aceitar/recusar e retorna um ARPC (Authorisation Response Cryptogram) mais um Authorisation Response Code, opcionalmente com scripts do emissor (templates 71/72) carregando comandos como troca de PIN, bloqueio/desbloqueio de aplicação ou atualização de parâmetros — cada um protegido por seu próprio MAC.

O terminal entrega quaisquer scripts ao cartão e então emite o segundo GENERATE AC para concluir: o cartão pondera a resposta do emissor (incluindo se a autenticação do emissor via ARPC teve sucesso) e devolve um TC final (aprovado) ou AAC (recusado). O bipe que você ouve é o terminal lendo esse último tipo de criptograma.

Cicatrizes de batalha

Três modos de falha que já vi consumirem dias de engenharia, para que você os reconheça mais rápido do que eu.

O AFL mente sobre a cobertura, e sua ODA silenciosamente não faz nada. Cada entrada do AFL diz quantos registros são cobertos pela autenticação de dados offline. Conte errado, faça hash do conjunto errado de registros, e a checagem de assinatura falha de um jeito que parece chave inválida. Verifique a aritmética dos registros cobertos antes de suspeitar da criptografia.

A ordem do CDOL não é a ordem das tags. O CDOL1 dita a ordem de concatenação dos valores que você alimenta ao GENERATE AC, e ela não é ordenada, não é a ordem em que as tags apareceram nos registros e não é negociável. Monte o campo de dados do GENERATE AC percorrendo o CDOL literalmente, da esquerda para a direita, substituindo o valor atual de cada tag. Um único campo transposto produz um criptograma perfeitamente formatado que o emissor rejeita sem erro útil.

Um 90 00 não é "aprovado". A status word 90 00 significa "o cartão processou seu APDU". Ela não diz nada sobre o resultado da transação. O resultado é o tipo de criptograma no CID (tag 9F27). Já vi dashboards tratarem 90 00 no GENERATE AC como métrica de sucesso; estavam contando recusas como aprovações.

Para onde esta série vai

Você agora tem o mapa. Cada parte restante de Payments Under the Hood dá zoom em uma região dele. A Parte 2 — "Lendo BER-TLV à Mão" disseca a codificação de que todo template 6F, 70 e 77 desta caminhada é feito, porque você não depura um fluxo que não consegue parsear. A Parte 3 — "O TVR, o TSI e Como um Terminal Decide te Recusar" abre o motor de decisão da Fase 8 bit a bit. A Parte 4 — "ARQC a Partir do Zero" constrói o criptograma da Fase 8 com chaves (de teste) reais. E o final regional leva o mesmo rigor ao PIX e ao QR EMVCo que o Brasil inteiro usa.

Se quiser mexer nos artefatos enquanto lê, o Dicionário de Tags EMV do gsstk resolve cada tag citada aqui — 82, 94, 8C, 9F27, 9F26 — com seu formato, template e o Book de origem.

Leitura Relacionada no gsstk

• Implementando EMV do Zero: Guia Completo para Terminais de Pagamento — o aprofundamento flagship que esta visão geral ancora.
• Lendo BER-TLV à Mão — e Por Que Você Não Deveria — Parte 2: a codificação por trás de todo template deste fluxo.
• O TVR, o TSI e Como um Terminal Decide te Recusar — Parte 3: o motor de decisão do GENERATE AC, de perto.
• ARQC a Partir do Zero: Criptogramas de Aplicação Sem Caixa-Preta — Parte 4: construindo o criptograma que este fluxo devolve.
• PIX, BR Code e o EMVCo MPM — Parte 5: a mesma disciplina em forma de QR code.

Ferramentas: o Dicionário de Tags EMV resolve cada tag citada aqui; a Tabela de Parâmetros de AID cobre a etapa de seleção de aplicação.

Arquivado em: EMV · Payments · POS · Acquiring · Contactless

Este artigo foi arquitetado por humanos e sintetizado com assistência de IA sob a persona Nexus (AI).