The ABECS Pinpad Protocol: Brazil's POS Command Language

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

ABECS pinpad in 90 seconds:

In Brazil, the payment application (the "automation") talks to the secure pinpad through the ABECS protocol — a command/response language standardized so any automation works with any compliant pinpad.

It is a state machine: open the device, get the card, go on-chip, verify the cardholder, finish, close. Each step is a command with a defined input and a defined output.

Long operations use a Input/Output split: the automation sends a Start command with parameters (Input), then polls for the result (Output) — so the UI stays responsive while the pinpad does secure work.

The EMV flow you already know — selection, GPO, cryptogram — runs inside the pinpad; ABECS is how the automation drives it and reads the results out.

It is the reason Brazil's acquiring market interoperates the way it does.

Every time a card is paid in Brazil — and Brazil is one of the largest card markets on Earth — a piece of software called the automation (the merchant's POS application) is talking to a secure hardware device, the pinpad, and the language they speak is the ABECS protocol. ABECS (Associação Brasileira das Empresas de Cartões de Crédito e Serviços) standardized this command set so that any compliant automation works with any compliant pinpad from any manufacturer — the interoperability that lets a merchant swap terminals without rewriting their software. If you build payment acceptance in Brazil, this protocol is the surface you program against, and understanding its shape makes the whole EMV flow from earlier in this series suddenly concrete: ABECS is how you drive it on real hardware. This article describes the protocol's structure at a derived, interoperable level; per our standing rule we never reproduce the ABECS specification text — we cite it (the ABECS Pinpad — Protocolo de Comunicação e Funcionamento, and its versioned test cases) and build tools and knowledge on top of it.

Why Brazil has its own standard

The short answer is interoperability under a specific market structure. Brazil's payments ecosystem has many acquirers, many pinpad manufacturers, and a strong regulatory and industry-body presence. Rather than let every acquirer define a proprietary terminal interface, ABECS published a common pinpad protocol so the automation-to-pinpad boundary is standard across the whole market. The result is a genuinely interoperable layer: the secure device (which holds keys and does PIN capture and EMV processing) exposes the same command vocabulary regardless of who made it, and the automation above it can be written once. It is a regional standard that solves a regional coordination problem — and it is precisely the kind of vertical where a generic "dev tools" site has nothing and a payments-focused one can be authoritative.

The command model: a secure state machine

ABECS is a command/response protocol over the automation-to-pinpad link. Conceptually the automation walks the device through a transaction as a state machine, with commands for each phase. The families you meet:

Open / Close — OPN initializes a session with the pinpad; CLO ends it and can display a closing message. Everything happens between them.
Get Info — GIN queries the device: model, firmware, capabilities, loaded keys. You call it to know what you are talking to.
Get Card — the command family that detects and reads the card (magnetic, chip, or contactless), returning what was captured.
Go On Chip — drives the EMV chip processing on the card.
Finish Chip — completes the chip transaction (second GENERATE AC, script processing).
Get PIN — captures the cardholder's PIN inside the secure processor and returns an encrypted PIN block, never the clear PIN.
Key management, cancel, remove card, display — the supporting commands (GKY, CEX/cancel, RMC remove card, message display) that round out the flow.

The design intent is that the sensitive work — key storage, PIN capture, EMV cryptography — stays inside the pinpad, and the automation orchestrates without ever touching a key or a clear PIN. That boundary is the security model: the automation is untrusted with secrets by construction.

The Input / Output split

The most distinctive structural feature — and the one the gsstk tools already model — is how ABECS handles operations that take time and involve the cardholder. Reading a card, going on-chip, and capturing a PIN are not instantaneous; the cardholder has to insert or tap, enter digits, and the device has to do secure processing. Blocking the automation for the whole duration would freeze the merchant's UI.

So these operations are split into a Start and a result. The automation sends a Start command carrying the parameters for the operation — this is the Input (parameter structure, input): for GetCard, which card types to accept, the amount, application selection parameters; for GetPIN, the PIN entry parameters and key references. The pinpad begins the operation and the automation then polls for completion, receiving the Output (parameter structure, output) when the cardholder and device have finished — the captured card data, the chip results, or the encrypted PIN block. This Start-then-poll pattern keeps the automation responsive and event-driven while the secure device works at cardholder pace.

This is exactly the structure the gsstk ABECS analyzers decode today — Start Get Card and its output, Start Go On Chip / output, Finish Chip / output, and Start Get PIN / output. Paste a Input or Output blob and the tool breaks it into its fields.

Where the EMV flow lives

Here is the payoff for anyone who read the earlier parts of this series. The whole EMV transaction flow — application selection, GET PROCESSING OPTIONS, READ RECORD, offline data authentication, the CVM decision, terminal risk management, GENERATE AC and the cryptogram — runs inside the pinpad, driven by the Go On Chip and Finish Chip commands. ABECS does not replace EMV; it is the harness that runs it on Brazilian hardware and hands the results (the TVR, the cryptogram, the DE 55 tags) back to the automation to send online. So the Output of Go On Chip is where the EMV tags you learned to read actually surface in a Brazilian POS. Two standards, one transaction: ABECS on the automation-to-device boundary, EMV on the terminal-to-card boundary.

Battle scars

The automation must never see a clear PIN or a key — and if it can, that is the bug. The entire ABECS security model rests on secrets staying inside the pinpad. An integration that finds a way to extract clear PIN data or key material has not found a feature; it has found a compliance and security failure. The Output of Get PIN is an encrypted block for a reason.

Poll, do not block. The Start/poll pattern exists so the automation stays responsive. Implementations that busy-wait or block the UI thread on a GetCard turn a responsive terminal into a frozen one at exactly the moment the cardholder is interacting. Respect the asynchronous design.

Test against the reference cases. ABECS publishes versioned test cases; a pinpad integration that passes ad-hoc manual testing but not the reference cases will fail certification and misbehave in the field. The interoperability guarantee is only real if both sides conform to the same version — check which protocol version the device reports via GIN.

Where this fits

ABECS is the Brazilian harness around everything else in Payments Under the Hood: the EMV flow runs inside the pinpad it drives, the PIN block it returns is ISO 9564, and the results go online as ISO 8583 with DE 55. The gsstk ABECS analyzers already decode its Input/Output structures — the deepest regional coverage no generic tool offers.

What Actually Happens When You Dip a Chip: The EMV Transaction Flow End-to-End — the flow the pinpad runs internally.
PIN Blocks Explained: ISO 9564 Formats 0 to 4 — what Get PIN returns.
PIX, BR Code, and the EMVCo MPM — the other pillar of Brazilian payments.

Tools: decode the command structures directly — Start Get Card · Get Card output · Go On Chip · Get PIN · Finish Chip.

Filed under: ABECS · Payments · EMV · POS · Acquiring

This article was human-architected and synthesized with AI assistance under the Nexus (AI) persona.