Post Técnico
Desenvolvendo para EMV, Parte I
A ID TECH fabrica e comercializa uma ampla variedade de dispositivos de pagamento, quase todos compatíveis, atualmente, com "cartões com chip" (ou "cartões inteligentes"). Os pagamentos realizados com cartão com chip são genericamente chamados de "EMV por contato" ou, simplesmente, "EMV". (EMV, claro, é a sigla para Europay, MasterCard e Visa — o consórcio das bandeiras de cartão.)
Em termos técnicos do setor, uma transação EMV é aquela que está em conformidade com os requisitos dos quatro volumes das EMV Integrated Circuit Card Specifications for Payment Systems (disponíveis em https://www.emvco.com/). Compreender essa especificação demanda tempo. Com quatro volumes, trata-se de um documento bastante extenso. No entanto, a ID TECH busca tornar a "compatibilidade com EMV" um objetivo acessível para os desenvolvedores, oferecendo uma variedade de ferramentas gratuitas, SDKs, demonstrações e outros recursos projetados para acelerar o tempo de chegada ao mercado para integradores de PDV e demais profissionais que precisam de resultados rápidos. conformidade com EMV.
EMV: Por Onde Começar?
A maioria dos novos clientes da ID TECH possui um bom nível de conhecimento técnico. Mesmo assim, há uma grande variação no grau de familiaridade com EMV que cada cliente traz para um novo projeto. A maior parte conhece muito bem os sistemas de pagamento no contexto de MSR (leitores de tarja magnética). Alguns já trabalharam com EMV anteriormente, mas não conhecem o sem contato EMV. Outros são novos no próprio EMV.
Como referência, costumamos recomendar aos integradores que consultem o white paper gratuito da ID TECH chamado EMV Transactions with the Universal SDK. A primeira metade deste white paper de 25 páginas é uma revisão sobre o fluxo de eventos EMV. Os principais eventos desse fluxo podem ser resumidos da seguinte forma:
Em cada etapa desse processo, o leitor de cartão se comunica com o chip do cartão inteligente utilizando protocolos de baixo nível definidos na norma ISO-7816. Praticamente toda a lógica do leitor de cartão para isso está isolada no que é conhecido como EMV Level 2 kernel. Em outras palavras, está fora do alcance do desenvolvedor do aplicativo de pagamento, que só precisa se preocupar em enviar comandos ao kernel (e não ao cartão em si). Mas mesmo isso não é totalmente preciso. Na prática, o desenvolvedor do aplicativo de pagamento enviará comandos ao leitor; e o leitor se encarregará das interações subjacentes necessárias com o kernel, que (por sua vez) interagirá com o cartão.
Comunicação com o Leitor
Como você envia comandos para o leitor? Há duas opções:
- Estabeleça a conectividade (geralmente via USB ou RS-232) com o leitor e envie comandos de firmware diretamente para ele. Ou então:
- Usando um SDK em linguagem de alto nível, escreva código (em C/C++, C#, Objective-C, Java ou Swift) que utilize a biblioteca SDK apropriada da ID TECH para emitir os comandos de firmware subjacentes.
O segundo método é geralmente mais fácil, pois exige relativamente pouco tempo para dominar as APIs de alto nível do Universal SDK da ID TECH (além disso, disponibilizamos uma grande quantidade de código de exemplo para servir como base). A desvantagem da opção 2 é que ela tende a vincular seu aplicativo a uma única linguagem de desenvolvimento e sistema operacional. Com a opção 1, a escolha da linguagem (e do sistema operacional) fica a seu critério, mas é necessário aprender a API de comandos de firmware em nível de byte do dispositivo em questão e lidar com todos os problemas de conectividade por conta própria.
Independentemente de você optar por se comunicar diretamente com o leitor de cartão (via conexão serial, usando comandos de firmware brutos) ou por meio da conectividade integrada e dos comandos de alto nível do Universal SDK, é importante entender que uma transação EMV (aqui, estou me referindo ao contato EMV tradicional, não ao contactless) ocorre em três etapas. Na terminologia do Universal SDK, chamamos essas etapas de Iniciar Transação, Autenticar Transação e Concluir Transação. (Cada uma possui um método ou função correspondente no USDK.) Do ponto de vista do fluxo do programa, isso significa que o kernel devolve o controle ao chamador duas vezes durante o fluxo da transação: uma vez, após o retorno de Iniciar Transação; e uma segunda vez, após Autenticar Transação (mas antes de Concluir Transação). Esses pontos de interrupção têm implicações importantes para o fluxo de dados, pois, entre outras coisas, diferentes TLVs (triplas tag-comprimento-valor) são retornados após cada fase da transação, e é fundamental capturar os TLVs necessários no momento em que estão disponíveis, pois eles podem não estar acessíveis em uma fase posterior. Exemplo típico: a Tag 57 (dados da Trilha 2) está disponível ao final de Iniciar Transação (mas não ao final de Concluir Transação).
Criptogramas em EMV
Um dos dados mais importantes em qualquer transação EMV é o Criptograma de Aplicação retornado na tag 9F26. Uma sessão EMV com contato normalmente produz dois criptogramas (9F26 é retornado duas vezes): um gerado antes da conclusão da transação e outro após. O evento que solicita ao cartão a geração do criptograma é chamado de requisição Gen AC (Generate Application Cryptogram).
A importância desses criptogramas reside no fato de constituírem a prova irrefutável de que um cartão com chip genuíno e legítimo estava fisicamente presente em uma determinada transação. (Eles também certificam os valores específicos dos dados gerados durante aquela transação.) No momento do Gen AC, o kernel L2 apresenta ao cartão com chip uma lista de objetos de dados (contendo dados específicos da transação em curso), e o cartão com chip responde utilizando sua chave privada (conhecida apenas pelo chip) para assinar esses dados e produzir um artefato digital inforjável — um criptograma de 8 bytes — que atesta a legitimidade do cartão e dos dados. A autenticidade do criptograma pode ser verificada pela autoridade online que, em última instância, aprovará ou recusará a transação. É para isso que os cartões com chip foram criados e é por isso que o EMV existe. Os dados de MagStripe são fáceis de falsificar. Os criptogramas gerados sob demanda por um chip, não.
No próximo post, daremos continuidade a esta discussão analisando os tipos de criptogramas que o cartão pode produzir, o que eles significam, o que o desenvolvedor de aplicações de pagamento precisa fazer com eles e como impactam o sucesso ou a falha de uma transação. Não perca a Parte II!
Tem dúvidas sobre transações EMV? Leitores de cartão? Tecnologia sem contato? Carteiras digitais? Fale com nossos especialistas: