Técnico

ISO 8583

ISO 8583 — padrão de mensagens de cartões (aquisição, autorização)

Padrão ISO publicado em 1987 que define o formato das mensagens trocadas entre os atores de cartões (terminal POS, PSP adquirente, scheme, emissor). Continua sendo o padrão dominante da autorização, da aquisição e da liquidação de cartões. Visa, Mastercard, CB e Amex usam todos ele.

Definição

O ISO 8583 é o padrão ISO (1987, revisado em 1993 e 2003) que define o formato das mensagens trocadas entre os atores do pagamento por cartão: terminal POS, PSP adquirente, switch da rede (Visa, Mastercard, CB) e banco emissor.

É o padrão dominante da autorização, da aquisição e da liquidação de cartões. Formato binário baseado em um MTI (Message Type Indicator, 4 dígitos: 0100 request, 0110 response…), um bitmap que indica os campos presentes e até 128 data elements. Concebido em 1987, continua incontornável — Visa (BASE I/II), Mastercard (MIP/MDS), CB, Amex, JCB e UnionPay usam todos ele, com variantes proprietárias.

Estrutura de uma mensagem

MTI            : 0100 (Authorization Request)
Bitmap         : 7234050108E18000... (indique champs présents)
DE2  PAN       : 4242424242424242
DE3  Proc Code : 000000 (purchase)
DE4  Amount    : 000000050000 (50.00 €)
DE7  Trans DT  : 0419103045 (avril 19, 10:30:45)
DE11 STAN      : 123456 (System Trace Audit Number)
DE22 POS Entry : 051 (chip + PIN)
DE32 Acquirer  : 12345678 (BIN PSP)
DE41 TID       : 00012345 (terminal)
DE42 MID       : 123456789012345 (merchant)
DE49 Currency  : 978 (EUR)
DE52 PIN Block : ... (encrypted)
DE55 EMV Data  : 9F26... (chip data)

Uma mensagem tem cerca de 300 a 500 bytes, transmitida em menos de 200 ms.

O ciclo de vida de uma transação

Três etapas: a autorização (online em menos de um segundo), o clearing (batch diário) e o settlement (liquidação líquida entre emissor e adquirente via rede, em D+1 ou D+2).

Variantes por rede

Cada rede deriva o ISO 8583 em seu próprio formato: Visa (BASE I para a auth, BASE II para o clearing), Mastercard (MIP + MDS), CB (próximo da Visa), Amex (proprietário), além de JCB, Discover e UnionPay. Um PSP adquirente multirredes (Stripe, Adyen, Worldline) deve, portanto, lidar com vários dialetos.

ISO 8583 vs ISO 20022

AspectoISO 8583 (1987)ISO 20022 (2004)
FormatoBitmap binárioXML / JSON
LegibilidadeBaixaBoa
RiquezaLimitadaMuito rica
Latência< 200 msMais pesado (parsing XML)
DomínioCartõesTudo (pagamentos, títulos, FX)
AdoçãoUniversal (cartões)Universal (SEPA / SWIFT MX)

O ISO 8583 resiste por quatro motivos: latência ultrabaixa (auth crítica em < 200 ms), compacidade (~300 bytes vs vários KB em XML), 40 anos de legado nos sistemas core e um custo de migração estimado em bilhões de dólares. Visa e Mastercard, no entanto, trabalham em uma transição gradual (Visa Direct e Mastercard Send já estão em ISO 20022), com um clearing de cartão em ISO 20022 previsto após 2030.

Atores

  • Redes: Visa, Mastercard, Amex, JCB, Discover, UnionPay, CB (FR).
  • Switches / processadores: Worldline (FR), Nexi (IT), Fiserv, TSYS / Global Payments, FIS.
  • Ferramentas: jPOS (a biblioteca Java open-source de referência), OpenISO8583.Net, iso8583py e HSMs Thales ou Utimaco para os criptogramas.

O que o ISO 8583 não é

  • Não é um padrão universal de pagamento: é específico para cartões; transferências e débitos diretos pertencem ao ISO 20022.
  • Não é um protocolo de transporte: ele descreve o formato das mensagens, sendo o transporte TCP/IP (ou X.25 historicamente).
  • Não é exigido pelos novos trilhos: FedNow, TIPS e SCT Inst estão em ISO 20022.
  • Não é criptografado por padrão: são necessárias camadas adicionais (TLS, P2PE, HSM).
  • Não é estritamente padronizado: cada rede tem sua variante ("sabor" Visa, Mastercard, CB).

No ecossistema PSD2 / Open Finance

O ISO 8583 é invisível para os TPPs da PSD2 (que trabalham em API REST/JSON), mas onipresente no lado do cartão: os adquirentes (Stripe, Adyen) traduzem suas APIs REST para o ISO 8583, os emissores BaaS (Treezor, Swan, Solaris) traduzem o ISO 8583 recebido para suas APIs de negócio, e parte dos desafios 3DS por ele transita. Continua, portanto, fundamental para entender o pagamento por cartão, mesmo na era do Open Banking.

Exemplos concretos

  • Stripe: recebe uma solicitação de pagamento, traduz para ISO 8583 em direção à Visa BASE I, recebe o 0110 de aprovação e confirma ao lojista.
  • Treezor: recebe um 0100 do switch de cartão, verifica saldo e scoring e devolve um 0110 approve/decline.
  • Worldline: opera vários switches FR e UE que processam mais de 50 mi de transações por dia.
  • jPOS: biblioteca open-source usada por centenas de processadores e fintechs emissoras.
  • Migração ISO 20022: Visa Direct e Mastercard Send (push payments) já migrados, mas o 0100/0110 histórico permanecerá em 8583 até depois de 2030.
  • Dois mundos: um desenvolvedor de fintech de crédito vê JSON/REST; um desenvolvedor de PSP adquirente vê bitmap 8583 em hexadecimal.

Fontes

Aprofundar

No blog

Leituras mais completas para ir além da definição.

7 de abril de 2026
técnico

Arquitetura técnica de uma API DSP2: o que é preciso saber antes de escrever a primeira linha de código — Ler o artigo

Panorama técnico da DSP2 para CTOs, desenvolvedores e PMs técnicos: padrões de API, segurança (mTLS, certificados eIDAS), OAuth2, fluxos SCA, gestão do consentimento, armadilhas de implementação.

6 de abril de 2026
regulação

Entender a PSD2: o que ela muda para seus clientes e seu negócio — Ler o artigo

Tudo o que um dirigente, um product manager ou uma equipe de negócios precisa entender sobre a PSD2 (DSP2). Atores, consentimento, oportunidades, sem jargão técnico.