Visão geral
Os avisos são identificados com a funcionalidadePHONE. Surgem sob phone_verifications[].warnings[] em GET /v3/session/{sessionId}/decision/ e seguem a estrutura padrão do objeto de aviso (feature, risk, additional_data, log_type, short_description, long_description, node_id). Cada aviso é também encaminhado para o registo por sessão, de modo a surgir na Business Console na secção Telefone.
Alguns avisos são acionadores de recusa automática estrita — definem sempre o estado da funcionalidade como Declined. Outros correspondem a uma ação configurável (DECLINE, REVIEW ou NO_ACTION, dependendo da definição) definida nas definições do seu fluxo, pelo que o mesmo código de risco pode recusar um fluxo e apenas sinalizar outro.
Condições de recusa automática
Os seguintes avisos recusam sempre o passo de Verificação de telefone, independentemente da configuração, e apresentam semprelog_type: "error":
VERIFICATION_CODE_ATTEMPTS_EXCEEDED— o utilizador esgotou o limite de tentativas de OTP: por predefinição, 2 submissões de códigos incorretos (phone_max_check_attempts) ou mais de 2 envios de OTP (phone_max_retries), ambos configuráveis por nó de fluxo. A API de telefone autónoma permite 3 tentativas de código.PHONE_NUMBER_IN_BLOCKLIST— o número está na sua lista de bloqueio gerida através da Lists API, ou corresponde a uma sessão na lista de bloqueio.
HIGH_RISK_PHONE_NUMBER — a camada antifraude do fornecedor de entrega que recusa enviar o OTP (envio Blocked) — recusa por predefinição, mas já não é incondicional: consulte high_risk_phone_action abaixo.
Riscos configuráveis
Cada um dos seguintes riscos mapeia para uma definição de fluxo que pode configurar paraDECLINE, REVIEW ou NO_ACTION (a predefinição — o aviso é registado sem afetar o estado). A ação configurada também define o log_type do aviso: DECLINE → error, REVIEW → warning, NO_ACTION → information.
A deteção de duplicados é executada na sua aplicação em verificações de telefone de KYC, KYB e de API autónoma, e agrupa as sessões por
vendor_data — as sessões que partilham o mesmo vendor_data são tratadas como um único utilizador final e são excluídas dos resultados de correspondência. Deixe o vendor_data vazio e cada sessão será tratada como um utilizador distinto.
Envios bloqueados
HIGH_RISK_PHONE_NUMBER segue o mesmo padrão com um conjunto de opções mais restrito, porque um envio recusado pelo fornecedor não pode ser aprovado:
A definição é aplicada apenas quando cada bloqueio de alto risco no passo apresentar
additional_data.risk_factors exatamente igual a ["device_attribute"] — o sinal do fornecedor de que “este dispositivo parece suspeito”, que é o que dispara em linhas móveis normais. Qualquer outro fator de risco, qualquer combinação que inclua device_attribute juntamente com outros fatores, ou um bloqueio sem quaisquer fatores de risco recusa independentemente da definição. O motivo do bloqueio (repeated_attempts, suspicious ou spam) é um campo separado, devolvido em additional_data.blocked_reason.
Independentemente da definição, um número presente numa lista de permissões de telefone criada através da Lists API nunca é recusado automaticamente por um envio bloqueado: o passo passa para Em análise, o aviso apresenta log_type: "warning" e additional_data.phone_number_in_allowlist é true.
Limites de tentativas de verificação
A funcionalidade Verificação de telefone aplica um limite rígido às tentativas de OTP para prevenir abusos:- Tentativas de introdução do código — Por predefinição, 2 envios incorretos (
phone_max_check_attempts) antes de o passo finalizar comoDeclinedcomVERIFICATION_CODE_ATTEMPTS_EXCEEDED. A API de telefone autónoma permite 3 tentativas de código por verificação. - Tentativas de envio — Por predefinição, 2 envios no total (
phone_max_retries): o envio inicial mais um reenvio. Um pedido de envio adicional finaliza o passo e geraVERIFICATION_CODE_ATTEMPTS_EXCEEDED. - Validade do OTP — Um OTP pendente é válido durante 5 minutos a partir do primeiro envio; as novas tentativas não prolongam a janela.
repeated_attempts, suspicious ou spam) — isso gera HIGH_RISK_PHONE_NUMBER, e não o aviso de tentativas.
Avisos gerados
Correspondências entre sessões
Quando um número é detetado noutras sessões ou na sua lista de bloqueio, essas correspondências também surgem emphone_verifications[].matches[] (com um limite de 5 entradas). Cada correspondência inclui session_id, session_number, vendor_data, verification_date, phone_number, status, is_blocklisted, api_service e uma source de session (outra sessão com o mesmo número, em qualquer estado) ou list_entry (uma correspondência sintética da lista de bloqueio adicionada no início do array). Se o número atual estiver na sua lista de permissões de telefone, a Didit mantém a evidência da correspondência, mas emite PHONE_NUMBER_IN_ALLOWLIST em vez de aplicar a ação relativa a números de telefone duplicados. Consulte o relatório de Verificação de telefone para obter o esquema completo de correspondências.
Exemplo
Um envio bloqueado (HIGH_RISK_PHONE_NUMBER) num número VoIP, com voip_number_action configurado para REVIEW:
Tipos de aviso
A cada risco é atribuída uma gravidade com base na configuração da sua aplicação. As gravidades dividem-se em três categorias:Conteúdo relacionado
- Visão geral da Verificação de telefone — comportamento da funcionalidade, preços, canais suportados.
- Relatório de Verificação de telefone — formato completo da resposta, incluindo
lifecycle[]ematches[]. - Modelos de dados — verificação de telefone — esquema canónico campo a campo.
- API de Gestão — Listas — faça a gestão da lista de bloqueio de números de telefone utilizada por
PHONE_NUMBER_IN_BLOCKLIST.