Conheça o EMV

Processos de monitoramento de transações adotados pelo sistema de bilhetagem digital desenvolvido pela ONBOARD em atendimento às especificações da indústria de pagamentos.

Objetivo

As informações detalhados a seguir, contextualizam o funcionamento do sistema, bem como a terminologia e a codificação adotadas, os modelos de relatórios atualmente disponíveis pelo sistema de Bilhetagem Digital, as implementações e ajustes adotados na mitigação de vulnerabilidades diagnosticadas. Importante destacar que o sistema e a indústria de pagamentos estão em constante evolução e aperfeiçoamento.

1. EMV Contactless- Certificação L3

Somente um sistema certificado L3 pode aceitar pagamentos EMV. Os processadores de pagamento certificam sistemas de pagamento EMV. Os provedores de aplicativos de pagamento solicitam a certificação L3 junto aos processadores de pagamento e seguem o processo de inscrição de cada processador para obter a certificação L3. O aplicativo de pagamento, o terminal de pagamento e a rede precisam passar por um conjunto de testes para receber a certificação. O aplicativo e o dispositivo de pagamento precisam ser desenvolvidos e configurados juntos para que possam passar em todos os testes exigidos em cada Ferramenta de Teste de Marca ( “Brand Test Tool- BTT”). As certificadoras independentes oferecem o BTT mais comum em uso.

Os integradores, no caso a ONBOARD, que concluem os testes de certificação EMV L3 têm um produto e um processador de pagamentos com quem trabalhar para obter a certificação.

O DBD possui certificação das bandeiras Visa, Elo e Mastercard, para a categoria L3 de certificação, que compreende o caminho seguro entre o dispositivo que capta a transação, no caso uma leitora contactless e o adquirente/emissor. Isto garante que as informações trafegadas pelo canal de utilização sejam seguras e não violáveis, obedecendo ao padrão da indústria de meios de pagamento. Mais informações podem ser obtidas diretamente da EMVco, responsável pelos padrões da indústria de pagamentos.

As certificações emitidas para a ONBOARD estão disponíveis neste link, referente ao “Conjunto de tecnologias, práticas, métodos e procedimentos de segurança implementados, incorporados e adotados pelo sistema de Bilhetagem Digital desenvolvido pela ONBOARD” enviado anteriormente em atendimento a outra solicitação da OAC.

2. Integração e homologação com a Adquirência Multi-bandeira (Cielo)

Para que uma transação EMV (por cartão de crédito ou débito) ocorra, as informações adquiridas na requisição de dados da leitora para o cartão deve ser enviada para a bandeira do cartão (Visa, Mastercard ou Elo), de forma que, se ocorrendo corretamente, a transação será aprovada e o valor debitado. Para que isso ocorra é necessário utilizar os serviços de um adquirente, responsável por tratar as informações de diversas bandeiras e encaminhar para a correta. Deste modo, este documento estará especificando funções utilizadas para que este processo seja validado na Adquirente Cielo.

O método utilizado para homologação da cobrança de tarifas com valores conhecidos (fixos) é o KFT (“Know Fare Transaction”). Pela documentação da Cielo (MassTransit) é possível notar que nem todas as TAGs necessárias para efetuar uma transação estão documentadas corretamente, fazendo com que seja necessário um breve estudo para saber como se comportam e como devem ser enviados todos os parâmetros. Depois de algumas validações e conversas com a equipe da Cielo, definimos que o seguinte Payload é válido para as transações EMV na API da Cielo.

3. Bloqueio de cartões EMV

Tendo em mente que o sistema aborda o método de pagamento do tipo online diferido, ou seja, a transação ocorre de forma online, e caso haja conexão, posteriormente, será enviada e processada no backoffice. Portanto, por meio do uso deste modelo, existem algumas formas de uma transação do tipo EMV ser recusada em uma tentativa de embarque, podendo ser pela própria leitora ou por inclusão em software.

a) Bloqueio na leitora:

Atualmente, o sistema utilizado para uma transação ser realizada no Dispositivo de Bilhetagem Digital (DBD) é o método de valor conhecido (KFT).

Deste modo, para uma transação ocorrer corretamente na leitora, deverá ser inserido um valor conhecido por trecho ou linha e o criptograma deverá ser gerado da forma correta, permitindo que o conjunto de dados obtidos possam ser validados em uma adquirente. No caso, pela Cielo.

I. ARQC- Authorization Request Cryptogram

