ISO 8583: a linguagem dos cartões de crédito

 (increase.com)
3 pontos por GN⁺ 2024-12-19 | 1 comentários | Compartilhar no WhatsApp
  • A ISO 8583 é o padrão de troca de mensagens em tempo real entre redes de cartões de crédito
  • Esse padrão define as mensagens que ocorrem quando você aproxima o cartão em um dispositivo de ponto de venda ou clica em "comprar" online
  • No início, os POS ou ATMs geravam as mensagens diretamente, mas hoje o mais comum é convertê-las primeiro para um formato de nível mais alto, como JSON, e depois transformá-las em ISO 8583
  • A estrutura da mensagem é simples, mas a implementação detalhada é complexa, com flexibilidade para garantir compatibilidade entre redes

Formato básico da mensagem

Indicador de tipo de mensagem (Message Type Indicator)

  • Um código de 4 dígitos indica o tipo de mensagem (por exemplo, 0100 é uma solicitação de autorização)
  • Ajuda o destinatário a identificar quais campos esperar
  • A forma de serialização pode variar por rede (BCD, ASCII etc.)

Bitmap

  • Indica a presença ou ausência de campos
  • 1 significa que o campo está presente, 0 significa que o campo não está presente
  • Tem tamanho de 8 bytes e pode representar até 64 campos

Elementos de dados (Data Elements)

  • Os campos são serializados depois do bitmap
  • Campos de tamanho fixo têm sempre o mesmo tamanho, enquanto campos de tamanho variável incluem informações de comprimento
  • A codificação dos campos pode usar ASCII, BCD, binário etc.

Estruturas de mensagem aninhadas

  • O padrão ISO 8583 permite que as redes incluam dados personalizados específicos da rede
  • Mensagens aninhadas podem ser implementadas nos formatos tabela, bitmap e TLV (Tag-Length-Value)

Tabelas

  • Todos os campos são incluídos com tamanho fixo
  • Para reduzir desperdício de espaço, também há suporte adicional a subcampos de tamanho variável

Mensagens com bitmap

  • A presença de cada subcampo é indicada por um bitmap
  • Evita desperdício de espaço quando um campo não está presente

Mensagens TLV

  • Os campos são serializados como tuplas de tag, comprimento e valor
  • São expansíveis e independem de ordem

Projeto do parser

  • Um parser ISO 8583 começa pela análise do bitmap e pela definição de serialização de cada campo
  • É preciso considerar o tratamento de mensagens aninhadas e as diferenças de implementação entre redes
  • O sistema de tipos Sorbet do Ruby é usado para definir classes de mensagem seguras
  • É possível configurar campos de tamanho fixo e variável, tratamento de padding etc.

Tratamento de erros

  • Em caso de falha ao fazer o parsing de um campo, o sistema é projetado para permitir o parsing dos próximos campos
  • Mantém a serialização da mensagem enquanto lida com erros parciais
  • Em caso de erro fatal, o processamento da mensagem é interrompido

Conclusão

  • O padrão ISO 8583 continua evoluindo desde sua definição em 1987, atendendo a diversas exigências de diferentes redes
  • A Increase ajuda a processar mensagens ISO 8583 para que você possa se concentrar no desenvolvimento de produtos para usuários
  • É possível consultar a documentação da API ou entrar em contato com a equipe da Increase

Leituras relacionadas

1 comentários

 
GN⁺ 2024-12-19
Comentários do Hacker News

  • Visa e Mastercard não implementam a ISO 8583 de forma padronizada. Cada empresa publica milhares de páginas de documentação explicando como usar os campos padrão e como incluir dados proprietários nas mensagens. A maioria das plataformas de gestão/emissão de cartões abstrai isso bem. A migração para ISO 20022 é uma melhoria positiva, mas dificilmente atenderá aos critérios de ROI.

  • Esse tipo de protocolo (tipo de mensagem, bitmap de definição de campos, conjunto de valores de tamanho fixo e variável) era comum na época em que foi desenvolvido. É preciso tomar cuidado no lado receptor para validar comprimentos de campo dinâmicos e não ler além do fim da mensagem. No entanto, esses problemas agora são bem compreendidos.

  • É desconcertante que o padrão ISO 8583 não especifique como codificar campos ou tipos de mensagem. Isso faz com que o receptor possa receber um conjunto aleatório de bytes que ele não consegue entender.

  • Tem havido muita discussão recente sobre pagamentos, e o patio11 produz um conteúdo excelente. Há 25 anos, não existiam sites com explicações visuais como este. Como outro comentário que mencionou EBCDIC, a conversão entre endianness é complexa. Foi divertido ter trabalhado com o cartão Discover no começo dos anos 2000 para adicionar um campo GUID à especificação ISO8583.

  • Os sistemas financeiros são uma das frentes de batalha da mudança. Muita gente não percebe essas transformações. As grandes empresas de tecnologia possuem seus próprios ecossistemas de pagamento, então é preciso oferecer esse tipo de insight para quem ainda não se deu conta disso. Alguns países estão acompanhando esse movimento.

  • Charles Stross ficou meio maluco por causa do padrão ISO 8583, e isso pode ter sido o que o levou a escrever Accelerando. Esse padrão provavelmente foi um novo padrão que substituiu protocolos vagos dos anos 70.

  • Excelente artigo explicando por que a ISO20022 tem motivos para substituir a 8583, especialmente em regiões não dominadas por redes proprietárias de M/V. Cartões de crédito podem ser implementados em novos sistemas de pagamento junto com contas de crédito fornecidas pelos bancos. Pagamentos instantâneos entre contas e transações de preço fixo e baixo custo passam a ser possíveis.

  • Foi interessante ver as várias formas de contornar as limitações da ISO 8583. Ultimamente, usa-se bastante o envio de informações adicionais fora da transação de pagamento por meio de chamadas de API antes/depois da mensagem ISO. Isso reduz o time-to-market, mas pode introduzir novos modos de falha.

  • Esse formato era divertido. Ao analisar mensagens ISO-8583, dava para ver a história se desenrolando. As mensagens que analisei eram BCD, não EBCDIC. Mas um campo continha XML, e o XML continha JSON. Cada expansão da mensagem refletia a moda do ano.

  • Ao contrário de Visa e Mastercard, os alertas de transação da AMEX chegam quase imediatamente. Assim que você passa o cartão, a notificação aparece no celular/relógio como mágica. Parece que a V/MC tem camadas que a AMEX não tem.

  • Tive bastante sucesso com iso8583 usando a biblioteca de Go.

  • Foi divertido revisar a lógica de mascaramento de dados de cartão de crédito ISO 8583 codificados em base64 nos logs do sistema (ou codificados em base64 codificado em EBCDIC).