A validade do cartão é um campo de quatro dígitos que parece não merecer atenção e concentra uma classe inteira de defeitos silenciosos. O motivo é simples: existem três representações diferentes do mesmo dado — o que está impresso no plástico, o que o cliente digita e o que o sistema transmite — e misturá-las produz erros que só aparecem na virada do mês.
O que está impresso e o que o sistema guarda
No cartão, a validade aparece como mês com dois dígitos seguido do ano com dois dígitos, sem dia. É um dado grosseiro por definição: não existe cartão que vença em uma data específica.
Internamente, os sistemas costumam trabalhar com o ano completo e o mês separado, porque comparar anos de dois dígitos é uma fonte garantida de problemas quando a virada de década chega. A camada de transporte entre loja e adquirente frequentemente usa mais uma convenção, com o ano completo em quatro dígitos.
Três camadas, três formatos. A regra prática é nunca guardar o que o cliente digitou: converta para uma representação interna estável e formate de volta só na exibição.
O cartão vale até o fim do mês
Esta é a informação que mais gera discussão no suporte. Um cartão marcado como válido até determinado mês permanece utilizável durante todos os dias daquele mês, inclusive o último. O vencimento efetivo é o primeiro dia do mês seguinte.
Quando alguém diz que o cartão “venceu dia dez”, está descrevendo outra coisa: a data em que o plástico foi enviado pelo correio, ou o dia em que o banco bloqueia o cartão por outros motivos. A validade impressa não funciona assim.
Há ainda uma sutileza de calendário que vale registrar. A comparação precisa ser feita entre datas, e não entre textos. Um campo guardado com o ano completo e outro guardado com dois algarismos ordenam de forma diferente, e uma comparação alfabética pode colocar um mês anterior depois de um mês seguinte. Quando o dado atravessa sistemas distintos, o formato usado em cada ponta precisa estar documentado, inclusive para quem for investigar uma recusa meses depois.
Essa diferença cria o teste de borda mais clássico do campo. Uma verificação que compara a data atual com o primeiro dia do mês informado recusa cartões que ainda são válidos. A comparação correta é entre o mês corrente e o mês impresso, considerando o cartão expirado apenas depois que o mês termina.
Erros de preenchimento mais frequentes
Os problemas que aparecem em produção costumam se repetir:
- Inversão de mês e ano, porque o cliente lê a tarja na ordem que preferir.
- Ano com quatro dígitos em um campo que só aceita dois, ou o contrário.
- Zero à esquerda omitido no mês, transformando janeiro em um dígito.
- Validade digitada como data completa, com dia, em um campo que não tem dia.
- Preenchimento automático do navegador gravando uma validade antiga de outro cartão.
Cada um desses casos tem uma solução de interface diferente: máscara, campo único com separador, campos separados, ou apenas texto livre com normalização no envio. Não existe escolha universalmente melhor, mas existe uma obrigação: a mensagem de erro precisa dizer com clareza o que se espera.
Um cartão vencido pode ser cobrado?
Não por uma cobrança nova, porque a autorização é recusada pelo emissor. Mas o histórico é mais sutil do que parece: assinaturas e cobranças recorrentes costumam ser tentadas de novo depois da atualização dos dados do cliente, e sistemas de cobrança guardam a validade antiga até que o portador informe a nova.
Isso significa que a data de validade guardada em um cadastro de cliente não é um dado permanente. Ela envelhece sozinha e precisa de um caminho de atualização, normalmente disparado por uma recusa específica do emissor.
Como testar a virada do mês?
Esse é o cenário que mais passa despercebido, porque testar exige simular o tempo. Uma abordagem que funciona bem é separar a função que decide se a data está expirada e alimentá-la com datas fixas:
- Um mês anterior ao atual, que deve ser considerado expirado.
- O mês atual, que deve ser considerado válido em qualquer dia, inclusive no último.
- O mês seguinte, que deve ser válido.
- Um caso no limite do século, para verificar se o ano de dois dígitos foi interpretado corretamente.
Se o código consulta a data do sistema diretamente, o teste fica impossível de escrever. Esse é um bom sinal de que a regra precisa ser isolada.
Gerando validades coerentes no gerador
Montar esses casos à mão é chato e propenso a erro, sobretudo quando você precisa de várias bandeiras ao mesmo tempo. O gerador de cartão virtual desta página produz número, validade e código de segurança coerentes entre si para a bandeira escolhida, e permite gerar quantos conjuntos você quiser. Todos os valores são fictícios, estruturalmente válidos e nunca foram emitidos: servem para preencher formulários em teste, nunca para uma cobrança real.
Para quem desenvolve: controle de entrada e valores de borda
Alguns cuidados reduzem bastante o retrabalho desse campo:
- Aceite a entrada com e sem separador, com dois ou quatro dígitos no ano, e normalize antes de validar.
- Não use o ano de dois dígitos como valor interno. Converta para o ano completo na entrada e formate na saída.
- Documente a regra do fim do mês no próprio código e nos testes, porque ela é contraintuitiva para quem revisa.
- Trate o campo como parte do conjunto: a página sobre formato do número do cartão explica por que a validação do número vem antes.
- Lembre-se do lado do servidor, como descreve o texto sobre validar número de cartão.
Próximos passos
Se o seu problema é o campo em si, comece pelos valores de borda do fim do mês. Se a intenção é revisar o checkout inteiro, o checklist de teste de formulário de pagamento cobre recusa, nova tentativa e reembolso na sequência em que costumam acontecer. Para gerar dados completos agora, use o gerador de cartão virtual.