Este é o resultado obtido após a validação do criptograma gerado pela leitora. Nesta etapa ocorrem algumas verificações para validar se este cartão é legível ou não, tais como, autenticação por aproximação, data de validade, valor inserido e outros. Este processo não é puramente online, ou seja, arrisca ser recusado na adquirente por algum motivo que não esteja atrelado somente ao saldo do cliente ou pelo bloqueio do cartão pelo usuário.

Atualmente, cartões com a bandeira do tipo VISA ou MASTERCARD podem conter esse tipo de retorno. E caso seja retornado algum valor diferente do ARQC ou do TC(“Transaction Certificate”) o embarque será bloqueado.

II. TC- Transaction Certificate

Este método contém as mesmas validações do método ARQC, porém ele traz maiores garantias para a transação online, fazendo com que o motivo de bloqueio na própria leitora seja reduzido.

Atualmente, cartões com a bandeira do tipo MASTERCARD, VISA ou ELO podem conter esse valor, porém somente os cartões da ELO possuem todos os retornos de criptograma com o valor TC. Caso seja apresentado algum valor diferente, para cartões do tipo ELO, a transação será recusada.

b) Retorno negativo pela adquirente:

A adquirente é responsável por fazer a validação dos dados obtidos em uma tentativa de cobrança, sendo responsável por validar a transação em paralelo com o banco. Deste modo, caso uma transação seja negada no banco, será enviado um código para ser possível tratar no backoffice e posteriormente adicionar o dispositivo utilizado na denylist, evitando que o mesmo dispositivo seja utilizado mais de uma vez.

A Tabela Oficial dos possíveis erros estão disponíveis no Normativo n.º21 da Associação Brasileira das Empresas de Cartões de Crédito e Serviços (ABECS) e disponíveis neste link.

c) Denylist:

Nesta etapa, os dados da transação são emitidos corretamente, porém existe a recusa por parte da adquirente e um dos motivos listados pela tabela ABECS é apresentado para o backoffice. Neste momento, o dispositivo é adicionado em uma lista de restrição até que o débito seja regularizado, permitindo somente um embarque. Esta necessidade existe, pois o método utilizado é do tipo online, uma vez que existem regiões com sombra de sinal, é necessário que a transação de transportes necessitem da utilização deste método. Existe uma identificação única para cada cartão de crédito, fazendo com que o mesmo dispositivo possa ser identificado em qualquer DBD.

4. Terminologia e a codificação adotadas

Segundo o Normativo n.º21 da ABECS, as Bandeiras associadas deverão efetuar os ajustes sistêmicos necessários exclusivamente sobre os códigos de motivos que passam por conversões no envio ao Credenciador ou fornecer as devidas orientações para as situações diferenciadas que devem ser agrupadas em algum determinado código de resposta.

Para fins de entendimento, as definições de transação reversível e transação irreversível, bem como os respectivos tratamentos a serem dados a cada uma destas transações, encontram-se no quadro a seguir:

5. Recuperação de transações

Quando uma pessoa tenta fazer uma compra com cartão na sua loja, a transação pode ser negada devido a uma série de fatores. As tentativas seguintes de concluir a transação usando o mesmo cartão é o que chamamos de retentativa.

A retentativa será permitida ou não dependendo da classificação do código de recusa da primeira transação, que varia para cada bandeira como já detalhado no tópico anterior:

Irreversível: não é permitido realizar a retentativa (o emissor nunca aprovará);
Reversível: é possível realizar a retentativa, de acordo com as regras de cada bandeira.

As retentativas podem ser cobradas pela bandeira e a quantidade de vezes que uma transação pode ser retentada antes da cobrança também varia de acordo com a bandeira.

A retentativa pode trazer um resultado positivo e converter transações que foram previamente negadas, porém o uso excessivo pode acabar prejudicando o EC perante aos emissores. O excesso de retentativas pode diminuir o índice de aprovação do estabelecimento e/ou gerar multa ao retentar de maneira incorreta.

Atualmente, o procedimento de retentativas de cobrança das transações que não foram processadas e o procedimento é esse mesmo. A cada 10 (dez) minutos há um reprocessamento de lotes de transações. Caso a transação não seja aprovada nas retentativas do dia haverá uma programação de retentativas, atualmente parametrizada para acontecer em D+1, D+3, D+6, D+12.

Além disso, acontecerá uma retentativa toda vez que esse cartão contido na denylist for apresentado ao equipamento.

6. Relatórios de monitoramento de transações

