Validação em bases de dados - ativar serviços e o que é cobrado
A validação em bases de dados confere os dados de identidade extraídos com um registro governamental ou autorizado. Por que um serviço mostra "Requer onboarding", por que retorna 403 ou nada, e quais consultas são cobradas.
A validação em bases de dados roda em segundo plano contra um registro oficial: a pessoa nunca a vê. Ela só é ativada após a primeira recarga da sua organização, alguns serviços mostram ainda "Requer onboarding" até a Didit habilitá-los para você, e toda consulta que o registro de fato responde é cobrada, inclusive uma sem correspondência.
Ler o documento diz o que está impresso nele. A validação em bases de dados diz se uma fonte autorizada concorda: um registro civil, uma autoridade fiscal, um bureau de crédito, uma base de habilitações. Cada país expõe um ou mais serviços, cada um com seu preço, seus dados de entrada e suas regras de consentimento. Veja países e serviços suportados e preços por serviço.
#Roda em silêncio, depois da etapa do documento
Não existe uma tela de validação em bases de dados. A etapa pega os dados extraídos do documento (ou os que você passou ao criar a sessão), envia ao registro e guarda a resposta no relatório da sessão. Duas consequências decorrem disso:
- Se a etapa de ID extraiu o número ou o nome errado, o registro é consultado com o valor errado e a verificação falha ou volta inconclusiva. Corrija a extração primeiro. Veja corrigir um nome ou campo lido errado.
- Você não pode "reenviar" uma validação em bases de dados para o usuário como reenvia um documento ou uma selfie, porque não há nada para ele refazer. Pedir um reenvio de
DATABASE_VALIDATIONretorna um erro dizendo que o recurso não faz parte das etapas reenviáveis da sessão. Para rodá-la de novo, chame a API independente de validação em bases de dados com os dados corrigidos. Essa chamada é cobrada por consulta como qualquer outra.
#Por que não está rodando
Verifique nesta ordem. Isso explica quase todos os relatos de "a validação em bases de dados não fez nada".
- Sua organização já fez alguma recarga?
A validação em bases de dados (e a verificação de telefone) só é ativada após uma primeira recarga. Créditos de boas-vindas, inclusive os US$ 10 de conta nova, não contam. Até lá a etapa é pulada, uma sessão pode voltar aprovada com a verificação silenciosamente não realizada, e uma chamada direta a
POST /v3/database-validation/responde 403. Veja recargas, faturas e formas de pagamento. - O serviço está marcado como Requer onboarding?
Na etapa de validação em bases de dados do fluxo, alguns serviços mostram "Requer onboarding. Entre em contato com o suporte da Didit para habilitá-lo." O serviço está visível, mas desativado para sua organização até a Didit ativá-lo. Não é um bug e não há chave de autoatendimento: abra um ticket de suporte informando o serviço e o país, e a equipe inicia o onboarding.
- O país está configurado?
Uma chamada de API para um país que você nunca selecionou no fluxo, ou uma chamada independente para um serviço que não habilitou, responde "No database validation services configured" para aquele país. Adicione o serviço à etapa, ou passe o
service_idexato da página do país. - O saldo é positivo?
A validação em bases de dados nunca está no plano gratuito. Um saldo zero ou negativo retorna
insufficient_credits, como qualquer recurso pago. Veja corrigir um erro de "créditos insuficientes".
#Serviços que precisam de onboarding com o provedor
Um punhado de fontes governamentais exige que a Didit cadastre a sua organização junto ao provedor, e não apenas ligue uma chave. Hoje isso vale para:
- Austrália (DVS: habilitação, passaporte, visto, Medicare e os demais serviços DVS)
- Nova Zelândia (DIA: passaporte, cidadania, registros de nascimento e óbito, habilitação)
- Canadá (serviços de bureau de crédito e de cruzamento tipo FINTRAC)
Para esses, o suporte envia os formulários do provedor, o provedor emite credenciais para sua conta e a ativação costuma levar até duas semanas. Austrália e Nova Zelândia historicamente exigiram ainda um acordo de serviço mínimo (um valor pré-pago único, atualmente US$ 5.000, que entra no seu saldo como créditos que nunca expiram). Essa exigência vale só para o acesso aos registros desses dois países, não para nenhum outro recurso da Didit, e está sendo revista à medida que a Didit conclui sua própria acreditação no esquema australiano; pergunte ao suporte as condições vigentes antes de planejar em cima disso.
Alguns serviços exigem ainda o consentimento explícito do usuário final antes de a consulta ser enviada (por exemplo a verificação de passaporte DIA da Nova Zelândia). A etapa do fluxo marca esses serviços, e o consentimento precisa ser coletado no seu fluxo antes de a verificação poder rodar.
#O que é cobrado
Você paga por serviço, por cada consulta que o registro responde, ao preço da página daquele serviço. Leia como "o registro foi consultado e respondeu", não como "a resposta foi a que você queria":
| Resultado | Cobrado? |
|---|---|
| Correspondência, correspondência parcial, sem correspondência | Sim |
| Inconclusivo, imagem biométrica inutilizável | Sim |
| Formato de documento inválido, entrada inválida (rejeitada pelo registro) | Sim |
REGISTRY_UNAVAILABLE, REGISTRY_ERROR (o registro nunca respondeu) | Não |
| Solicitação rejeitada antes de chegar ao registro (400 na API independente, ou etapa do fluxo pulada por campos ausentes ou malformados) | Não |
Uma sessão pode gerar várias consultas cobradas se rodar vários serviços, e cada consulta é cobrada uma vez por serviço, não por país. Detalhamento completo: preços de validação em bases de dados e códigos de resultado.
Um resultado vazio não é uma não correspondência. Se um serviço não retorna nada em vez de um
resultado NO_MATCH, as causas habituais são a regra da primeira recarga, um serviço ainda
aguardando onboarding ou uma queda do registro; vale descartá-las antes de depurar sua
integração. Veja erros da API e o que significam.
#O que volta
Cada serviço retorna um código de resultado padrão mais os dados do próprio registro quando a fonte permite: quais campos coincidiram, uma pontuação de correspondência quando o registro pontua em vez de responder sim ou não, e nos serviços biométricos (RENAPER da Argentina, BVN da Nigéria, Panamá) uma comparação facial com o retrato do registro. O que a Didit guarda dessa resposta é governado pelas configurações de Dados retornados da etapa. Veja escolher quais dados uma verificação retorna e o relatório de validação em bases de dados.
#Testar antes de ir para produção
Aplicações sandbox nunca chegam a um registro real nem gastam créditos: um cenário de sandbox como decline_database_no_match força o resultado que você quer ensaiar. O que o sandbox não pode dizer é se um serviço específico está provisionado para sua organização em produção; para isso é preciso a primeira recarga e uma chamada real. Veja testar no sandbox.