> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Dados de teste da sandbox: cenários, valores e documentos

> Teste a Didit na sandbox com cenários, valores mágicos, documentos e códigos OTP para resultados previsíveis, sem dados pessoais nem faturação.

O **sandbox** da Didit é o equivalente aos cartões de teste da Stripe ou aos modelos de documentos da Sumsub: permite reproduzir de forma determinística qualquer resultado de verificação, sem chamar fornecedores reais, sem tratar dados pessoais reais e sem afetar o seu saldo.

> [!NOTE]
>
> A fonte de verdade para estes dados é `serialize_catalog()` no serviço de verificação, disponibilizada em tempo real em `GET /v1/sandbox/scenarios/`. Uma cópia testada quanto a desvios é gerada em `docs/sandbox/SANDBOX_REFERENCE.md` no repositório `service-didit-verification`, com `pipenv run python scripts/generate_sandbox_reference.py`. Esta página reproduz essa referência: se algo aqui parecer desatualizado, confie sempre no endpoint do catálogo em tempo real. O endpoint do catálogo exige autenticação: envie a sua chave de API (`x-api-key`) como em qualquer outro pedido, ou um token de sessão se o estiver a consultar a partir de uma sessão em execução.

## Modelo de ambientes

O sandbox é um **modo por aplicação** (`ApplicationDetail.mode == SANDBOX`), à semelhança do modo de teste da Stripe. Enquanto uma sessão corre numa aplicação em sandbox:

