Proteger o cartão armazenado em arquivo é o desafio para todos os lojistas e a preocupação de todos os clientes.
Uma das facilidades oferecidas pelos sites de compras é a opção de registrar um número de cartão no cadastro da loja para facilitar a compras, num processo que foi denominado “compra em um click”.
Mas, como confiar que:
- A loja é idônea e não utilizará este cartão para finalidades não autorizadas? O cliente só aceitará guardar seu cartão em arquivo se tiver absoluta confiança na loja.
- Como garantir que a base de dados do lojista não será invadida, a exemplo do que já aconteceu no passado, com consequências bastante desagradáveis?
Veja algumas das alternativas de solução adotadas ao longo dos últimos anos:
Uso de cofres de chaves
Muitos lojistas, provedores de serviços recorrentes, seguradoras etc. adotaram soluções proprietárias para criptografar os números de cartões e impedir que uma invasão à base de informações criasse um sério problema financeiro e de imagem.
A questão é que estas soluções, por serem proprietárias, em geral não implementam protocolos de comunicação de segurança como PKCS #11 ou KMIP. E não estão sob uma gestão centralizada e automatizada dos processos de segurança.
Cartão Virtual
Alguns emissores passaram a gerar códigos de cartão específicos para as compras na Internet, associando novos números de cartão ao cartão real. Esta solução, apesar de apresentar alguns bons resultados, se mostrou de difícil administração. E em geral, o cartão virtual é armazenado no cadastro de um lojista para compras em um click.
Rumo à tokenização
As especificações EMV sobre tokenização endereça este problema. Caso o emissor já tenha implantado os serviços de tokenização dos seus cartões, o lojista, ao receber um número de cartão para armazenar em sua base pode solicitar a geração de um token específico para o seu uso. A figura a seguir, extraída do manual do EMVCo – “A Guide to Use Cases v2.0” mostra de maneira esquemática o processo de requisição e uso de um token para os processos de compras utilizando “Card on File”.
Utilizando os tokens de Card on File nas requisições de autenticação 3D Secure, lojista e emissor podem estabelecer um processo seguro, prático e amigável para converter as compras dos cientes.
Mas nem todos os emissores já tokenizaram seus cartões. Logo, esta solução, apesar de importante e estratégica para o futuro, não resolve o problema completamente. O que fazer então?
Transitando para uma solução comum
Seguindo na estratégia de implantar processos baseados em interoperabilidade e padrões de mercado, a sugestão para os lojistas e gateways de pagamento é:
- Solicite um token do cartão digitado por seu cliente. Já existem soluções de mercado para esta finalidade.
- Se a solicitação tiver resultado positivo, associe este token ao cadastro do seu cliente. Lembre-se que a partir de então, as transações sempre serão realizadas utilizando o token como PAN na transação de autorização. E lembre-se de informar no Areq da autenticação 3DS que este número o cartão é um token.
- Se a resposta for que o cartão não pode ser tokenizado, a sugestão é utilizar um processo padronizado e automatizado para tokenizar o número do cartão, usando os recursos de FPE. Este mesmo recurso pode e deve ser utilizado para proteger outras informações sensíveis, como identidade, CPF, nome, data de nascimento etc.
Com a evolução dos processos de pagamentos, como a tokenização e o SRC, cada vez será menos necessário usar diretamente o número do cartão para realizar uma transação.
Mas a proteção de dados sensíveis ou pessoas continuará sendo um requisito obrigatório, considerando as necessidades de privacidade e inviolabilidade dos dados.
