
O Protocolo ABECS de Pinpad: A Linguagem de Comandos do POS Brasileiro
Todo pagamento com cartão no Brasil passa por um pinpad falando o protocolo ABECS — uma máquina de estados de comando/resposta com seus próprios comandos de abertura, leitura de cartão, processamento de chip, captura de PIN e fechamento. Um guia estrutural de como a automação conversa com o dispositivo seguro, por que existe a divisão Input/Output, e onde o fluxo EMV que você conhece vive dentro dele.
✨TL;DR / Sumário Executivo
Todo pagamento com cartão no Brasil passa por um pinpad falando o protocolo ABECS — uma máquina de estados de comando/resposta com seus próprios comandos de abertura, leitura de cartão, processamento de chip, captura de PIN e fechamento. Um guia estrutural de como a automação conversa com o dispositivo seguro, por que existe a divisão Input/Output, e onde o fluxo EMV que você conhece vive dentro dele.
💡 TL;DR (Too Long; Didn't Read)
Pinpad ABECS em 90 segundos:
- No Brasil, a aplicação de pagamento (a "automação") conversa com o pinpad seguro através do protocolo ABECS — uma linguagem de comando/resposta padronizada para que qualquer automação funcione com qualquer pinpad conforme.
- É uma máquina de estados: abrir o dispositivo, obter o cartão, processar o chip, verificar o portador, finalizar, fechar. Cada etapa é um comando com entrada e saída definidas.
- Operações longas usam uma divisão Input/Output: a automação envia um comando Start com parâmetros (Input) e então consulta pelo resultado (Output) — mantendo a interface responsiva enquanto o pinpad faz o trabalho seguro.
- O fluxo EMV que você já conhece — seleção, GPO, criptograma — roda dentro do pinpad; o ABECS é como a automação o conduz e lê os resultados.
- É a razão pela qual o mercado adquirente brasileiro interopera como interopera.
Toda vez que um cartão é pago no Brasil — e o Brasil é um dos maiores mercados de cartão do planeta — um software chamado automação (a aplicação de POS do lojista) está conversando com um dispositivo de hardware seguro, o pinpad, e a língua que eles falam é o protocolo ABECS. A ABECS (Associação Brasileira das Empresas de Cartões de Crédito e Serviços) padronizou esse conjunto de comandos para que qualquer automação conforme funcione com qualquer pinpad conforme de qualquer fabricante — a interoperabilidade que permite a um lojista trocar de terminal sem reescrever seu software. Se você constrói aceitação de pagamentos no Brasil, este protocolo é a superfície contra a qual você programa, e entender sua forma torna todo o fluxo EMV das partes anteriores desta série subitamente concreto: o ABECS é como você o conduz em hardware real. Este artigo descreve a estrutura do protocolo num nível derivado e interoperável; pela nossa regra permanente nunca reproduzimos o texto da especificação ABECS — nós a citamos (o ABECS Pinpad — Protocolo de Comunicação e Funcionamento e seus casos de teste versionados) e construímos ferramentas e conhecimento sobre ela.
Por que o Brasil tem seu próprio padrão
A resposta curta é interoperabilidade sob uma estrutura de mercado específica. O ecossistema de pagamentos brasileiro tem muitos adquirentes, muitos fabricantes de pinpad e forte presença regulatória e de entidades setoriais. Em vez de deixar cada adquirente definir uma interface proprietária de terminal, a ABECS publicou um protocolo comum de pinpad para que a fronteira automação-pinpad seja padrão em todo o mercado. O resultado é uma camada genuinamente interoperável: o dispositivo seguro (que detém chaves, faz captura de PIN e processamento EMV) expõe o mesmo vocabulário de comandos independentemente de quem o fabricou, e a automação acima dele pode ser escrita uma vez. É um padrão regional que resolve um problema regional de coordenação — e é precisamente o tipo de vertical em que um site genérico de "dev tools" não tem nada e um focado em pagamentos pode ser autoridade.
O modelo de comandos: uma máquina de estados segura
O ABECS é um protocolo de comando/resposta sobre o enlace automação-pinpad. Conceitualmente a automação conduz o dispositivo por uma transação como uma máquina de estados, com comandos para cada fase. As famílias que você encontra:
- Open / Close — o
OPNinicializa uma sessão com o pinpad; oCLOa encerra e pode exibir uma mensagem de fechamento. Tudo acontece entre eles. - Get Info — o
GINconsulta o dispositivo: modelo, firmware, capacidades, chaves carregadas. Você o chama para saber com o que está conversando. - Get Card — a família de comandos que detecta e lê o cartão (magnético, chip ou contactless), devolvendo o que foi capturado.
- Go On Chip — conduz o processamento EMV do chip no cartão.
- Finish Chip — completa a transação com chip (segundo GENERATE AC, processamento de scripts).
- Get PIN — captura o PIN do portador dentro do processador seguro e devolve um PIN block cifrado, nunca o PIN em claro.
- Gerenciamento de chaves, cancelamento, remoção de cartão, exibição — os comandos de apoio (
GKY, cancelamento, remoção de cartão, exibição de mensagem) que completam o fluxo.
A intenção do desenho é que o trabalho sensível — armazenamento de chaves, captura de PIN, criptografia EMV — fique dentro do pinpad, e a automação orquestre sem nunca tocar uma chave ou um PIN em claro. Essa fronteira é o modelo de segurança: a automação não é confiável com segredos, por construção.
A divisão Input / Output
A característica estrutural mais distintiva — e a que as ferramentas do gsstk já modelam — é como o ABECS trata operações que levam tempo e envolvem o portador. Ler um cartão, processar o chip e capturar um PIN não são instantâneos; o portador precisa inserir ou aproximar, digitar dígitos, e o dispositivo precisa fazer processamento seguro. Bloquear a automação por toda a duração congelaria a interface do lojista.
Então essas operações são divididas em um Start e um resultado. A automação envia um comando Start portando os parâmetros da operação — este é o Input (estrutura de parâmetros, entrada): para o GetCard, quais tipos de cartão aceitar, o valor, parâmetros de seleção de aplicação; para o GetPIN, os parâmetros de digitação e as referências de chave. O pinpad inicia a operação e a automação então consulta pela conclusão, recebendo o Output (estrutura de parâmetros, saída) quando portador e dispositivo terminaram — os dados capturados do cartão, os resultados do chip ou o PIN block cifrado. Esse padrão Start-e-consulta mantém a automação responsiva e orientada a eventos enquanto o dispositivo seguro trabalha no ritmo do portador.
Esta é exatamente a estrutura que os analisadores ABECS do gsstk decodificam hoje — Start Get Card e sua saída, Start Go On Chip / saída, Finish Chip / saída, e Start Get PIN / saída. Cole um blob de Input ou Output e a ferramenta o quebra em seus campos.
Onde o fluxo EMV vive
Aqui está a recompensa para quem leu as partes anteriores desta série. Todo o fluxo da transação EMV — seleção de aplicação, GET PROCESSING OPTIONS, READ RECORD, autenticação de dados offline, a decisão de CVM, gerenciamento de risco do terminal, GENERATE AC e o criptograma — roda dentro do pinpad, conduzido pelos comandos Go On Chip e Finish Chip. O ABECS não substitui o EMV; ele é o arreio que o executa em hardware brasileiro e entrega os resultados (o TVR, o criptograma, as tags do DE 55) de volta à automação para enviar online. Então o Output do Go On Chip é onde as tags EMV que você aprendeu a ler efetivamente afloram num POS brasileiro. Dois padrões, uma transação: ABECS na fronteira automação-dispositivo, EMV na fronteira terminal-cartão.
Cicatrizes de batalha
A automação nunca deve ver um PIN em claro ou uma chave — e se puder, esse é o bug. O modelo de segurança ABECS inteiro repousa em segredos permanecerem dentro do pinpad. Uma integração que encontra um jeito de extrair dados de PIN em claro ou material de chave não encontrou uma funcionalidade; encontrou uma falha de segurança e de conformidade. O Output do Get PIN é um bloco cifrado por uma razão.
Consulte, não bloqueie. O padrão Start/consulta existe para manter a automação responsiva. Implementações que fazem espera ativa ou bloqueiam a thread de interface num GetCard transformam um terminal responsivo num congelado exatamente no momento em que o portador está interagindo. Respeite o desenho assíncrono.
Teste contra os casos de referência. A ABECS publica casos de teste versionados; uma integração de pinpad que passa em testes manuais ad-hoc mas não nos casos de referência vai falhar na certificação e se comportar mal em campo. A garantia de interoperabilidade só é real se os dois lados conformarem à mesma versão — cheque qual versão de protocolo o dispositivo reporta via GIN.
Onde isto se encaixa
O ABECS é o arreio brasileiro em torno de tudo o mais em Payments Under the Hood: o fluxo EMV roda dentro do pinpad que ele conduz, o PIN block que ele devolve é ISO 9564, e os resultados vão online como ISO 8583 com DE 55. Os analisadores ABECS do gsstk já decodificam suas estruturas Input/Output — a cobertura regional mais profunda que nenhuma ferramenta genérica oferece.
Leitura Relacionada no gsstk
- O Que Realmente Acontece Quando Você Insere um Chip — o fluxo que o pinpad executa internamente.
- PIN Blocks Explicados: Formatos 0 a 4 da ISO 9564 — o que o Get PIN devolve.
- PIX, BR Code e o EMVCo MPM — o outro pilar dos pagamentos brasileiros.
Ferramentas: decodifique as estruturas de comando diretamente — Start Get Card · Saída do Get Card · Go On Chip · Get PIN · Finish Chip.
Arquivado em: ABECS · Payments · EMV · POS · Acquiring
Este artigo foi arquitetado por humanos e sintetizado com assistência de IA sob a persona Nexus (AI).