Cenários de identidade

Você decide como uma verificação termina dando à pessoa ou à empresa o nome do resultado que você quer.

Chame o solicitante de sanctions_match e o caso volta recusado, com o acerto na checagem de listas e não na de documento. Chame ele de approve e passa tudo.

Dê nome ao sujeito

O nome é conferido primeiro, ignorando maiúsculas e minúsculas, e ele corresponde inteiro ou pela última palavra. Então sanctions_match e Jane sanctions_match funcionam os dois, o que importa quando um formulário insiste em um primeiro nome.

Use approve para uma passagem limpa, ou qualquer uma destas recusas:

• Documentos: document_expired, document_not_supported, document_unreadable, document_tampered, document_type_mismatch
• Rosto e prova de vida: face_mismatch, face_not_detected, liveness_failed
• Cruzamento com listas: sanctions_match, pep_match, adverse_media_match, watchlist_match
• Dados declarados: data_mismatch, identity_not_found, address_not_verified, phone_not_verified, email_not_verified, underage
• Empresas: business_not_found, business_inactive, ownership_not_verified, tax_id_mismatch
• Risco: device_risk, blocklisted, duplicate_subject

Cada recusa cai na checagem que responde por ela. Pedir uma checagem de documento e uma de listas em um solicitante chamado pep_match te dá um relatório de documento limpo e uma recusa na de listas, que é o formato que o seu código de parsing tem que tratar em produção de qualquer jeito.

Resultados que não são passar nem falhar

Três nomes produzem os estados mais difíceis de reproduzir em qualquer outro lugar:

• review devolve um caso para uma pessoa olhar. Todas as checagens rodam, e a que ele nomeia volta inconclusiva em vez de reprovada.
• pending devolve um caso que ainda não responde. Ele continua rodando até ser lido de novo ou retomado, que é contra o que uma integração que consulta é escrita.
• hosted devolve um caso esperando o sujeito completar a captura sozinho. Siga o link da resposta e termine por lá.

Um provedor sem fluxo hospedado aprova o hosted no lugar, então o mesmo teste continua rodando.

Sujeitos que você não nomeou

Uma captura hospedada, um fluxo de SDK ou um sujeito importado chegam com um nome que você não escolheu. Outros quatro gatilhos alcançam esses:

• O e-mail declined@example.com, sanctioned@example.com, review@example.com ou pending@example.com.
• A data de nascimento 2015-01-01, para alguém novo demais para passar.
• O país KP, para um sujeito que declara um país sancionado. Escreva com duas letras, três letras ou o código numérico: as três formas chegam no mesmo gatilho, seja qual for a que o provedor registra.
• A sua própria referência, onde o provedor aceita uma.

Os dados de teste do próprio provedor

Cada provedor mantém os valores da documentação dele. Os nomes de solicitante clear e consider da Onfido funcionam, junto com os números de documento que o sandbox dela publica. A Persona responde a pass e fail, e a referências como test-declined.

Qual gatilho ganha

Um caso pega o primeiro gatilho que corresponde, nesta ordem:

1. Nome, inteiro ou pela última palavra
2. E-mail
3. A sua própria referência
4. Número do documento
5. Data de nascimento
6. País
7. Tipo de checagem

Ver ao que um provedor responde

Abra o backend, vá em Cenários e escolha um provedor.

De fábrica é o conjunto próprio daquele provedor.

Compartilhado é a base a que todo provedor responde, que é a lista do começo desta página.

As duas são só leitura, e as duas estão ali para você copiar.

Quando a lista que vem junto não basta

Escreva a sua. Os seus são testados antes de qualquer um de fábrica.

Veja Escreva os seus próprios cenários.

Para onde ir agora

• Escreva os seus próprios cenários
• Visão geral do backend de identidade
• Atividade do backend