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 denominados "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 completamente essa especificação exige tempo. Com quatro volumes, trata-se de um documento bastante extenso. No entanto, a ID TECH procura tornar a "compatibilidade com EMV" uma meta facilmente alcançável para os desenvolvedores, oferecendo uma variedade de ferramentas gratuitas, SDKs, demonstrações e outros recursos criados para acelerar o tempo de lançamento no mercado de integradores de POS e demais profissionais que precisam de resultados rápidos. conformidade EMV.
EMV: Por Onde Começar?
A maioria dos novos clientes da ID TECH possui um bom nível de conhecimento técnico. Ainda assim, há grande variação no grau de familiaridade com EMV que cada cliente traz para um novo projeto. A maior parte conhece bem os sistemas de pagamento no contexto de leitores MSR (leitores de tarja magnética). Alguns já trabalharam com EMV, mas não têm experiência com EMV sem contato . Outros ainda são completamente novatos no EMV.
Como referência, geralmente recomendamos 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 do 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 ISO-7816. Praticamente toda a lógica do leitor de cartão para isso está encapsulada no que é conhecido como EMV Level 2 kernel. Em outras palavras, está fora do alcance do desenvolvedor do aplicativo de pagamento, que precisa se preocupar apenas em emitir comandos para o kernel (e não para o cartão em si). Mesmo isso é uma afirmação um pouco imprecisa. O desenvolvedor do aplicativo de pagamento, na verdade, enviará comandos para o leitor; e o leitor cuidará das interações subjacentes necessárias com o kernel, que (por sua vez) irá interagir com o cartão.
Comunicação com o Leitor
Como você envia comandos ao leitor? Há duas opções:
- Estabeleça a conectividade (normalmente via USB ou RS-232) com o leitor e envie comandos de firmware diretamente para ele. Ou então:
- Utilizando um SDK de linguagem de alto nível, escreva código (em C/C++, C#, Objective-C, Java ou Swift) que aproveite a biblioteca SDK apropriada da ID TECH para emitir os comandos de firmware subjacentes.
O segundo método é geralmente mais fácil, pois requer comparativamente 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 de base). A desvantagem da opção 2 é que ela tende a vincular o seu aplicativo a uma única linguagem de desenvolvimento e sistema operacional. Com a opção 1, a escolha da linguagem (e do SO) fica a seu critério, mas é necessário aprender a API de comandos de firmware (em nível de bytes) do dispositivo em questão e gerenciar todos os aspectos 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, é fundamental compreender que uma transação EMV — e aqui me refiro ao EMV de contato tradicional , não ao sem contato — ocorre em três etapas. Na terminologia do Universal SDK, essas etapas são denominadas 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 pausa têm implicações importantes para o fluxo de dados, pois diferentes TLVs (triplas tag-comprimento-valor) são retornados após cada fase da transação, e é essencial capturar os TLVs necessários no momento em que estiverem 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 de contato normalmente gera dois criptogramas (o 9F26 é retornado duas vezes): um antes de Concluir Transação e outro depois. O evento que solicita ao cartão a geração do criptograma é denominado requisição Gen AC (Generate Application Cryptogram).
O motivo pelo qual esses criptogramas são importantes é que constituem a prova irrefutável de que um chip de cartão 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 essa transação.) No momento do Gen AC, o kernel L2 apresenta ao chip do cartão uma lista de objetos de dados (contendo dados específicos da transação atual), e o chip do cartão responde utilizando sua chave privada (conhecida apenas pelo chip) para assinar esses dados e produzir um artefato digital impossível de falsificar (um criptograma de 8 bytes) que atesta a legitimidade do cartão e dos dados. A legitimidade do criptograma pode ser verificada pela autoridade online que, em última instância, autorizará a transação (ou a recusará, conforme o caso). É para isso que os cartões com chip foram criados, e é por isso que o EMV existe. Os dados de tarja magnética são fáceis de falsificar. Os criptogramas gerados sob demanda por um chip, não.
No próximo artigo, daremos continuidade a essa discussão analisando os tipos de criptogramas que o cartão pode produzir, o que eles significam, o que o desenvolvedor de aplicativos de pagamento precisa fazer com eles e como eles 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? Entre em contato com nossos especialistas: