Você está na página 1de 102

UNIVERSIDADE FEEVALE

FELIPE RICARDO DEL VECCHIO

EMULADOR DE AMBIENTES E SISTEMAS DE TRANSAÇÕES


ELETRÔNICAS BASEADO NA ISO 8583

Novo Hamburgo
2013
FELIPE RICARDO DEL VECCHIO

EMULADOR DE AMBIENTES E SISTEMAS DE TRANSAÇÕES


ELETRÔNICAS BASEADO NA ISO 8583

Trabalho de Conclusão de Curso


apresentado como requisito parcial
à obtenção do grau de Bacharel em
Ciência da Computação pela
Universidade Feevale

Orientador: Eduardo Pretz

Novo Hamburgo
2013
AGRADECIMENTOS

Gostaria de agradecer a todos os que, de alguma


maneira, contribuíram para a realização desse
trabalho de conclusão, em especial:

Professor Eduardo Pretz, Alexandre Andrade,


Bryan Boa Ventura, Cristian Mairesse
Cavalheiro, Eduardo Roloff, Ricardo Galho,
GetNet e aos Professores – vocês foram
realmente fantásticos; colegas e comunidade
acadêmica, minha sincera gratidão.

Também aos meus avós Vera e Afonso que


mantiveram as esperanças. Minha irmã Paola
del Vecchio por ser tão única, especial e ótima
com números. Meu Pai, minha Mãe e meu
Padrasto. Aos amigos e colegas de profissão
que acreditaram nesse trabalho e dedicaram seu
precioso tempo comigo. Meu muito obrigado!
RESUMO

O alto índice de crescimento da indústria de transações eletrônicas e do mercado de cartões


propicia as empresas atuantes na área de captura e processamento, incorporar cada vez mais
produtos e serviços em suas redes. Antigamente a aceitação se resumia apenas a cartões de
crédito e débito de grandes bandeiras, como MasterCard, VISA e AMEX, atualmente há
diversos novos produtos e nichos sendo explorados, como recarga de celular, correspondente
bancário, recarga de bilhetes, seguros, promoções, consultas de crédito e uma variedade de
cartões benefício, private labels e vouchers. Porém os serviços de autorização de transações
são bastante distribuídos (i.e.: uma empresa captura a transação, uma segunda processa e uma
terceira autoriza) e compostos por diversos sistemas. Apesar da ampla adoção da ISO 8583
pelo mercado para troca de mensagens financeiras, o que acontece na prática é a
implementação de uma versão customizada da norma por parte de cada empresa. Esse fato
resulta em um período maior de desenvolvimento de plataformas transacionais, muitas vezes
desencontrados em virtude de alguns sistemas terem sua fase de codificação finalizada muito
tempo antes de outros, dando início à fase de testes apenas quando todos os outros sistemas da
cadeia também estiverem concluídos e integrados. Desta forma, este trabalho tem como
objetivo propor e validar um emulador de ambientes e plataformas transacionais, agilizando o
processo de desenvolvimento de sistemas e aplicações, possibilitando estabelecer um
ambiente de simulação com o mínimo possível de infraestrutura, abstraindo camadas
desejadas de sistemas.

Palavras-chave: ISO 8583. Transações Eletrônicas. Network & Service Provider. Emulador de
Transações Financeiras
ABSTRACT

The high rate of growth of electronic payment systems and payment cards market share,
allows companies working in the area of capture and processing increasingly incorporate
products and services on their networks. Formerly acceptance was limited only to credit and
debit cards of large brands, such as MasterCard, VISA and AMEX, currently there are several
new products and niches being explored, such as mobile phone recharge, correspondent
banking, prepaid tickets, insurance discounts, credit inquiries and a variety of cards as
benefits, private labels and vouchers. However, the transaction authorization services are
fairly distributed (i.e.: a company is responsible for transaction data capture, other for
transaction processing and another for transaction authorization process) and composed of
several systems and partners. Despite the widespread adoption of ISO 8583 by the market to
interchange financial messages, what happens in practice is the implementation of a
customized version of the standard by each company. This fact results in a longer period of
development of payment platforms, often clashing because some systems have their
implementation phase completed in different times from others belonging to the same
platform, initiating the testing phase only when all other systems belonging to the same chain
are also finished and integrated. Thus, this paper aims to propose and validate an emulator of
transactional environments and platforms, speeding up the process of developing systems and
applications, allowing establishing a test environment with minimal infrastructure set,
abstracting desirable system layers.

Keywords: ISO 8583. Electronic Transactions. Network & Service Provider. Financial
Transactions Emulator.
LISTA DE FIGURAS

Figura 1.1 – Tipos de pesquisa científica ________________________________________ 15


Figura 2.1 – O passo-a-passo de uma transação ___________________________________ 18
Figura 2.2 – Terminal POS ___________________________________________________ 21
Figura 2.3 – Exemplo de terminal POS _________________________________________ 22
Figura 2.4 – Quantidade de terminais POS instalados ______________________________ 22
Figura 2.5 – Exemplo de PDV ________________________________________________ 23
Figura 2.6 – Exemplo de terminal Pinpad _______________________________________ 24
Figura 2.7 – Exemplo de troca de mensagens de transação financeira _________________ 27
Figura 2.8 – Ciclo de uma autorização __________________________________________ 27
Figura 2.9 – Estrutura de uma mensagem ISO 8583 _______________________________ 28
Figura 2.10 – Fluxo transacional ______________________________________________ 36
Figura 3.1 – Integração entre diferentes templates _________________________________ 38
Figura 3.2 – Exemplo de implementação customizada da ISO 8583 ___________________ 40
Figura 3.3 – Exemplo de customização _________________________________________ 40
Figura 3.4 – Simulador MasterCard como adquirente ______________________________ 44
Figura 3.5 – Simulador MasterCard como emissor ________________________________ 44
Figura 3.6 – Simulador MasterCard débito – tela de resultados ______________________ 45
Figura 3.7 – Simulador VISA VTS: Interface ____________________________________ 46
Figura 4.1 – Estrutura com múltiplos sistemas de processamento _____________________ 49
Figura 4.2 – Exemplo de estrutura de sistema de pagamento ________________________ 51
Figura 4.3 – Exemplo de mensagem de resposta __________________________________ 53
Figura 4.4 – Mensagem codificada em ASCII ____________________________________ 53
Figura 4.5 – Mensagem codificada em BCD _____________________________________ 54
Figura 4.6 – Complementação de template ______________________________________ 54
Figura 4.7 – Resposta de mensagem com base em conteúdo recebido _________________ 55
Figura 4.8 – Fluxo de transacional agrupado _____________________________________ 56
Figura 4.9 – Emulador em modo loop-back (abstração de todo sistema) _______________ 57
Figura 4.10 – Emulador em modo loop-back (abstração de um único sistema) __________ 58
Figura 4.11 – Emulador em modo pass-through (abstração de um único sistema) ________ 59
Figura 4.12 – Caso de uso emulador de transações ________________________________ 60
Figura 5.1 – Priorização de templates __________________________________________ 64
Figura 5.2 – Exemplo de parse de mensagem ____________________________________ 66
Figura 5.2 – Tela de status do Easy ISO 8583 ____________________________________ 68
Figura 5.3 – Tela de configuração do padrão de mensagens do Easy ISO 8583 __________ 70
Figura 5.4 – Tela de configuração de templates do Easy ISO 8583 ____________________ 71
Figura 5.5 – Tela de logs do Easy ISO 8583 _____________________________________ 72
Figura 5.6 – Diagrama de classes reduzido do Easy ISO 8583 _______________________ 73
Figura 5.7 – Diagrama de sequência ao processar uma transação _____________________ 75
Figura 5.8 – Detalhamento do ambiente da solução Mobile _________________________ 76
Figura 5.9 – Detalhamento do ambiente da solução TEF____________________________ 77
Figura 5.10 – Exemplo de nomes significativos para templates ______________________ 80
Figura 5.11 – SCC: cadastro do padrão ISO 8583 _________________________________ 81
Figura 5.12 – SCC: parametrização de conectividade ______________________________ 81
Figura 5.13 – SCC: cadastro das estruturas de mensagens __________________________ 82
Figura 5.14 – SCC: estrutura de uma mensagem __________________________________ 82
Figura 5.15 – Linguagem script do SCC ________________________________________ 83
Figura 5.16 – ASSET: tela inicial______________________________________________ 83
Figura 5.17 – ASSET: definição de um campo de dado ____________________________ 84
Figura 5.18 – ASSET: linguagem script proprietária _______________________________ 85
Figura 5.19 – VISA VTS: tela inicial ___________________________________________ 85
Figura 5.20 – VISA VTS: configuração de estrutura de mensagem ___________________ 86
Figura 5.21 – MasterCard Simulator: configuração de estrutura de mensagem __________ 87
Figura 5.22 – MasterCard Simulator: estrutura de mensagem detalhada ________________ 87
Figura 6.1 – Mapa de bits autorização (exemplo) ________________________________ 100
Figura 6.2 – Fluxo de mensagem (exemplo) ____________________________________ 100
Figura 6.3 – Dump da mensagem de requisição __________________________________ 101
Figura 6.4 – Mensagem de requisição em ASCII_________________________________ 101
Figura 6.5 – Mensagem de requisição detalhada _________________________________ 101
Figura 6.6 – Dump da mensagem de resposta ___________________________________ 102
Figura 6.7 – Mensagem de resposta em ASCII __________________________________ 102
Figura 6.8 – Mensagem de resposta detalhada ___________________________________ 102
LISTA DE TABELAS

Tabela 2.1 – Composição do MTI _____________________________________________ 29


Tabela 2.2 – MTI Posição 01: Versão da mensagem _______________________________ 29
Tabela 2.3 – MTI Posição 02: Classe da mensagem _______________________________ 30
Tabela 2.4 – MTI Posição 03: Função da mensagem _______________________________ 30
Tabela 2.5 – MTI Posição 04: Origem da comunicação ____________________________ 31
Tabela 2.6 – Exemplo de mapa de bits __________________________________________ 32
Tabela 2.7 – Mapa de bits detalhado (binário) ____________________________________ 32
Tabela 2.8 – Exemplo de elementos de dados ____________________________________ 32
Tabela 2.9 – Formato dos elementos de dados ____________________________________ 33
Tabela 2.10 – Especificação do tamanho dos campos de elementos de dados ___________ 33
Tabela 2.11 – Especificação de elementos de dados _______________________________ 34
Tabela 2.12 – Exemplo de codificação de caracteres _______________________________ 34
Tabela 2.13 – Elementos de dados reservados para uso futuro _______________________ 35
Tabela 2.14 – Template de mensagem administrativa ______________________________ 37
Tabela 3.1 – Exemplo de template de mensagem customizado _______________________ 41
Tabela 5.1 – Transações realizadas com a solução TEF ____________________________ 88
Tabela 5.2 – Transações realizadas com a solução mobile___________________________ 89
Tabela 5.3 – Comparação entre ASSET x Easy ISO 8583 ___________________________ 90
Tabela 5.4 – Comparação entre SCC (GetNet) x Easy ISO 8583 _____________________ 91
Tabela 5.5 – Comparação entre simuladores Mastercard x VISA x Easy ISO 8583 _______ 92
LISTA DE ABREVIATURAS E SIGLAS

ABA American Bankers Association


ABECS Associação Brasileira das Empresas de Cartões de Crédito e Serviços
AMEX American Express
ASCII American Standard Code for Information Interchange
ATM Automated Teller Machine
BACEN Banco Central
BCD Binary-coded Decimal
EBCDIC Extended Binary Coded Decimal Interchange Code
EC Estabelecimento Comercial
EMV Europay, MasterCard and VISA
GPRS General Packet Radio Service
ISO International Organization for Standardization
MPLS Multi Protocol Label Switching
MTI Message Type Indicator
NFC Near Field Communication
N&SP Network & Service Provider
PDV Ponto de Venda
PIB Produto Interno Bruto
POS Point-of-Sale
SDLC Synchronous Data Link Control
TEF Transferência Eletrônica de Fundos
VTS Visa Test System
SUMÁRIO

INTRODUÇÃO __________________________________________________________ 12
1. METODOLOGIA _______________________________________________________ 15
1.1 Pesquisa ____________________________________________________________ 15
1.2 Definição do Ambiente ________________________________________________ 16
2. CONCEITOS BÁSICOS _________________________________________________ 17
2.1 O que é uma Transação Eletrônica _______________________________________ 17
2.2 Benefícios dos Sistemas de Pagamentos Eletrônicos _________________________ 19
2.3 Meios de Captura _____________________________________________________ 20
2.3.1 Terminal POS __________________________________________________ 20
2.3.2 Soluções TEF ___________________________________________________ 23
2.4 Produtos e Serviços Disponibilizados nos Meios de Captura ___________________ 24
2.5 ISO 8583: Especificação de Mensagens de Intercâmbio ______________________ 25
2.5.1 Cabeçalho da Mensagem __________________________________________ 28
2.5.2 Identificador do Tipo da Mensagem (MTI) ____________________________ 29
2.5.3 Versão da Mensagem ISO 8583 ____________________________________ 29
2.5.4 Classe da Mensagem _____________________________________________ 29
2.5.5 Função da Mensagem ____________________________________________ 30
2.5.6 Origem da Comunicação __________________________________________ 31
2.5.7 Mapa de Bits da Mensagem ________________________________________ 31
2.5.8 Elementos de Dados da Mensagem __________________________________ 32
2.5.9 Formato dos Elementos de Dados ___________________________________ 33
2.5.10 Tamanho dos Campos de Elementos de Dados _________________________ 33
2.5.11 Codificação de Dados ____________________________________________ 34
2.5.12 Elementos de Dados Customizáveis _________________________________ 35
2.5.13 Fluxos de Mensagens _____________________________________________ 35
2.5.14 Padrões de Mensagens ____________________________________________ 37
3. ANÁLISE DE FERRAMENTAS ___________________________________________ 38
3.1 Exemplos de Customizações da ISO 8583 _________________________________ 39
3.1.1 Customização Padrão ISO 8583 ____________________________________ 39
3.1.2 Customização Opoente ao Padrão ISO 8583 ___________________________ 41
3.2 Soluções de Mercado __________________________________________________ 42
3.2.1 MasterCard Simulator Suite ________________________________________ 44
3.2.2 VISA Test System _______________________________________________ 46
3.2.3 ACI Payment Testing (ASSET)_____________________________________ 46
3.2.4 Paragon ISO 8583 Testing _________________________________________ 47
4. PROPOSTA ____________________________________________________________ 49
4.1 Emulador de Transações _______________________________________________ 50
4.1.1 Interpretador de Mensagens ________________________________________ 52
4.1.2 Ajuste de Conteúdo ______________________________________________ 54
4.1.3 Cadastro de Elementos de Dados ___________________________________ 55
4.1.4 Translate de Templates ___________________________________________ 55
4.1.5 Cadastro de Casos de Teste ________________________________________ 56
4.2 Modo de Comunicação ________________________________________________ 56
4.2.1 Loop-back _____________________________________________________ 57
4.2.2 Pass-through ___________________________________________________ 59
4.3 Casos de Uso ________________________________________________________ 60
5. EASY ISO 8583 EMULATOR _____________________________________________ 61
5.1 Funcionalidades ______________________________________________________ 61
5.1.1 Parametrização de Modelo de Mensageria ISO 8583 ____________________ 62
5.1.2 Gerenciamento de Templates de Scripts de Requisição e Resposta _________ 63
5.1.3 Interpretador de Mensagens de Requisição ____________________________ 65
5.1.4 Gerador de Mensagens de Resposta _________________________________ 66
5.2 Interface ____________________________________________________________ 67
5.2.1 Painel de Status _________________________________________________ 68
5.2.2 Painel de Configuração de Conexão _________________________________ 69
5.2.3 Painel de Configuração do Modelo ISO 8583 __________________________ 69
5.2.4 Painel de Configuração de Templates ________________________________ 70
5.2.5 Painel de Logs __________________________________________________ 71
5.3 Modelagem _________________________________________________________ 72
5.3.1 Diagrama de Classes _____________________________________________ 73
5.3.2 Diagrama de Sequência ___________________________________________ 74
5.4 Validação Experimental _______________________________________________ 76
5.4.1 Cenário 01: Solução Mobile _______________________________________ 76
5.4.2 Cenário 02: Solução TEF__________________________________________ 77
5.5 Experimentos ________________________________________________________ 77
5.5.1 Construção dos Ambientes ________________________________________ 78
5.5.2 Ponto de Vista do Terminal ________________________________________ 88
5.5.3 Comparativo entre Soluções _______________________________________ 89
CONCLUSÃO____________________________________________________________ 93
REFERÊNCIAS BIBLIOGRÁFICAS ________________________________________ 95
APÊNDICE A – EXEMPLO DE INTERCÂMBIO ____________________________ 100
INTRODUÇÃO

A utilização de meios eletrônicos para pagamentos de transações financeiras vem ao


longo dos anos se consolidando entre a população brasileira. De acordo com Yamaguti
(2012), a expansão do mercado brasileiro de cartões de pagamento cresce numa taxa superior
a 20% ao ano. Essa evolução contabiliza transações realizadas com cartões de crédito, débito
e private labels (cartões proprietários emitidos em geral por varejistas com intuito de fidelizar
o cliente) além de produtos como correspondente bancário e recarga de celular.

Segundo Caffarelli (2011, p.21), o mercado eletrônico no Brasil contabilizou em


2010 mais de sete bilhões de transações, movimentando valores superiores a R$ 500 bilhões
numa rede composta por mais 1,8 milhões de lojistas e 80 milhões de portadores de cartões.
De acordo com dados disponibilizados pela Associação Brasileira das Empresas de Cartões de
Crédito e Serviços (ABECS, 2012a), o primeiro trimestre de 2012 já superou as expectativas
previstas para o período, com um faturamento de R$ 175,8 bilhões (alta de 23% em relação ao
mesmo período de 2011) e com 704 milhões de plásticos (cartões) em circulação. Mantendo-
se os índices, a estimativa é que até 2015, 36% do consumo das famílias brasileiras serão
feitos por meio de cartões de crédito, débito e de loja (private label), e o faturamento do
mercado atingirá R$ 1,3 trilhão.

Os principais meios de captura de transações eletrônicas são os terminais Point-of-


sale (POS) – popularmente chamado de maquininha de cartões, os sistemas de Transferência
Eletrônica de Fundos (TEF) – responsáveis por atender grandes redes como supermercados e
farmácias, os Automated Teller Machine (ATM) – conhecidos também como caixas
eletrônicos / automático) e os dispositivos móveis (MATBOULI; GAO, 2012).

Juntamente com o incremento dos serviços de pagamento, o mercado de


transferência de fundos eletrônicos vem se expandindo massivamente, exigindo que as
empresas ofereçam serviços confiáveis e de alta disponibilidade, escalabilidade e segurança
(ARAUJO et al., 2009). Esse incremento e aumento do volume de cartões gera uma
necessidade de mercado e oportunidade para as empresas que capturam, processam e
autorizam transações eletrônicas.

O mercado de autorização de transações é bastante distribuído, há diversas empresas


atuando e interagindo entre si. É raro uma única empresa ser responsável por uma transação
de ponta a ponta, sendo comum a interconexão de sistemas que compõem uma plataforma
transacional entre diferentes empresas. O padrão ISO 8583 especifica o intercâmbio entre
13

emissões e aquisições com cartões de crédito (ISO, 1993), sendo este adotado amplamente
pelo mercado como leiaute padrão, desde os terminais encontrados nos pontos de venda até os
sistemas que capturam e processam as transações eletrônicas trocam mensagens seguindo o
mesmo protocolo. Devido a sua flexibilidade, capacidade e funcionalidade (MASTERCARD,
2010), além de toda uma base legada de sistemas bancários já existentes (DELIC;
VUKASINOVIC, 2006).

O maior problema apresentado pela ISO 8583 não é a sua complexidade, mas sim
diversidade. Além de possuir diversos campos do tipo private use (reservados para uso
privado), onde cada instituição adota um padrão, fazendo com que na prática cada instituição
adote sua própria implementação da norma, o padrão de como os dados de um determinado
campo é representado também não é definido pela norma, ou seja, um campo numérico pode
ser representado por uma sequência de caracteres ASCII, EBCDIC ou ainda BCD (exemplo:
1234 em ASCII = 0x31 0x32 0x33 0x34, em BCD = 0x12 x034).

Além disso, uma única transação financeira engloba uma série de troca de mensagens
(solicitação, resposta e confirmação) (ISO, 1993) que trafegam por diversos sistemas desde
sua captura inicial no varejo, como por exemplo, em um terminal POS, até sua autorização em
seu respectivo emissor (ARAUJO et al., 2009).

Entre os maiores desafios para as empresas adquirentes e de Network Service


Provider (N&SP), empresas que vendem acesso a sua rede de terminais para outras empresas,
oferecendo soluções em captura e processamento (GETNET, 2012a), na área de
desenvolvimento de sistemas estão:

 Integrar um novo produto aos produtos já existentes (i.e.: capturar e processar um


novo cartão na rede), ajustando sua implementação da ISO 8583 ao template do
cliente (acatando e formatando campos do tipo private use);

 possuir um ambiente de testes dedicado e amplamente disponível com entidades


externas durante e pós-implantação de produto;

 depender de outros subsistemas para ter seus respectivos desenvolvimentos


encerrados para iniciar testes e validações (principalmente integração);

 reproduzir comportamentos e testes específicos em subsistemas;

 abstrair sistemas dispensáveis em determinadas fases de testes e validações.


14

A dificuldade em desenvolver e integrar sistemas entre as entidades que capturam e


processam transações eletrônicas, bem como realização de testes geram grande esforço e
dependência entre as partes envolvidas. Analisando as soluções do principais fornecedores de
mercado, foram encontradas algumas aplicações para simulação de sistemas de autorização e
processamento, porém todas elas são soluções finais – simulam apenas uma parte completa de
um sistema. As empresas MasterCard e VISA, por exemplo, comercializam soluções que
simulam tanto o lado adquirente quanto o lado emissor – porém todas elas são soluções
exclusivas e dedicadas ao seu negócio, não possibilitando a personalização de um produto
terceiro nelas (MASTERCARD, 2012a; VISA, 2012a).

Desta forma, este trabalho tem como propósito suprir esta carência, definindo uma
ferramenta que seja capaz de emular tanto sistemas completos quanto subsistemas que
trafegam mensagens de intercâmbio baseadas na ISO 8583, conservando sua flexibilidade,
capacidade e funcionalidade além de permitir a codificação dos dados nos modelos adotados
atualmente entre as instituições (ASCII, EBCDIC e BCD), conversão e também alteração do
conteúdo das mensagens de resposta baseado em valores de campos da mensagem de
requisição.

O conteúdo do presente trabalho está organizado e distribuído em cinco capítulos. O


Capítulo 1 consiste da metodologia adotada para a pesquisa, determinando sua natureza,
objetivos e procedimentos. No Capítulo 2, são abordados temas pertinentes as transações
eletrônicas, tais como definições, normas e estrutura de mensagens financeiras - sendo estes
pontos determinantes para compreensão do trabalho. O Capítulo 3 apresenta as principais
ferramentas de mercado para simulação de transações, detalhando suas respectivas
características e comportamentos - servindo estas como referências para a proposta e
desenvolvimento do trabalho. O Capítulo 4 é composto da proposta deste trabalho e sua
aplicabilidade. No Capítulo 5 é apresentado o simulador desenvolvido, acompanhado de suas
funcionalidades, modelagem e interface. Por último, as conclusões sobre o desenvolvimento
do projeto realizado.
1. METODOLOGIA

Neste capítulo será apresentada a metodologia no que diz respeito ao tipo de pesquisa
realizada, seguido das ferramentas selecionadas para o desenvolvimento da solução proposta.
A Figura 1.1 auxilia a compreender a classificação da pesquisa utilizada na elaboração deste
trabalho – os itens de contorno mais escuro correspondem as classificações empregadas.

Pesquisa Exploratória

Pesquisa Descritiva

Pesquisa Explicativa

Pesquisa Básica

Quanto aos Quanto aos


Quanto à Natureza
Objetivos Procedimentos

Pesquisa Aplicada

Pesquisa Documental

Gera Produtos e/ou Processos Estudo de Caso Pesquisa Bibliográfica


(Com finalidades imediatas)
Utiliza os conhecimentos Pesquisa Experimental
Pesquisa-Ação
gerados pela Pesquisa Básica
+ Tecnologias Existentes
Pesquisa Participante Pesquisa Operacional

Pesquisa Ex-PostFacto

Figura 1.1 – Tipos de pesquisa científica


Fonte: baseado em PRODANOV e FREITAS (2009, p.62)

Do ponto de vista da forma de abordagem do problema, segundo Cleber Prodanov,

na abordagem qualitativa, a pesquisa tem o ambiente o ambiente como fonte direta


dos dados. O pesquisador mantém contato direto com o ambiente e o objeto de
estudo em questão, necessitando um trabalho mais intensivo de campo. Nesse caso,
as questões são estudadas no ambiente em que elas se apresentam sem qualquer
manipulação intencional do pesquisador (PRODANOV e FREITAS, 2009, p.81).
Compreendendo o enfoque adotado pelo autor no estudo desenvolvido.

1.1 Pesquisa

A natureza deste trabalho consiste em uma pesquisa aplicada, buscando identificar as


necessidades do mercado brasileiro e também funcionalidades existentes em simuladores
semelhantes. Para tal, primeiramente foi realizado um levantamento bibliográfico, através do
16

estudo e análise das normas ISO 8583 (edições :1987, :1993 e :2003), especificações técnicas
VISA, MasterCard e GetNet1. Posteriormente foram analisadas as principais soluções de
mercado dedicadas à simulação de ambientes de transações eletrônicas.

A empresa GetNet possui um cenário bastante amplo, contemplando diversos


sistemas e soluções implementadas, servindo esta, como forte referência para a elaboração da
proposta deste trabalho. Além da consulta a profissionais com vasta experiência na
implementação e sustentação das tecnologias citadas ao longo do trabalho.

Após, foi realizada a prototipação do sistema proposto, a fim do mesmo ser validado
através de experimentação, sendo esta, conduzida em um ambiente real de desenvolvimento
de soluções para meios de pagamento. Com os resultados dos experimentos, foi possível
realizar a análise de viabilidade de utilização da solução. Identificando funcionalidades
contempladas, não contempladas, melhorias desejáveis, aderência ao negócio e possibilidade
de utilização em larga escala.

1.2 Definição do Ambiente

Para o desenvolvimento da solução, optou-se pela linguagem Java, devido ser uma
linguagem orientada a objetos largamente utilizada, open source, free e principalmente por ser
multi-plataforma. Os binários gerados podem ser executados em qualquer sistema
operacional, desde que este possua instalado o Java Virtual Machine2 (JVM).

Para desenvolvimento da solução e escolha das respectivas Integrated Development


Environment (IDE), a aplicação foi arquitetada de forma que a camada de apresentação para o
usuário seja independente das demais camadas. Dessa forma, o core da aplicação foi
desenvolvido com o Eclipse IDE for Java Developer (Juno)3, enquanto a interface gráfica foi
implementada com o NetBeans IDE 7.2.14.

Os dados manipulados pela solução tais como templates de mensageria ISO 8583 e
pares de requisições e respostas, constituem-se de arquivos do tipo Extensible Markup
Language (XML) 1.0 – sendo estes carregados e instanciados em tempo de execução,
eliminando a dependência de uma base de dados e facilitando o transporte e manipulação dos
dados.

1
http://www.getnet.com.br
2
http://java.com/en/download/index.jsp
3
http://www.eclipse.org/
4
https://netbeans.org/
2. CONCEITOS BÁSICOS

De acordo com os dados fornecidos pelo American Bankers Association (ABA),


maior associação de comércio bancário dos Estados Unidos, em 2009 os cartões de crédito
foram responsáveis por mais de 2.5 trilhões de dólares em transações no mundo inteiro, sendo
estes aceitos em mais de 24 milhões de estabelecimentos distribuídos em mais de 200 países e
territórios (ABA, 2009).

Segundo Clayton (2009), é incompreensível considerar o tamanho de redes de


computadores, sistemas de comunicação, faturamento e instalações de processamento,
sistemas antifraudes em programas de clientes necessários para lidar com até 10.000
transações com cartões de pagamento a cada segundo em todo mundo.

Dentre os instrumentos eletrônicos, o cartão de pagamento é o que apresenta maior


crescimento em número de transações de varejo no ponto de venda, inclusive no comércio
eletrônico (BANCO CENTRAL, 2010, p.13). Os números em torno do mercado de cartões
são muito expressivos, bem como a complexidade do negócio dado o volume e as diversas
partes envolvidas (proprietários de esquemas de cartões, bancos, adquirentes,
estabelecimentos comerciais e portadores de cartões). Para auxiliar a buscar tal compreensão,
serão abordadas e conceituadas as principais partes envolvidas durante o processo de
autorização de transações financeiras.

2.1 O que é uma Transação Eletrônica

Primeiramente, o que é uma transação eletrônica. Há diversas definições para o


termo transação eletrônica – conceituando especificamente para o mercado de cartões de
pagamento, o Anuário Brasileiro de Meios de Pagamento (ELAP, 2011, p.590) caracteriza
como “função do cartão para compras ou saques, qualquer troca de valor financeiro por bens
ou serviços”. Andrade (2012) complementa a definição dizendo ser “toda e qualquer captura,
troca e processamento de informações por meio eletrônico, sejam eles de forma online ou
não”.
18

De acordo com a MasterCard (2012), o processo de autorização pode ser


compreendido através das seguintes etapas – correspondentes a Figura 2.1:

1. Início da transação (Transaction begins): O portador do cartão realiza uma


compra de bens ou serviços de um estabelecimento comercial (EC).

2. Autenticação (Authentication): O estabelecimento realiza a venda ao


comprador – sendo este reembolsado pelo montante da venda já descontada
as taxas da transação.

3. Transação (Transaction): O adquirente submete a transação ao banco emissor


para pagamento através do sistema de intercâmbio e liquidação.

4. Pagamento ao Estabelecimento (Merchant Payment): O banco emissor do


cartão paga o adquirente, já tendo descontado suas taxas através do sistema
de liquidação.

5. Pagamento do portador (Cardholder Payment): O titular do cartão paga ao


emissor pela compra realizada originalmente no estabelecimento.

Figura 2.1 – O passo-a-passo de uma transação


Fonte: http://www.mastercard.com/br/sobre_nos/pt/transacao.html
19

2.2 Benefícios dos Sistemas de Pagamentos Eletrônicos

No aspecto econômico para o país, de acordo com o diagnóstico do Banco


Central (2005, p.10),

uma característica comum entre os países que passaram por processos de


modernização de seus sistemas de pagamento de varejo é a tendência à migração dos
pagamentos realizados com a utilização de instrumentos em papel para pagamentos
eletrônicos. A razão fundamental dessa tendência é a maior eficiência que os
instrumentos de pagamento eletrônicos apresentam se comparados aos em papel.
Estudos demonstram que o custo de um pagamento eletrônico representa entre 1/3 a
1/2 do custo de um pagamento em papel.
Outro dado muito importante, é que a migração completa de instrumentos em
papel para eletrônicos produziriam uma redução anual de custo na ordem de 1% a 3%
do Produto Interno Bruto (PIB), (Humphrey, Pu lley e Vesala, 1996; Robins on, 1995;
Swartz, 2004 apud BANCO CENTRAL, 2005, p.10).

Há ainda diversos outros aspectos que devem ser levados em conta, por
exemplo:

 Estímulo à formalização da economia;

 eficiência na administração do crédito do consumidor;

 maior segurança para consumidor e lojista;

 inovação tecnológica;

 redução da inadimplência do varejo;

 substituição na forma de pagamento (Cartão x Moeda e Cheques);

 incremento do faturamento pela facilidade de uso inclusive no exterior.

Ao invés de portar dinheiro em espécie, é possível carregar apenas um simples


cartão protegido por senha para realizar o pagamento de despesas do dia a dia, com total
segurança e praticidade. Atualmente 71% da população possuem algum tipo de meio
eletrônico de pagamento e as estimativas apontam que até o ano de 2015 mais de 909
milhões de cartões estarão em circulação no Brasil (ABECS, 2012b).

O crescimento da base de usuários de cartões impacta diretamente no


crescimento da base de estabelecimentos comerciais. O Banco Central (Economides e
White, 1994; Economides, 1996 apud 2005, p. 109), respalda essa informação em seus
estudos, afirmando que:
20

no mercado de cartões de pagamentos, quanto maior o número de usuários, maior o


número de estabelecimentos comerciais dispostos a aderir às redes de acesso a esse
instrumento de pagamento. Isso ocorre porque, ao proporcionarem alternativa de
pagamento mais conveniente aos clientes, o potencial de vendas do estabelecimento
comercial aumenta. Além disso, quanto maior o número de estabelecimentos
comerciais que aceitam pagamentos por meio de cartão, maior será o valor desse
instrumento de pagamento para o usuário.
Com base nos números apresentados, conclui-se que a adoção de meios
eletrônicos para pagamento seja vantajosa para os estabelecimentos comercias, pois
além de atingir uma grande parcela da população, há a certeza de recebimento do
pagamento da transação. Também há aumento nas vendas de produtos com maior
margem de lucro além dos consumidores gastarem mais, devido não estarem limitados
ao dinheiro em espécie. Outro benefício é a velocidade no processo de pagamento,
diminuindo filas e não havendo necessidade de dar troco para os clientes
(MASTERCARD, 2012b).

2.3 Meios de Captura

Captura de transações significa o mesmo que realizar uma venda com cartão de
crédito ou débito, por meio de um terminal eletrônico (POS ou PDV) – sendo este chamado
de meio de captura. Os terminais eletrônicos são utilizados pelos estabelecimentos para pedir
autorização, registrar operações feitas com cartão de crédito ou débito e para imprimir o
comprovante de venda (ABECS, 2012c).

Os principais meios de captura utilizados para realização de transações com cartões


de pagamento são os terminais POS e as soluções TEF.

2.3.1 Terminal POS

Os terminais POS, são equipamentos eletrônicos que dispõem de teclado numérico,


leitora de cartões, impressora e modem para comunicação. Esse meio de captura é indicado
para estabelecimentos comerciais ou profissionais autônomos que possuem um caixa ou um
balcão de atendimento com fluxo não muito intenso de atendimento (REDECARD, 2012a). A
Figura 2.2 contém as características básicas encontradas nos principais modelos de terminais
POS.
21

Figura 2.2 – Terminal POS


Fonte: EMVCO (2011, p.39)

Esse tipo de terminal conecta-se diretamente com a sua rede adquirente para realizar
transações, não havendo qualquer tipo de integração com sistemas do estabelecimento
comercial (i.e: software de gestão). Há duas modalidades desses terminais: os fixos – os quais
utilizam linha telefônica ou para realizar conexão e solicitar autorizações; e os terminais
móveis – os quais utilizam comunicação telefônica móvel – GPRS. Os terminais POS são de
propriedade de suas redes, sendo estas responsáveis pela manutenção, instalação e atualização
de software, e estes adquiridos pelos estabelecimentos comerciais na forma de contrato de
aluguel (SANTANDER, 2012a).

Atualmente os terminais POS têm acompanhado a evolução juntamente com os


demais dispositivos eletrônicos. Novos modelos, como o da Figura 2.3, possuem telas grandes
e coloridas, com tecnologia touch screen, acesso a redes WI-FI, portas USB, processadores de
alto desempenho e grande capacidade de memória.
22

Figura 2.3 – Exemplo de terminal POS5


Fonte: http://www.ingenico.com/en/products/payment-terminals/wireless/iwl-touch-series/

Segundo o Banco Central (2010, p. 89) “os principais credenciadores no Brasil


utilizam redes próprias de terminais POS, não interoperáveis, para captura de transações feitas
com cartões dos respectivos esquemas”. Essa afirmação explica porque é comum encontrar
diversos terminais POS instalados num mesmo estabelecimento comercial.

Conclui-se com a Figura 2.4 que há uma base de meios de captura superior a dois
milhões de terminais POS, que realizam transações em diferentes esquemas de cartões,
conectando-se em diferentes ambientes e aceitando diversos tipos de cartões e produtos.

Figura 2.4 – Quantidade de terminais POS instalados


Fonte: Banco Central (2010, p.31)

5
Terminal POS Ingenico iWL Touch 280 e iWL Touch 350
23

2.3.2 Soluções TEF

As soluções TEF constituem um meio de captura mais complexo e bastante diferente


do POS, pois são totalmente integradas ao sistema do estabelecimento comercial. Sua
composição é bastante fragmentada, havendo diversas empresas envolvidas na constituição de
uma única solução. Entre elas há uma responsável pelo software de frente de caixa, que é a
aplicação encontrada nos PDV's, responsável por registrar as compras e integrar-se com o
software de gestão do EC e com a solução TEF. A Figura 2.5 exemplifica esse tipo de
solução, como todos seus respectivos dispositivos.

Figura 2.5 – Exemplo de PDV


Fonte: http://www.bematech.com.br/equipamento.html

Outra parte é a solução TEF em si, responsável por conectar-se às redes adquirentes
para solicitar autorização de transações. Essa aplicação é composta por módulos e cada
adquirente possui o seu módulo próprio, sendo este desenvolvido pela software-house
proprietária da solução TEF (também conhecida como integradora), porém baseado no leiaute
do adquirente.

Neste tipo de solução, o adquirente não tem a mesma autonomia que possui em seus
terminais POS. Caso este deseje realizar qualquer alteração no leiaute de mensagens ou
inserção de novos produtos, faz-se necessário solicitar a integradora, a qual deverá analisar,
desenvolver e gerar uma nova versão do seu módulo. Posteriormente atualizando a base de
clientes em comum com o adquirente. Sendo este processo necessário com cada integradora.

Estabelecimentos comerciais de grande porte, que possuem check-outs interligados


em rede e grande volume de transações (i.e.: redes de supermercados) adotam esse tipo de
solução, tanto por ser mais ágil, quanto por se integrar com seu software de gestão
(REDECARD, 2012b).
24

As soluções TEF capturam transações através de um terminal pinpad, que é um leitor


de cartões seguro integrado ao terminal PDV para realizar vendas (Figura 2.6). Este pode ser
adquirido ou alugado pelo estabelecimento comercial. Esse tipo de solução opera com
conexão dedicada (i.e.: x.25 ou MPLS), o que permite realizar uma transação em frações de
segundo. Essa estrutura é de responsabilidade do estabelecimento comercial (SANTANDER,
2012b; CIELO, 2012).

Figura 2.6 – Exemplo de terminal Pinpad


Fonte: http://www.gertec.com.br/produto.aspx/produtosdetalhe/23/PPC_900

2.4 Produtos e Serviços Disponibilizados nos Meios de Captura

A amplitude do mercado de cartões e do elevado número de portadores de cartões


(72% da população possui algum tipo de cartão de pagamento na carteira (ABECS, 2012d)),
propiciou aos adquirentes identificarem novas oportunidades em suas redes, além dos
tradicionais cartões de crédito e débito. Estas eram anteriormente subutilizadas, devido não
aproveitarem todo o potencial e recursos da infraestrutura oferecidos.

Um modelo básico de terminal POS, possui um processador ARM 9, 16MB de


memória RAM e display colorido (INGENICO, 2012), além de diversas combinações de
conectividade (i.e.: SDLC, GPRS, Ethernet, WIFI). Com a melhoria dos serviços de
telecomunicações e maior oferta e disponibilidade (BRASIL MAIOR, 2012), os terminais
podem tirar proveito dessa infraestrutura para realizar mais do que transações de crédito e
débito. Oferecendo os mais diversos serviços e produtos, tais como:

 Recarga de Celular: substituindo os antigos bilhetes físicos, os terminais


eletrônicos permitem tanto a impressão de códigos contendo crédito (modo
offline) quanto à inserção de crédito direto na linha (modo online). Não
25

havendo mais necessidade do lojista ter de fazer previsão de vendas e tendo


de realizar a compra antecipadamente – pagando apenas pelo que foi
realmente vendido e possuindo estoque infinito, já que este é virtual
(GETNET, 2012b).

 Correspondente Bancário: propicia aos estabelecimentos comerciais a


realização de transações bancárias, antes realizadas apenas em agências
conveniadas, tais como pagamento de títulos e boletos (GRISI, 2012).

 Promoções: substituindo os antigos cupons de papel, os quais eram


devidamente distribuídos e preenchidos pelos clientes, sendo posteriormente
depositados em uma urna. Exigindo todo um esquema logístico para
recolhimento ao longo do Brasil inteiro e então realização do sorteio. A rede
de postos de combustíveis Ipiranga adotou o formato eletrônico, utilizando o
mesmo terminal para outros tipos de transações. Neste novo formato não há
problemas de logística, além de ser eficiente ainda preserva a natureza
(IPIRANGA, 2012).

Estes são apenas alguns exemplos de soluções incorporadas nos terminais


eletrônicos. O intuito desse trabalho não é detalhar todos os casos de estudos implementados,
apenas mostrar que as redes adquirentes podem agregar muito mais valor, incorporando os
mais variados produtos e serviços.

2.5 ISO 8583: Especificação de Mensagens de Intercâmbio

Há diversos tipos de transações, produtos e serviços providos digitalmente, todos


com um volume muito significativo e que a cada ano apresenta números ainda mais
expressivos. Mas o que realmente está por trás de toda essa infraestrutura, fazendo com que o
dinheiro seja virtualmente movimentado entre instituições, estabelecimentos comerciais e
consumidores é a norma ISO 8583 Financial transaction card originated messages —
Interchange message specifications.

Quando uma transação de compra é realizada em um terminal POS ou quando um


saque é realizado em um caixa eletrônico (ATM), é muito provável que uma mensagem ISO
8583 tenha sido utilizada nos bastidores.

A ISO 8583 especifica um padrão de mensagens pelo qual transações financeiras


originadas por cartões possam ser trocadas entre adquirentes e emissores de cartões. A norma
26

especifica a estrutura da mensagem, formato e conteúdo, elementos de dados e valores de


elementos de dados (ISO, 2012, tradução nossa).

A primeira versão elaborada da norma foi publicada em 1987, sendo este o padrão
adotado pelas bandeiras VISA e MasterCard. Versões posteriores foram lançadas em 1993,
sendo este padrão utilizado pela bandeira AMEX, e 2003 (MASTERCARD, 2010). Em
virtude disso, a grande adoção do mercado reflete-se na ISO8583:1987.

Os três maiores esquemas mundiais de cartões de crédito, VISA, MasterCard e


American Express – 52.4%, 32.8% e 11.2% de marketshare na respectiva ordem
(NERDWALLET, 2012), baseiam seus sistemas de autorização na ISO 8583
(MASTERCARD, 2010; BUGAJSKI; SMEDT, 2007).

Segundo a MasterCard (2010), entre os principais benefícios da adoção da ISO 8583-


1987 estão:

 Há diversos programas existentes operando nesse padrão,

 Flexibilidade: clientes podem usar a mesma interface como gateway para


outras redes de cartões, diminuindo custos e desenvolvimento de novos
interpretadores de mensagens.

 Capacidade: esse tipo interface permite aos clientes ampla vantagem nas
redes existentes para troca de mensagens, com alto nível de desempenho.

 Funcionalidade: redes nacionais e internacionais desenvolvidas utilizando


como base o mesmo protocolo.

Onde quer que uma transação seja feita, os dados dela são transportados de um
sistema para outro. Por exemplo, uma transação realizada em um posto de gasolina, parte do
terminal eletrônico contido no estabelecimento comercial para a rede do adquirente. Da rede
do adquirente ela é enviada para a rede do banco emissor do cartão, podendo ainda ter sido
transportada por outras redes ou sistemas intermediários antes de chegar ao seu destino final.
As mensagens transmitidas transportam dados pertinentes a transação, tais como o tipo da
transação realizada, número do cartão, valor da transação, senha do portador dentre outros
(MASTERCARD, 2012c).
27

Terminal POS Host Adquirente

0200 - requisição

0210 - resposta

0202 - confirmação

Figura 2.7 – Exemplo de troca de mensagens de transação financeira


Fonte: baseado em GetNet (2010, p.152)

A mensagem de resposta, contendo uma autorização ou declinação, faz o caminho


inverso, imprimindo um comprovante (transação autorizada) ou exibindo uma mensagem de
erro (transação declinada), (MASTERCARD, 2012c). A Figura 2.7 ilustra o fluxo de troca de
mensagens entre o terminal POS e o host do adquirente. Do host adquirente para a rede de
autorização, e da rede de autorização para o emissor, o fluxo de mensagens ocorre da mesma
forma. A Figura 2.8 demonstra o ciclo completo do processo de autorização VISA, com todos
os membros participantes do processo.

Figura 2.8 – Ciclo de uma autorização


Fonte: Bugajski e Smedt (2007)

A Figura 2.9 ilustra a composição estrutural de uma mensagem ISO 8583, sendo esta
composta pelas seguintes partes:

 Header: é o cabeçalho da mensagem. A utilização deste campo varia de rede


para rede (tanto em conteúdo quanto em tamanho) e não é especificado na
ISO 8583.
28

 Message Type Identifier (MTI): é o identificador de tipo da mensagem. Este


campo indica o tipo da mensagem (i.e.: financeira, administrativa e etc.).

 Primary Bitmap: é o primeiro mapa de bits da mensagem. Indica quais bits


(elementos de dados) estarão presentes na área de campo de dados (data
elements), do bit 1 ao 64.

 Secondary Bitmap: é o segundo mapa de bits da mensagem. Indica quais bits


(elementos de dados) estarão presentes na área de campo de dados (data
elements), do bit 65 ao 128.

 Data elements: contém os elementos da mensagem (i.e.: campo valor da


transação, número do cartão, data, hora e etc.). Os valores contidos nessa área
de dados correspondem aos bits que estão ligados no primeiro e segundo
mapa de bits.

Message type Primary Secondary


Header Data elements
identifier bitmap bitmap

Figura 2.9 – Estrutura de uma mensagem ISO 8583


Fonte: do Autor

2.5.1 Cabeçalho da Mensagem

Em algumas implementações, as mensagens devem incluir um cabeçalho (header)


antes do identificador do tipo da mensagem (message type identifier). As implementações
típicas são informações para roteamento das mensagens e tamanho do pacote ISO.

No caso do tamanho, é comum sua inclusão quando a mensagem for trafegada entre
sistemas. Utilizando dois bytes (binary unsigned integer) com o tamanho total do pacote. Essa
implementação facilita a interpretação da mensagem, pois a primeira validação realizada será
se o tamanho expresso corresponde ao do buffer recebido.
29

2.5.2 Identificador do Tipo da Mensagem (MTI)

Esse campo é composto por 4 dígitos numéricos, os quais classificam a mensagem


em alto nível. Cada dígito corresponde a um subcampo com significado específico. A Tabela
2.1 explica os subcampos, utilizando como exemplo o valor “0110”.

Tabela 2.1 – Composição do MTI


Posição Descrição Significado
0xxx Versão da ISO 8583 Versão 1987
x1xx Classe da mensagem Mensagem de autorização
xx1x Função da mensagem Resposta de requisição
xxx0 Origem da comunicação Adquirente
Fonte: baseado na ISO (1993, p.3).

2.5.3 Versão da Mensagem ISO 8583

A primeira posição do MTI especifica a versão da ISO 8583 utilizada para transmitir
a mensagem. A Tabela 2.2 especifica os possíveis valores e seus respectivos significados.

Tabela 2.2 – MTI Posição 01: Versão da mensagem


Posição Significado
0xxx Versão ISO 8583:1987
1xxx Versão ISO 8583:1993
2xxx Versão ISO 8583:2003
3xxx Reservado para uso da ISO
4xxx Reservado para uso da ISO
5xxx Reservado para uso da ISO
6xxx Reservado para uso da ISO
7xxx Reservado para uso da ISO
8xxx Reservado para uso nacional
9xxx Reservado para uso privado
Fonte: baseado na ISO (1993, p.3).

2.5.4 Classe da Mensagem

A segunda posição do MTI indica o propósito geral da mensagem. A Tabela 2.3


especifica os possíveis valores e seus respectivos significados.
30

Tabela 2.3 – MTI Posição 02: Classe da mensagem


Posição Significado Utilização
x1xx Autorização Dual message system (i.e.: autorização de crédito)
x2xx Financeira Single message system (i.e.: autorização de débito)
x3xx Modificação Adicionar, alterar, substituir ou deletar mensagem
x4xx Reversão Reversão de transações
x5xx Reconciliação Transação de reconciliação
x6xx Administrativas Transação administrativa
x7xx Taxas Cobrança de taxas
x8xx Gerenciamento da Rede Mensagens de rede (troca de chaves, logon)
x9xx Reservado para ISO Uso reservado
Fonte: baseado na ISO (1993, p.3).

2.5.5 Função da Mensagem

A terceira posição do MTI especifica a função da mensagem, que define como o


fluxo da mensagem deve ocorrer dentro do sistema. Requisições (requests) são mensagens de
fim-a-fim (i.e.: do terminal para o host do adquirente, e de volta, possuindo tempo limite para
ser respondida e reversão automática quando este atingido). Enquanto que avisos (advices)
são mensagens de ponto-a-ponto (i.e.: do terminal para o adquirente, do adquirente para a
rede, da rede para o emissor), com transmissão garantida em cada link, porém não
necessariamente de imediato (elas acontecerão em algum momento). A Tabela 2.4 especifica
os possíveis valores e seus respectivos significados.

Tabela 2.4 – MTI Posição 03: Função da mensagem


Posição Significado
xx0x Requisição
xx1x Requisição – resposta
xx2x Aviso
xx3x Aviso – resposta
xx4x Notificação
xx8x Reconhecimento de resposta
xx9x Negativo de reconhecimento
Fonte: baseado na ISO (1993, p.3).
31

2.5.6 Origem da Comunicação

A quarta posição do MTI define a localização da fonte da mensagem na cadeia de


pagamento. A Tabela 2.5 especifica os possíveis valores e seus respectivos significados.

Tabela 2.5 – MTI Posição 04: Origem da comunicação


Posição Significado
xxx0 Adquirente
xxx1 Adquirente – repetição
xxx2 Emissor
xxx3 Emissor – repetição
xxx4 Outro
xxx5 Outro – repetição
Fonte: baseado na ISO (1993, p.3).

2.5.7 Mapa de Bits da Mensagem

Dentro da ISO 8583, um mapa de bits (message bitmap) é um campo ou um


subcampo dentro de uma mensagem que indica quais outros elementos de dados ou
subcampos de dados podem estar presentes em outro local na mensagem. Uma mensagem
contém no mínimo um mapa de bits, chamado primary bitmap, o qual indica quais elementos
de dados entre 1 e 64 estão presentes. Um segundo mapa de bits também pode estar presente,
geralmente como data elemento 1 e indicando quais elementos entre 65 e 128 estarão
presentes.

Há ainda um terceiro mapa de bits especificado, porém o mesmo caiu em desuso.


Originalmente reservado para transportar elementos de dados de transações com cartões com
chip, este foi posteriormente substituído pelo elemento de dados 55 – o qual utiliza o padrão
BER-TLV (baseado em tag, length e value) para transporte de toda a informação originada da
transação com smartcard (EMVCO, 2011).

Cada mapa de bits é composto de 8 bytes (64 bits representados por cada mapa),
sendo estes transmitidos no formato hexadecimal (0-F). No bitmap, cada bit representa a
presença ou ausência do dado na mensagem. Se o bit estiver ligado, o campo de dado estará
presente na mensagem, se não estiver ligado, o campo de dado não estará presente. A Tabela
2.6 exemplifica um mapa de bits e seus respectivos campos presentes, enquanto a Tabela 2.7
detalha o primeiro mapa de bits contido na tabela 2.6.
32

Tabela 2.6 – Exemplo de mapa de bits


Mapa de Bits Elementos presentes
B2 38 04 00 20 E0 02 00 Campos: 1, 3, 4, 7, 11, 12, 13, 22, 35, 41, 42, 43 e 55
42 10 00 11 02 C0 48 04 Campos: 2, 7, 12, 28, 32, 39, 41, 42, 50, 53 e 62
80 00 00 00 00 00 00 01 Campos: 1 e 64
Fonte: do Autor.

Tabela 2.7 – Mapa de bits detalhado (binário)


Binário Hexadecimal Determina a presença do(s) campo(s)
10110010 0xB2 1, 3, 4 e 7
00111000 0x38 11, 12 e 13
00000100 0x04 22
00000000 0x00 -
00100000 0x20 35
11100000 0xE0 41, 42 e 43
00000010 0x02 55
00000000 0x00 -
Fonte: do Autor.

2.5.8 Elementos de Dados da Mensagem

Elementos de dados da mensagem (também chamados de bits da mensagem) são


campos individuais que transportam alguma informação da transação. Cada elemento de dado
possui um significado e formato previamente definido. A ISO 8583 também inclui alguns
elementos de dados de uso geral (private use), que podem ser utilizados de diferentes formas
e propósitos. A implementação destes campos privados torna a ISO 8583 adotada uma
variação do padrão definido originalmente, pois sua utilização e conhecimento ficarão restrito
aos membros participantes do esquema. A Tabela 2.8, relaciona alguns campos padrões de
dados da mensagem (ISO, 1993, p.16).

Tabela 2.8 – Exemplo de elementos de dados


Bit Nome do Elemento de Dados
2 Número do cartão
4 Valor da transação
7 Data e hora da transmissão
35 Trilha 2
55 Dados ICC
Fonte: baseado na ISO (1993, p.15).
33

Assim como toda a estrutura da mensagem constitui um padrão, alguns campos de


dados transportam informações obedecendo a outros padrões estabelecidos. Por exemplo, o
bit 35 (trilha 2) segue a ISO 7811 e o bit 49 (código da moeda corrente) segue a ISO 4217.

2.5.9 Formato dos Elementos de Dados

Cada elemento de dados é especificado em um formato padrão que define o conteúdo


permitido do campo (numérico, binário e etc.) e o tamanho do campo (fixo ou variável), de
acordo com a Tabela 2.9.

Tabela 2.9 – Formato dos elementos de dados


Abreviação Significado
a Alfa, incluindo espaços
n Numérico
s Caracteres especiais
an Alfanumérico
as Alfa e caracteres especiais
ns Numérico e caracteres especiais
ans Alfanumérico e caracteres especiais
b Binário
h Hexadecimal
z Trilhas 2 e 3 do cartão
. ou .. ou ... Tamanho de campo variável
x ou xx ou xxx Tamanho de campo fixo ou tamanho máximo do campo
Fonte: baseado na ISO (1993, p.14).

2.5.10 Tamanho dos Campos de Elementos de Dados

Adicionalmente, cada elemento de dados possui um tamanho fixo ou variável. Se for


variável, o campo será precedido pelo indicador do tamanho do campo. A Tabela 2.10
descreve os possíveis formatos para indicação de tamanho dos elementos de dados.

Tabela 2.10 – Especificação do tamanho dos campos de elementos de dados


Tipo Significado
Fixed Campo deve obedecer o tamanho indicado, não é utilizado indicador de
tamanho
LLVar ou Quando LL < 100, significa que dois dígitos especificam o tamanho do
(..xx) campo VAR (00 a 99)
LLLVar ou Quando LLL < 1000, significa que dois dígitos especificam o tamanho do
(...xxx) campo VAR (000 a 999)
Fonte: baseado na ISO (1993, p.14).
34

A Tabela 2.11 relaciona alguns elementos de dados com seus respectivos formatos e
atributos.

Tabela 2.11 – Especificação de elementos de dados


Bit Nome do Elemento de Dados FormatoAtributo
2 Número do cartão LLVAR n..19
3 Código de processamento n6
35 Trilha 2 LLVAR z..37
41 Identificação do terminal ans 8
52 Número de identificação pessoal (senha) b8
104 Descrição da transação LLLVAR ans...100
Fonte: baseado na ISO (1993, p.15-18).

2.5.11 Codificação de Dados

A ISO 8583 não normatiza a utilização de um sistema de representação de caracteres


para codificação da mensagem, tais como ASCII, BCD ou EBCDIC. A adoção de um padrão
fica a critério dos sistemas e programas da rede que se comunicarão. Este trabalho não tem
por objetivo detalhar todas as diferenças entre um padrão e outro, apenas referenciar a
existência dos padrões e que um mesmo dado pode ser codificado e interpretado de diferentes
formas (ASCII ...2012; IBM, 2012).

A Tabela 2.12 demonstra os diferentes valores de um mesmo dado em diferentes


codificações.

Tabela 2.12 – Exemplo de codificação de caracteres


Codificação Valor
Decimal 46
Binário 00101110
Hexadecimal 2E
BCD 0100 0110
ASCII 34 36
EBCDIC F4 F6
Fonte: do Autor.

O APÊNDICE A contém um exemplo de intercâmbio de mensagem, incluindo fluxo


transacional, mapa de bits, dump da mensagem de requisição e resposta e análise dos dados
trocados entre um terminal POS e um host.
35

2.5.12 Elementos de Dados Customizáveis

A ISO 8583 é bastante flexível e permite a customização de campos específicos, para


utilização proprietária. Esse recurso facilita a adoção e permite que empresas adotem a norma
original, possuindo ainda margem para a personalização de seus produtos, ou mesmo para
enriquecer as mensagens transportando dados úteis ao seu negócio (MASTERCARD, 2010).

Para tal, a ISO definiu alguns intervalos de elementos de dados como reservados para
uso próprio (RFU – reserved future use) e também para uso privado. Os campos reservados,
são listados na norma com formato e atributo definidos – dessa forma, mesmo com a
customização, é preservado a originalidade especificada e mantido interoperabilidade. Dessa
forma, um sistema pode processar uma mensagem, mesmo não interpretando o conteúdo de
determinado campo, mantendo a interoperabilidade. A Tabela 2.13 contém a relação dos
elementos de dados reservados e seu respectivo destino, formato e atributo.

Tabela 2.13 – Elementos de dados reservados para uso futuro


Bit Nome do Elemento de Dados Formato Atributo
47 Dados adicionais - nacional LLLVAR ans...999
48 Dados adicionais – privado LLLVAR ans...999
60 Reservado para uso nacional LLLVAR ans...999
61 Reservado para uso nacional LLLVAR ans...999
62 Reservado para uso privado LLLVAR ans...999
63 Reservado para uso privado LLLVAR ans...999
65 Reservado para uso da ISO b 8
111-115 Reservado para uso da ISO LLLVAR ans...999
116-122 Reservado para uso nacional LLLVAR ans...999
123-127 Reservado para uso privado LLLVAR ans...999
Fonte: baseado na ISO (1993, p.15-18).

2.5.13 Fluxos de Mensagens

A norma ISO 8583 prevê também os fluxos que as trocas de mensagens devem
seguir. Indicando quais mensagens originadas devem ser respondidas, quais mensagens
respondidas devem ser confirmadas e também o comportamento a ser seguido caso ocorra
uma falha no processo. A Figura 2.10 ilustra as possíveis sequências de fluxos para transações
de classe “x1xx”, “x2xx” e “x4xx”.
36

Início

Autorização

Financeira

Legenda:

Reversão Estorno Transação

Fluxo em que a
transação deve ocorrer
Fluxo em que a
transação pode ocorrer
FIM

Figura 2.10 – Fluxo transacional


Fonte: baseado na ISO (1993, p.48)

De forma resumida, há três tipos de fluxos:

 Apenas envio: é o caso de mensagens de repetição e notificação, o qual


determinada entidade reenvia uma mensagem já submetida anteriormente ou
apenas notifica o host de determinado comportamento na rede.

 Requisição e resposta: ocorre na maioria dos casos (mensagens de


autorização, aviso, reversão, administrativa, gerenciamento de rede), no qual
uma parte envia uma requisição e recebe como retorno uma resposta da
requisição.

 Requisição, resposta e confirmação: em alguns casos é estabelecida a


necessidade da transação ser confirmada no exato momento em que é
processada, garantindo que a resposta foi recebida corretamente. Para tal,
após recebimento da resposta, a parte requisitante deve enviar a confirmação
da resposta recebida à parte que a respondeu.
37

2.5.14 Padrões de Mensagens

A ISO especifica templates de mensagens, que podem ser utilizados como base para
elaboração das mensagens utilizadas nas redes de determinado programa. Para cada função de
mensagem, há um mapa indicando quais bits devem existir em cada fluxo de troca de
mensagens. A Tabela 2.14 ilustra todas as possíveis mensagens num fluxo administrativo e
seu respectivo conteúdo.

Tabela 2.14 – Template de mensagem administrativa


Mensagem Administrativa Identificador do Tipo de Mensagem (MTI)
Bit Elemento de dados 1604 1614 1624 1634 1644
1605 1625
1 Mapa de bits secundário
11 NSU do terminal M ME M ME M
12 Data e hora local M ME M ME M
24 Código da função M M M
33 Código instituição envio 10 10 10 10 10
39 Código de resposta M M M M
59 Dados de transporte 16 16
72 Dados gravados M M M
93 Código instituição destino M ME M ME M
94 Código instituição origem M ME M ME M
100 Código instituição recebida 19 19 19 19 19
Fonte: baseado na ISO (1993, p.25).
Para cada campo da mensagem é utilizada a seguinte convenção:

 Mandatório (M): presença mandatória ou condicional, caso o dado exista


deve ser enviado junto na mensagem.

 Opcional (O): indica que o dado pode estar presente ou não, de acordo com
condições dadas.

 Mandatório Eco (ME): repete o mesmo valor. Se o campo for opcional e


estiver ausente na mensagem anterior, também estará ausente nesta. Para
transações de 3 pernas, a mensagem de resposta deverá ecoar valores da
mensagem de requisição enquanto a mensagem de confirmação deverá ecoar
valores da mensagem de resposta.
3. ANÁLISE DE FERRAMENTAS

No cenário atual, cada instituição adota sua respectiva implementação da ISO 8583
para intercâmbio de mensagens. No caso do adquirente, seu protocolo é utilizado entre seus
terminais até os seus respectivos hosts, havendo comunicação externa (com outras
instituições), normalmente é realizado uma adaptação de templates, para que ambas as
instituições troquem informações através de um protocolo único. Fazendo com que, dessa
forma, uma única transação durante seu ciclo de vida, possa trafegar por diferentes sistemas,
tendo seu conteúdo modificado, complementado, formatado em diferentes padrões de
codificação, com dados criptografados e descriptografados, para então chegar ao seu destino,
podendo repetir todo o processo ao realizar o caminho inverso.

A Figura 3.1 ilustra exatamente essa situação, enquanto o terminal “A” possui uma
aplicação para um produto específico, o terminal “B” possui uma segunda aplicação
contemplando outro produto. Ambos se comunicam com o mesmo Host Adquirente, sendo
este responsável por tratar e interfacear as transações com os demais Autorizadores e suas
respectivas redes.

Template 3
MasterCard

Template 1
A Template 4
Visa

Template 5
Private Label
Template 2
B
Template 6
Recarga Celular

Terminais Host Adquirente Autorizadores

Figura 3.1 – Integração entre diferentes templates


Fonte: do Autor

Com a disponibilização de novos produtos e serviços na rede adquirente ao longo do


tempo, novas aplicações para terminais POS vão surgindo, bem como sistemas e interfaces
com novos autorizadores nos sistemas adquirentes. Consequentemente, o número de
templates, padrões e fluxos de mensagens também – aumentando a complexidade da rede.
39

3.1 Exemplos de Customizações da ISO 8583

As customizações são fundamentais, pois propiciam aprimorar os produtos com base


no negócio no qual estão emersos. Os terminais deixaram de atender apenas cartões de crédito
e débito e se tornaram pontos de serviço – junto disso surgiu à necessidade de ter maior
flexibilidade para atender novos produtos, na mesma escala que estes são criados.

Com base nas soluções de mercado analisadas, foram encontradas soluções de


customização aderentes à norma proposta pela ISO 8583 e também soluções diferentes do
padrão proposto. De forma que, é possível encontrar no mercado, soluções derivadas do
padrão ISO 8583, mais ainda aderentes à norma (mantendo a interoperabilidade) e também
soluções com muitas discrepâncias em sua implementação – seguindo em parte os padrões
estipulados.

3.1.1 Customização Padrão ISO 8583

Um dos problemas reportados pela empresa GetNet (GALHO, 2013), foi a questão
de possuir um grande parque de terminais instalados, com diversos clientes oferecendo os
mais diferentes produtos. Como há uma dificuldade técnica e alto custo para atualizar as
aplicações dos terminais em campo e novos produtos são lançados em curtos espaços de
tempo, para produtos de prateleira foi adotada a solução de conteúdo dinâmico – ficando a
cargo do host configurar e atualizar os terminais.

Entre esses conteúdos, encontra-se o comprovante de transações. Os tickets


impressos pelos terminais POS, são formatados (tamanho e disposição de caracteres)
remotamente. Dessa forma, é possível flexibilizar o conteúdo dos comprovantes de acordo
com a necessidade do cliente (seja provendo mensagens promocionais, destacando produtos,
número de vias e etc.).

De acordo com a tabela 2.13, os bits 62 e 63 são reservados para uso privado. Em
uma de suas implementações, a GetNet utiliza esses mesmos dois campos para formatar o
comprovante e mensagens de display das transações dinamicamente. Dessa forma não há
necessidade de alterar a aplicação do terminal POS apenas para editar o conteúdo de um
comprovante específico – ficando a cargo do host o conteúdo e formatação do mesmo
(GETNET, 2011, p.69).

A Figura 3.2 contém um exemplo de implementação customizada, aderente aos


padrões ISO 8583. Nesse caso, uma string é enviada na mensagem de resposta para o terminal
40

POS (campo de dados 62), decorrente de uma transação autorizada. Já a Figura 3.3 demonstra
o resultado obtido no terminal (display e comprovante).

Figura 3.2 – Exemplo de implementação customizada da ISO 8583


Fonte: baseado em GetNet (2011, p.90)

Figura 3.3 – Exemplo de customização


Fonte: baseado em GetNet (2011, p.90)

Dessa forma, é possível customizar produtos e serviços, provendo conteúdo


dinâmico diferenciado para cada um deles, ainda com a possibilidade de modificá-los a
qualquer momento, sem necessidade que este seja definido de maneira fixa. Essa
implementação trata de fins específicos, não previstos pela norma, mas ainda assim
mantendo-se em conformidade com o padrão ISO 8583.
41

3.1.2 Customização Opoente ao Padrão ISO 8583

Foram encontradas também algumas customizações implementadas adversas aos dos


padrões pré-estabelecidos pela ISO 8583. Essas personalizações seguem boa parte das
recomendações da norma, mas em algum momento transgridem outras.

A Tabela 3.1 ilustra um mapa de bits de mensagem administrativa, também utilizado


pela GetNet em uma de suas aplicações de terminais POS.

Tabela 3.1 – Exemplo de template de mensagem customizado


Bit 0700 0710 Tamanho Tipo Descrição
1 M - 16 b Segundo mapa de bits
3 M ME 6 n Código de processamento
7 M M 10 n Data e hora GMT
11 M ME 6 n NSU local
32 M ME LL..11 n Código da operadora
33 O - LL..2 n Dados conectividade
39 - M 2 n Código de resposta
40 M - 3 n Versão da mensagem
41 M ME 8 a Identificação do terminal
42 M ME 15 n Código do EC
43 M - LL..99 n Número de série do terminal
48 - M LLLVAR a Produtos habilitados
62 - O LLLVAR a Dados dinâmicos
71 M - 8 n Versão da aplicação
128 O - LLLVAR n Dados da autocarga
Fonte: baseado em GetNet (2010, p.158).

As diferenças encontradas entre a norma ISO 8583 e a implementação contida na


figura 3.4 são:

 Classe da mensagem: de acordo com a tabela 2.3 o código "0700" indica uma
mensagem de classe "Taxas", enquanto a norma dedica para transações
administrativas o código “0600” e o código “0800” para gerenciamento de
rede.

 Campos de dados: os campos 33, 39, 40, 71 e 128 não são utilizados como
especificados pela ISO 8583, transportando conteúdo diferente dos previstos
– alguns deles possuem tamanhos diferentes dos especificados na norma.
42

Este tipo de implementação não se caracteriza como errada, ou ainda incorreta, mas
sim como uma especificação proprietária baseada na ISO 8583. Um dos problemas
ocasionados neste tipo de implementação é a baixa interoperabilidade.

3.2 Soluções de Mercado

Atualmente as instituições financeiras dispõem de algumas soluções, que permitem


simular e emular ambientes transacionais. Essas ferramentas possibilitam a automação de
grande parte dos testes de suas plataformas, garantindo que seus sistemas de pagamentos
sejam confiáveis e livres de erros.

Entre os tipos de soluções encontradas estão, as de proprietários de grandes


esquemas de cartões de pagamento – disponíveis exclusivamente para uma única bandeira e
plataforma; as de provedoras de soluções para meios de pagamento, que se caracterizam
principalmente por se integrarem as suas respectivas plataformas comercializadas; e também
as soluções sob encomenda, esta última sendo especificada por uma instituição e desenvolvida
por uma empresa terceira.

As soluções oferecidas pelas principais bandeiras de cartões (MasterCard, VISA e


AMEX), caracterizam-se principalmente por serem soluções fechadas, com baixa
flexibilização e quase nenhuma customização – esse tipo de ferramenta é de uso exclusivo ao
esquema pertencente (contempla apenas produtos oferecidos por este). A comercialização de
cada aplicação é realizada diretamente com cada bandeira, além de possuir um alto custo,
estão disponíveis apenas para os membros filiados. O foco desse tipo de solução são os
milhares de emissores e adquirentes ao redor do mundo, que necessitam desenvolver e testar
seus produtos. Utilizando estas soluções uma instituição pode realizar testes simulando a outra
(adquirente pode simular o emissor e vice-versa).

Os principais provedores de soluções de meios de pagamento, também oferecem


produtos para auxiliar no desenvolvimento e testes de produtos de pagamento. Entre eles
estão a ACI Worldwide6 e a Paragon Application Systems7. Ambas possuem soluções de
renome e que suportam os principais esquemas de cartões, formatos de mensagem principais
tecnologias encontradas no mercado. Os principais pontos negativos da adoção destas
ferramentas são o alto custo de adoção, implementação e principalmente customização.

6
http://www.aciworldwide.com
7
http://www.paragonedge.com
43

Como ambas as empresas são fornecedoras de soluções robustas para processamento


de transações eletrônicas, a adoção exclusiva de uma ferramenta de simulação implica
diretamente em um maior custo de implementação. Principalmente pelo fato de não haver um
contrato de manutenção e suporte existente – a contratação exclusiva de suporte para um
único produto eleva bastante o preço da solução num todo. Mais importante ainda é o fato das
soluções serem de prateleira – a mesma solução é ofertada no mundo inteiro e o foco são os
produtos das grandes bandeiras.

Como o mercado brasileiro é bastante segmentado e diversificado, a adoção de uma


plataforma com estas características, exige muita customização (e customização exige tempo
e muitas horas de contrato de manutenção, resultando em valores bem expressivos), pois estas
aplicações não são adaptadas ao mercado brasileiro, vide produtos como recarga de celular e a
ampla variedade de cartões private label existentes.

Dependendo da necessidade e do tipo de negócio, a rentabilidade gerada não justifica


a adoção de tal solução, principalmente quando não houver tanta complexidade envolvida,
sendo mais econômico investir numa equipe dedicada a testes manuais ou ainda na
terceirização de equipes especializadas.

Por último, há as soluções sob demanda, sendo estas desenvolvidas por empresas que
conhecem e atuam no mercado brasileiro. Dada a diversidade e necessidade variada do
mercado brasileiro, tais soluções são implementadas de acordo com as necessidades dos
clientes. Para isso, elas devem ser especificadas para então serem precificadas, seguidas de
desenvolvimento, testes, implementação e integração.

Apesar deste tipo de solução também possuir um custo significativo, ainda assim
pode ser mais atraente que as soluções comercializadas pelas grandes provedoras de soluções
de pagamento. Os custos com customização são menores e a flexibilidade é maior, já que a
ferramenta é desenvolvida para integrar-se a um negócio específico. O principal contra é o
tempo necessário para a implementação deste tipo de solução e a real efetividade em sua
utilização. Dentre as empresas nacionais que desenvolvem soluções customizadas para esse
tipo de negócio, estão a SOFTWARE EXPRESS8 e a SETIS9.

8
http://www.softwareexpress.com.br/
9
http://www.setis.com.br
44

3.2.1 MasterCard Simulator Suite

A MasterCard disponibiliza duas suítes de simuladores, sendo eles o MasterCard


Authorization Simulator (MAS) e o MasterCard Debit Financial Simulator (MDFS). Ambas
as ferramentas tem o propósito de simular ambientes transacionais, evitando a necessidade de
que testes sejam realizados utilizando uma infraestrutura real. Isso é muito importante, pois
realizar testes com uma infraestrutura completa implica em reservar janela de testes com a
bandeira (alto custo e tempo limitado) e também com um emissor (no caso do adquirente), no
caso do emissor há a necessidade de reservar janela com algum adquirente.

Ambos os produtos utilizam o padrão de mensageria ISO 8583:1987, provendo aos


membros a capacidade de realizar extensivos testes de preparação online em um ambiente
offline (MASTERCARD, 2005, p.15).

Os simuladores compreendem todos os produtos oferecidos pela bandeira (cartões de


tarja magnética, com chip, contactless, e-commerce e etc.) e por padrão, possuem todos os
templates de testes de preparação e certificação cadastrados – possibilitando aos membros
também o cadastro de casos adicionais. As Figuras 3.4 e 3.5 ilustram o funcionamento dos
simuladores na modalidade adquirente e emissor.

Figura 3.4 – Simulador MasterCard como adquirente


Fonte: MasterCard (2005, p.16)

Figura 3.5 – Simulador MasterCard como emissor


Fonte: MasterCard (2005, p.16)
45

A parametrização do simulador é realizada através de templates e baseado em


elementos de dados da transação (i.e.: valor, número do cartão). Dessa forma, podem-se obter
determinadas respostas condicionadas aos dados contidos na mensagem. A MasterCard
também exige a utilização de seus simuladores para gerar evidências de produtos antes de
estes migrarem para produção.

A Figura 3.6 ilustra a tela principal do simulador de débito (o de crédito é bastante


similar). No caso de este estar configurado em “modo emissor” (simulando respostas de um
instituição emissora de cartões), na tela de resultados é possível observar todos os campos da
mensagem enviada para a rede (MasterCard network) e também da rede para o emissor (e
vice-versa) de modo detalhado.

Figura 3.6 – Simulador MasterCard débito – tela de resultados


Fonte: MasterCard (2005, p.31)

Esta ferramenta é bastante conveniente e de suma importância para instituições que


capturam, processam ou autorizam transações MasterCard.
46

3.2.2 VISA Test System

Assim como no caso da MasterCard, a VISA também oferece uma solução para seus
membros simularem sua plataforma transacional, tanto o lado emissor como o adquirente.
Com o VISA Test System (VTS) é possível montar casos de testes para cada tipo de produto
específico, com respostas de acordo com a respectiva necessidade. O maior inconveniente, se
comparada à solução MasterCard, é a ausência de templates pré-definidos, prontos para uso.

A Figura 3.7 demonstra um caso de teste implementado. No quadro à esquerda da


figura consta o nome do caso (case 1), contendo as respectivas mensagens, enquanto no
quadro a direita consta a parametrização do mesmo.

Figura 3.7 – Simulador VISA VTS: Interface


Fonte: VISA (2012b, p.80)

Assim como na suíte de simuladores MasterCard, a personalização de templates e


casos de teste no VTS fica restrita aos produtos da bandeira VISA, não sendo possível a
customização para outros negócios.

3.2.3 ACI Payment Testing (ASSET)

A ACI WorldWide fornece soluções de pagamentos eletrônicos e bancários para


mais de 1650 instituições financeiras, lojistas e processadores de todo o mundo. Seu software
permite $12 trilhões de dólares em pagamentos diários, atuando com 14 dos principais
varejistas globais e 24 dos 25 maiores bancos (ACI WORLDWIDE, 2012a).
47

Uma das soluções ofertadas pela empresa é o ACI Payment Testing (ASSET). A
ferramenta é projetada para trabalhar com todos os principais motores de pagamento de
terceiros, além de simular e testar todos os elementos da infraestrutura de pagamentos
subjacente incluindo ATM, POS e interfaces de rede.

O ASSET é um simulador para testes de fim-a-fim de sistemas de pagamento, tendo


como foco principal sistemas complexos de pagamento que se integram com diversas redes e
processam os principais produtos, protocolos e tecnologias de mercado. Entre suas vantagens
estão a possibilidade de integrá-lo com ferramentas como o HP Quality Center, testes de
performance, criação de scripts personalizados para casos de uso, conversão de protocolos de
mensagem e suporte nativo para simulação das redes Visanet, Link, Amex e Europay (ACI
WORLDWIDE, 2012b).

O ASSET é uma solução bastante completa e eficiente, porém opera como um


módulo integrado de outra solução da ACI Worldwide, o processador e roteador de transações
(para elencar apenas algumas de suas capacidades) BASE 24 – tornando sua implementação
bastante restrita, além de exigir bastante customização para o mercado brasileiro.

3.2.4 Paragon ISO 8583 Testing

A Paragon Application Systems fornece soluções de teste de software para testar


confiabilidade e integridade de sistemas de pagamentos eletrônicos. Atualmente a Paragon é o
fornecedor líder mundial de soluções para simulação e teste de comércio eletrônico. Seus
clientes possuem juntos mais de 100.000 ATMs, conectados a mais de 100 redes processando
milhares de transações por segundo. São mais de 590 clientes em 85 países, incluindo
instituições financeiras, adquirentes, processadores e emissores (PARAGON, 2012).

As soluções ofertadas pela Paragon são distribuídas em módulos específicos, cada


qual contemplando uma funcionalidade específica (ATM, POS, EMV, ISO 8583, pré-
certificação, entre outros). Seu produto dedicado a certificações de redes e simulação de
plataformas transacionais, chama-se FASTest™ for ISO10.

Entre suas características estão o suporte aos principais formatos de mensagem,


automatização de testes para adquirentes e emissores, flexibilidade e customização de scripts
e enorme foco em pré-certificações de esquemas de cartões (MasterCard, VISA, Amex e

10
http://www.paragonedge.com/products/fastest-for-iso.html
48

outros). A ferramenta suporta as principais bandeiras mundiais e ao contrário da solução da


ACI Worlwide, integra-se com as principais soluções de processamento de transações.

Em contrapartida, a solução é extremamente voltada a soluções robustas e esquemas


proprietários de cartões e pagamento eletrônico. A customização da ferramenta apenas para
atender outros esquemas menores, não se justifica em virtude do elevado custo e baixo
aproveitamento dos recursos contemplados.
4. PROPOSTA

De acordo com as soluções de mercado apresentadas, estas são sempre baseadas em


programas de cartões específicos, dedicados a atender uma única finalidade. Os simuladores
MasterCard e VISA, dedicam-se exclusivamente aos seus produtos e certificações, enquanto
as aplicações ASSET e FASTest™ for ISO são designadas a atender outros produtos
concebidos pelo mesmo fabricante ou designam-se a algumas poucas suítes de mercado (i.e.:
módulo de teste e simulação de um empresa x integra-se ao seu outro produto, um
processador de transações). Esse conceito restringe bastante a adoção, além de obrigar
clientes a usarem um único fornecedor de software e não suprir toda a sua necessidade.

