Post Técnico
Primeiros Passos na Integração com Gateway de Pagamento
Colocar um aplicativo de pagamento em funcionamento significa ser capaz de lidar com pelo menos dois tipos diferentes de integração: primeiro, é preciso saber como integrar o hardware necessário (ou seja, o leitor de cartão e o dispositivo ao qual ele está conectado); depois, é preciso saber como integrar um "back end" de pagamentos, como um gateway de pagamento online (a parte responsável por "aprovar" a transação e processá-la para liquidação).
Em posts anteriores, já falei bastante sobre a parte de integração de hardware desse processo, que acaba não sendo tão difícil assim, pois com os leitores de cartão da ID TECH você pode usar nosso Universal SDK para se comunicar com os dispositivos a partir de um ambiente de linguagem de alto nível, ou optar por uma solução totalmente em JavaScript, caso esteja disposto a incluir o Node JS em sua arquitetura. De qualquer forma, comunicar-se com os dispositivos da ID TECH não é, na prática, uma tarefa muito complexa.
Mas a questão continua: depois de fazer o leitor de cartão de crédito ler o chip ou a tarja magnética do cartão, como converter essas informações em uma transação aprovada?
Provavelmente, você já sabe qual processadora de cartões irá processar suas solicitações. Portanto, o desafio se resume a descobrir que tipo de suporte a SDK sua processadora ou gateway oferece para o atendimento de requisições online.
A maioria dos gateways ou processadoras possui um programa para desenvolvedores, ou um portal de desenvolvimento online, onde é possível obter SDKs para a criação de aplicativos de pagamento. Os SDKs geralmente permitem construir uma combinação de componentes front-end e back-end para acessar as APIs de pagamento da processadora. Essas APIs, por sua vez, suportam o envio de dados de MagStripe e/ou de cartão com chip (ICC) pela rede até uma processadora de back end, com o objetivo de obter autorização em tempo real.
A autorização de pagamento é, na verdade, apenas um dos vários tipos de requisição online que você provavelmente precisará suportar. Alguns dos outros tipos de requisição estão listados na tabela abaixo.
Tipo de Requisição
Descrição
Auth
Solicitar autorização de pagamento
Conf
Confirmar uma solicitação de autorização anterior
Offline
Liquidar uma transação EMV offline
PreAuth
Confirmar que os dados do cartão são válidos por meio de uma transação de pequeno valor
Refund
Reembolsar uma transação liquidada anteriormente
Test
Testar a conectividade com o processador
VoiceReferralNotification
Notificar o processador sobre o resultado de uma solicitação de referência por voz
Anular
Utilizado para anular uma transação que ainda não foi liquidada
Ao estudar a documentação do SDK do seu processador de pagamentos, você perceberá que uma grande variedade de códigos de resultado e/ou códigos de erro se aplica a cada tipo de transação. Como testar todos esses possíveis tipos de erro? Resposta: a maioria dos processadores adota um esquema no qual o valor em centavos de uma transação pode ser definido como um valor especial para acionar um erro específico em um ambiente de sandbox de testes. (Por exemplo, se o código de erro para Valor Muito Alto for 1243, o SDK poderá permitir que você acione esse erro específico enviando uma transação de teste no valor de R$ 12,43.) Consulte a documentação do SDK do seu provedor para mais detalhes.
Muitos processadores de pagamentos oferecem soluções "in app" pré-certificadas (semi-integradas) que permitem encaminhar dados de cartão criptografados diretamente ao back-end de forma praticamente transparente, mantendo seu aplicativo de pagamentos fora do escopo PCI, enquanto outros pressupõem que você mesmo lidará com as questões de escopo. Nesse caso, você provavelmente enviará os dados criptografados do cartão pela rede até o servidor próprio, protegido por um firewall, onde — com o auxílio de um HSM — os dados serão descriptografados antes de serem encaminhados a um adquirente ou gateway.
UM EXEMPLO
Chega de visão geral em alto nível. Vamos falar sobre o que significa, na prática, integrar-se a um back-end de pagamentos.
Este exemplo específico não se aplica a todos os casos — nenhum exemplo único consegue abranger tudo —, mas deve dar uma ideia do que você provavelmente encontrará ao integrar-se a um back-end.
Neste caso, fui encarregado de desenvolver um aplicativo de demonstração de "terminal virtual" que envia dados de transação ao CreditCall servidor de testes para obter uma autorização em tempo real para transações EMV. O CreditCall disponibiliza uma API de servidor back-end acessível via HTTPS por meio de sua ChipDNA Direct API, que por sua vez pode ser "desenvolvida" utilizando um SDK em Java, C++, Perl ou outras linguagens. Optei pela versão em Java.
No site do ChipDNA Direct , criei uma conta de desenvolvedor e recebi rapidamente (por e-mail) as credenciais de acesso ao servidor de testes da CreditCall. Também fiz o download do SDK Java da CreditCall e comecei a analisar o código de exemplo. Meu objetivo específico era aprender a submeter transações EMV para autorização. Por sorte, um dos arquivos de código de exemplo, ExampleAuthEMV.java, continha exatamente o tipo de código que eu precisava.
Comecei a desenvolver duas classes Java: uma classe servlet para processar requisições HTTP provenientes de uma interface web, e uma classe "worker" para encaminhar os dados do navegador (obtidos pelo servlet) ao back end da CreditCall. A primeira resultou em aproximadamente 250 linhas de Java; a segunda, em 92 linhas.
Não vou apresentar o código da classe servlet, pois se trata essencialmente de um código servlet Java padrão, com a diferença de que recebe valores TLV (enviados como valores de campos de formulário via AJAX) e os armazena em um objeto java.util.Hashtable em tempo de execução. Esse Hashtable é então passado ao método estático authorize() da minha classe worker. A classe worker utiliza as classes auxiliares (biblioteca) do SDK ChipDNA Direct da CreditCall para criar um objeto com.creditcall.Request, que é entregue a um objeto Client, o qual, por sua vez, realiza a chamada ao servidor da CreditCall. Veja o código a seguir:
Este código é tão conciso e autoexplicativo que dispensa maiores comentários. O que há de mais elegante nele é que as classes Request e Client da CreditCall se encarregam de criar os documentos XML necessários que são enviados ao servidor da CreditCall. Como desenvolvedor, você nunca precisa visualizar, manipular, interpretar ou se preocupar com XML bruto (como deveria ser).
Observe que é necessário informar as credenciais da sua conta de teste nas linhas 18 e 19. (As credenciais exibidas acima são fictícias. Não tente utilizar o código literalmente!) A linha 69 é onde você define a URL do endpoint da CreditCall. A linha 72 realiza a chamada HTTPS de saída propriamente dita.
O servidor da CreditCall não é particularmente exigente em relação às tags TLV enviadas nos dados da transação, desde que você inclua aquelas que contêm os dados essenciais do cartão (por exemplo: as tags 5A e 57, para EMV com contato; a tag 56, para sem contato; além de 9F26 e 9F27, contendo informações do criptograma). Em resposta aos dados EMV, o servidor da CreditCall geralmente retornará TLVs para as tags 8A, 89 e 91, e opcionalmente 71 ou 72 (caso scripts precisem ser transmitidos ao chip do cartão). O código de autorização desejado está na tag 89.
Por tentativa e erro, aprendi que o aplicativo de servidor CreditCall não se apressa em recusar uma transação simplesmente porque o cartão apresenta um criptograma AAC. (É possível determinar o tipo de criptograma inspecionando os bits superiores da tag 9F27. Zeros indicam AAC, ou Recusa.) Isso não é inesperado, pois a recomendação do cartão é apenas isso: uma recomendação. A decisão final de aprovação ou recusa de uma transação EMV geralmente cabe ao adquirente. O cartão pode ser — e frequentemente é — sobreposto.
Como se pode perceber, é possível aprender muitos detalhes interessantes sobre EMV ao experimentar com esses recursos. Nada supera a realização de uma autorização ao vivo na hora de verificar o código de um aplicativo de pagamento!
Quer mais orientações sobre transações EMV? Acesse nossa página Development Home na Base de Conhecimento ID TECH. Baixe nosso white paper de desenvolvimento EMV. Ou ligue para um de nossos especialistas gratuitamente para começar com um kit de avaliação: