CVV, CVC, CID e CVV2: o que o código de segurança do cartão realmente significa

Poucas coisas em pagamentos geram mais confusão do que o código de três dígitos no verso do cartão. É CVV, CVC, CVV2 ou CID? Fica na frente no caso do Amex? Você pode armazená-lo? Este artigo esclarece a terminologia e as regras que importam para desenvolvedores.

Quatro nomes, uma única ideia

O código de segurança é um número curto que não está codificado na tarja magnética nem no chip EMV. Sua função é provar que quem está pagando tem o cartão em mãos, o que o torna valioso para transações sem presença do cartão (CNP).

A distinção entre CVV e CVV2 (ou CVC e CVC2) é histórica: o sufixo "2" se refere ao uso do mesmo valor em transações sem presença do cartão. No dia a dia do desenvolvimento, "CVV" é usado como nome genérico do campo em todas as bandeiras.

As duas coisas que realmente importam no código:

1. O Amex usa 4 dígitos na frente: qualquer campo de entrada que force 3 dígitos vai falhar nos testes com Amex.
2. O valor completo é dado sensível do portador do cartão, portanto está coberto pelo PCI DSS.

As regras do PCI DSS que você não pode ignorar

O CVV é classificado como dado de autenticação sensível. De acordo com o PCI DSS:

• Você pode usá-lo para processar uma transação.
• Você não pode armazená-lo após a autorização: nem em logs, nem em banco de dados, nem em um evento de analytics, nem em um print de tela do suporte.
• Você não pode armazená-lo nem mesmo criptografado. A proibição é absoluta.
• Você também não deve exibi-lo novamente ao usuário depois do envio.

Na prática, isso significa:

• Nunca registre em log payloads de requisições que contenham cvv, cvc, cid ou security_code.
• Marque o campo como sensível nas suas ferramentas de observabilidade e remova-o na borda da rede.
• Quando os provedores retornarem um resultado de verificação, armazene o resultado (cvv_check: pass/fail/unchecked), nunca o valor em si.
• Mantenha o campo CVV fora da sua própria API se o navegador puder enviá-lo direto ao endpoint de tokenização do gateway de pagamento.

Como as verificações de CVV se comportam na prática

A verificação do CVV é um sinal de autorização separado, não uma barreira rígida. Cada emissor e cada gateway de pagamento tratam uma divergência de forma diferente:

• Alguns recusam a transação de imediato.
• Outros aprovam e retornam um código CVC mismatch, deixando a decisão para o comerciante.
• E outros são configurados para pular a verificação por completo em certas regiões.

Você pode testar isso de forma deliberada: o 4000 0000 0000 0127 da Stripe sempre retorna uma resposta de CVC incorreto, ideal para exercitar o tratamento de erros sem tocar em um cartão real. Veja a lista completa de cartões de teste para mais opções.

Como gerar CVVs de teste

Para trabalhar em sandbox, a maioria dos gateways de pagamento aceita quaisquer 3 dígitos (ou 4 no caso do Amex). O nosso gerador de cartões pode anexar um CVV aleatório ou fixo a cada número gerado e exibir o resultado em um formato separado por barras verticais, fácil de converter em fixtures:

4242424242424242|12|2030|123

Se você precisar gerar números para uma faixa de emissor específica, o gerador avançado aceita padrões com curingas e o verificador de BIN mostra a qual bandeira um prefixo pertence.

Resumo

• CVV, CVC, CID, CVV2 e CSC descrevem a mesma ideia com nomes próprios de cada bandeira.
• O Amex é a exceção: 4 dígitos, impressos na frente.
• Nunca armazene o código após a autorização: o PCI DSS o trata como dado de autenticação sensível.
• Trate uma divergência de CVV como um resultado configurável e teste tanto a recusa quanto o caminho de falha suave.