A Figura 4.1 ilustra o problema que ocorre quando há mais de uma solução de
processamento de transações em um mesmo site. Com a adoção de uma aplicação integrada,
apenas uma das soluções de processamento disporá de recursos de simulação e automatização
– e estes recursos estarão emulando sempre a rede e emissores de cartões, subsistemas
utilizados antes do processador A não serão contemplados.

VISA Processador A Simulador

Processador B ?
Private Label

Figura 4.1 – Estrutura com múltiplos sistemas de processamento


Fonte: do Autor

As adequações e implementações destes tipos de soluções tornam-se longas,


burocráticas e demandam tempo e dinheiro com customizações, nem sempre atendendo a
todas as necessidades do contratante. No caso da figura 4.1, o Processador B não seria
contemplado, enquanto o Processador A disporia de todo um ambiente automatizado. O
know-how e expertise empregados não são reutilizados com os demais sistemas, que juntos
compõem uma única plataforma transacional.

Após análise do mercado e das soluções disponíveis, observa-se como principal


ponto a ausência de uma ferramenta para realização de atividades mais básicas (i.e.:
50

roteamentos, translate de templates, pequenas automatizações, experimentos e etc.) e que não


seja baseada em programas específicos. Algo genérico, flexível, de rápida implementação e o
mais importante: aderente ao mercado brasileiro. Há muita customização no mercado
brasileiro: os meios de pagamentos aqui implementados são muito diferentes dos de outras
regiões como América do Norte e Europa; encontra-se diversos produtos e serviços
eletrônicos sem a utilização de cartões (i.e.: recarga de celular e pagamento de boletos
bancários); produtos implementados diferente do restante do mundo (i.e.: pré-autorização e
venda parcelada), mensagens, fluxos e elementos de dados não aderentes ao padrão ISO 8583
(ainda que utilizem estrutura baseada na norma) operando em diversos sistemas e milhares de
cartões private labels emitidos não de acordo com a norma ISO 7813 (define padrões de
cartões magnéticos, como por exemplo, dados e composição da trilha do cartão).

Entre os sistemas e aplicações não contemplados com as soluções apresentadas, estão


os produtos locais, de menor escala, disponibilizados nos aplicativos de meios de captura
(terminais POS, TEF e ATM) e os subsistemas desenvolvidos internamente pelas empresas
adquirentes. Como cada adquirente possui uma base considerável de terminais instalados, ao
disponibilizar um novo produto ou alterar parametrizações de produtos existentes em sua
rede, faz-se necessário validar o comportamento das diferentes versões de aplicativos e
sistemas existentes.

Analisar o impacto de novos produtos, descobrindo modificações necessárias em


sistemas e aplicativos de terminais POS e TEF pode tornar-se uma atividade mais simples.
Permitindo diminuir a complexidade de grandes plataformas e tendo como foco apenas o
sistema alvo. Aplicando simulações objetivas e prevendo possíveis comportamentos na rede.

4.1 Emulador de Transações

Uma solução adequada para esse problema é a concepção de um emulador de


transações ISO 8583 ponto-a-ponto, capaz de se adaptar aos mais variados tipos de
implementações e codificações. Ao atuar como um sistema independente ou mesmo
abstraindo uma camada inteira de sistemas. Segundo Beuran (2012, tradução nossa),

emulação é uma técnica de experimentação híbrida destinada a preencher a lacuna


entre a simulação e testes reais. A idéia fundamental da emulação é reproduzir, em
tempo real e de um modo controlado a funcionalidade essencial de um sistema, de
modo que possa interagir com outros sistemas reais que podem assim ser avaliados.
Ao contrário das soluções fim-a-fim, que possuem uma finalidade específica (i.e.:
simular ambientes VISA e certificações de produtos MasterCard) e interagem com a
51

plataforma transacional como se esta fosse uma caixa preta, um sistema ponto-a-ponto
possibilita que sistemas não existentes ou funcionalidades ainda não implementadas sejam
reproduzidas – auxiliando no desenvolvimento e testes de outras aplicações individualmente.

A Figura 4.2 ilustra uma plataforma de transações eletrônicas, com diversos produtos
e serviços disponibilizados em sua rede de terminais. Os templates correspondem a
implementações distintas da ISO 8583, que são utilizadas para intercâmbio de transações dos
diversos produtos e serviços disponibilizados na rede (MasterCard, VISA, cartões Private
Labels e Recarga de Celular). Como se pode observar, há também diversos sistemas
interligados, que realizam algum tipo de processamento nas transações que por ali trafegam.

Template 3
Template 1
Redes de Autorização

Processador 1
Template 4
Sistemas de Sustentação

Template 2
Template 5, 6 e 7

Private Labels
Processador 2
Private Labels

Sistemas de Sustentação

Recarga de Celular

Figura 4.2 – Exemplo de estrutura de sistema de pagamento


Fonte: do Autor

Ainda com base na figura 4.2, a utilização de um emulador de transações ponto-a-


ponto, auxiliaria nas seguintes situações:

 Desenvolvimento de aplicativos para terminais POS: realização de testes e


validações sem a necessidade de algum sistema de processamento /
autorização (abstração total).
52

 Eliminar a necessidade de ambiente replicado para testes e desenvolvimento:


algumas partes da estrutura podem ser complexas e caras para haver mais de
uma instância operando – ou exigir licenças (abstração parcial).

 Integração de novos produtos à rede: ao iniciar o processo de integração de


sistemas com uma nova rede (i.e.: um novo private label), é possível emular a
rede previamente (antes de ela estar realmente implementada).

 Comportamentos específicos: testes de produtos específicos podem ser


facilmente obtidos, sem a necessidade de múltiplos cartões ou cadastros (i.e.:
transação declinada por falta de saldo, terminal não registrado para o produto
x, parcelamento máximo permitido com y parcelas).

Esses são alguns dos comportamentos que o emulador poderia assumir, auxiliando as
equipes de desenvolvimento e de teste de software. As possibilidades em si, são bem maiores,
desde que haja intercâmbio de mensagens ISO 8583 entre terminais, sistemas e plataformas.
Para tal, será necessário interpretar os diversos tipos de implementação da norma ISO.

4.1.1 Interpretador de Mensagens

Uma das principais funcionalidades a ser implementada, é o interpretador de


mensagens. Este deve funcionar como o "motor" do emulador de transações, pois compete a
ele decifrar os mais variados templates de mensagens, nos diferentes tipos de codificação de
caracteres possíveis. Como algumas mensagens podem conter um header antes do início da
mensagem ISO em si, a existência ou não desse campo, deve ser validado também. Caso o
tamanho do buffer esteja contido no header, é bastante conveniente confrontar o tamanho da
mensagem identificado com o tamanho do pacote recebido.

Além do tamanho do pacote, o header pode conter outras informações, como por
exemplo, de roteamento. Se for o caso, esses dados não receberão nenhum tipo de tratamento
– sendo apenas replicado (se necessário). Ao tratar o tamanho do pacote, este pode estar
codificado com o byte mais significativo à esquerda ou direita – sendo necessário tratar ambos
os tipos.

A Figura 4.3 contém uma mensagem ISO 8583 em claro (texto simples). Ao enviar
essa mensagem de resposta para o requisitante, é necessário codificá-la no mesmo formato em
que foi recebida: header (se necessário) + mensagem. No caso de utilização de header
53

simples (apenas dois bytes para tamanho), o buffer da Figura 4.4 seria precedido de “0x01
0x17”, enquanto o da Figura 4.5 seria “0x00 0x80”.

Figura 4.3 – Exemplo de mensagem de resposta


Fonte: do Autor

Caso a mensagem de requisição tenha sido recebida codificada em ASCII, a


conversão da mensagem de resposta (figura 4.3) resultará no buffer da figura 4.4. Caso a
codificação utilizada seja BCD, resultará no buffer da figura 4.5.

Figura 4.4 – Mensagem codificada em ASCII


Fonte: do Autor
54

Figura 4.5 – Mensagem codificada em BCD


Fonte: do Autor

A diferença entre o tamanho do buffer da figura 4.4 comparada a da figura 4.5, dá-se
pelo fato do padrão ASCII utilizar 01 byte para expressar cada caractere, enquanto no BCD os
campos numéricos e binários são representados por nibbles (agregação de quatro bits). A
precisão para interpretar os diferentes tipos de codificação é de suma importância, pois
qualquer equívoco acarretará em uma análise incorreta de conteúdo.

4.1.2 Ajuste de Conteúdo

Outra característica necessária é a de ajustar o conteúdo das mensagens. Seja


removendo, incrementando ou inserindo novos dados ou campos. Durante o ciclo de vida de
uma transação, os sistemas por onde esta mensagem trafega, podem modificá-la, realizando
exatamente as funções citadas anteriormente.

A Figura 4.6 ilustra exatamente essa situação, a mensagem originada do terminal


para o host A é incrementada antes de ser roteada para o host B (recebe um novo campo de
dados, elemento 61).

Inclui o campo 61

Host A Host B

Terminal

Figura 4.6 – Complementação de template


Fonte: do Autor
55

Havendo a necessidade de edição condicional, relativo ao conteúdo de algum dos


campos da mensagem recebida, para formatação da mensagem de resposta o sistema se
comportará de acordo com a Figura 4.7.

Outro valor R$ 10,00


Valor da
Transação

Aprova Declina

Figura 4.7 – Resposta de mensagem com base em conteúdo recebido


Fonte: do Autor

4.1.3 Cadastro de Elementos de Dados

A norma ISO 8583, especifica todos os 128 campos de dados da mensagem, bem
como o tipo do campo (numérico, alfanumérico e etc.). Porém há divergência entre alguns
campos, conforme a versão da norma. Por exemplo, o campo 22 (modo de entrada do cartão)
na norma de 1987 possui tamanho fixo de 3 dígitos numéricos, enquanto na norma de 1993,
seu tamanho foi ampliado para 12 dígitos.

Para evitar conflitos entre as versões da ISO 8583 e manter interoperabilidade entre
possíveis implementações divergentes dos padrões, o tamanho e formato dos campos poderá
ser tratado individualmente.

4.1.4 Translate de Templates

O translate e adaptação de templates fazem-se necessários quando determinada parte


da transação é baseada em uma implementação e a parte seguinte em outra. Nesse caso deve
haver uma adaptação para que ambas as partes consigam trocar mensagens corretamente.

Um terminal POS comunica-se com um host autorizador baseado em uma estrutura


definida de mensagens. Porém, quando esse host comunica-se com outras plataformas, há
uma adaptação de templates de mensagens para cada uma delas.
56

4.1.5 Cadastro de Casos de Teste

O sistema deverá permitir que os fluxos transacionais sejam agrupados, com base no
tipos das transações e nas características do template utilizado (padrão ISO e customizado).
Essa característica evitará parametrizações errôneas e dispensará conhecimentos técnicos
sobre a norma ISO 8583, tornando a estrutura reaproveitável.

É comum o intercâmbio de mensagens sequenciais entre dois pontos na rede (i.e.:


terminal e host). Prevendo essa situação, o sistema será desenvolvido de forma a agrupar
respostas baseadas no MTI da mensagem e em mais algum campo de dados (i.e.: valor da
transação). Dessa forma é possível ter casos semelhantes (replicados), porém com
comportamentos distintos para cada um.

Com base na Figura 4.8, cada cadastrado (003700 e 003800) possuirá seu próprio
mapa de mensagens, com seus respectivos campos de mensagem. O objetivo principal do
cadastro de casos de teste é evitar o retrabalho – evitando que um mesmo caso tenha que ser
recriado novamente. A solução será uma biblioteca, com base na implementação ISO 8583
utilizada.

MTI

0100

003700 003800
Parcelado Lojista Parcelado Emissor

Código Processamento

Figura 4.8 – Fluxo de transacional agrupado


Fonte: do Autor

4.2 Modo de Comunicação

O modo de comunicação impacta diretamente em como o emulador irá se portar. É


preterido que este opere abstraindo sistemas e plataformas transacionais inteiras. Para atender
o propósito desejado, o sistema deverá operar em dois modos distintos, um como loop-back,
no qual o sistema se comportará como um ponto final de um sistema de comunicação, e outro
57

como pass-through, onde o sistema se portará como uma ponte entre outros dois sistemas. Em
ambos os casos, possibilitando convergência entre templates, alterações, modificações,
incrementos e adaptações de dados nas mensagens ISO 8583.

4.2.1 Loop-back

No modo loop-back, o sistema substituirá uma parcela completa de sistemas, ou


ainda todos os sistemas de um ponto a outro. Pode ser observado na Figura 4.9, o emulador
abstraindo todos os sistemas participantes de uma transação. Nesse caso, o terminal se
comunicará diretamente com o emulador (para troca de mensagens ISO 8583), recebendo
diretamente dele, respostas para todas suas requisições. Aos olhos do operador do terminal, a
sensação será a mesma de que se o terminal estivesse se comunicando com todos os sistemas
da camada abstraída.

CAMADA ABSTRAÍDA

Gateway
Autorizador A
(Private Label)

Autorizador B
(Recarga de Celular)

Terminal POS Autorizador C


(Promoção XYZ)
EMULADOR
Processador Sistema de Captura Autorizador Interno
Emissores / Autorizadores
Adquirente

Figura 4.9 – Emulador em modo loop-back (abstração de todo sistema)


Fonte: do Autor

Este caso demonstra-se ideal quando há a necessidade de abstrair uma camada


completa de sistemas, por exemplo, para realizar testes focados nos aplicativos dos terminais
POS. Tanto em aplicações existentes (i.e.: validar se o comportamento de parametrizações
dinâmicas é aceito e opera de acordo com o esperado; validar se alterações em camadas de
sistemas do adquirente e emissor causa impacto na base de terminais instalados) quanto no
desenvolvimento de novos aplicativos (sendo possível emular comportamentos e
funcionalidades ainda não contemplados pelos sistemas contidos na plataforma ou que
58

deverão se integrar a mesma), sem necessidade de depender de infraestrutura interna (sistemas


adquirentes) e externa (sistemas emissores).

No caso da Figura 4.10, a abstração contempla apenas a uma entidade externa


(autorizador A), sendo esta emulada. Todos demais sistemas do lado adquirente continuam
compondo a plataforma transacional. Este comportamento tem por objetivo, auxiliar a fase de
desenvolvimento de sistemas do adquirente e auxiliar nas validações de sua estrutura
transacional. Dessa forma não há necessidade de aguardar o término da fase de
desenvolvimento do lado emissor / autorizador para iniciar validações, bem como, os sistemas
poderão se valer de um maior número de testes e confiabilidade.

CAMADA ABSTRAÍDA

Autorizador A
Gateway
(Private Label)

EMULADOR
Autorizador B
(Recarga de Celular)

Terminal POS Autorizador C


(Promoção XYZ)

Emissores / Autorizadores

Processador Sistema de Captura Autorizador Interno


Adquirente

Figura 4.10 – Emulador em modo loop-back (abstração de um único sistema)


Fonte: do Autor

Alguns exemplos de comportamentos e testes que poderiam ser facilmente atendidos


pelo emulador e que demandariam condições específicas, mesmo com o sistema desenvolvido
e integrado:

 Cartão bloqueado ou com saldo insuficiente;

 condições de parcelamento não permitido;

 condições de parcelamento atendidos;

 códigos de erro.
59

Todos os casos acimas listados exigiriam interação humana em alteração de cadastro


de determinada conta de cartão, como disposição física de diversos cartões para situações
distintas (i.e.: cartão bloqueado e sem saldo). Com o emulador, ambas as necessidades seriam
supridas e facilmente modificáveis.

4.2.2 Pass-through

Em modo pass-through, o emulador deverá realizar uma ponte entre dois outros
sistemas, tendo a possibilidade de modificar ou converter um tipo de mensagem ou ainda
incrementar informações dos campos de dados das mensagens. Na Figura 4.11, é ilustrado o
emulador substituindo um sistema da plataforma transacional, o qual recebe uma mensagem,
realiza sua função e reencaminha a mensagem para outro sistema – havendo também a
possibilidade da mensagem percorrer o caminho inverso.

Gateway Autorizador A
(Private Label)

Autorizador B
(Recarga de Celular)

Terminal POS Autorizador C


(Promoção XYZ)

Emissores / Autorizadores
Processador Autorizador Interno
CAMADA ABSTRAÍDA
EMULADOR

Adquirente
Sistema de Captura

Figura 4.11 – Emulador em modo pass-through (abstração de um único sistema)


Fonte: do Autor
60

4.3 Casos de Uso

O sistema deverá permitir que o usuário seja capaz de configurar o modo de


operação do sistema (loop-back ou pass-through), parametrizar o header padrão das
mensagens, definir templates de mensagens – sendo estes em conformidade com a ISO 8583
ou customizados, e também ser capaz de definir os fluxos de mensagens. Estes processos
permitirão que o usuário consiga parametrizar a ferramenta de tal forma que ela seja
facilmente ajustável a qualquer outro sistema.

O caso de uso ilustrado na Figura 4.12, demonstra os requisitos pretendidos na


construção do emulador de transações.

«extends» Loop-back

«uses» Configurar Modo de «extends»


Operação
Pass-through
«uses»

«uses» Configurar Header


Mensagem
Usuário Sistema

«uses» «extends»
Definir Template ISO 8583 Padrão
da Mensagem
«extends»

Definir Fluxos de Customizada


Mensagens

Figura 4.12 – Caso de uso emulador de transações


Fonte: do Autor
5. EASY ISO 8583 EMULATOR

Para validar a proposta elaborada no capítulo 4, mantendo como premissa atender o


maior número de requisitos e características da solução, tendo em vista, tempo hábil para
desenvolvimento, execução e validação de testes, análise comparativa entre ferramentas e
análise de resultados, decidiu-se por prototipar a solução. Para tal, foi definido um cenário
específico para a condução dos experimentos:

 Baseado em uma única implementação ISO 8583;

 utilizando dois meios de captura distintos: uma solução mobile e uma solução
TEF;

 abstraindo o maior número de sistemas possíveis para cada meio de captura,


de acordo com as possibilidades de cada solução;

 executando um conjunto de testes similar em cada ferramenta utilizada para


efeitos de comparação.

Dessa forma, a solução desenvolvida baseia-se no Capítulo 4.2.1, o qual apresenta o


sistema operando em modo de comunicação loop-back. O modo escolhido não limita
nenhuma funcionalidade do processo de manipulação de mensagens, permitindo a reprodução
de condições válidas, elaboração de scripts e respostas diferenciadas para meios de
pagamento baseados em campos da mensagem, atendendo a sistemas que necessitam abstrair
camadas superiores, além da utilização de um modelo ISO 8583 padrão ou customizado. Com
o modelo este proposto, a única funcionalidade não contemplada corresponde ao modo de
comunicação pass-through, contido no Capítulo 4.2.2.

5.1 Funcionalidades

Nesta seção, são detalhadas as devidas funcionalidades implementadas no protótipo


desenvolvido. Tais funcionalidades baseiam-se nos requisitos da proposta deste trabalho – os
quais foram descritos no Capítulo 4. Estas funcionalidades constituem uma configuração
mínima requerida para que o sistema tenha capacidade de interpretar requisições, gerenciar
padrões de mensagens e arquivos base para respostas, bem como formatar mensagens de
saída.

Um dos principais objetivos no desenvolvimento do protótipo foi o de conseguir


eliminar a complexidade do negócio ao usuário da solução, fator esse, encontrado nas diversas
62

soluções de mercado. Tais complexidades são encontradas no nível de conhecimento exigido


do usuário, principalmente em relação a:

 Negócio: o usuário deve ter conhecimento total das regras de negócio, as


quais deverão ser implementadas para gerar a automação requerida.

 Ferramenta: conhecimento da solução para realização de configurações,


parametrizações e linguagens de programação script própria.

 ISO 8583: o usuário deve ter pleno conhecimento da norma e da


implementação utilizada no negócio.

Muitas vezes o desejo do usuário é o de apenas enviar uma requisição e receber


determinada resposta. Ao eliminar essa complexidade, a solução fica mais aderente ao que
realmente se destina, propiciando uma melhor experiência, principalmente para usuários das
outras soluções e com pouca experiência.

