Integração e Exemplos Práticos
Esta secção detalha como os endpoints do módulo CVV se encaixam na arquitetura real de um emissor ou processador de cartões, apresentando os fluxos recomendados, boas práticas de segurança e exemplos de código prontos a utilizar.
Fluxo Típico: Emissão de Cartão
No momento da personalização e emissão de um novo cartão, o emissor necessita tipicamente de gerar os três valores de CVV de uma só vez .
O fluxo recomendado é o seguinte:
Autenticação: Obter o token JWT via Auth0 (utilizando o grant
client_credentials), que é válido tipicamente por 24 horas.Geração em Lote: Invocar o endpoint
SuperGenerateCVenviando o array["<track>", "000", "999"]no camposerviceCodeArraypara obter o CVV1, CVV2 e dCVV numa única chamada.Persistência e Roteamento: Persistir os valores no sistema do emissor da seguinte forma:
O CVV1 segue para gravação na tarja/chip.
O CVV2 segue para a gráfica (impressão no plástico).
O dCVV é guardado apenas no servidor para validação em transações futuras.
Tratamento da Resposta: Verificar se
retCode = 0eretValid = true. Em caso de falha, consultar o catálogo de erros para diagnóstico.
Fluxo Típico: Autorização de Transação
Para transações e-commerce/MOTO (Card-Not-Present) que exigem o CVV2:
Autenticação: Obter ou recuperar do cache o token JWT do Auth0 .
Validação Estática: Invocar o
ValidateCVenviandoserviceCode = "000"e ocvpreenchido no checkout pelo portador.Decisão de Negócio: Avaliar o campo
retValid:true: Seguir com a autorização da compra.false: Recusar a transação ou solicitar nova digitação do código .
Para transações presenciais (Chip/Contactless) com dCVV:
Substituir o passo 2 pelo uso do endpoint
VerifyDynCV, preenchendo os campos dependentes da bandeira (comobrand,dynCvVers,atc, etc.) recebidos no momento da aproximação.
Boas Práticas de Integração
Antes de colocar o código em produção, valide se a sua aplicação cumpre as seguintes diretrizes essenciais de segurança e resiliência:
Autenticação
Cache do JWT: Os tokens Auth0 possuem validade longa. Não solicite um novo token a cada chamada de CVV; isso introduz latência desnecessária e pode esgotar os rate limits do serviço de autenticação.
Resiliência
Idempotência Nativa: Os endpoints GenerateCV e SuperGenerateCV são determinísticos. Para os mesmos inputs (PAN, expDate, serviceCode e chave), retornarão sempre o mesmo CVV. Isto permite o replay seguro de requisições em caso de timeout de rede .
Segurança
Higienização de Logs: Jamais registe o CVV em texto claro nos logs da sua aplicação. Registe apenas o client_id, keyId, retCode e retDesc para auditoria. Nunca guarde o PAN completo, o campo cv de entrada ou o retValue contendo a resposta .
Políticas de Retry
Como tratar erros: Erros 500 e 504 podem sofrer tentativas repetidas (retry) com backoff exponencial. Erros 400 (input inválido), 401 e 404 (chave inexistente) não devem ser retentados sem que a aplicação corrija o dado de origem .
Exemplos de Código
Estes snippets demonstram a invocação prática dos endpoints.
cURL — Gerar CVV2 (GenerateCV)
GenerateCV)Python — Validar CVV2 no Checkout (ValidateCV)
ValidateCV)Python
Node.js — Gerar os 3 CVVs na Emissão (SuperGenerateCV)
SuperGenerateCV)Last updated