A seguir, serão listados alguns relatórios atualmente disponíveis no Sistema de Bilhetagem Digital da ONBOARD. Além desses relatórios, a adquirente (Cielo) e as bandeiras (Visa, Mastercard e Elo) também possuem relatórios próprios que podem ser confrontados e auditados com os relatórios do Sistema de Bilhetagem Digital.

Disponíveis no Módulo “Relatórios”, submódulo “Arrecadação” e submódulo de segundo nível “Ocorrências EMV”, em todos os relatórios disponíveis é possível utilizar o filtro para buscar as informações por:

Dia;
Período;
Linhas;
Carros;
Bandeiras;
Tipo de transação;
Status;
NSU.

Além disso, é possível exportar os relatórios de cada aba em PDF, CSV e XLS.

6.1 Reprovação por motivo

O relatório “Reprovação por motivo” exibe a quantidade de cada motivo de reprovação. Os motivos são padrões EMV e são enviados pela Cielo. Os dados exibidos são: valor absoluto, porcentagem e visualização gráfica.

6.2 Aprovação por tentativa

O relatório “Aprovação por tentativa” exibe uma tabela com a quantidade de embarques por número de tentativas, tanto em valor total quanto por bandeira. No rodapé da tabela, é exibido o total de embarques em valor absoluto e valor percentual total e por bandeira.

6.3 Aprovação por Debt Recovery

O relatório “Aprovação por Debt Recovery” informa, por bandeira, a relação entre o número total de embarques e, desses embarques, quantos foram aprovados via debt recovery — tanto em valor absoluto quanto em porcentagem.

6.4 Aprovação por bandeira

O relatório “Aprovação por bandeira” exibe, por bandeira, a quantidade de utilizações e, dessas utilizações, quantas foram aprovadas, reprovadas e a taxa de aprovação.

6.5 Aprovação 1º tap por bandeira

O relatório “Aprovação 1º tap por bandeira” exibe, por bandeira, a quantidade de aprovações e, dessas, quantas foram no 1º tap, assim como a taxa de aprovação.

relatórios-emv-final.mp4

7. Implementações e desenvolvimentos realizados para aumentar a taxa de aprovação

A seguir estão descritas algumas implementações realizadas a partir das análises dos códigos de retorno das transações negadas. O objetivo dessas implementações é aumentar a taxa de conversão (aprovação) das transações.

7.1 Dupla Aquisição

As transações bancárias ocorrem, normalmente, por meio de cartões de crédito ou débito. No entanto, atualmente, um cartão pode ser utilizado unicamente como crédito, ou unicamente como débito ou múltiplo, que contenha ambos os métodos de pagamento. Deste modo, faz se necessário a seleção de prioridade da cobrança conforme o tipo do cartão. Vale salientar que para cartões múltiplos, a prioridade é selecionada pelo seu emissor (“banco”) ou por carteiras utilizadas em dispositivos inteligentes, tais como smartphones e smartwatches.

Anteriormente, transações do tipo EMV eram realizadas conforme a prioridade de seleção existente no cartão ou nas wallets. No entanto, foi observado que em alguns casos, a prioridade do cartão foi gerada de forma errada ou sua modalidade prioritária foi inativada, fazendo com que um cartão que deveria funcionar somente como crédito fosse analisado como débito. Deste modo, o dispositivo era validado de forma online e recusado de forma online.

Após a validação de que a seleção automática não podia garantir que a transação ocorresse corretamente, foi necessário inserir uma aquisição dupla de ambos os tipos com o intuito de garantir que aquela transação ocorresse em uma das modalidades existentes. Deste modo, caso a seleção automática possibilite uma transação do tipo crédito, uma segunda transação será realizada com o tipo oposto, neste caso, de débito.

Vale salientar que esse modelo é válido somente para dispositivos físicos e não para dispositivos virtuais.

7.2 Problemas com cartões virtuais

Foi analisado, em produção, com o grande uso em carteiras digitais, alguns problemas relacionados à transações do tipo EMV. Deste modo, este documento tem como intuito, informar os problemas encontrados e possíveis soluções aplicadas quando possível.

a) Cartões de Débito/Crédito em Wallets

As wallets são carteiras virtuais disponibilizadas por smartphones ou smartwatches que conseguem processar transações do tipo EMV ao cadastrar um cartão válido no aplicativo do dispositivo a ser utilizado. Deste modo, um cartão virtual é gerado com novos dados, possuindo um novo PAN Primary Account Number e um novo HASH.