5.1.1 Parametrização de Modelo de Mensageria ISO 8583

Ao estudar os diferentes tipos de implementações da ISO 8583, constatou-se que os


terminais e sistemas de meios de pagamentos, utilizam, sempre uma mesma implementação
da norma, em determinado circuito de uma transação. Dessa forma, quando se pretende
emular um determinado sistema ou uma plataforma inteira, necessita-se apenas de um modelo
único, para interagir com os sistemas desejados.

Ao invés de limitar as implementações a determinados padrões, optou-se por permitir


a customização dos campos que a compõem. Para tal, o modelo da norma foi estruturado em
um arquivo XML, composto do campo, seu formato (Tabela 2.9), tamanho máximo para
composição do campo de dado, tipo do conteúdo (Tabela 2.10) e codificação de caracteres
utilizada para representação dado (Tabela 2.12). O código abaixo representa parte de um
arquivo de template do modelo da ISO 8583 utilizado.
<?xml version="1.0" encoding="UTF-8"?>
<modelo>
<campo num="1" formato="FIXED" tamanho="16" tipo="ANS" encode="ASCII"/>
<campo num="2" formato="LLVAR" tamanho="19" tipo="ANS" encode="ASCII"/>
<campo num="3" formato="FIXED" tamanho="6" tipo="ANS" encode="ASCII"/>
...
</modelo>

É requisito de o sistema ter um modelo destes associado à instância em execução.


Todas as demais funcionalidades da aplicação se baseiam nesse mesmo padrão. Com essa
63

estrutura definida, é possível reproduzir qualquer implementação da ISO 8583, atendendo os


mais variados modelos e customizações (mesmo as em inconformidade com a norma).

5.1.2 Gerenciamento de Templates de Scripts de Requisição e Resposta

O gerenciamento de templates de scripts permite que o usuário utilize casos de testes


no emulador. Esses casos de testes são sempre constituídos de um par – uma mensagem de
requisição com sua devida mensagem de resposta. Esse par contém a estrutura das mensagens
e as possíveis validações (para a mensagem de requisição) e condições (para a mensagem de
resposta).

A mensagem de requisição é identificada primeiramente pelo seu tipo (Tabelas 2.2,


2.3, 2.4 e 2.5), posteriormente é definida sua estrutura, onde são indicados os campos que
compõem a mensagem, sua obrigatoriedade (sim / não) – há alguns campos que podem ser
opcionais, dependendo o tipo da requisição, e se são chaves. Caso um campo seja definido
como chave, deverá ser explicitado o valor atribuído como tal.

Na estrutura de script abaixo (arquivo XML), para que uma mensagem de requisição
seja interpretada pelo template e respondida, ela deverá conter todos os campos definidos
como obrigatórios e possuir o campo 3 (código de processamento) com o valor “003000” e o
campo 4 (valor da transação) deverá ser equivalente a R$ 10,00 (000000001000).
<?xml version="1.0" encoding="UTF-8"?>
<mensageria>
<requisicao tipo="0100">
<campo num="3" obrigatorio="s" chave="003000" />
<campo num="4" obrigatorio="s" chave="000000001000" />
<campo num="7" obrigatorio="s" />
<campo num="12" obrigatorio="s" />
<campo num="13" obrigatorio="s" />
<campo num="22" obrigatorio="s" />
<campo num="32" obrigatorio="s" />
<campo num="35" obrigatorio="s" />
<campo num="49" obrigatorio="n" />
</requisicao>

<resposta tipo="0110">
<campo num="3" tipo="ECO" />
<campo num="4" tipo="ECO" />
<campo num="7" tipo="DATA" />
<campo num="12" tipo="ECO" />
<campo num="13" tipo="ECO" />
<campo num="32" tipo="ECO" />
<campo num="39" tipo="VALOR" conteudo="00" />
<campo num="62" tipo="VALOR" conteudo="COMPROVANTE DA TRANSACAO1" />
</resposta>
</mensageria>
64

A mensagem de resposta contém o valor do tipo da mensagem (que deverá ser


utilizado), os devidos campos que deverão estar presentes na mensagem e o tipo de resposta.
Os tipos considerados foram:

 ECO: um campo definido como tal, fará que o campo da mensagem de


resposta reflita o valor contido na íntegra na mensagem de requisição.

 DATA: um campo definido como data, fará com que o sistema atribua uma
data no formato refletido na norma ISO 8583 padrão para o respectivo
campo.

 VALOR: quando um campo for assim definido, ele deverá possuir a tag
“conteúdo”, que deverá ter seu valor atribuído a ele. Esse valor será
respondido como conteúdo do respectivo campo de dado.

Através dessa estrutura, é possível definir testes específicos ou genéricos, de acordo


com a necessidade e critérios estabelecidos. Sendo possível elaborar qualquer tipo de
mensagem, com qualquer que seja o conteúdo desejado.

Outra função do gerenciador de templates é a de gerir a prioridade de cada script.


Essa funcionalidade possibilita que o usuário utilize scripts similares para obter
comportamentos distintos, com pequenos ajustes de conteúdo. A Figura 5.1 exemplifica dois
templates similares, distintos apenas no tratamento do “Campo 04”. Ao processar uma
requisição do tipo “0100”, o gerenciador tentará localizar um template correspondente, para
tal, serão comparados campo-a-campo da mensagem recebida contra a relação de templates
com “Tipo: 0100” (uma-a-uma).

Script: #01 Script: #02


Tipo: 0100 Tipo: 0100
- Prioridade: 0 - Prioridade: 1
Campo 03: “003000" Campo 03: “003000"
Campo 04: R$10,00 Campo 04: Qualquer
Campos xxxxx Campos xxxxx

Resposta: Resposta:
Declina a transação Aprova a transação

Figura 5.1 – Priorização de templates


Fonte: do Autor
65

Quando o gerenciador identificar um template, onde todos os critérios correspondam


com os da mensagem de requisição, a busca será imediatamente encerrada. Utilizando a figura
5.1 ainda como exemplo, o primeiro script a ser analisado para uma mensagem do tipo 0100,
seria o “Script #01”, devido a sua respectiva prioridade ser a maior. Caso a prioridade do
“Script #02” fosse a maior, o “Script #01” nunca seria utilizado, essa situação ocorreria
devido o critério do campo 04 do “Script #02” estar definido como “qualquer”.

Essa funcionalidade permite que o usuário defina scripts com comportamentos


específicos (colocando maior prioridade neles) e tenha também scripts genéricos (com menor
prioridade). Dessa forma, é possível elaborar um conjunto de testes baseado apenas no valores
da transações, por exemplo:

 R$10,00: nega a transação com código de erro 05;

 R$11,00: nega a transação com código de erro 55;

 R$12,00: aprova a transação enviando comprovante do tipo 01;

 R$13,00: aprova a transação enviando comprovante do tipo 02;

 R$14,00: aprova a transação e envia uma parametrização;

5.1.3 Interpretador de Mensagens de Requisição

O interpretador de mensagens de requisição tem como função analisar os pacotes


ISO recebidos. Esses pacotes são recebidos através de uma conexão socket estabelecida com a
aplicação. As requisições devem ser compostas pelo tamanho do pacote ISO (02 bytes) +
pacote ISO. Os dois bytes contidos no início da mensagem, constituem o header.

Ao analisar o pacote ISO, o interpretador tentará realizar a decomposição da


mensagem, de acordo com o modelo padrão da ISO 8583 carregado pelo usuário. Caso a
mensagem esteja no padrão esperado, o sistema criará um objeto (requisição), caso contrário,
a mensagem será ignorada.

Retomando as características da norma ISO (tabela 2.10), os campos de dados não


são delimitados apenas por tamanhos de campos pré-estabelecidos. Há diversos campos com
tamanho variável (o próprio campo tamanho possui variações na sua composição) os quais
devem ser interpretados campo-a-campo. Dessa forma, após interpretar o mapa de bits da
66

mensagem (tabela 2.6), o interpretador se encarrega de consultar o modelo específico de cada


campo no modelo e realizar o parse um-a-um.

A Figura 5.2 ilustra três exemplos de campos de dados, cujos tamanhos são
compostos de formas distintas. Enquanto o campo “código de processamento” é fixo (06
posições - FIXED), o campo “trilha 2” é variável (entre 00-99 - LLVAR). O campo
“autorização” também é variável, porém seu tamanho deve ser definido utilizando o range
000-999 (LLLVAR).

Figura 5.2 – Exemplo de parse de mensagem


Fonte: do Autor

5.1.4 Gerador de Mensagens de Resposta

O gerador de mensagens é responsável por estruturar as mensagens de resposta.


Como base, ele necessita de uma mensagem de requisição e um template de script compatível
com ela. Ao contrário do interpretador, que realiza uma leitura e interpreta o dado, o gerador
precisa compor toda a estrutura da mensagem, estrutura esta, composta do header, do tipo de
mensagem (MTI), do mapa de bits e de seus respectivos campos de dados.

Para montar cada campo de dado, o gerador consulta o template de resposta, para
identificar qual valor do campo será esperado na mensagem de resposta (eco, data ou valor).
Caso o valor esperado seja um ECO, será buscado o conteúdo do campo na mensagem de
requisição; caso o valor seja DATA, será gerada uma data no formato esperado (seguindo o
padrão da norma ISO 8583); e por último, caso o valor esperado esteja definido como
VALOR, será utilizado o campo “conteúdo” contido no script de template da mensagem de
resposta.

Tendo conhecimento do tipo de dado, é consultado então o modelo padrão da ISO


8583, para obter-se as características do campo (formato, tamanho máximo, tipo e encode),
posteriormente o dado é inserido na mensagem, já formatado no respectivo padrão e na ordem
pertencente (do menor para o maior).
67

Completados os passos anteriores, o gerador formata a mensagem de acordo com o


padrão de codificação, encerrando seu processo. O gerador também possui capacidade de
realizar a complementação de campos, gerar valores de data e hora (de acordo com
requerimentos dos campos) e formatar um valor para LVAR, LLVAR ou LLLVAR.

O log abaixo resulta de um processamento completo do emulador. Recebendo uma


mensagem de requisição (Message Type: 0100), analisando a relação de templates de
resposta, buscando o primeiro template compatível e por final respondendo a mensagem.
Encerrando assim o ciclo de vida de uma transação.

ISO8583 Server in Accept()


0100B21804012008800000000000000000000030000000000010001231101112101010121202111123456789013712
34567890123456=1234567890123456789076B1234567890123456^TCC FELIPE DEL VECCHIO
^12345678901234567890**XXX******986

Message Type: 0100


First Bitmap: B218040120088000
001 => 0000000000000000
003 => 003000
004 => 000000001000
007 => 1231101112
012 => 101010
013 => 1212
022 => 021
032 => 12345678901
035 => 1234567890123456=12345678901234567890
045 => B1234567890123456^TCC FELIPE DEL VECCHIO ^12345678901234567890**XXX******
049 => 986

Tam da lista de templates: 3

0110B218000102000004000000000000000000300000000000100032191032091010101212111234567890100025CO
MPROVANTE DA TRANSACAO1
Message Type: 0110
First Bitmap: B218000102000004
001 => 0000000000000000
003 => 003000
004 => 000000001000
007 => 3219103209
012 => 101010
013 => 1212
032 => 1112345678901
039 => 00
062 => 025COMPROVANTE DA TRANSACAO1

Cliente desconectou

5.2 Interface

Um dos objetivos na concepção deste trabalho é o de tornar a aplicação desenvolvida


amigável e intuitiva, exigindo o menor nível de conhecimento técnico para manipulá-la. Para
a realização da configuração, definição de padrão da norma ISO 8583 e setup de scripts, são
necessários poucos passos.

Nessa seção, serão detalhadas as telas do Emulador de Transações e suas respectivas


características.
68

5.2.1 Painel de Status

A tela inicial do aplicativo corresponde ao painel de status (Figura 5.2) – sendo este
o primeiro a ser visualizado pelo usuário. No topo da janela, há o botão de start / stop,
indicando por cores seu estado atual. Logo abaixo há três painéis, responsáveis por transmitir
informações sobre o status do processamento de mensagens:

 Conexões: indicação quantitativa de mensagens recebidas, mensagens


processadas corretamente, mensagens incorretas, mensagens respondidas e
erros.

 Última mensagem processada: Nesse painel são exibidas informações


referentes ao processamento da última transação, incluindo o message type,
processing code e o template utilizado para responder a transação (caso não
haja template para a mensagem requisitada, o sistema informará que não
houve resposta).

 Sistema: esse painel exibe informações do sistema, tais quais: erros de


processamento, falha ao carregar um arquivo XML e etc.

Figura 5.2 – Tela de status do Easy ISO 8583


Fonte: do Autor
69

5.2.2 Painel de Configuração de Conexão

No painel de configurações de conexão da aplicação, há apenas três itens


parametrizáveis pelo usuário:

 Porta: configuração de qual porta será utilizada pela solução para receber
conexões.

 Timeout da conexão: tempo máximo pelo o qual a solução aguardará pelo


lado cliente. Em transações eletrônicas, é comum aos sistemas, que estes
nunca finalizem uma conexão após uma troca de mensagens. Em
determinadas situações os sistemas podem realizar a troca de diversas
mensagens consecutivas. O cenário normal é o do cliente realizando a
desconexão, porém, para o sistema não aguardar eternamente pelo cliente, é
determinado um tempo limite em que o cliente pode ficar ocioso –
ultrapassando esse limite, ocorrerá a desconexão por parte do servidor.

 Opção para salvar logs: permite que o usuário armazene em arquivo todas as
interações ocorridas entre clientes e o servidor.

5.2.3 Painel de Configuração do Modelo ISO 8583

O painel de configuração do modelo ISO 8583 (Figura 5.3), permite ao usuário


carregar o padrão da norma que será utilizado para interpretar e montar mensagens. Por
padrão, o sistema possui dois modelos padrões estabelecidos (um ASCII e outro BCD). Ao
carregar o modelo, o usuário deverá definir o padrão de codificação de caracteres que será
utilizado, para definição das rotinas internas do sistema.
70

Figura 5.3 – Tela de configuração do padrão de mensagens do Easy ISO 8583


Fonte: do Autor

Havendo necessidade de ajustes no modelo padrão, esse deverá ser realizado


diretamente no arquivo XML, vide definição contida na seção 5.1.1. A utilização de arquivos
XML facilita a edição, manutenção e principalmente o transporte de dados. Além de ser
bastante simples o formato do arquivo, permite ao usuário visualizar num todo o conteúdo do
modelo, possibilitando assim, que o sistema opere com diferentes implementações da norma
ISO 8583.

5.2.4 Painel de Configuração de Templates

O painel de configuração de templates permite ao usuário gerir os scripts de resposta


(abordados na seção 5.1.2), em tempo de execução. A qualquer momento um script pode ser
adicionado, excluído ou ainda ter sua prioridade aumentada ou diminuída – de acordo com a
necessidade.

O item “1” assinalado na Figura 5.4, detalha o nome do arquivo XML de script
carregado e sua respectiva prioridade perante os demais. O item “2” permite que o usuário
priorize os templates. Ao utilizar as setas (cima / baixo), são modificados os níveis de
71

prioridade, alternando o comportamento do Emulador ao realizar a busca por templates para


uma mensagem de requisição.

Figura 5.4 – Tela de configuração de templates do Easy ISO 8583


Fonte: do Autor

5.2.5 Painel de Logs

Por fim, o painel de logs detalha ao usuário todos os eventos ocorridos durante o
processamento de transações. Há também a possibilidade de filtrar as informações que serão
dispostas (apenas mensagens de entrada, apenas mensagens de saída, incluir dump,
mensagens de sistema e mensagens de erro completas).

A Figura 5.5 exemplifica um caso, contendo uma mensagem de requisição e seu


devido dump (seleção Requisição) e sua respectiva mensagem de resposta com o dump
(seleção Resposta). No topo da figura 5.5, também é possível visualizar o botão de start/stop
indicando que o sistema está ativo.
72

Figura 5.5 – Tela de logs do Easy ISO 8583


Fonte: do Autor

5.3 Modelagem

Nesta seção, serão analisados os diagramas do protótipo implementado. Para auxiliar


na compreensão da solução, foram desenvolvidos dois diagramas: um de classes e outro de
sequência.
73

5.3.1 Diagrama de Classes

Um diagrama de classes é uma representação da estrutura e relações das classes que


servem de modelo para objetos (BELL, 2013). Além disso, é uma modelagem bastante útil
para o desenvolvimento de sistemas, pois define todas as classes que o sistema necessita
possuir e é a base para a construção dos diagramas de comunicação, sequência e estados.

A Figura 5.6 contém o diagrama de classes simplificado do protótipo. Nesse


diagrama reduzido, é possível visualizar o relacionamento entre os elementos do sistema.

Figura 5.6 – Diagrama de classes reduzido do Easy ISO 8583


Fonte: do Autor

Inicialmente foi projetada a biblioteca ISO 8583, responsável por realizar as funções
básicas para interpretação e composição de campos e mensagens, bem como lidar com os
diversos tipos previstos de implementações da norma e diferentes scripts de resposta. Essa
biblioteca é composta das classes ISO8583, Bit e das interfaces DesmontaISO8583 e
MontaISO8583.
74

Posteriormente foram construídas as classes de modelo da ISO e de templates de


requisição e resposta (ModeloISO8583 e TemplateISO8583). Essas classes compõe os
modelos dos arquivos XML (quando instanciados), que são interpretados com auxílio da
biblioteca stAX11 (API para leitura e gravação de arquivos XML).

A interface gráfica do sistema (referenciada como classe GUI) foi a última etapa do
desenvolvimento, sendo ela responsável por gerir o instanciamento das demais classes.
Operando como ponte entre o usuário e as funcionalidades da aplicação (carregar templates,
carregar modelo ISO 8583, parametrização e etc.).

5.3.2 Diagrama de Sequência

Os diagramas de sequência têm por objetivo mostrar como as mensagens entre os


objetos são trocadas no decorrer do tempo para a realização de uma operação. O diagrama
contido na Figura 5.7, detalha o processo realizado internamente no sistema ao receber uma
mensagem de requisição – auxiliando na sua devida compreensão.

Primeiramente, a mensagem de requisição é recebida pela classe Socket (objeto


"conexao"), através do método recebeBuffer(). Posteriormente, sendo encaminhada para o
objeto processadorISO8583, que tem como objetivo realizar o processamento completo das
mensagens. O processamento ocorre através dos métodos crackISO8583Message() –
responsável por interpretar a mensagem, buscaTemplate() – cuja finalidade é encontrar um
template cuja estrutura seja compatível com a mensagem recebida, e por último, o método
mountISO8583Message() – responsável por gerar a mensagem de resposta com base no
template localizado e na própria mensagem de requisição.

11
http://stax.codehaus.org/
Figura 5.7 – Diagrama de sequência ao processar uma transação
Fonte: do Autor
5.4 Validação Experimental

Para a realização da validação da proposta do trabalho e de seu respectivo protótipo


implementado, o autor decidiu por utilizar um ambiente real de desenvolvimento de soluções
de meios de pagamento, de modo que transações pudessem ser geradas em um ambiente
controlado, mantendo a maior proximidade possível de comportamentos encontrados em um
ambiente produtivo. Outro fator de escolha do autor foi a de utilizar o menor número possível
de sistemas, fazendo com que a solução seja responsável pela maior parte da transação.

Os experimentos foram conduzidos utilizando parte da infraestrutura da empresa


GetNet, que cordialmente disponibilizou profissionais e meios de captura para tal. As seções
subsequentes explicam os meios de captura utilizados e a composição de sistemas que foram
substituídas pelo emulador – os sistemas GetNet não serão detalhados devido a questões de
segurança e confidencialidade, sendo estes tratados como "Plataforma GetNet".

5.4.1 Cenário 01: Solução Mobile

A solução mobile é composta de um app para iPhone, a qual conecta-se diretamente


