# Como ler um resultado de verificação

Source: https://help.didit.me/pt-PT/verification-sessions/reading-a-verification-result
Updated: 2026-10-12

O resultado de uma sessão é um estado mais um resultado por comprovação mais uma lista de avisos - os avisos são a parte que te diz o que realmente aconteceu.

Lê pela seguinte ordem: o **estado geral**, depois os **estados por
comprovação**, depois os **avisos**. Os avisos são a única parte que te diz
*porquê* - tudo o resto só te diz *o quê*.

[Video: Como ler um resultado de verificação - Didit Academy](https://www.youtube.com/watch?v=7htTWCWsl60)

Abre qualquer sessão em **Verificações** na [Consola de Negócio](https://business.didit.me) e obténs as mesmas três camadas, quer estejas a olhar para a consola, para o payload de um webhook, ou para uma resposta da API.

![Detalhe de sessão na consola Didit com o veredito geral, os resultados por comprovação e os dados extraídos](https://help.didit.me/screenshots/session-detail-light.webp)

*Uma sessão, três camadas: estado geral, resultados por comprovação, e os avisos por trás deles.*

## Camada 1 - o estado geral

O veredito único da sessão: Aprovada, Recusada, Em Revisão, e assim por diante. É nisto que a maioria das integrações se baseia para agir. É um agregado: resulta de combinar o resultado de cada comprovação de acordo com a forma como o teu fluxo de trabalho está configurado, por isso nunca te diz sozinho qual comprovação foi responsável.

## Camada 2 - um resultado por comprovação

Cada comprovação que correu tem o seu próprio estado e os seus próprios dados. As que vais ver com mais frequência:

| Comprovação | O que consultar |
|---|---|
| **Verificação de identidade** | Campos extraídos (nome, número do documento, datas), tipo de documento e país, e se a MRZ validou |
| **Prova de vida passiva / ativa** | Se foi detetado um ser humano vivo, e qualquer sinal de ataque |
| **Correspondência facial 1:1** | A pontuação de semelhança entre a selfie e a fotografia do documento |
| **Pesquisa facial 1:N** | Se esta cara corresponde a um utilizador já verificado ou a uma entrada na lista de bloqueio |
| **Cribagem AML** | As ocorrências encontradas, cada uma com uma pontuação de correspondência e uma pontuação de risco |
| **Análise de dispositivo e IP** | País, sinais de VPN ou proxy, endereços na lista de bloqueio |
| **Comprovativo de morada** | A morada extraída e o quanto correspondeu à que forneceste |
| **NFC** | Se o chip foi lido e se a sua assinatura encadeou até um emissor de confiança |
| **Telefone / e-mail** | Se o OTP foi confirmado, mais sinais de risco sobre o número ou a morada |

Uma comprovação pode estar Aprovada enquanto a sessão está Recusada, e vice-versa. Isso é normal - o estado da sessão é a combinação, não o pior caso.

## Camada 3 - os avisos

Os avisos são a camada que realmente explica o resultado. Cada um é um código específico e nomeado, associado à comprovação que o gerou - por exemplo:

- `DOCUMENT_EXPIRED` - a data de validade do documento já passou.
- `MRZ_VALIDATION_FAILED` - o checksum da zona de leitura ótica não bateu certo. Um forte sinal de adulteração.
- `LOW_FACE_MATCH_SIMILARITY` - a selfie e a fotografia do documento pontuaram abaixo do teu limiar.
- `LIVENESS_FACE_ATTACK` - foi detetado um ataque de apresentação durante a selfie.
- `POSSIBLE_MATCH_FOUND` - a AML encontrou uma possível ocorrência que precisa de ser resolvida.
- `NFC_DATA_DOES_NOT_MATCH_OCR` - o chip e os dados impressos não coincidem.
- `IP_ADDRESS_IN_BLOCKLIST` - a ligação veio de um endereço que tens bloqueado.

> **Tip:** Quando estiveres a investigar uma sessão específica, vai diretamente aos
> avisos. O estado dá-te a conclusão; os avisos dão-te a evidência. Todos os
> catálogos de avisos por funcionalidade estão documentados em
> [core technology](https://docs.didit.me/core-technology/id-verification/warnings-id-verification).

## Dados extraídos vs. o que esperavas

Se passaste `expected_details` ao criar a sessão - um nome, uma data de nascimento, um número de documento que já tinhas - o resultado também te diz se o documento concordava com isso. Uma discrepância aí costuma ser um problema de introdução de dados do teu lado em vez de um documento fraudulento, por isso vale a pena verificar antes de recusares alguém.

> **Warning:** Os nomes extraídos podem estar transliterados. Um documento em escrita
> cirílica, árabe ou grega produz um nome em escrita latina que pode não
> corresponder aos teus registos carácter a carácter, mesmo sendo a mesma
> pessoa. Compara também pelo número de documento ou pela data de nascimento
> antes de tratares uma discrepância de nome como fraude.

## Os resultados em sandbox parecem ligeiramente diferentes

Numa sessão sandbox, a consola assinala as secções de dados extraídos com um chip de **Dados simulados**. A media foi captada de verdade, mas os campos e o resultado vieram do cenário que escolheste - por isso não tires conclusões dos valores em si. Consulta [testar em sandbox](https://help.didit.me/pt-PT/getting-started/sandbox-and-testing).

## Obter o mesmo de forma programática

O payload do webhook e o `GET /v3/session/{id}/decision/` trazem as três camadas num único objeto `decision`. Trata o webhook como a tua fonte de verdade e usa o polling apenas para reconciliação - alguns eventos, como edições de dados feitas por um revisor, só chegam por webhook. Consulta [obter resultados com webhooks](https://help.didit.me/pt-PT/integration/webhooks-basics).

## Obter uma cópia para os teus registos

Para auditorias e submissões regulatórias, descarrega a sessão como PDF - reúne cada passo, os dados extraídos, as pontuações biométricas, os resultados de AML, e a decisão final. Consulta [descarregar um relatório de verificação](https://help.didit.me/pt-PT/verification-sessions/download-verification-report).