Gere o status do seu produto a partir do resultado e armazene `checkStatus` ao lado como explicação. Mapeie cada um dos dez valores de status para um estado em seu próprio sistema e obtenha o status mais recente de `verification.status_updated` ou por meio de polling.
Atribua um requestId a cada verificação lógica, salve-o antes de enviar a solicitação e reutilize-o em cada nova tentativa. Um requestId repetido retorna a verificação existente em vez de criar e cobrar uma segunda.
Coloque a chave pública no seu aplicativo e mantenha a chave secreta no seu servidor. Uma chave pública pode iniciar uma verificação e ler informações mínimas de status, nunca dados de identidade, portanto, esteja preparado para possíveis vazamentos e limite os custos decorrentes deles.
Use os IDs de teste do sandbox publicados, cujos últimos dígitos determinam o resultado, para gerar todos os resultados que seu código precisa processar. Em seguida, teste seu receptor de webhook com eventos simulados e assinados antes de usar chaves reais.
Monte o SDK com um ID de fluxo de trabalho e a configuração do fluxo será obtida do servidor a cada verificação. A republicação altera as etapas, verificações, cópias e regras de decisão para a próxima verificação, sem necessidade de relançamento do aplicativo.
Quando uma verificação termina, o gráfico de decisão do fluxo de trabalho reúne os resultados, percorre os ramos em um conjunto fechado de campos e decide entre aprovar, revisar ou rejeitar. O resultado define a decisão do cliente sem alterar o que as verificações encontraram.
Considere o envio como o início de uma máquina de estados, não como o fim de uma requisição. Exiba um estado pendente com base no ID de verificação, atualize-o por meio de webhooks e permita que o status mude mais de uma vez.
Verificar a assinatura V2 nos bytes brutos da solicitação, rejeitar carimbos de data/hora fora da janela de reprodução, registrar o ID do evento sob uma restrição exclusiva antes de realizar qualquer operação e retornar 2xx somente quando o evento for armazenado de forma duradoura.
Incorpore o SDK quando a verificação ocorrer dentro do seu produto; envie um link hospedado por candidato quando ela ocorrer fora dele. De qualquer forma, execute um fluxo de trabalho publicado para que a escolha seja sobre a entrega, e não sobre o fluxo em si.
Todas as três leis tratam os dados biométricos como uma categoria especial. A Nigéria menciona imagens faciais e limita o uso de dados sensíveis a casos específicos; o Quênia considera o processamento biométrico como de alto risco; e a POPIA o proíbe, a menos que haja autorização. Planeje uma base legal, uma Avaliação de Impacto sobre a Proteção de Dados (AIPD) e medidas de minimização.
Os sinais de dispositivo e IP descrevem o aparelho e a conexão, não a pessoa. Emuladores e IPs de data center são fortes indícios; dispositivos compartilhados, velocidade do IP e localização do IP são indícios fracos. Use-os como confirmação e confie na localização do IP apenas em nível de país.
Quando um login parecer uma tentativa de invasão de conta, não tire conclusões precipitadas. Deixe a sessão continuar com privilégios limitados e solicite comprovação que somente a pessoa verificada possa fornecer, como uma selfie recente que corresponda ao seu cadastro, antes de qualquer pagamento, alteração de beneficiário ou redefinição de senha.