Portanto, sempre que um cartão virtual fosse removido e adicionado na wallet, um novo cartão era gerado, fazendo com que um usuário sem saldo ou com restrições no dispositivo anterior conseguisse realizar uma nova transação por não possuir a identificação deste novo dispositivo.

Foi analisado por meio do suporte técnico da Mastercard, que cartões virtuais possuem um identificador PAR (Payment Account Reference) que é único e invariável quando gerados por um mesmo cartão, seja este virtual ou físico. Deste modo, sempre que uma transação é realizada por uma wallet, procura-se pelo PAR e não pelo HASH do cartão físico. Possibilitando a identificação do dispositivo mesmo que ele seja removido e adicionado a uma nova wallet.

b) Novos cartões virtuais gerados diariamente

Após analisar algumas transações, foi observado que um novo PAR estava sendo adicionado na denylist e não estava sendo recuperado. Deste modo, foram realizados alguns testes com o intuito de produzir o mesmo comportamento observado em logs e outras análises em conjunto com a equipe da Mastercard. Deste modo, identificou-se um problema que depende de uma solução por parte dos bancos (emissores), que permitem a criação de cartões virtuais sem nenhuma restrição.

O problema se dá pelo fato de um cartão poder ser utilizado por dispositivos inteligentes somente se adicionado na wallet. Caso um cartão virtual seja adicionado na wallet, será gerado um cartão com PAN e HASH novos, porém com um único PAR

No entanto, caso o cartão virtual seja deletado e um novo cartão virtual seja gerado. Devido aos novos dados do cartão virtual, o cartão que será adicionado na wallet conterá o PAN, o HASH e o PAR com valores diferentes, fazendo com que seja impossível rastrear o dispositivo virtual deletado anteriormente. Portanto, utilizando deste meio de fraude, o usuário sempre será adicionado na denylist após a autorização do seu “primeiro” embarque.

Para manter a transação com os princípios de conexões estabelecidos em uma transação do tipo Online Diferida, que pode funcionar de forma online em casos com perda de conexão, os bancos precisam fazer uma modificação na geração de cartões virtuais ou restringir a quantidade de cartões que podem ser gerados. Outra solução é fazer com que toda a transação seja processada online. O problema desta abordagem é o aumento na espera da validação dos dados obtidos e erros relacionados a possíveis perdas de comunicação com a rede de internet.

Atualizações:

🚩Correção deste problema para Nubank + Mastercard em dezembro de 2024.

c) Cartões de alimentação e ou refeição que são utilizados na trilha de crédito

Com a atual abertura do arranjo de pagamentos dos cartões de benefício (alimentação e refeição), foram emitidos cartões de benefício que transacionam utilizando a trilha dos cartões de crédito, ou seja, é possível utilizar um cartão de alimentação na modalidade “crédito”, controlando sua aceitação pelo Merchant Category Code — MCC.

Como os cartões das bandeiras Visa e Mastercard possuem homologação do tipo ARQC, ou seja, possuem autenticação online, mas precisam de aprovação online, alguns casos de fraude são passíveis de existirem. Este é o caso dos cartões de alimentação e/ou refeição dessas bandeiras desenvolvidos para serem utilizados na trilha de crédito, fazendo com que seja emitido uma autorização ARQC, pois os dados são válidos, e posteriormente recusado no processamento online, pois o código de transporte não pode ser utilizado para estes fins.

Assim que este tipo de transação é identificada, o cartão é adicionado na denylist. No entanto, a primeira transação sempre é permitida, atendendo os princípios da transação online diferida, o que para indústria de pagamentos é conhecido como “First Ride Risk”.

Uma vez que o Sistema de Bilhetagem Digital não tem como mudar o tipo do criptograma recebido de ARQC para TC, a única solução definitiva para bloquear o acesso antecipado deste tipo de dispositivo é com a transação puramente online, algo que não é recomendado para transportes.

7.3 Verificação de Tap Lateral

A funcionalidade de verificação de tap lateral está no arcabouço de verificações online por requisição entre o backend do Sistema de Bilhetagem Digital e o DBD — Dispositivo de Bilhetagem Digital —, garantindo assim mais segurança contra possíveis fraudes e usos indevidos de mídias de acesso.

Essa funcionalidade visa impedir que o usuário consiga utilizar uma determinada mídia de acesso em uma janela de tempo, evitando o mesmo passe em DBDs próximos ou no mesmo aparelho. Após esse período parametrizável a mídia pode ser novamente utilizada.

Page updated

Report abuse