Campo 55: A Ponte EMV Dentro do ISO 8583

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

Campo 55 em 90 segundos:

O DE 55 é o elemento de dados numa mensagem ISO 8583 que carrega os dados EMV do chip — como BER-TLV, a mesma codificação que o cartão usa.

É a ponte entre duas eras: o chip fala tags EMV; a rede fala ISO 8583; o DE 55 envelopa o primeiro dentro do segundo.

A carga crítica é o criptograma (9F26) e tudo de que o emissor precisa para validá-lo: TVR (95), ATC (9F36), unpredictable number (9F37), CID (9F27), IAD (9F10), valor, moeda, data e mais.

Cada bandeira exige seu próprio conjunto de tags no DE 55 (VIS da Visa, M/Chip da Mastercard…). Envie as tags erradas e o ARQC falha na validação mesmo que o cartão estivesse perfeito.

Quando "a transação com chip recusou online sem razão clara", o DE 55 é o primeiro lugar para olhar.

Duas tecnologias que nunca deveriam ter precisado conversar movem juntas os pagamentos com cartão do mundo: o EMV, uma especificação de smartcard dos anos 1990 que fala em objetos de dados BER-TLV, e o ISO 8583, um padrão de mensageria dos anos 1980 que fala em elementos de dados numerados. Quando uma transação com chip vai online, algo precisa levar a prova criptográfica do chip pela rede até o emissor, e esse algo é o Elemento de Dados 55 — "Integrated Circuit Card (ICC) System Related Data". O DE 55 é a ponte: ele empacota tags EMV, inalteradas, dentro da mensagem ISO 8583. Entendê-lo é entender onde o chip encontra o trilho e — na prática — onde termina uma fatia grande das investigações de "recusou online e eu não sei por quê". Isto se apoia no EMVCo Book 3 e no ISO 8583, com os requisitos concretos de tags definidos por cada bandeira; trate como a planta da ponte e a especificação da sua rede como a lista de peças.

BER-TLV, dentro de um campo numerado

Lembre do artigo do ISO 8583 que o DE 55 é um campo LLLVAR — um prefixo de comprimento de 3 dígitos seguido de até 999 bytes de valor. O que vive nesse valor não é o formato próprio do ISO 8583; é BER-TLV, exatamente a codificação tag-comprimento-valor que o próprio chip usa. Então parsear o DE 55 é uma operação de duas camadas: primeiro a camada ISO 8583 extrai o campo por seu prefixo de comprimento, depois a camada EMV percorre as tags dentro. É por isso que um único engenheiro precisa das duas habilidades — a gramática da mensagem e a gramática das tags — para depurar uma recusa online de chip.

O que realmente vai no Campo 55

O trabalho do emissor ao receber a mensagem é re-derivar e validar o ARQC — recalcular o criptograma a partir dos dados da transação e das chaves do cartão, e checar se casa. Para isso ele precisa de toda entrada que entrou no criptograma. Então o DE 55 carrega, no mínimo, o criptograma e seus ingredientes:

9F26 — Application Cryptogram (o próprio ARQC). O valor sendo validado.
9F27 — Cryptogram Information Data (CID). Qual tipo de criptograma o cartão devolveu.
9F10 — Issuer Application Data (IAD). Dados internos do cartão, incluindo o CVN que diz ao emissor qual receita usar na validação — a tag mais importante para acertar a validação.
9F36 — Application Transaction Counter (ATC). O contador por cartão; também conduz a derivação da chave de sessão.
9F37 — Unpredictable Number. A entrada aleatória do terminal no criptograma.
95 — Terminal Verification Results. O TVR, que é criptograficamente vinculado ao ARQC e também diz ao emissor o que o terminal observou.
9A / 9C / 9F02 / 5F2A — data, tipo, valor e moeda da transação: o contexto que entra no MAC.
82 — AIP, 9F1A — país do terminal, 9F03 — outro valor, 9F33 — capacidades do terminal, 9F34 — resultados de CVM, 9F35 — tipo de terminal, 9F1E — serial do IFD, 9F41 — contador de sequência da transação: o contexto de apoio que diferentes bandeiras exigem.

A lista exata não é universal — o que nos leva à armadilha.

Cada bandeira exige um conjunto de tags diferente

Aqui está o detalhe que transforma uma integração funcional numa quebrada: o VIS da Visa, o M/Chip da Mastercard e cada outra bandeira definem suas próprias listas de tags obrigatórias e opcionais para o DE 55, em sua própria ordem. O criptograma é calculado sobre um conjunto específico de objetos de dados definido pela bandeira (o CDOL que o cartão pediu), e o emissor valida contra uma expectativa específica da bandeira. Envie o conjunto de tags da Mastercard a um emissor Visa, omita uma tag que a bandeira exige, ou inclua as tags mas numa forma que a bandeira não espera, e a re-derivação do emissor produz um criptograma diferente do que o cartão produziu — e a transação recusa com falha de validação de criptograma, mesmo que cartão e terminal tenham feito tudo certo.

É por isso que montar o DE 55 não é "jogue todas as tags EMV no campo". É "monte exatamente as tags que esta bandeira exige, a partir dos valores que cartão e terminal produziram, na codificação esperada". O IAD 9F10, carregando o CVN, é o que diz ao emissor contra qual manual de regras validar — erre o conjunto de tags para aquele CVN e nada a jusante funciona.

Depurando uma recusa online de chip

Quando uma transação com chip recusa online com um código de resposta que cheira a problema de criptograma, o DE 55 é a cena do crime, e a investigação é ordenada:

Primeiro, confirme que o campo parseou — extraia o DE 55 pelo seu comprimento LLLVAR e decodifique o TLV de forma limpa. Um erro de prefixo de comprimento ou um campo truncado vai parecer falha de criptografia, mas é falha de parsing. Segundo, cheque o CVN na 9F10 e confirme que o conjunto de tags do DE 55 casa com o que aquele CVN e aquela bandeira exigem — a causa real mais comum. Terceiro, verifique se o ATC (9F36) é sensato e está avançando — um contador travado ou retrocedendo sinaliza cartão clonado ou mensagem repetida, e emissores recusam por isso. Quarto, confirme que o TVR (95) no campo casa com a decisão do terminal — se discordam, algo re-serializou o campo incorretamente. O ponto desta série é que cada uma dessas é uma condição específica e legível, não uma "recusa" opaca.

Cicatrizes de batalha

Uma tag ausente ou extra falha a validação silenciosamente. Como o criptograma é um MAC sobre um conjunto específico de dados, um DE 55 errado por uma tag produz um campo perfeitamente formatado que não valida em lugar nenhum. Raramente há um erro útil — apenas uma recusa. Monte o DE 55 a partir da lista obrigatória da bandeira, não a partir do "o que o cartão devolveu".

O IAD (9F10) é a Pedra de Roseta. Ele carrega o CVN, e o CVN seleciona a receita inteira de validação. Se você está adivinhando por que um ARQC não valida, decodifique a 9F10 primeiro: ela diz ao emissor — e a você — qual método deveria ter sido usado.

O DE 55 é BER-TLV, então todas as armadilhas de TLV se aplicam. Tags de dois bytes, comprimentos de forma longa, templates aninhados — os perigos de parsing da Parte 2 vivem dentro do DE 55 também. Um bug de DE 55 é muito frequentemente um bug de TLV vestido de ISO 8583.

Onde isto se encaixa

O DE 55 é a costura desta série inteira: ele carrega o criptograma do artigo do ARQC, o TVR do artigo da decisão e os resultados de CVM, todos envelopados em BER-TLV dentro de uma mensagem ISO 8583. Parseie a mensagem com o Parser ISO 8583, depois decodifique as tags do DE 55 no Dicionário de Tags EMV.

Leitura Relacionada no gsstk

ISO 8583 Ainda Está em Todo Lugar — o envelope em que o DE 55 vive.
ARQC a Partir do Zero: Criptogramas de Aplicação Sem Caixa-Preta — o criptograma que o DE 55 carrega.
Lendo BER-TLV à Mão — e Por Que Você Não Deveria — a codificação dentro do campo.

Ferramentas: parseie a mensagem com o Parser ISO 8583; decodifique as tags do campo — 9F26, 9F10, 9F36, 95 — no Dicionário de Tags EMV.

Arquivado em: EMV · ISO 8583 · Payments · Acquiring · Card Issuing

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