Chave PIX: CPF, e-mail, telefone ou aleatória
Um formulário de cadastro de chave PIX parece, à primeira vista, só mais um campo de texto com validação. Na prática esconde quatro formatos completamente diferentes por trás da mesma caixa de entrada (CPF/CNPJ, e-mail, telefone e uma chave aleatória), cada um com sua própria regra de formato e, mais importante para quem testa, sua própria regra de unicidade dentro do sistema financeiro. Entender essas diferenças evita tanto falsos positivos (rejeitar uma chave válida) quanto falsos negativos (aceitar uma chave que o Banco Central rejeitaria).
As quatro modalidades e o que validar em cada uma
CPF e CNPJ como chave PIX seguem exatamente o mesmo dígito verificador (módulo 11) que qualquer outro campo desses documentos, então a validação de formato pode reaproveitar a mesma rotina usada em qualquer outro lugar do sistema; o Validador de CPF e o Validador de CNPJ deste site servem para conferir isso rapidamente. E-mail e telefone seguem os formatos já conhecidos de qualquer formulário (RFC 5322 para e-mail, DDD mais número para telefone), sem regra especial adicionada pelo PIX. A diferença real de comportamento aparece na quarta modalidade: a chave aleatória, também chamada de EVP (Endereço Virtual de Pagamento).
A chave aleatória é, na prática, um UUID
Segundo o manual operacional do DICT (o Diretório de Identificadores de Contas Transacionais mantido pelo Banco Central), a chave aleatória segue o padrão UUID versão 4: 32 caracteres hexadecimais formatados como 8-4-4-4-12, exatamente o mesmo formato que identificadores únicos usam em bancos de dados e APIs no mundo inteiro. Isso significa que testar a geração e o formato de uma chave aleatória de PIX é, tecnicamente, o mesmo problema que testar a geração de qualquer UUID v4: o Gerador de UUID deste site produz valores no formato exato que uma chave aleatória de PIX deveria ter, úteis para preencher um cenário de teste sem esperar o sistema real gerar uma.
A diferença entre um UUID qualquer e uma chave aleatória de PIX de verdade não está no formato, está na origem: o DICT gera a chave dentro do próprio sistema do Banco Central no momento do cadastro, vinculando-a imediatamente a uma conta específica. Um UUID gerado localmente para popular um cenário de teste é estruturalmente idêntico, mas não está registrado em lugar nenhum, então serve para testar o campo de exibição e o formato aceito pela interface, não para simular um cadastro de fato validado pelo DICT.
A regra que mais pega quem testa: unicidade por chave
Cada chave PIX só pode estar vinculada a uma única conta por vez em todo o sistema financeiro nacional, com uma única exceção: o número de celular é a única modalidade que ainda permite vínculo com contas diferentes. Isso muda completamente o desenho de um cenário de teste de cadastro de chave: tentar registrar duas contas de teste com o mesmo CPF como chave, por exemplo, deveria ser rejeitado pelo sistema (ou disparar um fluxo de portabilidade, dependendo da regra de negócio implementada), e um teste que não cobre esse caso está testando só o caminho feliz do cadastro isolado, sem cobrir a regra de negócio que mais gera chamado de suporte na vida real.
Vale ainda testar, especificamente em CPF e CNPJ como chave, a regra que exige que o documento esteja "em situação regular" perante a Receita Federal antes do cadastro ser aceito, um dado que só o backend integrado ao DICT consegue confirmar, e que nenhuma validação client-side, incluindo o validador deste site, tem como simular.
O lado da privacidade
Usar o CPF como chave PIX é conveniente (qualquer um já sabe de cor o próprio número), mas cria uma superfície de exposição que vale considerar em teste de segurança: qualquer aplicativo bancário permite consultar o nome do titular a partir da chave, antes mesmo de confirmar uma transferência, como medida antifraude. Isso significa que um CPF cadastrado como chave PIX vira, na prática, consultável por qualquer pessoa que o digite em um app de banco, uma superfície de exposição de dado pessoal que a chave aleatória elimina por completo, já que o EVP não carrega nenhuma informação sobre o titular no próprio valor. Times que testam fluxos de cadastro de chave PIX ganham com isso um cenário de teste explícito de LGPD: confirmar que o nome exibido na consulta de uma chave é sempre o do titular correto, e que o sistema não vaza esse dado para quem não deveria ter acesso à consulta.