O que é CVV é uma pergunta de resposta curta: é o código impresso no cartão que serve para provar que ele está nas mãos de quem está pagando. A parte interessante vem depois, quando se entende por que esse código não pode ser armazenado e o que isso muda em um formulário de checkout.
Onde ficam os três ou quatro dígitos
A posição e o tamanho do código dependem da bandeira:
- Na maior parte das bandeiras, são três dígitos impressos no verso, junto à faixa de assinatura.
- Em uma bandeira de viagens bastante conhecida, são quatro dígitos impressos na frente, acima do número.
O nome varia conforme quem descreve. Alguns materiais chamam de código de verificação do cartão, outros de código de verificação do valor, e há ainda quem use a sigla de três letras consagrada pelo mercado. Todos se referem ao mesmo dado impresso.
Existe também um valor diferente, gravado na tarja magnética e no chip, usado para conferir a autenticidade dos dados durante uma transação presencial. Esse valor não aparece em nenhum formulário e não é o que o cliente digita. Confundir os dois leva a requisitos equivocados, como pedir um dado que o cliente não tem como informar.
Por que esse código não pode ser deduzido
Um número de cartão tem estrutura pública: qualquer pessoa pode descobrir que um prefixo pertence a uma faixa e reconstruir a lógica dos dígitos. O código impresso segue outro caminho. Ele não é calculado a partir do número e não aparece em extratos, notas fiscais ou relatórios de vendas.
É essa independência que dá utilidade ao campo. Quem obteve o número do cartão a partir de um banco de dados vazado tem apenas uma parte da informação. Ao pedir o código em uma compra sem cartão presente, o lojista exige algo que só está no plástico.
Vale repetir que não se trata de uma garantia absoluta. É uma barreira adicional, de custo baixo para o cliente e de eficácia razoável contra usos mais simples.
A regra que proíbe guardar o código
Aqui está o ponto mais rígido de todo o assunto. As normas de segurança do setor de cartões classificam o código de segurança como dado de autenticação sensível, e determinam que ele não seja armazenado após a autorização da transação.
A lógica é direta. Se o código fosse guardado junto com o número, qualquer acesso indevido ao banco de dados entregaria tudo o que é necessário para cobrar, e o código deixaria de provar coisa alguma. O valor dele depende de ser esquecido.
Para quem constrói sistemas, a consequência é concreta:
- O campo não entra em tabelas, arquivos de cache, filas de mensagens nem registros de log.
- Ele existe em memória durante a chamada de autorização e é descartado logo depois.
- Ferramentas de monitoramento precisam ser configuradas para não capturar o corpo da requisição de pagamento.
- Um recurso de salvar cartão pode guardar número, validade e bandeira, jamais o código.
Guardar o dado por conveniência de depuração é o erro mais comum, e é também o mais caro.
Responder o CVV confirma que a conta existe?
Não. O código confirma apenas que quem preencheu o formulário tem acesso ao cartão, ou a uma cópia fiel dos dados impressos nele. Ele não diz se a conta está ativa, se há limite disponível nem se o portador está autorizado a usar aquele cartão.
A verificação da conta acontece em outra etapa, no diálogo entre adquirente, bandeira e banco emissor. Se a cobrança é recusada por código incorreto, isso indica divergência de dados, e não problema na conta. Interpretar corretamente o motivo da recusa é o que permite mostrar a mensagem certa ao cliente.
Por que o campo aparece em todo formulário?
Porque o custo de pedir é baixo e o benefício é imediato: exige a presença do cartão e reduz tentativas feitas apenas com um número copiado. Em contrapartida, é um campo a mais para o cliente digitar, o que sempre gera atrito e erros de digitação.
O equilíbrio comum é manter o campo obrigatório na primeira compra e, quando o lojista guarda o cartão do cliente, continuar pedindo o código nas compras seguintes. Isso mantém a prova de posse sem exigir que o cliente redigite o número inteiro.
Testando o campo com dados sintéticos
O campo parece trivial e concentra uma quantidade surpreendente de defeitos. O gerador de cartão virtual desta página produz número, validade e código coerentes com o formato esperado, o que permite exercitar o formulário do começo ao fim. Os dados são sintéticos, estruturalmente válidos e nunca foram emitidos por nenhuma instituição, então não servem para uma cobrança real.
Para quem desenvolve: nada de log, nada de cache
Além da proibição de armazenar, alguns cuidados práticos evitam vazamentos acidentais:
- Trate o campo como efêmero por definição: ele entra na requisição e não deve sobreviver a ela.
- Revise capturas automáticas de erro, que costumam enviar o corpo inteiro da requisição para um serviço externo.
- Cuidado com o preenchimento automático do navegador e com relatórios de teste que gravam a tela.
- Não inclua o valor em mensagens de depuração nem em trilhas de auditoria.
- Ao criar um recurso de cartão salvo, verifique o que a sua integração realmente persiste, como detalha o texto sobre dados de teste PCI DSS.
- Nos testes, use apenas valores fictícios e cubra letras, espaços, dígitos a menos e dígitos a mais, seguindo o checklist de teste de formulário de pagamento.
Próximos passos
Se a sua dúvida era conceitual, o essencial está aqui: o código prova posse, não substitui a autorização e não pode ser guardado. Para seguir a trilha dos campos do checkout, veja o formato da data de validade e o formato do número do cartão.