a um webservice GetNet. Esta aplicação possibilita que um EC realize a comercialização de
recarga de celulares para seus clientes (de todas as operadoras), utilizando seu respectivo
dispositivo como meio de captura. Dentre as possíveis transações, estão: venda de recarga
online, venda de recarga offline, desfazimento de transações (reversals), relatório de vendas,
solicitação de boleto de pagamento e parametrização dinâmica dos produtos.

A Figura 5.8 detalha a estrutura dessa solução, bem como a área de atuação do
Emulador de Transações.

Camada substituída pelo Emulador

Internet

Solução Firewall WebServer WebLogic Plataforma GetNet


mobile

Figura 5.8 – Detalhamento do ambiente da solução Mobile


Fonte: do Autor
77

5.4.2 Cenário 02: Solução TEF

A solução TEF é constituída de uma aplicação instalada em um estabelecimento


comercial (composta de módulos Servidor e Cliente) a qual se integra a sua solução frente de
caixa. Essa se conecta a uma rede, a qual é responsável por capturar e processar suas
transações, bem como encaminhar requisições de autorização a emissores.

No caso de private labels, a plataforma conecta-se diretamente a uma processadora,


retornando a resposta da transação de requisição para o meio de captura, no caminho inverso.
A Figura 5.9 exemplifica esse fluxo, sendo determinado pelo quadro, os sistemas que terão
seus comportamentos emulados.

Cliente TEF Servidor TEF


Roteador Gateway
Camada substituída pelo Emulador

Estabelecimento Comercial Plataforma GetNet Bandeiras Emissor

Figura 5.9 – Detalhamento do ambiente da solução TEF


Fonte: do Autor

Nesse cenário, foram realizadas transações de crédito à vista, crédito parcelado,


débito, pré-autorização, consulta de saldo e estorno, utilizando cartões VISA, MasterCard e
private labels. Além destas, foram contempladas transações de relatório de vendas,
administrativas, desfazimentos e parametrização do terminal – sendo estas transações típicas
de rede adquirente.

5.5 Experimentos

Na condução dos experimentos da solução, buscou-se realizar o maior número


possível de transações, contemplando os mais variados comportamentos dos respectivos
meios de captura. Para tal, foram gerados casos de teste, através da utilização dos templates
de script – os quais permitem definir as respostas de acordo com as mensagens de requisição
(seção 5.1.2).

Os experimentos conduzidos foram divididos em três fases: construção de ambiente,


ponto de vista do terminal e comparativo entre soluções. Na primeira fase são abordados os
aspectos relativos à estruturação e criação do ambiente transacional (detalhando as
78

dificuldades e facilidades encontradas), tipos de mensagens criadas, conteúdo de campos de


dados manipulados e casos de testes contemplados. Na segunda fase, são abordados aspectos
em nível de usuário, condizentes a experiência ao utilizar o meio de captura interagindo com a
solução proposta e validação de fluxos e comprovantes. Por fim, são analisadas as
características de utilização de ferramentas de mercado com solução prototipada, detalhando
os resultados: itens contemplados, não contemplados e melhorias desejadas para uma eventual
implementação.

5.5.1 Construção dos Ambientes

Nesta seção serão demonstrados os passos necessários para realizar a configuração e


estruturação de um ambiente emulado com a solução prototipada neste trabalho, baseados nos
ambientes contidos nas figuras 5.8 (solução mobile e transações de recarga de celular) e 5.9
(solução TEF e transações de crédito e débito). Posteriormente são comparados os processos
necessários para realização dos mesmos procedimentos nas soluções de mercado. No
ambiente cedido pela empresa GetNet, foram disponibilizadas as seguintes aplicações:
ASSET, MasterCard Simulator e VISA VTS para transações TEF; SCC (sistema interno
GetNet) para transações mobile.

Tanto o ASSET como o SCC, permite a estruturação de um ambiente completo,


enquanto os simuladores MasterCard e VISA, nesse caso, atuam apenas simulando
comportamentos das respectivas bandeiras e emissores. Estes últimos requerem uma estrutura
maior de sistemas internos (plataforma GetNet) para realizar o devido processamento das
mensagens, já que a parte simulada é a última da cadeia. Mesmo assim, eles foram utilizados
para efeito de comparação dos produtos aceitos por tais soluções – uma vez que o Emulador
ISO 8583 também as suporta.

5.5.1.1 Easy ISO 8583 Emulator


A configuração inicial do Easy ISO 8583 Emulator é bastante simples, a maior parte
do processo corresponde a marcar algumas check-box e dar alguns cliques para carregar
modelos prontos da ISO 8583 (a solução dispõem de um kit básico atendendo a diversas
implementações). O modelo ISO é carregado de acordo com o procedimento da figura 5.3,
caso o usuário precise ainda alterar qualquer parâmetro da implementação, basta acessar o
diretório "modelo" da aplicação, e com auxílio de um editor de texto criar ou modificar um
dos arquivos existentes.
79

Como próximo (e último) passo, devem ser criados os templates de resposta para as
transações. Como a aplicação instanciada opera com apenas um padrão de mensageria, os
templates não requerem qualquer parametrização da ISO quanto à encode, tamanho de campo
ou tipo de dado – simplificando e acelerando o processo. Acessando o diretório “template”, o
usuário encontra diversos arquivos de exemplo (assim como o modelo ISO, estes devem ser
manipulados através de um editor de texto).

O conjunto de testes criado foi dividido por cenário e grupo, de acordo com o MTI
das transações. A organização tanto para transações do cenário TEF quanto mobile são
bastante similares no processo, porém muito distintas quanto ao tipo de contéudo tratado e no
formato que deve ser enviado nas respostas das mensagens. Transações de configuração
foram dividas em diversas pernas, pois ocorre uma sucessiva troca de mensagens entre o
terminal e o host – isso devido ao fato da mensagem ter um limite de transporte de dados,
próximo a dois kilobytes.

Ambas as estruturas e conteúdo das mensagens foram elaborados de acordo com as


especificações técnicas dos meios de captura (pertencentes a empresa GetNet), contemplando
todos os comportamentos possíveis de serem obtidos através da Plataforma GetNet. Para
atingir esse objetivo, os templates foram criados utilizando diversos campos chaves, diferindo
mensagens similares entre um mesmo conjunto (i.e.: crédito à vista aprovada, crédito à vista
declinada, crédito à vista parcelada aprovada e etc.). Esta distinção ocorre principalmente com
os campos: valor da transação, trilha 2 do cartão, código do estabelecimento e campos do tipo
reserved for private use para transações de recarga de celular.

Para facilitar a identificação e priorização, recomenda-se atribuir um nome de


arquivo significativo, de fácil assimilação à transação contemplada por cada template (como
pode ser visto na Figura 5.10). A seção 5.1.2 detalha o processo e conteúdo dos arquivos de
templates. O formato definido permite que o usuário enxergue em uma única tela, toda a
estrutura da mensagem de requisição, resposta e seu devido conteúdo. Terminado o processo,
resta ao usuário carregar os arquivos de templates, priorizá-los de acordo com sua necessidade
(figura 5.4) e iniciar o serviço.
80

Figura 5.10 – Exemplo de nomes significativos para templates


Fonte: do Autor

5.5.1.2 SCC (GetNet)


A solução SCC utilizada internamente na GetNet como apoio, é bastante flexível e
robusta, tornando possível a estruturação de ambientes bastante complexos. Porém exige um
alto nível de conhecimento técnico e experiência do usuário com o meio de captura, em
mensageria ISO, comportamentos de transações, além de programação em linguagem Java.

Para estruturar um ambiente, faz-se necessário realizar diversos passos, muitos deles
exigem detalhes minuciosos ao usuário, sendo este um fator bastante negativo, pois gera uma
experiência negativa, devido principalmente à complexidade. Nessa solução, foram
implementadas as transações para recarga de celular.

O início do processo começa pelo cadastro da norma ISO 8583, que deve ser
parametrizada campo-a-campo (num total de 128 registros), incluindo dados de formatação do
campo, tipo de dados, codificação e outros. Como os registros são informados em uma
interface gráfica, devem necessariamente ser percorridos todos os campos individualmente,
como pode ser visto na Figura 5.11.
81

Figura 5.11 – SCC: cadastro do padrão ISO 8583


Fonte: do Autor

Em seguida o usuário deve configurar as parametrizações de comunicação da


aplicação, informando a porta local, preâmbulo, definição de tamanho de mensagem, prefixos
de script e timeout. Estes itens de configuração podem ser vistos na Figura 5.12.

Figura 5.12 – SCC: parametrização de conectividade


Fonte: do Autor
82

Posteriormente o usuário deve cadastrar todas as estruturas de mensagens que


trafegarão pelo sistema (uma-a-uma). Esse processo acaba tomando bastante tempo do
usuário, que deve conhecer toda a mensageria da aplicação. O cadastro corresponde em
compor uma estrutura, definindo quais campos de dados estarão presentes. A Figura 5.13
contém a relação de templates criados na elaboração do ambiente, enquanto a Figura 5.14
contém o detalhe do cadastro de um template.

Figura 5.13 – SCC: cadastro das estruturas de mensagens


Fonte: do Autor

Figura 5.14 – SCC: estrutura de uma mensagem


Fonte: do Autor
83

Para que a ferramenta responda transações, o usuário deve programar um único


script para cada tipo de mensagem (i.e: 0100, 0200), concentrando todas as respostas de um
mesmo tipo de transação num único local. Soluções complexas acabam gerando arquivos com
mais de mil linhas de código. A Figura 5.15, detalha um pequeno trecho de código exemplo.

Figura 5.15 – Linguagem script do SCC


Fonte: do Autor

Terminada a configuração, o sistema está pronto para responder as transações


encaminhadas a ele.

5.5.1.3 ASSET
A solução ASSET foi utilizada para compor um ambiente de crédito e débito para
MasterCard, VISA e Private Labels. Esta aplicação é bastante robusta e voltada para integrar
com os principais processadores de transações e esquemas de pagamentos, porém assim como
o SCC (GetNet), consiste de uma ferramenta demasiadamente complexa, a começar pela tela
inicial da aplicação (Figura 5.16).

Figura 5.16 – ASSET: tela inicial


Fonte: do Autor
84

A solução não possui nenhum modelo padrão para ser utilizada, a estrutura inicial
deve ser toda ela construída. A definição dos campos do padrão ISO 8583 e estruturas de
mensagens devem ser definidas uma a uma – a Figura 5.17 detalha o preenchimento de um
único campo de dado. O usuário precisa definir os 128 campos da ISO 8583, entre eles:
formato do campo e encode.

Figura 5.17 – ASSET: definição de um campo de dado


Fonte: do Autor

Para definir as mensagens de resposta, o usuário deve aprender uma linguagem de


script própria da aplicação, devendo programar cada resposta deseja para cada tipo de
mensagem de requisição. A Figura 5.18 detalha uma porção de código utilizado.
85

Figura 5.18 – ASSET: linguagem script proprietária


Fonte: do Autor

O tempo gasto aprendendo a manusear a solução, bem como estruturar mensagens e


implantar casos de testes é bastante grande.

5.5.1.4 MasterCard Simulator e VISA VTS


Ambas as soluções possuem uma estrutura base bastante completa, oferecendo
diversos tipos de testes após a sua instalação. Porém produtos considerados “tropicalismo12”
não constam nesse setup básico, como por exemplo, transações parceladas e pré-autorizações.
As opções de configurações são muitas, porém o enfoque das soluções são os produtos VISA
e MasterCard, nenhum produto diferente destes é parametrizável.

A Figura 5.19 detalha a tela inicial da aplicação VISA VTS, enquanto a Figura 5.20
exibe o menu de configuração de uma mensagem ISO da mesma solução.

Figura 5.19 – VISA VTS: tela inicial


Fonte: do Autor

12
Adaptação própria do mercado local.
86

Figura 5.20 – VISA VTS: configuração de estrutura de mensagem


Fonte: do Autor

A personalização de templates de mensagens da solução VISA VTS, ainda que


resumida a uma única implementação, é um tanto abstrata e confusa, exigindo alto nível de
conhecimento técnico quanto à especificação do protocolo VISA de mensageria.

A suíte MasterCard, assim como a da VISA, dedica-se exclusivamente ao seu


respectivo negócio. Esta é ainda mais complexa, porém conta com uma gama de templates de
testes ainda mais completa, compreendendo smartcards e todos os tipos de produtos, sendo
atualizados constantemente com os padrões da bandeira. Porém a ausência de templates
locais, também é sentida, fazendo com que a parametrização de templates adicionais seja
necessária. As Figuras 5.21 e 5.22 detalham a personalização de uma única mensagem, sendo
esse processo um tanto burocrático e dependendo dos parâmetros alterados, podem impactar
no setup básico dos casos de testes iniciais.
87

Figura 5.21 – MasterCard Simulator: configuração de estrutura de mensagem


Fonte: do Autor

Figura 5.22 – MasterCard Simulator: estrutura de mensagem detalhada


Fonte: do Autor
88

5.5.2 Ponto de Vista do Terminal

Depois de realizado a construção dos ambientes e dos respectivos templates para as


transações de cada meio de captura, foram realizadas as transações. Utilizou-se um iPhone
para realizar as transações de recarga para celular (que no caso apenas registram as
transações, sem a devida carga de créditos real) e uma aplicação TEF com simulador de PDV
para as transações de crédito e débito (com cartões MasterCard, VISA e private labels).
Através destes dispositivos, foi possível realizar todos os tipos de transações (detalhadas nas
seções 5.4.1 e 5.4.2) com o emulador.

A estrutura do Easy ISO 8583, ainda que bastante simplificada se comparada às


outras soluções de mercado, atendeu tão bem quanto estas. Transações realizadas com private
labels e cartões fora do padrão ISO 7816 também não apresentaram qualquer tipo de
inconsistência, sendo estas, transparentes para a solução desenvolvida. Demais customizações
da implementação ISO 8583 utilizada também puderam ser contempladas, como o uso de
comprovantes e demais dados utilizados em campos privados.

A Tabela 5.1 contém a relação de todas as transações realizadas com a solução TEF.
Transações administrativas (como relatório de vendas), teste de conexão e de desfazimento
não estão contidas na tabela, pois não se aplicam a um único produto, mas também foram
contempladas.

Tabela 5.1 – Transações realizadas com a solução TEF


Transação Cartão MasterCard CartãoVISA Cartão Private Label
Débito à vista x x x
Débito parcelado - - x
Crédito à vista x x x
Crédito parc. estab. x x x
Crédito parc. emissor x x x
Pré-autorização x x x
Conf. pré-autorização x x x
Estorno x x x
Saldo - - x
Fonte: do Autor.

A Tabela 5.2 contém a relação de transações realizadas com o produto de recarga


móvel de créditos para celular. Para este produto o termo online significa que o crédito será
inserido automaticamente, enquanto o termo offline significar que o cliente receberá um
código, com o qual fará a inserção de créditos na linha desejada.
89

Tabela 5.2 – Transações realizadas com a solução mobile


Transação Claro Oi Tim Vivo
Recarga valor fixo online x x x x
Recarga valor fixo offline - x x x
Recarga valor variável online x x x x
Recarga valor variável offline - x x -
Fonte: do Autor.

Para um usuário normal, não houve discernimento na utilização das soluções em um


ambiente produtivo ou com o Emulador operando como host principal. As transações
configuradas foram todas atendidas corretamente, sendo possível manipular os diversos tipos
de campos de dados das mensagens de entrada, respondendo com todas as saídas desejadas.

5.5.3 Comparativo entre Soluções

Se todas as corporações seguissem um modelo padrão de implementação da ISO


8583, poderiam também utilizar um plano de teste específico para validar suas mensagens
financeiras. Na verdade, cada organização possui diferentes implementações e uma coleção de
diferentes produtos e transações suportados, além de papéis variados no decorrer da transação
(emissor, adquirente ou processador). Desse modo, cada especificação de mensagem tem
requisitos que afetam diferentes processos do sistema.

Esse mesmo critério se aplica na escolha de ferramentas que se adequem as


necessidades de desenvolvedores e analistas de testes. Algumas soluções são mais flexíveis,
permitindo um maior nível de customização e aplicação, enquanto outras se dedicam
exclusivamente a determinados nichos, atuando em papéis específicos – não esquecendo
também do fator custo.

Nesta seção serão comparadas as características das soluções de mercado utilizadas


nos experimentos com a aplicação desenvolvida, o Easy ISO 8583 Emulator.

5.5.3.1 Comparação com o ASSET


A solução ASSET utilizada para simular comportamentos das bandeiras MasterCard,
VISA e de private labels, possui bastante flexibilidade, porém sua configuração e
parametrização são bastante burocráticas. O usuário necessita possuir conhecimentos técnicos
avançados em mensageria ISO 8583 e na própria ferramenta.
90

A construção de respostas automatizadas inicia pela definição do leiaute dos campos


de dados, partindo para a estrutura das mensagens e então para a sintaxe script implementada
pela solução. O tempo de implementação de um ambiente emulado é bastante alto, podendo
ser equiparado ao desenvolvimento do próprio sistema. O que muita vezes não justifica a sua
utilização, principalmente se analisado com o custo total de implementação.

Outro ponto negativo do ASSET é o licenciamento, o qual restringe a plataforma a


uma instalação por licença, a qual deve ser obrigatoriamente em um servidor rodando sistema
operacional Microsoft Windows. Além disso, o sistema opera em apenas uma rede executando
o servidor. O setup inicial além de complicado não possui qualquer template inicial,
obrigando o usuário a obter suporte oficial. A vantagem da solução é a integração com os
demais sistemas da ACI WorldWide e também com outras soluções padrões de mercado –
principalmente as baseadas nos sistemas MasterCard e VISA.

Na Tabela 5.3 são destacados os pontos levados em conta ao compará-lo com o


Emulador ISO 8583 desenvolvido. O custo de implementação e tempo empregado na
estruturação e manutenção da solução requerem que o usuário torne-se um especialista, além
do alto custo ser um fator determinante.

Tabela 5.3 – Comparação entre ASSET x Easy ISO 8583


Características ASSET Easy ISO 8583
Cadastro da implementação ISO 8583 Manual Arquivos
Cadastro das estruturas de mensagens Manual N/A13
Cadastro de formato de campos de dados Manual (por mensagem) N/A
Implementação de scripts de resposta Script (linguagem própria) XML (texto simples)
Possui templates padrões Não Sim
Plataforma Microsoft Multiplataforma
Exige servidor dedicado Sim Não
Custo de implementação Alto Baixo
Perfil necessário para implementação Analista Sênior Analista Júnior
14
Horas estimadas para implementação 100-120 horas 16 horas
Customização da ISO 8583 Sim Sim
Fonte: do Autor.
Ao trazer esta situação para o ambiente GetNet, que possui aceitação de mais de
vinte private labels em sua rede de captura de transações, tanto o número de licenças como o
tempo necessário para configuração e estruturação dos ambientes com o ASSET tornam-se
inviáveis.

13
Não se aplica.
14
Baseado no tempo utilizado pelo autor.
91

5.5.3.2 Comparação com o SCC (GetNet)


A solução SCC utilizada internamente na GetNet, tem características similares ao
ASSET, porém com foco maior em gestão de certificações. Essa aplicação foi utilizada para a
construção do ambiente mobile para o produto Recarga de Celular. Entre as vantagens está o
fato de este ser uma aplicação web – ainda que exija um servidor dedicado com banco de
dados e de ser construída especificadamente para o browser Internet Explorer.

O custo de licenciamento é relativamente mais baixo, porém o processo de


construção e manutenção de ambientes é tão burocrático quanto ao do ASSET, também
exigindo nível avançado de conhecimento. Faz-se necessário a criação do padrão ISO 8583
manualmente (campo-a-campo), estruturas de mensagens – criando cada uma das mensagens
e formatando manualmente cada campo de dado, além do script de resposta baseado na
linguagem de programação Java.

Usuários com pouca experiência tendem a não completar o processo sem auxílio de
um usuário avançado dedicado, o que torna a ferramenta bastante dificil de operar num
primeiro momento. Qualquer erro induzido num script de resposta impacta em todas as
respostas, sendo necessário realizar debug visual através da console do Tomcat.

Na Tabela 5.4 pode ser visto o comparativo entre o SCC GetNet e o Easy ISO 8583
Emulator. As horas estimadas para implementação do ambiente, são reflexo do tempo
utilizado na elaboração dos experimentos deste trabalho.

Tabela 5.4 – Comparação entre SCC (GetNet) x Easy ISO 8583


Características SCC Easy ISO 8583
Cadastro da implementação ISO 8583 Manual Arquivos
Cadastro das estruturas de mensagens Manual N/A
Cadastro de campos de dados Não N/A
Implementação de scripts de resposta Script (Java) XML (texto simples)
Possui templates padrões Não Sim
Plataforma Web Multiplataforma
Exige servidor dedicado Sim Não
Custo de implementação Alto Baixo
Perfil necessário para implementação Analista Sênior Analista Júnior
Horas estimadas para implementação 80 horas 10 horas
Customização da ISO 8583 Sim Sim
Fonte: do Autor.
92

5.5.3.3 Comparação com MasterCard Simulator e VISA VTS


O principal diferencial das soluções fornecidas pelas bandeiras MasterCard e VISA é
o propósito a que se destinam. Elas têm objetivo único de simular comportamentos de
adquirentes ou emissores e da rede dos seus respectivos negócios. Dessa forma, esses sistemas
não conseguem se comportar como subsistemas internos, auxiliando no desenvolvimento de
outros sistemas integrantes de uma mesma plataforma transacional.

Porém a utilização dessas ferramentas torna-se obrigatória, devido ao custo de


licenciamento e manutenção ainda serem mais viáveis que o tempo de locação de ambientes
de teste reais – além da disponibilidade de ambiente e necessidade para a realização de
processos de certificações de produtos e de rede.

Mesmo com a relativa obrigação em possuir tais soluções, sua disponibilidade


interna (i.e.: ambiente de desenvolvimento GetNet) se limita a algumas áreas. Tal fato faz
com que a utilização de outras soluções seja também requerida. A Tabela 5.5 contém a
comparação destas duas soluções com o Emulador de Transações ISO 8583.

Tabela 5.5 – Comparação entre simuladores Mastercard x VISA x Easy ISO 8583
Características MasterCard VTS Easy ISO 8583
Cadastro da implementação ISO 8583 N/A N/A Arquivos
Cadastro das estruturas de mensagens N/A N/A N/A
Cadastro de formato de campos de dados N/A N/A N/A
Implementação de scripts de resposta Limitada Manual XML (texto simples)
Possui templates padrões Sim Sim Sim
Plataforma Microsoft Microsoft Multiplataforma
Exige servidor dedicado Sim Sim Não
Custo de implementação Alto Médio Baixo
Perfil necessário para implementação Analista Júnior An. Júnior An. Júnior
Horas estimadas para implementação 40 horas 40 horas 10 horas
Customização da ISO 8583 Não Não Sim
Fonte: do Autor.

Apesar de ambas as soluções possuírem templates padrões de resposta, os


comportamentos não contemplam: “tropicalismo” (transações parceladas, pré-autorização e
etc.), transações declinadas e outras condições necessárias para reprodução completa de todos
os comportamentos da respectiva rede.
CONCLUSÃO

Neste trabalho foram apresentados e conceituados todos os atores envolvidos ao


longo do processamento de uma transação financeira eletrônica, tendo sido detalhado como
uma transação ocorre no mais baixo nível operacional, tipos de terminais, sistemas, padrões
de intercâmbio de mensagens, fluxos e codificação de dados.

Em um mundo ideal, os sistemas de meios de pagamentos seriam interoperáveis,


principalmente pelo fato da maioria deles serem baseados na mesma norma, a ISO 8583.
Porém como visto ao longo do trabalho, além da norma permitir a customização de alguns
campos de dados, não há um padrão de codificação de caracteres estabelecido, acarretando na
implementação de uma norma customizada por cada instituição que a adota.

Com os dados apresentados neste trabalho é possível observar que os principais


problemas para a implementação de sistemas de meios de pagamentos são a alta segmentação
e falta de interoperabilidade. As grandes bandeiras como VISA e MasterCard, se resguardam
oferecendo infraestrutura completa para seus respectivos esquemas – com simuladores, suítes
de testes integrados e suporte para cada tipo de produto. Enquanto isso, instituições com
volumes menores e negócios regionalizados, não possuem justificativa para tal investimento –
ficando sem o devido suporte.

As ferramentas de mercado apresentadas possuem papel fundamental nos processos


de desenvolvimento e certificações de soluções de pagamentos. Entretanto, possuem foco
específico: cartões de crédito e débito, limitando muitas vezes a utilização de determinada
solução para um cenário específico. Fazendo com que a utilização de outras soluções seja
necessária, elevando ainda mais o custo de implementação com licenças e suporte, além de
conhecimento técnico e pessoas dedicadas a operar e prestar manutenção nas ferramentas.
Esse último item faz com que, muitas vezes, apenas partes da plataforma transacional
possuam algum sistema de apoio ao longo do processo de desenvolvimento.

De encontro com essas dificuldades e ausência de soluções especializadas em private


labels e demais produtos eletrônicos, este trabalho propôs e validou uma solução capaz de
atender às principais implementações de mercado para cartões de crédito e débito, cartões do
tipo private labels, além de produtos sem a participação de cartões, como a recarga de
celulares, característicos do mercado brasileiro, sendo esta solução, capaz de abstrair não
somente camadas finais de sistemas, como também intermediárias, auxiliando em todas as
etapas e sistemas envolvidos no processamento de uma transação.
94

Outro fato diferencial da solução gerada neste trabalho é a facilidade em realizar sua
parametrização, seja na elaboração de um conjunto de casos de testes ou na definição de um
modelo de implementação da ISO 8583, com o menor esforço possível em um ambiente
multi-plataforma e de baixo custo de implementação, contando ainda com as principais
características encontradas nas principais soluções de mercado.

O sistema apresentado permite agilizar o processo de desenvolvimento, suprindo


uma carência de soluções de automatização de testes para produtos de todos os tipos, cujas
implementações sejam variantes da ISO 8583, servindo também de apoio para a realização de
testes específicos, auxiliando desenvolvedores, testadores e demais grupos que necessitem
realizar simulações.

Conclui-se que o objetivo geral do trabalho, em construir uma aplicação capaz de


substituir sistemas transacionais completos ou parte deles (subsistemas) foi atingido. A
solução desenvolvida equipara-se com as demais soluções de mercado, respondendo à
requisições com tratamento de conteúdo, interpretando todos os tipos de dados e principais
padrões de codificação de caracteres, propiciando um conjunto de testes tão amplo quanto um
ambiente real, possuindo baixo custo e facilidade de implementação, utilização, estruturação,
manutenção do ambiente e personalização de transações tipicamente brasileiras.

Como trabalhos futuros, este trabalho deixa alguns aspectos que podem ser
expandidos e complementados, a fim de trazer novas funcionalidades, agregando maior valor
à solução. Em termo de usabilidade, uma interface visual para a criação de scripts de
templates e modelos da ISO 8583 – permitindo que o usuário tenha um ambiente ainda mais
amigável para manipulação de arquivos XML. Do ponto de vista transacional, um próximo
passo seria a criação de módulos, entre eles, para validação de casos de testes, sugestões de
testes com base nos cenários cadastrados, relatórios de testes e também um módulo para
interação com smartcards (geração de respostas e scripts “71 e “72 autenticados).
REFERÊNCIAS BIBLIOGRÁFICAS

ABA, American Bankers Association. ABA Statement On Debit Interchange Rule


Proposal. Disponível em: <http://www.aba.com/Products/Pages/Periodicals.aspx>. Acesso
em: 22 set. 2012.

ABECS, Associação Brasileira das Empresas de Cartões de Crédito e Serviços. Consumo das
Famílias no Cartão. 2012. Disponível em:
<http://www.abecs.org.br/site2012/noticiasInterna.asp?id=81>. Acesso em : 18 ago. 2012a.

ABECS, Associação Brasileira das Empresas de Cartões de Crédito e Serviços. Benefícios do


Cartão. Disponível em: <http://www.abecs.org.br/site2012/beneficiosDoCartao.asp>. Acesso
em: 20 set. 2012b.

ABECS, Associação Brasileira das Empresas de Cartões de Crédito e Serviços. Mercado


brasileiro de cartões cresce 24% em 2011. Disponível em: <http://www.abecs.org.br>.
Acesso em: 13 out. 2012c.

ABECS, Associação Brasileira das Empresas de Cartões de Crédito e Serviços. O que é o


POS? Disponível em: <http://www.abecs.org.br/site2012/faqEstabelecimentos.asp>. Acesso
em: 20 set. 2012d.

ACI WORLDWIDE. ASSET: Product Flyer. Disponível em:


<http://www.aciworldwide.com/~/media/Files/Collateral/ASSET_FL_US_1110_4459.ashx>.
Acesso em: 27 out. 2012a.

ACI WORLDWIDE. Who we are?: Payments and banking. Disponível em:


<http://www.aciworldwide.com/en/Who-we-are.aspx>. Acesso em: 27 out. 2012b.

ANDRADE, Alexandre. Definição de transação eletrônica. [mensagem pessoal] Mensagem


recebida por: <aandrade@getnet.com.br>. em: 22 set. 2012.

ARAÚJO, Carlos et al. Performance Modeling for Evaluation and Planning of Electronic
Funds Transfer Systems with Bursty Arrival Traffic. In: INTENSIVE '09. Intensive
Applications and Services. [S.l.:s.n.], 2009. p. 65 - 70. Disponível em:
<http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4976424&isnumber=4976405>.
Acesso em: 01 out. 2012

ASCII Table: ASCII Table and Description. Disponível em: <http://www.asciitable.com/>.


Acesso em: 07 out. 2012.

BANCO CENTRAL, Diagnóstico do Sistema de Pagamentos de Varejo do Brasil. 1ª


Edição. Brasilia, maio/2005. Disponível em: <http://www.bcb.gov.br/?spbpublic>. Acesso
em: 20 set. 2012.

BANCO CENTRAL, Relatório sobre a Indústria de Cartões de Pagamentos. 1ª Edição.


Brasilia, maio/2010. Disponível em: <http://www.bcb.gov.br/?spbpublic>. Acesso em: 20 set.
2012.
96

BANCO CENTRAL, Relatório sobre a Indústria de Cartões de Pagamentos, Adendo


Estatístico - 2010. Brasilia, dezembro/2011. Disponível em:
<http://www.bcb.gov.br/?spbpublic>. Acesso em: 20 set. 2012.

BEURAN, Razvan. Introduction to Network Emulation. [s. L.]: Pan Stanford Publishing,
2012. 426 p.

BELL, Donald. UML Basisc: The Class Diagram. Disponível em:


<http://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/>.
Acesso em: 10 jul. 2013.

BUGAJSKI, Joseph; SMEDT, Philippe de. Assuring Data Interoperability Through The
Use Of Formal Models Of Visa Payment Messages. In Mary Ann Robbert, Robert O Hare,
M. Lynne Markus, Barbara D. Klein, editors, Proceedings of the 12th International
Conference on Information Quality, MIT, Cambridge, MA, USA, November 9-11, 2007.
p.29-37, MIT, 2007.

BRASIL MAIOR. Número de conexões 3G cresce 270% em 2 anos. Disponível em:


<http://www.brasilmaior.mdic.gov.br/noticia/index/institucional/id/1557>. Acesso em: 13 out.
2012.

CAFFARELLI, Paulo Rogério. Mercado de Cartões: 2010: um ano para comemorar. Meios
Eletrônicos de Pagamento: Anuário Brasileiro 2011, São Paulo, p.21-24, 2012. Anual.

CIELO. Soluções TEF: TEF Dedicado. Disponível em:


<http://www.cielo.com.br/portal/cielo/solucoes-de-tecnologia/solucoes-tef.html>. Acesso em:
20 set. 2012.

CLAYTON, Kenneth J.. Testimony of Kenneth J. Clayton Before the Subcommittee on


Financial Institutions and Consumer Credit Committee on Financial Services United
States House of Representatives. Disponível em:
<http://www.aba.com/aba/documents/press/march192009kenclayton.pdf>. Acesso em: 22 set.
2012.

DELIC, Natali; VUKASINOVIC, Ana. Mobile Payment Solution - Symbiosis Between


Banks, Application Service Providers and Mobile Network Operators. In: THIRD
INTERNATIONAL CONFERENCE, 2006. Information Technology: New Generations.
ITNG, 2006. p. 346 - 350. Disponível em:
<http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1611617&isnumber=33849>.
Acesso em: 01 out. 2012.

ELAP (Empresa Latino-americana de Publicações). Transação : p.654. In: Anuário


Brasileiro de Meios Eletrônicos de Pagamento; São Paulo, 2011.

EMVCO. Book 4 - Cardholder, Attendant, and Acquirer Interface Requirements. 4.3,


2011. 140 p. Disponível em: <http://www.emvco.com/specifications.aspx>. Acesso em: 22
set. 2012.

GALHO, Ricardo. Problemas em Rede Multi-serviços. [mensagem pessoal] Mensagem


recebida por: <rgalho@getnet.com.br>. em: 02 jan. 2013.
97

GETNET. Especificação Técnica para Meio de Captura POS. Porto Alegre, 2011. 175 p.

GETNET. Especificação Técnica para Meio de Captura POS. São Paulo, 2010. 119 p.

GETNET. Sobre a GetNet. Disponível em: <http://www.getnet.com.br/site/home>. Acesso


em: 18 ago. 2012a.

GETNET. Recarga Telefônica. Disponível em: <http://www.getnet.com.br/site/page-


recarga-telefonica>. Acesso em: 13 out. 2012b.

GRISI, Celso Cláudio de Hildebrand e. Correspondentes Bancários: A alternativa capilarizada


dos bancos. Meios Eletrônicos de Pagamento: Anuário Brasileiro 2011, São Paulo, p.41-54,
2012. Anual.

IBM, International Business Machines. ASCII and EBCDIC character sets. Disponível em:
<http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=%2Fcom.ibm.xl
f101a.doc%2Fxlflr%2Fasciit.htm>. Acesso em: 07 out. 2012.

INGENICO. Counter Top EFT 930 Series. Disponível em:


<http://www.ingenico.com/zee_uploads/all/all/gallery_gallery/4125/eft930s-series-en.pdf>.
Acesso em: 13 out. 2012.

IPIRANGA. Regulamento do consumidor para o programa de fidelidade km de


vantagens. Disponível em: <https://www.kmdevantagens.com.br/Nregulamento.asp?>.
Acesso em: 13 out. 2012.

ISO, International Organization for Standardization. ISO 8583-1993: Financial Transaction


Card Originated Messages – Interchange Message Specifications. 2. ed. Geneve - Suíça, 1993.
128 p.

ISO, International Organization for Standardization. ISO 8583-1993: Financial Transaction


Card Originated Messages – Interchange Message Specifications. Disponível em:
<http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=15871
>. Acesso em: 20 set. 2012.

MASTERCARD, MasterCard Academy. The Customer Interface Specification Format.


2010. Disponível em: < http://www.mastercardacademy.com>. Acesso em: 18 ago. 2012.

MASTERCARD, MasterCard Academy. MasterCard Debit Financial Simulator. 2005.


Disponível em: < http://www.mastercardacademy.com>. Acesso em: 18 ago. 2012.

MASTERCARD. M-TIP Process Guide. Disponível em:


<http://www.paypass.com/TIP/MTPG_Manual.pdf>. Acesso em: 05 out. 2012a.

MASTERCARD. Benefícios ao aceitar os cartões MasterCard. Disponível em:


<http://www.mastercard.com/br/merchant/pt/benefits_accepting/index.html>. Acesso em: 20
set. 2012b.
98

MASTERCARD. O Passo-a-passo de uma transação. Disponível em:


<http://www.mastercard.com/br/sobre_nos/pt/transacao.html>. Acesso em: 20 set. 2012c.
99

MATBOULI, Hatoon; GAO, Qigang. An Overview on Web Security Threats and Impact to e-
commerce Success. In: INTERNATIONAL CONFERENCE, 1., 2012, [S.l.]. Information
Technology and e-Services (ICITeS). [S.l.:s.n.], 2012. p. 1 - 6. Disponível em: <URL:
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6216645&isnumber=6216590>.
Acesso em: 01 out. 2012.

NERDWALLET. Credit Card and Debit Card Transaction Volume Statistics. Disponível
em: <http://www.nerdwallet.com/blog/credit-card-data/credit-card-transaction-volume-
statistics/>. Acesso em: 17 out. 2012.

PARAGON. About Us. Disponível em: <http://www.paragonedge.com/company/about-


us.html>. Acesso em: 27 out. 2012.

PRODANOV, Cleber; FREITAS, Ernani Cesar de. Metodologia do Trabalho Científico:


métodos e técnicas da pesquisa e do trabalho acadêmico. 1ª ed. Novo Hamburgo: FEEVALE,
2009. 288p.

REDECARD. PIN PAD: O que é?. Disponível em: <http://www.redecard.com.br/pt-


BR/produtosservicos/Paginas/pinpad.aspx>. Acesso em: 20 set. 2012a.

REDECARD. Soluções: Terminais. Disponível em: <http://www.redecard.com.br/pt-


BR/produtosservicos/Paginas/maquininhacomfio.aspx>. Acesso em: 20 set. 2012b.

ROGER CHENG. CNET. Visa: Mobile payments will hit mainstream in 2 to 3 years.
Disponível em: <http://news.cnet.com/8301-1035_3-57478991-94/visa-mobile-payments-
will-hit-mainstream-in-2-to-3-years/>. Acesso em: 13 out. 2012.

SANTANDER. Soluções de POS. Disponível em:


<https://www.santandergetnet.com.br/site/Tecnologia/solucoes-pos>. Acesso em: 20 set.
2012a.

SANTANDER. Soluções de TEF. Disponível em:


<https://www.santandergetnet.com.br/site/Tecnologia/solucoes-tef>. Acesso em: 20 set.
2012b.

VISA. Welcome to Visa Test System: V.I.P. User's Guide. Disponível em:
<http://www.visa.com>. Acesso em: 20 out. 2012a.

VISA. VTS/3 workshop. Disponível em: <http://www.visabs.com/default.aspx?e=106>.


Acesso em: 05 out. 2012b.

YAMAGUTI, Claudio. O Mercado Brasileiro de Cartões de Pagamento. 2012. Disponível


em: < http://www.abecs.org.br/site2012/artigos.asp >. Acesso em : 18 ago. 2012.
APÊNDICE A – EXEMPLO DE INTERCÂMBIO

Esse apêndice tem o propósito de exemplificar um intercâmbio de mensagens ISO


8583 entre duas entidades (terminal POS e host). O mapa de bits das mensagens é baseado na
Figura 6.1 e o fluxo transacional na Figura 6.2.

Figura 6.1 – Mapa de bits autorização (exemplo)


Fonte: do Autor

Figura 6.2 – Fluxo de mensagem (exemplo)


Fonte: do Autor

Quando o terminal envia um mensagem de requisição ao host, esse recebe um buffer


equivalente a Figura 6.3. Esse buffer está codificado no formato ASCII, sua interpretação
resulta na Figura 6.4. A Figura 6.5 detalha o conteúdo recebido em seus devidos campos.
101

Figura 6.3 – Dump da mensagem de requisição


Fonte: do Autor

Figura 6.4 – Mensagem de requisição em ASCII


Fonte: do Autor

Figura 6.5 – Mensagem de requisição detalhada


Fonte: do Autor
102

Após processar a mensagem recebida, o host envia uma mensagem de resposta ao


terminal. O dump da mensagem enviada é representado na Figura 6.6 e sua tradução em
ASCII na Figura 6.7. O detalhamento dos campos da mensagem de resposta é ilustrado na
Figura 6.8.

Figura 6.6 – Dump da mensagem de resposta


Fonte: do Autor

Figura 6.7 – Mensagem de resposta em ASCII


Fonte: do Autor

Figura 6.8 – Mensagem de resposta detalhada


Fonte: do Autor

Você também pode gostar