* Todos os fornecedores externos (OCR, AML, correspondência facial, prova de vida, NFC, telefone, e-mail, IP, comprovativo de morada, validação de base de dados e Document AI) são **simulados**. Nenhum terceiro é chamado.
* **A prova de vida funciona exatamente como em produção.** Um fluxo de prova de vida ativa executa a captura ativa real no sandbox, tanto no fluxo alojado como na transferência para a web a partir dos SDKs nativos, para que possa testar a experiência que os seus utilizadores terão. Só o *resultado* da prova de vida é simulado, pelo cenário ou pelo valor mágico, e o relatório regista o método que o seu fluxo configura.
* **Os domínios personalizados existem apenas em produção.** Uma aplicação em sandbox não pode adicionar um [domínio personalizado](https://docs.didit.me/pt/console/custom-domain.md); as sessões em sandbox usam sempre o domínio de verificação alojado por defeito.
* As sessões **nunca são cobradas** e a verificação de saldo é ignorada.
* É aplicada uma quota de **500 criações de sessão / 24 h** por aplicação.
* Os webhooks incluem `"environment": "sandbox"` (as sessões em produção incluem `"environment": "live"`).
* O fluxo alojado expõe o ambiente da sessão para que a interface possa avisar os utilizadores para não carregarem dados pessoais reais.
* **Os resultados nunca dependem dos pixels**: os dados extraídos e os estados vêm do cenário ou do valor mágico. Os próprios ficheiros capturados (documentos, selfie, vídeo, ficheiros de comprovativo de morada) são guardados de facto, exatamente como numa sessão em produção.

## Monitorização de transações no sandbox

O sandbox tem **a forma de uma sessão**: simula os fornecedores que uma sessão de verificação chamaria. A Monitorização de transações não tem fornecedor para simular, por isso uma aplicação sandbox segue o outro caminho: a transação é guardada, mas **nada que decida, faça triagem, notifique ou fature é executado sobre ela**.

Uma transação criada numa aplicação sandbox é guardada e devolvida como habitualmente, e nada do seguinte acontece com ela:

* **Sem avaliação de regras.** `rule_runs` fica vazio, independentemente do modo em que estejam as suas regras. Uma regra `ACTIVE` numa aplicação sandbox nunca dispara, por isso a transação mantém-se `APPROVED` com pontuação `0` e não é aberto qualquer alerta nem caso.
* **Sem triagem AML nem de carteiras.** `provider_results` fica vazio, mesmo em transações de cripto numa aplicação com monitorização ativada.
* **Sem webhooks.** Nem `transaction.created` nem `transaction.status.updated` são enviados para uma transação sandbox.
* **Sem faturação.** É registado um evento de utilização com preço `0.0000`, e o seu saldo não é alterado.

Cada resposta de transação inclui um campo `environment` (`"live"` ou `"sandbox"`), para que um `rule_runs` vazio nunca seja ambíguo: `"sandbox"` significa que as regras não foram avaliadas, e não que nenhuma delas correspondeu. A Business Console diz o mesmo no cartão *Risk & decision* da transação, em vez de apresentar apenas "No rules evaluated".

> [!NOTE]
>
> **A Travel Rule é a única exceção a "nada é executado".** Numa aplicação com a Travel Rule ativada, uma transação `travelRule` sandbox continua a executar o motor de exchange: o registo da transferência é criado e avança pelos seus estados.
> O que o sandbox nunca faz é comunicar com alguém fora da Didit.
> A sua única contraparte é o [Didit Test VASP](https://docs.didit.me/pt/transaction-monitoring/travel-rule-sandbox.md), integrado na plataforma: nenhuma mensagem de conformidade chega a um VASP contraparte real por nenhum canal (`TRP`, uma rede à qual se tenha ligado, e-mail ou `INTERNAL`), a atribuição de VASP contraparte na triagem é ignorada, e um cancelamento não envia nada à contraparte.
> Os webhooks `travel_rule.status.updated` são enviados, marcados com `"environment": "sandbox"`.
>
> **Saída** - uma transação `travelRule` que submete.
> A verificação de `threshold_amount` é feita primeiro e, no sandbox, só se aplica quando envia `transaction_details.amount_in_default_currency`, porque o sandbox não converte moedas; sem este campo, cada transferência sandbox conta como acima do limiar.
> Uma transferência sem resposta expira após `confirmation_timeout_hours`, e o seu `timeout_outcome` aplica-se então à transação.
> Acima do limiar, a verificação de carteira autocustodiada aplica-se como habitualmente: uma transferência para uma [carteira autocustodiada declarada](https://docs.didit.me/pt/transaction-monitoring/travel-rule.md#carteiras-autocustodiadas-declaradas) passa para `UNCONFIRMED_OWNERSHIP` sem nada ser enviado, e pode concluí-la no sandbox através do [widget de verificação de propriedade da carteira](https://docs.didit.me/pt/transaction-monitoring/wallet-ownership-widget.md), ou através de [confirmar propriedade](https://docs.didit.me/pt/management-api/travel-rule/confirm-ownership.md) quando a carteira de destino já está na sua lista de endereços de carteiras.
> Qualquer outra transferência acima do limiar é enviada para o Didit Test VASP no canal `TEST_VASP`, que lhe responde dentro da Didit com o cenário que escolher pela carteira ou pelo nome do beneficiário: é concluída, é recusada, não coincide, passa para `COUNTERPARTY_VASP_NOT_REACHABLE`, expira (e o seu `timeout_outcome` aplica-se então à transação) ou fica a aguardar a propriedade da carteira.
> Veja [Testar a Travel Rule no sandbox](https://docs.didit.me/pt/transaction-monitoring/travel-rule-sandbox.md) para todos os cenários.
>
> **Entrada** - `POST /v3/travel-rule/inbound/`. O registo nunca é enviado por um canal, por isso nada nele é simulado: o sandbox resolve o depósito contra a sua lista de endereços de carteiras e liquida de forma síncrona, exatamente como em produção. Resulta num resultado real e não em `AWAITING_COUNTERPARTY`: `ON_HOLD` (sem correspondência na lista de endereços), `UNCONFIRMED_OWNERSHIP` (a propriedade da entrada correspondente não foi verificada), `COUNTERPARTY_MISMATCHED_DATA` (o nome do beneficiário não corresponde ao titular da carteira), ou `COMPLETED` e depois `FINISHED` (correspondeu a uma entrada verificada).
> Para receber uma transferência do Didit Test VASP, use [Acionar transferência de entrada do Test VASP](https://docs.didit.me/pt/management-api/travel-rule/trigger-test-vasp-inbound.md) com uma das carteiras da sua lista de endereços.

### Cenários do Test VASP da Travel Rule

O `travel_rule.scenarios` do catálogo lista estes cenários de saída. Defina o nome do beneficiário abaixo numa transação `travelRule` de saída depois de ativar a Travel Rule na sua aplicação sandbox. As verificações de limiar e de carteira autocustodiada declarada descritas acima são executadas primeiro.

| Cenário | Nome do beneficiário | Resultado |
| - | - | - |
| `accept` | `Didit Test VASP` | `COMPLETED` |
| `decline` | `Didit Test VASP Decline` | `COUNTERPARTY_VASP_GENERAL_DECLINE` |
| `name_mismatch` | `Didit Test VASP Name Mismatch` | `COUNTERPARTY_MISMATCHED_DATA` |
| `not_reachable` | `Didit Test VASP Not Reachable` | `COUNTERPARTY_VASP_NOT_REACHABLE` após novas tentativas de entrega |
| `timeout` | `Didit Test VASP Timeout` | `EXPIRED` quando a verificação de expiração é executada depois do prazo de um minuto |
| `self_hosted` | `Didit Test VASP Self Hosted` | `UNCONFIRMED_OWNERSHIP` |

Também pode escolher um cenário com o endereço da carteira do beneficiário em vez do nome (a carteira prevalece quando ambos estão definidos), e uma transferência que não indique nenhum dos dois é concluída como `accept`. [Testar a Travel Rule no sandbox](https://docs.didit.me/pt/transaction-monitoring/travel-rule-sandbox.md) lista o endereço de carteira de cada cenário e o seu resultado exato.

O [acionador de entrada do Test VASP](https://docs.didit.me/pt/management-api/travel-rule/trigger-test-vasp-inbound.md) aceita apenas `accept` e `name_mismatch` no seu campo `scenario`.

> [!NOTE]
>
> **Como testar uma regra antes de a colocar em produção.** Utilize o [Backtest](https://docs.didit.me/pt/transaction-monitoring/rules-api.md#criar-fazer-backtest-e-ativar): reexecuta a regra sobre o seu histórico real de transações e apresenta `evaluated` / `matched` / `affected_entities` sem alterar o estado de nenhuma transação. Combine-o com o modo `TEST` na aplicação de produção - uma regra `TEST` é avaliada em cada nova transação real e regista aquilo a que teria correspondido, sem alterar a pontuação nem o estado - e passe para `ACTIVE` quando a seletividade estiver adequada.

## Como alternar entre produção e sandbox

A produção e o sandbox são **aplicações separadas**, pelo que o tráfego de teste e os dados de produção nunca se misturam. Cada aplicação tem um `mode` de `live` ou `sandbox`:

* Use a chave de API de uma aplicação em **modo sandbox** para obter sessões simuladas, não faturadas e passíveis de simulação.
* Use a chave de API de uma aplicação em **modo de produção** para verificações reais.

O campo `sandbox_scenario` (na criação de sessões e na API AML autónoma) e os endpoints de simulação só são aceites em aplicações sandbox; são rejeitados em aplicações de produção.

## Sandbox no fluxo de verificação alojado

As sessões criadas numa aplicação sandbox apresentam elementos de interface adicionais no fluxo de verificação alojado (o `url` devolvido por `POST /v3/session/`):

* **Banner sandbox no cartão.** Todos os ecrãs apresentam um banner dentro do cartão - "Apenas dados de teste - sem chamadas reais" - para que fique sempre evidente que a sessão nunca chama fornecedores reais nem afeta o seu saldo. Os conteúdos multimédia capturados são conservados como em qualquer sessão, por isso use os documentos de exemplo e os dados de teste em vez de documentos de identidade reais ou informações pessoais.
* **Seletor de cenários antes do fluxo.** Antes de a captura começar, um seletor no cartão guia o utilizador na escolha de um resultado de teste: escolher um resultado e, em seguida, um acionador para esse resultado. A confirmação chama `POST /v3/session/{session_id}/sandbox/arm/` (ver [Preparar (ou preparar novamente) a sessão antes de o fluxo começar](#3-armar-ou-voltar-a-armar-a-sessão-antes-de-o-fluxo-começar) abaixo) e continua o fluxo com os valores mágicos desse cenário já aplicados.
* **Faixa de documentos de exemplo.** Uma única linha de documentos de exemplo do sandbox (até 3) fica diretamente abaixo do componente de carregamento e captura de documentos. Toque num deles para o usar em vez de um carregamento real.

As sessões sandbox guardam os conteúdos multimédia **reais** capturados - documentos, selfie, vídeo de prova de vida e ficheiros de comprovativo de morada são carregados e conservados exatamente como numa sessão de produção. Os dados *extraídos* (campos de verificação de identidade, pontuações de correspondência facial, resultados de prova de vida e semelhantes) e o próprio resultado da sessão (Aprovada / Em análise / Recusada) são simulados pelo cenário ou pelo valor mágico, nunca derivados dos conteúdos capturados. A Business Console assinala as secções de dados extraídos de uma sessão sandbox com um chip **Dados simulados**, para que os revisores percebam de imediato que partes da sessão correspondem à captura real e quais são guiadas por cenário.

## Cenários

Cada cenário é um conjunto nomeado de valores mágicos. Passe o respetivo slug como `sandbox_scenario` ao criar a sessão (ou ao endpoint de simulação) para reproduzir o resultado.

| Slug | Título | Estado predefinido | Descrição |
| - | - | - | - |
| `approve` | Caminho feliz – todas as funcionalidades aprovam | Aprovada | Comportamento predefinido do sandbox: cada funcionalidade simulada devolve o resultado limpo APPROVED. A sessão termina com o estado APPROVED. |
| `decline_aml_hit` | AML – pessoa politicamente exposta | Recusada | O mock de AML devolve uma correspondência e a sessão é recusada na funcionalidade de AML. A correspondência usa o mesmo [Esquema de correspondência](https://docs.didit.me/pt/core-technology/aml-screening/report-aml-screening.md#campos-por-hit) dos fornecedores de AML em produção: `url`, `match_score`, `risk_score`, `review_status`, `properties`, `pep_matches[]` e `score_breakdown` ficam todos preenchidos, e é escrito um registo de aviso POSSIBLE\_MATCH\_FOUND. |
| `decline_document_expired` | Verificação de identidade – documento expirado | Recusada | O mock de verificação de identidade devolve um passaporte cuja data de validade está no passado. A sessão é recusada na verificação de identidade, com um registo de aviso DOCUMENT\_EXPIRED. |
| `decline_minimum_age` | Verificação de identidade – abaixo da política de idade mínima | Recusada | O mock de verificação de identidade devolve uma data de nascimento que faz com que o utilizador tenha cerca de 10 anos. A verificação de idade em produção emite MINIMUM\_AGE\_NOT\_MET e o fluxo recusa a sessão. |
| `decline_mrz_validation` | Verificação de identidade – falha na soma de verificação do MRZ | Recusada | O mock de verificação de identidade devolve um passaporte com a soma de verificação do MRZ corrompida. O validador de MRZ em produção emite MRZ\_VALIDATION\_FAILED e a sessão é recusada. |
| `decline_could_not_recognize_document` | Verificação de identidade – documento ilegível | Recusada | O mock de verificação de identidade devolve uma resposta vazia. Em produção, é gerado COULD\_NOT\_RECOGNIZE\_DOCUMENT e esse erro é apresentado ao SDK. |
| `decline_face_match_low_similarity` | Correspondência facial – similaridade abaixo do limiar de recusa | Recusada | O mock de correspondência facial devolve uma pontuação baixa. Em produção, é emitido LOW\_FACE\_MATCH\_SIMILARITY e o mapeamento de ação do nó do fluxo recusa a sessão. |
| `decline_database_no_match` | Validação de base de dados – sem correspondência em todos os serviços | Recusada | Cada serviço de base de dados selecionado devolve NO\_MATCH. Em produção, é emitido DATABASE\_VALIDATION\_NO\_MATCH e o fluxo recusa a sessão. |
| `decline_phone_high_risk` | Telefone – número de teste de risco elevado reservado | Recusada | O mock de verificação de telefone bloqueia a verificação (intervalo reservado para testes). A verificação de telefone termina como BLOCKED e emite HIGH\_RISK\_PHONE\_NUMBER. |
| `decline_email_breach` | E-mail – correspondência numa base de dados de violações | Recusada | O mock de violações de e-mail devolve um resultado de violação para o endereço. A verificação de e-mail emite BREACHED\_EMAIL\_DETECTED. |
| `decline_ip_blocklist` | Análise de IP – endereço IP na lista de bloqueio | Recusada | O mock de análise de IP recusa a localização com IP\_ADDRESS\_IN\_BLOCKLIST. A sessão é recusada na análise de IP. |
| `decline_poa_address_mismatch` | POA – morada divergente da fornecida | Recusada | O mock de POA recusa o comprovativo de morada com ADDRESS\_MISMATCH\_WITH\_PROVIDED. A sessão é recusada no POA. |
| `decline_liveness_attack` | Prova de vida – ataque facial detetado | Recusada | O mock de prova de vida passiva deteta um sinal de ataque facial e emite LIVENESS\_FACE\_ATTACK. A sessão é recusada na prova de vida. |
| `decline_nfc_chip_not_verified` | NFC – chip do ePassport não verificado | Recusada | O mock do ePassport devolve um chip cuja assinatura SOD/DG falha na verificação de integridade. Em produção, é emitido NFC\_CHIP\_NOT\_VERIFIED e a sessão é recusada no NFC quando o fluxo recusa chips não verificados. |
| `decline_nfc_trust_anchor_missing` | NFC – âncora de confiança da entidade emissora indisponível | Recusada | O mock do ePassport devolve um chip assinado por uma DSC cuja CSCA emissora está ausente do repositório de confiança. Em produção, é emitido NFC\_TRUST\_ANCHOR\_MISSING e a sessão é recusada quando o fluxo recusa chips não verificados. |
| `decline_document_ai_unreadable` | Document AI – documento ilegível | Recusada | O mock do Document AI não devolve campos legíveis. Em produção, é emitido DOCUMENT\_AI\_UNREADABLE\_DOCUMENT e o documento é considerado recusado quando se esgota o número de tentativas. |
| `review_aml_possible_match` | AML – possível correspondência que requer revisão | Em análise | O mock de AML devolve uma correspondência com menor confiança. A sessão fica Em análise, com um registo de aviso POSSIBLE\_MATCH\_FOUND para um analista resolver. |
| `review_face_match_borderline` | Correspondência facial – similaridade limítrofe | Em análise | O mock de correspondência facial devolve uma pontuação entre os limiares de revisão e de recusa. A sessão fica Em análise na correspondência facial. |
| `review_document_borderline_age` | Verificação de identidade – menor enviado para revisão | Em análise | O mock de verificação de identidade devolve uma data de nascimento abaixo da idade mínima configurada no fluxo. O minimum\_age\_action do fluxo está definido como REVIEW em vez de DECLINE, pelo que a sessão fica Em análise na verificação de identidade em vez de ser recusada. |
| `review_poa_partial_match` | POA – correspondência parcial de morada | Em análise | O mock de POA devolve uma morada que só corresponde parcialmente à fornecida. A sessão fica Em análise no comprovativo de morada. |
| `review_database_partial_match` | Validação de base de dados – correspondência parcial | Em análise | Os serviços de base de dados devolvem correspondências parciais no nome e na data de nascimento. A sessão fica Em análise na validação de base de dados. |
| `decline_kyb_registry_mismatch` | KYB – dados do registo divergentes | Recusada | O mock do registo devolve uma empresa cujos dados de registo não coincidem com os detalhes esperados. A sessão empresarial é recusada na verificação do registo. |
| `review_kyb_registry_partial` | KYB – dados do registo parcialmente correspondentes | Em análise | O mock do registo devolve uma empresa cujo nome só corresponde parcialmente. A sessão empresarial fica Em análise na verificação do registo. |

Os cenários `review_*` existem para poder testar a experiência de revisão manual (a fila de revisão na consola, webhooks de `In Review`, ações de aprovação e recusa do revisor) sem precisar de uma entrada que provoque uma recusa. Os dois cenários `kyb_*` acima definem `expected_details.registration_number` em vez de `expected_details.first_name`: aplicam-se apenas a sessões de Verificação de empresas (KYB).

## Valores mágicos

Um valor mágico é uma entrada específica que faz uma funcionalidade simulada gerar um risco específico. Defina o campo de entrada com o valor mágico (diretamente ou através de um cenário) para acionar esse risco.

| Funcionalidade | Campo de entrada | Valor mágico | Risco | Descrição |
| - | - | - | - | - |
| AML | `user_email` | `sandbox+aml_hit@didit.test` | `POSSIBLE_MATCH_FOUND` | AML — pessoa politicamente exposta; a simulação de AML devolve uma correspondência e a sessão é recusada na verificação AML. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DOCUMENT_EXPIRED` | `DOCUMENT_EXPIRED` | OCR — documento expirado; a sessão é recusada na verificação de identidade. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_MINIMUM_AGE_NOT_MET` | `MINIMUM_AGE_NOT_MET` | OCR — a data de nascimento indica que o utilizador tem uma idade inferior à idade mínima configurada; a sessão é recusada. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_MAXIMUM_AGE_EXCEEDED` | `MAXIMUM_AGE_EXCEEDED` | OCR — a data de nascimento extraída excede a política de idade máxima configurada. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DOCUMENT_NUMBER_FORMAT_MISMATCH` | `DOCUMENT_NUMBER_FORMAT_MISMATCH` | OCR — o número do documento extraído não corresponde à expressão regular de formato esperada para o documento, definida no registo de documentos. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_PERSONAL_NUMBER_FORMAT_MISMATCH` | `PERSONAL_NUMBER_FORMAT_MISMATCH` | OCR — o número pessoal extraído não passa a verificação de formato do registo de documentos. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DOCUMENT_NOT_SUPPORTED_FOR_APPLICATION` | `DOCUMENT_NOT_SUPPORTED_FOR_APPLICATION` | OCR — o tipo de documento extraído está fora da política `documents_allowed` da aplicação. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_FULL_NAME_MISMATCH_WITH_PROVIDED` | `FULL_NAME_MISMATCH_WITH_PROVIDED` | OCR — o nome no documento não corresponde ao nome que o cliente pré-preencheu em `expected_details`, acima do limiar de correspondência de nomes. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_GENDER_MISMATCH_WITH_PROVIDED` | `GENDER_MISMATCH_WITH_PROVIDED` | OCR — o género extraído não coincide com `expected_details.gender`. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DOB_MISMATCH_WITH_PROVIDED` | `DOB_MISMATCH_WITH_PROVIDED` | OCR — a data de nascimento extraída não coincide com `expected_details.date_of_birth`. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_COUNTRY_MISMATCH_WITH_PROVIDED` | `COUNTRY_MISMATCH_WITH_PROVIDED` | OCR — o país emissor não coincide com `expected_details.country` (ou `id_country`). |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_NATIONALITY_MISMATCH_WITH_PROVIDED` | `NATIONALITY_MISMATCH_WITH_PROVIDED` | OCR — a nacionalidade extraída não coincide com `expected_details.nationality`. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_IDENTIFICATION_NUMBER_MISMATCH_WITH_PROVIDED` | `IDENTIFICATION_NUMBER_MISMATCH_WITH_PROVIDED` | OCR — o número do documento, pessoal ou fiscal extraído não coincide com `expected_details.identification_number`. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_COULD_NOT_RECOGNIZE_DOCUMENT` | `COULD_NOT_RECOGNIZE_DOCUMENT` | O pipeline de OCR devolve um resultado vazio ou não reconhecível; em produção, gera COULD\_NOT\_RECOGNIZE\_DOCUMENT. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_MRZ_NOT_DETECTED` | `MRZ_NOT_DETECTED` | OCR — o documento requer uma MRZ, mas o pipeline não a conseguiu localizar. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_MRZ_VALIDATION_FAILED` | `MRZ_VALIDATION_FAILED` | OCR — a MRZ foi encontrada, mas falhou a validação de soma de verificação ou de formato. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_MRZ_AND_DATA_EXTRACTED_FROM_OCR_NOT_SAME` | `MRZ_AND_DATA_EXTRACTED_FROM_OCR_NOT_SAME` | OCR — os campos de identidade da MRZ não coincidem com os campos extraídos da VIZ. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_BARCODE_NOT_DETECTED` | `BARCODE_NOT_DETECTED` | OCR — o documento requer um código de barras, mas não foi encontrado nenhum. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_BARCODE_VALIDATION_FAILED` | `BARCODE_VALIDATION_FAILED` | OCR — o código de barras foi descodificado, mas falhou a validação cruzada entre campos. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_QR_NOT_DETECTED` | `QR_NOT_DETECTED` | OCR — o documento requer um código QR, mas não foi encontrado nenhum. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_QR_VALIDATION_FAILED` | `QR_VALIDATION_FAILED` | OCR — o código QR foi descodificado, mas falhou a validação cruzada entre campos. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DATA_INCONSISTENT` | `DATA_INCONSISTENT` | OCR — as verificações de consistência interna dos campos da VIZ não coincidem entre si. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DOCUMENT_SIDES_MISMATCH` | `DOCUMENT_SIDES_MISMATCH` | OCR — a frente e o verso do document\_name não correspondem ao mesmo documento. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_NAME_NOT_DETECTED` | `NAME_NOT_DETECTED` | OCR — não foi possível extrair nem o primeiro nome nem o apelido do documento. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DATE_OF_BIRTH_NOT_DETECTED` | `DATE_OF_BIRTH_NOT_DETECTED` | OCR — a classe do documento exige uma data de nascimento, mas a extração não devolveu nenhuma. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_EXPIRATION_DATE_NOT_DETECTED` | `EXPIRATION_DATE_NOT_DETECTED` | OCR — a classe do documento exige uma data de validade, mas a extração não devolveu nenhuma. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DOCUMENT_NUMBER_NOT_DETECTED` | `DOCUMENT_NUMBER_NOT_DETECTED` | OCR — não foi possível extrair nem o número do documento nem o número pessoal. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_COULD_NOT_DETECT_DOCUMENT_TYPE` | `COULD_NOT_DETECT_DOCUMENT_TYPE` | OCR — o classificador não conseguiu associar a captura a um tipo de documento suportado. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_PORTRAIT_IMAGE_NOT_DETECTED` | `PORTRAIT_IMAGE_NOT_DETECTED` | OCR — o pipeline não conseguiu isolar uma região de retrato no documento. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_UNPARSED_ADDRESS` | `UNPARSED_ADDRESS` | OCR — o documento tem um campo de morada, mas a geocodificação / análise não devolveu nada utilizável. |
| DATABASE\_VALIDATION | `expected_details.first_name` | `SANDBOX_DB_NO_MATCH` | `DATABASE_VALIDATION_NO_MATCH` | Validação de base de dados — todos os serviços governamentais/de registo devolvem NO\_MATCH; a sessão é recusada na validação de base de dados. |
| FACEMATCH | `expected_details.first_name` | `SANDBOX_FACE_LOW_MATCH` | `LOW_FACE_MATCH_SIMILARITY` | Correspondência facial — pontuação de semelhança abaixo do limiar de recusa; a sessão é recusada na correspondência facial. |
| PHONE | `phone_number` | `+15005550009` | `HIGH_RISK_PHONE_NUMBER` | Telefone — número de teste reservado, não entregável / de risco elevado; a simulação da verificação de telefone devolve uma falha. |
| EMAIL | `user_email` | `sandbox+breach@didit.test` | `BREACHED_EMAIL_DETECTED` | E-mail — a base de dados de violações de dados devolve uma correspondência para este endereço. |
| LOCATION | `expected_details.first_name` | `SANDBOX_IP_BLOCKLIST` | `IP_ADDRESS_IN_BLOCKLIST` | Análise de IP — o endereço IP do chamador consta da lista de bloqueio da aplicação; a sessão é recusada na análise de IP. |
| PROOF\_OF\_ADDRESS | `expected_details.first_name` | `SANDBOX_POA_ADDRESS_MISMATCH` | `ADDRESS_MISMATCH_WITH_PROVIDED` | POA — a morada no documento carregado não coincide com a morada que o cliente preencheu em `expected_details`; a sessão é recusada na POA. |
| LIVENESS | `expected_details.first_name` | `SANDBOX_LIVENESS_ATTACK` | `LIVENESS_FACE_ATTACK` | Prova de vida — a simulação de prova de vida passiva deteta um sinal de ataque facial; a sessão é recusada na prova de vida. |
| NFC | `expected_details.first_name` | `SANDBOX_NFC_CHIP_NOT_VERIFIED` | `NFC_CHIP_NOT_VERIFIED` | NFC — o mock do ePassport devolve um chip cuja assinatura SOD/DG falha na verificação de integridade; em produção, emite NFC\_CHIP\_NOT\_VERIFIED e recusa quando o fluxo recusa chips não verificados. |
| NFC | `expected_details.first_name` | `SANDBOX_NFC_TRUST_ANCHOR_MISSING` | `NFC_TRUST_ANCHOR_MISSING` | NFC — o DSC forma uma cadeia até uma CSCA ausente do repositório de confiança; em produção, emite NFC\_TRUST\_ANCHOR\_MISSING e aplica a ação configurada para chips não verificados. |
| DOCUMENT\_AI | `expected_details.first_name` | `SANDBOX_DOCUMENT_AI_UNREADABLE` | `DOCUMENT_AI_UNREADABLE_DOCUMENT` | Document AI — a extração não devolve quaisquer campos legíveis; em produção, emite DOCUMENT\_AI\_UNREADABLE\_DOCUMENT e o documento fica recusado quando o limite de tentativas é esgotado. |
| AML | `user_email` | `sandbox+aml_review@didit.test` | `POSSIBLE_MATCH_FOUND` | AML — possível correspondência que precisa de resolução manual; a sessão fica em análise. |
| FACEMATCH | `expected_details.first_name` | `SANDBOX_FACE_BORDERLINE_MATCH` | `LOW_FACE_MATCH_SIMILARITY` | Correspondência facial — semelhança limítrofe entre os limiares de análise e de recusa; a sessão fica em análise. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_BORDERLINE_AGE` | `MINIMUM_AGE_NOT_MET` | OCR — a data de nascimento é inferior à idade mínima, mas o fluxo analisa em vez de recusar falhas de idade mínima; a sessão fica em análise. |
| DATABASE\_VALIDATION | `expected_details.first_name` | `SANDBOX_DB_PARTIAL_MATCH` | `DATABASE_VALIDATION_PARTIAL_MATCH` | Validação de base de dados — a identificação coincide, mas o nome e a data de nascimento coincidem apenas parcialmente; a sessão fica em análise. |
| PROOF\_OF\_ADDRESS | `expected_details.first_name` | `SANDBOX_POA_PARTIAL_MATCH` | `ADDRESS_MISMATCH_WITH_PROVIDED` | POA — a morada no documento carregado coincide parcialmente com a morada fornecida; a sessão fica em análise. |
| KYB\_REGISTRY | `expected_details.registration_number` | `SANDBOX-KYB-MISMATCH` | `KYB_REGISTRY_DATA_MISMATCH_WITH_EXPECTED` | KYB - os dados da empresa no registo não coincidem com os dados esperados; a sessão é recusada. |
| KYB\_REGISTRY | `expected_details.registration_number` | `SANDBOX-KYB-REVIEW` | `KYB_REGISTRY_DATA_PARTIAL_MATCH_WITH_EXPECTED` | KYB - os dados da empresa no registo coincidem parcialmente; a sessão fica em análise. |

## Consulta sem documento e carteiras de identidade

As aplicações sandbox podem ativar todas as carteiras de identidade do catálogo do país, incluindo carteiras indisponíveis em aplicações de produção.
O cenário predefinido `approve` simula uma identidade verificada sem iniciar sessão numa carteira externa.
O resultado fica guardado na sessão e segue o próximo passo normal do fluxo.
O sandbox não valida uma credencial de carteira real nem cobra pelas tentativas simuladas.

Os pedidos de consulta continuam a validar os campos introduzidos e a usar o limite de tentativas configurado, que por predefinição é de um.
Use os cenários seguintes para testar novas tentativas e as regras de recurso:

| Cenário | Resultado simulado |
| - | - |
| `lookup_partial_match` | Correspondência parcial no registo; conta para o limite de tentativas. |
| `lookup_no_match` | O registo responde sem correspondência; conta para o limite de tentativas. |
| `lookup_provider_error` | O registo não devolve resposta; pede-se ao utilizador que tente novamente e, após três tentativas sem resposta, aplica-se a regra de recurso por erro do fornecedor. |
| `wallet_cancelled` | O utilizador cancela o início de sessão na carteira. |
| `wallet_timeout` | O início de sessão na carteira expira. |
| `wallet_provider_error` | A carteira não consegue concluir o início de sessão. |

As falhas da carteira seguem a definição do país: recorrer à captura do documento ou recusar.
As tentativas de consulta concluídas são registadas separadamente; assim, duas tentativas permitidas produzem dois resultados antes do recurso.
Toda a utilização do sandbox continua gratuita.

## Verificação bancária e verificação de conta

Um passo de Verificação bancária no sandbox oferece [ambos os métodos](https://docs.didit.me/pt/core-technology/bank-verification/verification-methods.md) em todos os países, pela ordem definida pelo passo, num serviço simulado, sem banco real e sem custos.
Com a ordem predefinida, a pessoa começa no início de sessão no banco e seleciona **Introduza os dados da sua conta** para executar a [verificação de conta](https://docs.didit.me/pt/core-technology/bank-verification/account-check.md); defina `bank_method_order` como `["account_lookup", "open_banking"]` para começar por esta opção.
Os últimos quatro caracteres da conta introduzida determinam a resposta; consulte [Testar no sandbox](https://docs.didit.me/pt/core-technology/bank-verification/account-check.md#testar-na-sandbox) para ver todas as terminações e uma conta válida por formato.
A [API de verificação de conta](https://docs.didit.me/pt/standalone-apis/bank-account-check.md) devolve uma chave de sandbox com base nas mesmas terminações.

## Os documentos de exemplo

> [!WARNING]
>
> Nunca carregue documentos de identidade reais no sandbox. Use, em vez disso, os documentos de exemplo incorporados.

O fluxo alojado oferece três documentos de exemplo, um por tipo de documento:

| País | Tipo de documento |
| - | - |
| Espanha | Cartão de identidade nacional |
| Argentina | Passaporte |
| Polónia | Carta de condução |

Toque num exemplo na faixa para o usar em vez de uma captura real. Os dados extraídos e o resultado da sessão vêm sempre do cenário ou do valor mágico selecionado, pelo que qualquer exemplo funciona com qualquer cenário.

## Identidade de exemplo: testar `expected_details`

Todos os documentos de sandbox são fabricados a partir de uma única identidade **fixa**.
Os valores extraídos são iguais em todas as sessões e nunca são derivados da data atual, pelo que pode pré-preencher `expected_details` com eles e verificar de ponta a ponta a comparação de campos e o tratamento de avisos.
Se passar os valores abaixo, as verificações de comparação passam; se passar outros valores, o aviso `*_MISMATCH_WITH_PROVIDED` correspondente é disparado de propósito.

As datas são partilhadas por todos os documentos de exemplo:

| Campo | Valor |
| - | - |
| `date_of_birth` | `1990-06-15` |
| Data de emissão | `2025-06-15` |
| Data de validade | `2035-06-15` |

O restante da identidade depende do documento utilizado:

| `sandbox_sample` | Documento | `first_name` | `last_name` | `gender` | `nationality` | `id_country` | `identification_number` |
| - | - | - | - | - | - | - | - |
| *(padrão, nenhum exemplo selecionado)* | Passaporte eletrónico do Brasil | `GUSTAVO` | `MATSUMOTO` | `M` | `BRA` | `BRA` | `YC531181` |
| `spain-id-card-2021` | Cartão de identidade nacional de Espanha | `CARMEN` | `ESPAÑOLA ESPAÑOLA` | `F` | `ESP` | `ESP` | `CAA000000` |
| `argentina-passport-2009` | Passaporte da Argentina | `MARIA VICTORIA` | `VILLAREAL` | `F` | `ARG` | `ARG` | `AAF794880` |
| `poland-driving-license-2019` | Carta de condução da Polónia | `JAN` | `KOWALSKI` | não consta neste documento | `POL` | `POL` | `SP005/89/5` |

```json theme={null}
{
  "workflow_id": "<your-workflow-uuid>",
  "expected_details": {
    "date_of_birth": "1990-06-15",
    "gender": "M",
    "nationality": "BRA",
    "identification_number": "YC531181"
  }
}
```

`first_name` e `last_name` são a exceção: o sandbox repete no documento fabricado os nomes que envia em `expected_details`, pelo que a correspondência de nomes passa com qualquer nome.
Use o valor mágico `SANDBOX_OCR_FULL_NAME_MISMATCH_WITH_PROVIDED` para testar uma divergência de nome, e `SANDBOX_OCR_DOB_MISMATCH_WITH_PROVIDED` para uma divergência na data de nascimento.

> [!NOTE]
>
> Se o seu fluxo restringir `documents_allowed` a um país ou tipo de documento que exclua o passaporte eletrónico do Brasil, o sandbox fabrica, em vez disso, um documento a partir do primeiro país permitido, pelo que `nationality`, `id_country` e o nome do documento acompanham esse país. As datas acima mantêm-se.

### O que o documento fabricado não contém

O documento fabricado é o modelo genérico do país e do tipo de documento permitidos, pelo que os campos que só um documento real emitido por um estado fornece ficam vazios. O que mais importa para o encaminhamento é a **região / estado dos EUA** (`kyc.region`): uma carta de condução ou um cartão de identificação dos EUA de sandbox não tem estado, pelo que uma condição de ramificação como `Region equals IL` nunca é satisfeita no sandbox e, quando também nenhuma outra ramificação do nó corresponde, o fluxo segue a ramificação de fallback do nó (a ramificação sem condições). Isto não é uma revisão nem uma falha da ramificação - a condição simplesmente não tem o que ler. Um campo em falta também faz falhar `not equals` e `not in`; veja [como as condições de ramificação leem os dados da sessão](https://docs.didit.me/pt/console/workflows.md#como-as-condições-de-ramificação-leem-os-dados-da-sessão) para a diferença entre um campo em falta e uma string vazia.

Para testar um fluxo que depende do estado no sandbox, baseie a decisão num valor que controla na sessão, e não no documento:

* Envie o estado em `metadata` ao criar a sessão (por exemplo, `"metadata": {"credential_state": "IL"}`) e crie a ramificação com base em `metadata.credential_state`. Os metadados são avaliados no sandbox exatamente como em produção.
* Mantenha a condição `kyc.region`, baseada no documento, para o tráfego real, se também precisar que o documento comprove o estado; em produção, a região é lida do documento real.

Tudo o resto no encaminhamento é idêntico ao modo real: o grafo do fluxo, as condições de ramificação, os valores de `metadata` e `expected_details`, os nós de ação e os nós de estado são todos executados a sério. O sandbox nunca força uma sessão para revisão por iniciativa própria - uma sessão do sandbox só passa para Em análise quando o fluxo a encaminha para lá (um cenário `review_*`, um valor mágico mapeado para uma ação de revisão ou um nó de estado no grafo).

## Códigos OTP e adesão ao envio de e-mails

* **OTP por telefone:** a verificação de telefone do sandbox aceita qualquer código bem formado (de 4 a 8 dígitos; inclui `123456`). Uma entrada mal formada continua a devolver `400`.
* **OTP por e-mail:** a verificação de e-mail do sandbox aceita qualquer código bem formado (inclui `123456`). Uma entrada mal formada continua a devolver `400`.

Por predefinição, as sessões do sandbox **não** enviam e-mails (alertas de revisão, alterações de estado, OTP, reenvio, nova ligação de sessão, etc.). Para entregar um e-mail mesmo assim, use um destes padrões de adesão no endereço do destinatário:

| Padrão de adesão | Exemplo |
| - | - |
| `<local>+sandbox@<domain>` | `alice+sandbox@example.com` |
| `*@didit.test` | `alice@didit.test` |

## Condução dos resultados: cenários, valores mágicos, armação e o endpoint de simulação

Existem cinco formas de controlar um resultado sandbox.

### 1. `sandbox_scenario` na criação da sessão

Defina o slug do cenário ao criar a sessão (`POST /v3/session/`). O fluxo de criação expande os valores mágicos agrupados no cenário para os campos de entrada da sessão, de modo que os fornecedores simulados emitam o resultado pretendido através do pipeline real do fluxo.

```json theme={null}
{
  "workflow_id": "<your-workflow-uuid>",
  "sandbox_scenario": "decline_document_expired"
}
```

### 2. Valores mágicos introduzidos manualmente

Defina os campos de entrada individualmente (por exemplo, `expected_details.first_name = "SANDBOX_OCR_DOCUMENT_EXPIRED"` ou `user_email = "sandbox+aml_hit@didit.test"`). Consulte a tabela de valores mágicos acima para o registo completo.

### 3. Armar (ou voltar a armar) a sessão antes de o fluxo começar

Defina ou substitua o cenário armado numa sessão já existente, desde que esta não tenha avançado para além de `Not Started`. Este é o endpoint que o [seletor de cenário anterior ao fluxo](#sandbox-no-fluxo-de-verificação-alojado) chama, e pode chamá-lo diretamente para criar um seletor personalizado ou um ambiente de teste:

```
POST /v3/session/{session_id}/sandbox/arm/
Session-Token: <session_token>
```

```json theme={null}
{
  "scenario": "decline_document_expired"
}
```

Resposta 200:

```json theme={null}
{
  "session_id": "<session_id>",
  "scenario": "decline_document_expired",
  "status": "Not Started"
}
```

* Autentique-se com o `Session-Token` da própria sessão (devolvido como `session_token` na criação da sessão), e não com a chave de API da aplicação: trata-se de um endpoint voltado para o cliente.
* Devolve `400` para um slug de cenário desconhecido, e `400` quando a sessão já avançou para além de `Not Started` (`"Scenario can only be armed before the verification starts."`).
* Devolve `404` quando o `Session-Token` pertence a uma aplicação de produção (não sandbox), ou quando não corresponde ao `session_id` do caminho.
* **Voltar a armar substitui o cenário anterior.** Limpa apenas os valores mágicos que o cenário anterior escreveu e deixa intacto tudo o que o utilizador já tenha introduzido manualmente (e-mail, nome próprio, etc.). Por exemplo: arme `decline_phone_high_risk` e depois arme `approve`. O número de telefone volta a ficar por definir, mas um e-mail introduzido pelo cliente sobrevive às duas chamadas.

### 4. O endpoint de simulação

Force um estado final a posteriori:

* Consola / chave de API (requer o privilégio `write:sessions`; uma chave de API com âmbito limitado precisa de acesso de escrita às sessões): `POST /v3/session/{session_id}/simulate/`
* Fluxo alojado (cabeçalho `Session-Token`): `POST /v3/session/{session_id}/sandbox/simulate/`

Ambos funcionam em sessões sandbox KYC e KYB.
Uma sessão de produção (não sandbox) devolve `404`, e o mesmo acontece com um `Session-Token` que não corresponda ao `session_id` do caminho.

Todos os campos do corpo são opcionais, mas é obrigatório pelo menos um de `new_status`, `scenario` ou `risk`:

| Campo | Tipo | O que faz |
| - | - | - |
| `new_status` | string | `Approved`, `Declined`, `In Review`, `Expired` ou `Abandoned`. Quando o omite, assume o estado predefinido do caso de risco (`risk`, ou o primeiro risco que os valores mágicos do cenário trazem) ou, na sua falta, o estado predefinido do cenário. |
| `scenario` | string, até 100 caracteres | Um slug de cenário. Sem `risk`, é aplicado o primeiro risco que os seus valores mágicos incluem. |
| `risk` | string, até 128 caracteres | Um caso de risco. O respetivo aviso é adicionado à sessão. |
| `node_id` | string, até 128 caracteres | O nó do fluxo ao qual o aviso fica associado. O valor predefinido é o nó atual da sessão. |
| `comment` | string, até 500 caracteres | Nota adicionada à entrada de atividade que regista a alteração de estado. |
| `send_webhooks` | booleano, predefinido `true` | Se a alteração de estado envia webhooks. |

Com `send_webhooks: true`, são enviados exatamente os webhooks que uma alteração de estado real envia: `status.updated`, além dos eventos `user.status.updated` e `user.data.updated` (ou `business.status.updated` e `business.data.updated` numa sessão de empresa) que a alteração provoca, para os destinos que subscreveram esses eventos.
Com `send_webhooks: false`, o estado continua a mudar, mas nenhum webhook é registado nem enviado.
A recuperação de webhooks perdidos nunca reenvia essa decisão, e a consola continua a atualizar-se em tempo real.
A próxima alteração de estado da sessão envia webhooks como habitualmente.

```json theme={null}
{
  "scenario": "decline_aml_hit",
  "send_webhooks": false
}
```

Resposta 200:

```json theme={null}
{
  "session_id": "<session_id>",
  "previous_status": "In Progress",
  "status": "Declined",
  "scenario": "decline_aml_hit",
  "risk": "POSSIBLE_MATCH_FOUND",
  "send_webhooks": false
}
```

* `status` é o estado que a simulação definiu, e `previous_status` o estado que a sessão tinha antes.
* `scenario` repete o slug enviado e `risk` é o caso de risco aplicado; cada um é `null` quando não existe.
* `send_webhooks` repete o valor aplicado.
* Devolve `400` para um cenário ou risco desconhecido, quando não é possível derivar nenhum `new_status`, para qualquer outro `new_status`, e quando a sessão já tem o estado pedido (`["The new status is the same as the current status."]`).

### 5. `sandbox_scenario` na API AML autónoma

A triagem AML em back-end não tem utilizador final nem sessão para armar, por isso o slug vai no próprio pedido de triagem (`POST /v3/aml/`):

```json theme={null}
{
  "full_name": "Ada Lovelace",
  "save_api_request": true,
  "sandbox_scenario": "decline_aml_hit"
}
```

* `decline_aml_hit` devolve uma correspondência com o formato de produção e fecha a triagem como `Declined`; `review_aml_possible_match` fecha-a como `In Review`. Um cenário que não arma nenhum resultado AML deixa a triagem limpa.
* Com `save_api_request: true` (valor predefinido), a triagem é guardada exatamente como numa chave de produção, pelo que o `request_id` devolvido é resolvido através de `GET /v3/session/{request_id}/decision/` e `GET /v3/session/{request_id}/generate-pdf/`.
* Devolve `400` para um slug de cenário desconhecido, e `400` quando a chave de API pertence a uma aplicação de produção.

## Onde aparece `sandbox_scenario`

O slug do cenário armado (`null` se nenhum estiver armado) é devolvido em algumas superfícies e intencionalmente omitido noutras:

| Superfície | Exposta? |
| - | - |
| Payload do passo atual (KYC e KYB) | Sim, como `sandbox_scenario` |
| `GET /v1/session/{id}/decision/` | Sim, como `sandbox_scenario` |
| `GET /v3/session/{id}/decision/` (ver [Obter sessão](https://docs.didit.me/pt/sessions-api/retrieve-session.md)) | Sim, `sandbox_scenario` de primeiro nível (null quando não armado) |
| Webhooks de sessão (`status.updated`, `data.updated`) | Sim, como `sandbox_scenario`; `null` em sessões de produção ou em sessões sandbox sem cenário armado |

Se a sua integração precisar de ramificar com base no cenário armado do lado do servidor, leia-o do envelope do webhook ou de qualquer um dos endpoints de decisão (`v1` ou `v3`).

## Utilização e faturação

A utilização de sandbox é registada, mas nunca faturada:

* Cada chamada simulada continua a registar um evento de utilização (`is_sandbox: true`, com preço `0.0000`), para que o volume de sandbox fique visível para depuração. No entanto, esse evento nunca é somado aos seus totais de utilização, nunca é descontado do saldo e nunca aparece numa fatura.
* O saldo, o carregamento de saldo e as vistas de utilização em produção da Business Console excluem a utilização de sandbox por defeito. Os endpoints de utilização de carregamento de saldo aceitam um parâmetro `environment` (`live`, o valor por defeito, ou `sandbox`) para que o volume de sandbox possa ser consultado separadamente, sempre a custo zero e sem consumo do plano gratuito.
* A verificação de e-mail e de telefone é faturada por pedido e não por resultado de sessão, e o sandbox não consegue replicar totalmente este comportamento ao nível do webhook. As verificações de e-mail e de telefone em sandbox continuam a registar um evento de utilização por pedido, ao preço `0.0000`, tal como qualquer outra funcionalidade simulada. Trata-se de uma divergência aceite e conhecida em relação ao comportamento de faturação em produção, e não de um erro.
* A estrutura da resposta da validação de base de dados em sandbox diverge intencionalmente da estrutura específica de cada fornecedor em produção, uma vez que não existe um fornecedor real a replicar. Trate os payloads de validação de base de dados em sandbox como um substituto do resultado (estado e código de aviso), e não como uma pré-visualização, byte a byte, de uma resposta real de um fornecedor.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.