> ## 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.

# Sandbox: dados de teste, valores mágicos e documentos

> Teste a Didit no sandbox: cenários, valores mágicos, endpoint arm, documentos e códigos OTP para resultados previsíveis, sem PII nem faturamento.

O **sandbox** da Didit equivale aos cartões de teste da Stripe ou aos modelos de documentos da Sumsub: ele permite reproduzir qualquer resultado de verificação de forma determinística, sem acionar provedores reais, sem dados pessoais reais (PII) e sem consumir seu saldo.

> [!NOTE]
>
> A fonte da verdade desses dados é `serialize_catalog()` no serviço de verificação, disponibilizada em tempo real no `GET /v1/sandbox/scenarios/`. Uma cópia testada contra divergências é gerada em `docs/sandbox/SANDBOX_REFERENCE.md` no repositório `service-didit-verification` por meio de `pipenv run python scripts/generate_sandbox_reference.py`. Esta página espelha essa referência. Se algo aqui parecer desatualizado, confie sempre no endpoint do catálogo em tempo real. O endpoint do catálogo é autenticado: envie sua chave de API (`x-api-key`) da mesma forma que em qualquer outra chamada, ou um token de sessão se você estiver lendo o catálogo de dentro de uma sessão em andamento.

## Modelo de ambientes

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

* Todos os provedores externos (OCR, AML, correspondência facial, prova de vida, NFC, telefone, e-mail, IP, comprovante de endereço, validação de banco de dados, Document AI) são **simulados**: nenhum terceiro é chamado em momento algum.
* **A prova de vida é executada exatamente como no ambiente de produção.** Um fluxo com prova de vida ativa executa a captura ativa real no sandbox, tanto no fluxo hospedado quanto na redirecionamento para a web dos SDKs nativos, para que você possa testar a experiência que seus usuários terão. Apenas o *resultado* da prova de vida é simulado, pelo cenário ou pelo valor mágico, e o relatório registra o método configurado no seu fluxo.
* **Domínios personalizados existem apenas no ambiente de produção.** Uma aplicação sandbox não pode adicionar um [domínio personalizado](https://docs.didit.me/pt-br/console/custom-domain.md); as sessões sandbox sempre são executadas no domínio padrão de verificação hospedada.
* As sessões **nunca são cobradas** e a verificação de saldo é ignorada.
* É aplicada uma cota por aplicação de **500 criações de sessão / 24h**.
* Os webhooks incluem `"environment": "sandbox"` (as sessões de produção incluem `"environment": "live"`).
* O fluxo hospedado expõe o ambiente da sessão para que a interface possa avisar os usuários a não enviar dados pessoais reais (PII).
* **Os resultados nunca dependem dos pixels**: os dados extraídos e os status vêm do cenário / valor mágico. A mídia capturada em si (documentos, selfie, vídeo, arquivos de comprovante de endereço) é armazenada de verdade, exatamente como em uma sessão de produção.

## Monitoramento de transações no sandbox

O sandbox é **orientado a sessões**: ele simula os provedores que uma sessão de verificação
chamaria. O Monitoramento de transações não tem provedor para simular, então uma aplicação de sandbox segue
o outro caminho: a transação é armazenada, mas **nada que toma decisões, faz triagem,
notifica ou cobra é executado para ela**.

Uma transação criada em uma aplicação de sandbox é persistida e retornada normalmente,
e nada do que segue acontece com ela:

* **Nenhuma avaliação de regras.** `rule_runs` fica vazio, seja qual for o modo das suas regras. Uma regra `ACTIVE` em uma aplicação de sandbox nunca é acionada, então a transação permanece `APPROVED` com pontuação `0` e nenhum alerta ou caso é aberto.
* **Nenhuma triagem AML / de carteiras.** `provider_results` fica vazio mesmo para transações cripto em uma aplicação com monitoramento ativado.
* **Nenhum webhook.** Nem `transaction.created` nem `transaction.status.updated` são entregues para uma transação de sandbox.
* **Nenhum faturamento.** Um evento de uso é registrado com preço `0.0000` e seu saldo não é alterado.

Toda resposta de transação traz 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 teve correspondência. O Business Console diz a mesma coisa
no card *Risk & decision* da transação, em vez de um simples "No rules
evaluated".

> [!NOTE]
>
> **A Travel Rule é a única exceção ao "nada é executado".** Em uma aplicação com
> a Travel Rule ativada, uma transação `travelRule` de sandbox ainda executa o mecanismo de intercâmbio:
> o registro da transferência é criado e passa pelos seus status.
> O que o sandbox nunca faz é se comunicar com alguém fora da Didit.
> Sua única contraparte é o [Didit Test VASP](https://docs.didit.me/pt-br/transaction-monitoring/travel-rule-sandbox.md), integrado à plataforma: nenhuma mensagem de conformidade chega a um VASP de contraparte real por nenhum canal (`TRP`, uma associação a rede que você conectou, e-mail ou `INTERNAL`), a triagem de atribuição do VASP de contraparte é ignorada e um cancelamento não envia nada a uma contraparte.
> Os webhooks `travel_rule.status.updated` são entregues, marcados com `"environment": "sandbox"`.
>
> **Saída** - uma transação `travelRule` que você envia.
> A verificação de `threshold_amount` é executada primeiro e, no sandbox, só se aplica quando você envia `transaction_details.amount_in_default_currency`, porque o sandbox não converte moedas; sem esse campo, toda transferência de sandbox é considerada acima do limiar.
> Uma transferência sem resposta expira após `confirmation_timeout_hours`, e então o seu `timeout_outcome` é aplicado à transação.
> Acima do limiar, a verificação de carteira autocustodiada é aplicada normalmente: uma transferência para uma [carteira autocustodiada declarada](https://docs.didit.me/pt-br/transaction-monitoring/travel-rule.md#carteiras-autocustodiadas-declaradas) vai para `UNCONFIRMED_OWNERSHIP` sem nenhum envio, e você pode concluí-la no sandbox pelo [widget de propriedade de carteira](https://docs.didit.me/pt-br/transaction-monitoring/wallet-ownership-widget.md), ou por meio de [confirmar propriedade](https://docs.didit.me/pt-br/management-api/travel-rule/confirm-ownership.md) quando a carteira de destino já estiver no seu catálogo de endereços de carteiras.
> Qualquer outra transferência acima do limiar vai para o Didit Test VASP pelo canal `TEST_VASP`, que responde a ela dentro da Didit com o cenário que você escolhe pela carteira ou pelo nome do beneficiário: ela é concluída, é recusada, apresenta divergência, passa a `COUNTERPARTY_VASP_NOT_REACHABLE`, expira (e então o seu `timeout_outcome` é aplicado à transação) ou aguarda a propriedade da carteira.
> Consulte [Testar a Travel Rule no sandbox](https://docs.didit.me/pt-br/transaction-monitoring/travel-rule-sandbox.md) para ver todos os cenários.
>
> **Entrada** - `POST /v3/travel-rule/inbound/`. O registro nunca é enviado por um
> canal, então nada nele é simulado: o sandbox confronta o depósito com o seu
> catálogo de endereços de carteiras e liquida de forma síncrona, exatamente como no ambiente de produção. Ele resulta em
> um desfecho real, e não em `AWAITING_COUNTERPARTY` - `ON_HOLD` (nenhuma correspondência
> no catálogo de endereços), `UNCONFIRMED_OWNERSHIP` (a entrada correspondente não tem propriedade 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 [Disparar transferência de entrada do Test VASP](https://docs.didit.me/pt-br/management-api/travel-rule/trigger-test-vasp-inbound.md) com uma das carteiras do seu próprio catálogo 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 em uma transação `travelRule` de saída depois de ativar a Travel Rule na sua aplicação de 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 após o prazo de um minuto |
| `self_hosted` | `Didit Test VASP Self Hosted` | `UNCONFIRMED_OWNERSHIP` |

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

O [gatilho de entrada do Test VASP](https://docs.didit.me/pt-br/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 ela entrar em produção.** Use o
> [Backtest](https://docs.didit.me/pt-br/transaction-monitoring/rules-api.md#criar-fazer-backtest-ativar): ele reexecuta
> a regra sobre o seu histórico real de transações e informa `evaluated` /
> `matched` / `affected_entities` sem alterar o status 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 de produção e registra as correspondências que teria encontrado, sem alterar a
> pontuação nem o status - e mude para `ACTIVE` quando a seletividade parecer adequada.

## Como alternar entre produção e sandbox

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

* Use a chave de API de uma aplicação em **modo sandbox** para obter sessões simuladas, sem cobrança 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ão e na API de AML independente) e os endpoints de simulação só são aceitos em aplicações sandbox; eles são rejeitados em aplicações de produção.

## Sandbox no fluxo de verificação hospedado

Sessões criadas em uma aplicação sandbox exibem elementos de interface extras no fluxo de verificação hospedado (a `url` retornada por `POST /v3/session/`):

* **Banner de sandbox no card.** Todas as telas mostram um banner dentro do card, "Somente dados de teste, sem chamadas reais", para deixar sempre claro que a sessão nunca faz chamadas a provedores reais e nunca afeta o seu saldo. As mídias capturadas são armazenadas como em qualquer sessão, então use os documentos de exemplo e os dados de teste em vez de documentos de identidade ou informações pessoais reais.
* **Seletor de cenário antes do fluxo.** Antes de a captura começar, um seletor no card guia o usuário na escolha de um resultado de teste: escolha um resultado e, em seguida, um gatilho para esse resultado. A confirmação chama `POST /v3/session/{session_id}/sandbox/arm/` (veja [Ativar (ou reativar) a sessão antes de o fluxo começar](#3-armar-ou-armar-novamente-a-sessão-antes-de-o-fluxo-começar) abaixo) e depois segue para 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 logo abaixo do componente de envio/captura de documento. Toque em um deles para usá-lo no lugar de um upload real.

Sessões sandbox armazenam as mídias capturadas **reais**: documentos, selfie, vídeo de prova de vida e arquivos de comprovante de endereço são enviados e retidos exatamente como seriam em uma 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 similares) e o próprio resultado da sessão (Aprovado / Em revisão / Recusado) são simulados pelo cenário ou pelo valor mágico e nunca derivados das mídias capturadas. O Business Console marca as seções de dados extraídos de uma sessão sandbox com um selo **Dados simulados**, para que os revisores identifiquem rapidamente quais partes da sessão são a captura real e quais são definidas pelo cenário.

## Cenários

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

| Slug | Título | Status padrão | Descrição |
| - | - | - | - |
| `approve` | Caminho feliz — todos os recursos aprovam | Aprovado | Comportamento padrão do sandbox: cada recurso simulado retorna seu resultado APPROVED limpo. O status da sessão termina como APPROVED. |
| `decline_aml_hit` | AML — pessoa politicamente exposta | Recusado | O mock de AML retorna uma ocorrência e a sessão é recusada no recurso de AML. A ocorrência usa o mesmo [esquema de Hit](https://docs.didit.me/pt-br/core-technology/aml-screening/report-aml-screening.md#campos-por-hit) dos provedores de AML em produção — `url`, `match_score`, `risk_score`, `review_status`, `properties`, `pep_matches[]` e `score_breakdown` vêm todos preenchidos — e é gravado um Log de aviso POSSIBLE\_MATCH\_FOUND. |
| `decline_document_expired` | Verificação de identidade — documento expirado | Recusado | O mock de verificação de identidade retorna um passaporte cuja data de validade está no passado. A sessão é recusada na verificação de identidade com um Log de aviso DOCUMENT\_EXPIRED. |
| `decline_minimum_age` | Verificação de identidade — abaixo da política de idade mínima | Recusado | O mock de verificação de identidade retorna uma data de nascimento que dá ao usuário cerca de 10 anos de idade. A verificação de idade em produção emite MINIMUM\_AGE\_NOT\_MET e o fluxo recusa. |
| `decline_mrz_validation` | Verificação de identidade — falha no dígito verificador da MRZ | Recusado | O mock de verificação de identidade retorna um passaporte com o dígito verificador da MRZ corrompido. O validador de MRZ de produção emite MRZ\_VALIDATION\_FAILED e a sessão é recusada. |
| `decline_could_not_recognize_document` | Verificação de identidade — documento ilegível | Recusado | O mock de verificação de identidade retorna uma resposta vazia. A produção gera COULD\_NOT\_RECOGNIZE\_DOCUMENT e o repassa ao SDK. |
| `decline_face_match_low_similarity` | Correspondência facial — similaridade abaixo do limiar de recusa | Recusado | O mock de correspondência facial retorna uma pontuação baixa. A produção emite LOW\_FACE\_MATCH\_SIMILARITY e o mapeamento de ações do nó do fluxo faz com que o fluxo recuse. |
| `decline_database_no_match` | Validação de banco de dados — nenhuma correspondência em todos os serviços | Recusado | Cada serviço de banco de dados selecionado retorna NO\_MATCH. A produção emite DATABASE\_VALIDATION\_NO\_MATCH e o fluxo recusa. |
| `decline_phone_high_risk` | Telefone — número de teste reservado de alto risco | Recusado | O mock de verificação de telefone bloqueia a verificação (faixa de teste reservada). A verificação de telefone termina como BLOCKED e emite HIGH\_RISK\_PHONE\_NUMBER. |
| `decline_email_breach` | E-mail — ocorrência em banco de dados de vazamentos | Recusado | O mock de vazamentos de e-mail retorna uma ocorrência de vazamento 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 | Recusado | 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` | Comprovante de endereço — endereço divergente do informado | Recusado | O mock de comprovante de endereço recusa o comprovante de endereço com ADDRESS\_MISMATCH\_WITH\_PROVIDED. A sessão é recusada no comprovante de endereço. |
| `decline_liveness_attack` | Prova de vida — ataque facial detectado | Recusado | O mock de prova de vida passiva detecta 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 passaporte eletrônico não verificado | Recusado | O mock de passaporte eletrônico retorna um chip cuja assinatura SOD/DG falha na verificação de integridade. A produção emite NFC\_CHIP\_NOT\_VERIFIED e a sessão é recusada no NFC quando o fluxo está configurado para recusar chips não verificados. |
| `decline_nfc_trust_anchor_missing` | NFC — âncora de confiança emissora indisponível | Recusado | O mock de passaporte eletrônico retorna um chip assinado por um DSC cuja CSCA emissora não está no repositório de confiança. A produção emite NFC\_TRUST\_ANCHOR\_MISSING e a sessão é recusada quando o fluxo está configurado para recusar chips não verificados. |
| `decline_document_ai_unreadable` | Document AI — documento ilegível | Recusado | O mock de Document AI não retorna nenhum campo legível. A produção emite DOCUMENT\_AI\_UNREADABLE\_DOCUMENT e o documento fica como recusado quando o limite de novas tentativas se esgota. |
| `review_aml_possible_match` | AML — possível correspondência requer revisão | Em revisão | O mock de AML retorna uma ocorrência de menor confiança. A sessão fica Em revisão com um Log de nível de aviso POSSIBLE\_MATCH\_FOUND para um analista resolver. |
| `review_face_match_borderline` | Correspondência facial — similaridade limítrofe | Em revisão | O mock de correspondência facial retorna uma pontuação entre os limiares de revisão e de recusa. A sessão fica Em revisão na correspondência facial. |
| `review_document_borderline_age` | Verificação de identidade - menor de idade enviado para revisão | Em revisão | O mock de verificação de identidade retorna 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, então a sessão fica Em revisão na verificação de identidade em vez de ser recusada. |
| `review_poa_partial_match` | Comprovante de endereço — correspondência parcial do endereço | Em revisão | O mock de comprovante de endereço retorna um endereço que corresponde apenas parcialmente ao informado. A sessão fica Em revisão no comprovante de endereço. |
| `review_database_partial_match` | Validação de banco de dados — correspondência parcial | Em revisão | Os serviços de banco de dados retornam correspondências parciais de nome e data de nascimento. A sessão fica Em revisão na validação de banco de dados. |
| `decline_kyb_registry_mismatch` | KYB - dados de registro divergentes | Recusado | O mock de registro retorna uma empresa cujos dados de registro divergem dos dados esperados. A sessão de empresa é recusada na checagem de registro. |
| `review_kyb_registry_partial` | KYB - dados de registro com correspondência parcial | Em revisão | O mock de registro retorna uma empresa cujo nome corresponde apenas parcialmente. A sessão de empresa fica Em revisão na checagem de registro. |

Os cenários `review_*` existem para que você possa testar a experiência de revisão manual (a fila de revisão do console, os webhooks `In Review`, as ações de aprovar/recusar do revisor) sem precisar de uma entrada que leve a uma recusa. Os dois cenários `kyb_*` acima definem `expected_details.registration_number` em vez de `expected_details.first_name`: eles se aplicam apenas a sessões de Verificação de empresas (KYB).

## Valores mágicos

Um valor mágico é uma entrada específica que faz um recurso simulado emitir um risco específico. Defina o campo de entrada com o valor mágico (diretamente ou por meio de um cenário) para acionar o risco.

| Recurso | 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 retorna uma ocorrência e a sessão é recusada na etapa de 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 deixa o usuário abaixo da 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 à regex de formato esperada para o documento no registro 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 na verificação de formato do registro 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 preencheu previamente em `expected_details` acima do limiar de correspondência de nome. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_GENDER_MISMATCH_WITH_PROVIDED` | `GENDER_MISMATCH_WITH_PROVIDED` | OCR — o gênero extraído diverge de `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 diverge de `expected_details.date_of_birth`. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_COUNTRY_MISMATCH_WITH_PROVIDED` | `COUNTRY_MISMATCH_WITH_PROVIDED` | OCR — o Estado emissor diverge de `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 diverge de `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 corresponde a `expected_details.identification_number`. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_COULD_NOT_RECOGNIZE_DOCUMENT` | `COULD_NOT_RECOGNIZE_DOCUMENT` | O pipeline de OCR retorna um resultado vazio ou irreconhecível; em produção, é gerado COULD\_NOT\_RECOGNIZE\_DOCUMENT. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_MRZ_NOT_DETECTED` | `MRZ_NOT_DETECTED` | OCR — o documento deveria ter uma MRZ, mas o pipeline não conseguiu localizá-la. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_MRZ_VALIDATION_FAILED` | `MRZ_VALIDATION_FAILED` | OCR — a MRZ foi encontrada, mas falhou na validação de checksum 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 divergem dos campos extraídos da VIZ. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_BARCODE_NOT_DETECTED` | `BARCODE_NOT_DETECTED` | OCR — o documento deveria ter um código de barras, mas nenhum foi encontrado. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_BARCODE_VALIDATION_FAILED` | `BARCODE_VALIDATION_FAILED` | OCR — o código de barras foi decodificado, mas falhou na validação cruzada de campos. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_QR_NOT_DETECTED` | `QR_NOT_DETECTED` | OCR — o documento deveria ter um QR code, mas nenhum foi encontrado. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_QR_VALIDATION_FAILED` | `QR_VALIDATION_FAILED` | OCR — o QR code foi decodificado, mas falhou na validação cruzada de 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 divergem. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DOCUMENT_SIDES_MISMATCH` | `DOCUMENT_SIDES_MISMATCH` | OCR — os document\_name da frente e do verso 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 do documento nem o nome nem o sobrenome. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DATE_OF_BIRTH_NOT_DETECTED` | `DATE_OF_BIRTH_NOT_DETECTED` | OCR — a classe do documento prevê uma data de nascimento, mas a extração não retornou nenhuma. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_EXPIRATION_DATE_NOT_DETECTED` | `EXPIRATION_DATE_NOT_DETECTED` | OCR — a classe do documento prevê uma data de validade, mas a extração não retornou 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 compatível. |
| 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 endereço, mas a geocodificação / análise não retornou nada utilizável. |
| DATABASE\_VALIDATION | `expected_details.first_name` | `SANDBOX_DB_NO_MATCH` | `DATABASE_VALIDATION_NO_MATCH` | Validação de banco de dados — todos os serviços governamentais/de registro retornam NO\_MATCH; a sessão é recusada na validação de banco de dados. |
| FACEMATCH | `expected_details.first_name` | `SANDBOX_FACE_LOW_MATCH` | `LOW_FACE_MATCH_SIMILARITY` | Correspondência facial — pontuação de similaridade 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 ou de alto risco; o mock de verificação de telefone retorna falha. |
| EMAIL | `user_email` | `sandbox+breach@didit.test` | `BREACHED_EMAIL_DETECTED` | E-mail — o banco de dados de vazamentos retorna uma ocorrência para este endereço. |
| LOCATION | `expected_details.first_name` | `SANDBOX_IP_BLOCKLIST` | `IP_ADDRESS_IN_BLOCKLIST` | Análise de IP — o IP do solicitante aparece na 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 — o endereço no documento enviado diverge do endereço que o cliente preencheu previamente em `expected_details`; a sessão é recusada no POA. |
| LIVENESS | `expected_details.first_name` | `SANDBOX_LIVENESS_ATTACK` | `LIVENESS_FACE_ATTACK` | Prova de vida — o mock de prova de vida passiva detecta 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 de ePassport retorna 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 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 se encadeia a uma CSCA ausente do repositório de confiança; em produção, é emitido NFC\_TRUST\_ANCHOR\_MISSING e aplica-se 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 retorna campos legíveis; em produção, é emitido DOCUMENT\_AI\_UNREADABLE\_DOCUMENT e o documento é recusado quando se esgota o limite de tentativas. |
| AML | `user_email` | `sandbox+aml_review@didit.test` | `POSSIBLE_MATCH_FOUND` | AML — possível correspondência que exige resolução manual; a sessão fica Em revisão. |
| FACEMATCH | `expected_details.first_name` | `SANDBOX_FACE_BORDERLINE_MATCH` | `LOW_FACE_MATCH_SIMILARITY` | Correspondência facial — similaridade limítrofe entre os limiares de revisão e de recusa; a sessão fica Em revisão. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_BORDERLINE_AGE` | `MINIMUM_AGE_NOT_MET` | OCR — a data de nascimento está abaixo da idade mínima, mas o fluxo envia para revisão em vez de recusar falhas de idade mínima; a sessão fica Em revisão. |
| DATABASE\_VALIDATION | `expected_details.first_name` | `SANDBOX_DB_PARTIAL_MATCH` | `DATABASE_VALIDATION_PARTIAL_MATCH` | Validação de banco de dados — a identificação corresponde, mas nome/data de nascimento correspondem apenas parcialmente; a sessão fica Em revisão. |
| PROOF\_OF\_ADDRESS | `expected_details.first_name` | `SANDBOX_POA_PARTIAL_MATCH` | `ADDRESS_MISMATCH_WITH_PROVIDED` | POA — o endereço no documento enviado corresponde parcialmente ao endereço fornecido; a sessão fica Em revisão. |
| KYB\_REGISTRY | `expected_details.registration_number` | `SANDBOX-KYB-MISMATCH` | `KYB_REGISTRY_DATA_MISMATCH_WITH_EXPECTED` | KYB - os dados da empresa no registro divergem dos detalhes 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 registro correspondem parcialmente; a sessão fica Em revisão. |

## Consulta sem documento e carteiras de identidade

Aplicações de sandbox podem ativar todas as carteiras de identidade do catálogo de países, incluindo carteiras indisponíveis em aplicações de produção.
O cenário padrão `approve` simula uma identidade verificada sem fazer login em uma carteira externa.
O resultado é armazenado na sessão e segue para a etapa seguinte normal do fluxo.
O sandbox não valida uma credencial real de carteira nem cobra pelas tentativas simuladas.

As requisições de consulta continuam validando os campos informados e usam o limite de tentativas configurado, que por padrão é um.
Use os cenários a seguir para testar novas tentativas e regras de fallback:

| Cenário | Resultado simulado |
| - | - |
| `lookup_partial_match` | Correspondência parcial no registro; conta para o limite de tentativas. |
| `lookup_no_match` | O registro responde sem correspondência; conta para o limite de tentativas. |
| `lookup_provider_error` | O registro não retorna resposta; o usuário recebe uma solicitação para tentar novamente e, após três tentativas sem resposta, aplica-se o fallback de erro do provedor. |
| `wallet_cancelled` | O usuário cancela o login na carteira. |
| `wallet_timeout` | O login na carteira expira. |
| `wallet_provider_error` | A carteira não consegue concluir o login. |

Falhas de carteira seguem a configuração do país para recorrer à captura de documento ou recusar.
As tentativas de consulta concluídas são registradas separadamente, então duas tentativas permitidas geram dois resultados antes do fallback.
Todo o uso de sandbox continua gratuito.

## Verificação de conta na Verificação bancária

A Verificação bancária ainda não está habilitada em produção, então esta seção se aplica quando ela estiver: até lá, uma chave de sandbox recebe a mesma resposta `bank_verification_not_available` que uma chave de produção.

Uma etapa de Verificação bancária em sandbox oferece [os dois métodos](https://docs.didit.me/pt-br/core-technology/bank-verification/verification-methods.md) em todos os países, na ordem definida pela etapa, em um serviço simulado, sem banco e sem custo.
Com a ordem padrão, a pessoa começa pelo login no banco e escolhe **Informe os dados da sua conta** para executar a [verificação de conta](https://docs.didit.me/pt-br/core-technology/bank-verification/account-check.md); defina `bank_method_order` como `["account_lookup", "open_banking"]` para começar por ela.
Os quatro últimos caracteres da conta digitada determinam a resposta; consulte [Teste no sandbox](https://docs.didit.me/pt-br/core-technology/bank-verification/account-check.md#teste-no-sandbox) para ver todas as terminações e uma conta válida para cada formato.
A [API de verificação de conta](https://docs.didit.me/pt-br/standalone-apis/bank-account-check.md) retorna, para uma chave de sandbox, respostas com base nas mesmas terminações.

## Documentos de exemplo

> [!WARNING]
>
> Nunca envie documentos de identidade reais no sandbox. Use os documentos de exemplo integrados.

O fluxo hospedado oferece três documentos de exemplo, um para cada tipo de documento:

| País | Tipo de documento |
| - | - |
| Espanha | Carteira de identidade nacional |
| Argentina | Passaporte |
| Polônia | Carteira de habilitação |

Toque em um exemplo na faixa para usá-lo no lugar de uma captura real. Os dados extraídos e o resultado da sessão sempre vêm do cenário ou do valor mágico selecionado, então qualquer exemplo funciona com qualquer cenário.

## Identidade de exemplo: testando `expected_details`

Todo documento do sandbox é gerado a partir de uma única identidade **fixa**.
Os valores extraídos são os mesmos em todas as sessões e nunca são derivados da data atual, então você pode preencher `expected_details` com eles e verificar de ponta a ponta o tratamento das comparações de campos e dos avisos.
Envie os valores abaixo e as verificações de comparação passam; envie qualquer outro valor e o aviso `*_MISMATCH_WITH_PROVIDED` correspondente é disparado de propósito.

As datas são as mesmas em 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 que você usa:

| `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` | Carteira de identidade nacional da 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` | Carteira de habilitaçã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 replica no documento gerado os nomes que você envia em `expected_details`, então a correspondência de nome 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 de 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 gera um documento do primeiro país permitido, então `nationality`, `id_country` e o nome do documento seguem esse país. As datas acima continuam as mesmas.

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

O documento gerado é o modelo genérico para o país e o tipo de documento permitidos, então os campos que só um documento real, emitido pelo governo, fornece ficam vazios. O que importa para o roteamento é a **região / estado dos EUA** (`kyc.region`): uma carteira de habilitação ou carteira de identidade dos EUA no sandbox não tem estado, então uma condição de ramificação como `Region equals IL` nunca é atendida no sandbox e, quando nenhuma outra ramificação desse nó também é atendida, o fluxo segue a ramificação de fallback do nó (a ramificação sem condições). Isso não é uma revisão nem uma falha da ramificação - a condição simplesmente não tem o que ler. Um campo ausente também não atende a `not equals` e `not in`; consulte [como as condições de ramificação leem os dados da sessão](https://docs.didit.me/pt-br/console/workflows.md#como-as-condições-de-ramificação-leem-os-dados-da-sessão) para entender a diferença entre um campo ausente e uma string vazia.

Para testar no sandbox um fluxo que depende do estado, baseie a decisão em um valor que você 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` derivada do documento para o tráfego de produção se você também precisar que o documento comprove o estado; no modo de produção, a região é lida do documento real.

Todo o restante do roteamento é idêntico ao de produção: 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 status são todos executados de verdade. O sandbox nunca coloca uma sessão em revisão por conta própria - uma sessão de sandbox termina em revisão somente quando o fluxo a direciona para lá (um cenário `review_*`, um valor mágico associado a uma ação de revisão ou um nó de status no grafo).

## Códigos OTP e opt-in de e-mail

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

Por padrão, as sessões de sandbox **não** enviam e-mails (alertas de revisão, mudança de status, OTP, reenvio, link de nova sessão etc.). Para enviar um e-mail mesmo assim, use um destes padrões de opt-in no endereço do destinatário:

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

## Controlar resultados: cenários, valores mágicos, armar a sessão e o endpoint de simulação

Há cinco formas de controlar o resultado no 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 incluídos no cenário para os campos de entrada da sessão, de modo que os provedores simulados produzam o resultado pretendido por meio do pipeline real do fluxo de verificação (workflow).

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

### 2. Valores mágicos digitados manualmente

Defina você mesmo os campos de entrada individuais (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 ver o registro completo.

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

Defina ou substitua o cenário armado em uma sessão que já existe, desde que ela não tenha passado do status `Not Started`. Este é o endpoint que o [seletor de cenários pré-fluxo](#sandbox-no-fluxo-de-verificação-hospedado) chama, e você pode chamá-lo por conta própria para criar um seletor personalizado ou um ambiente de testes:

```
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 com o próprio `Session-Token` da sessão (retornado como `session_token` na criação da sessão), e não com a chave de API da sua aplicação: este é um endpoint voltado ao cliente.
* Retorna `400` para um slug de cenário desconhecido e `400` quando a sessão já passou do status `Not Started` (`"Scenario can only be armed before the verification starts."`).
* Retorna `404` quando o `Session-Token` pertence a uma aplicação de produção (fora do sandbox) ou não corresponde ao `session_id` no caminho.
* **Armar novamente substitui o cenário anterior.** Apenas os valores mágicos que o cenário anterior gravou são apagados, e tudo o que o usuário já digitou manualmente (e-mail, nome etc.) permanece intacto. Por exemplo: arme `decline_phone_high_risk` e, depois, arme `approve`. O número de telefone volta a ficar sem valor, mas um e-mail inserido pelo cliente se mantém após as duas chamadas.

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

Force um status final posteriormente:

* Console / chave de API (exige o privilégio `write:sessions`; uma chave de API com escopo precisa de acesso de escrita a sessões): `POST /v3/session/{session_id}/simulate/`
* Fluxo hospedado (cabeçalho `Session-Token`): `POST /v3/session/{session_id}/sandbox/simulate/`

Ambos funcionam em sessões de sandbox de KYC e de KYB.
Uma sessão de produção (fora do sandbox) retorna `404`, assim como um `Session-Token` que não corresponde ao `session_id` no caminho.

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

| Campo | Tipo | O que faz |
| - | - | - |
| `new_status` | string | `Approved`, `Declined`, `In Review`, `Expired` ou `Abandoned`. Quando omitido, assume o status padrão do caso de risco (`risk`, ou o primeiro risco presente nos valores mágicos do cenário) ou, na falta dele, o status padrão do cenário. |
| `scenario` | string, até 100 caracteres | Um slug de cenário. Sem `risk`, é aplicado o primeiro risco presente nos valores mágicos dele. |
| `risk` | string, até 128 caracteres | Um caso de risco. O aviso correspondente é adicionado à sessão. |
| `node_id` | string, até 128 caracteres | O nó do fluxo ao qual o aviso é vinculado. O padrão é o nó atual da sessão. |
| `comment` | string, até 500 caracteres | Nota adicionada à entrada de atividade que registra a mudança de status. |
| `send_webhooks` | boolean, padrão `true` | Define se a mudança de status envia webhooks. |

`send_webhooks: true` envia exatamente os webhooks que uma mudança de status real envia: `status.updated`, mais os eventos `user.status.updated` e `user.data.updated` (ou `business.status.updated` e `business.data.updated` para uma sessão de empresa) que a mudança gera, para os destinos inscritos neles.
Com `send_webhooks: false`, o status muda mesmo assim, mas nenhum webhook é registrado ou enviado.
A recuperação de webhooks perdidos nunca reenvia essa decisão, e o console continua sendo atualizado em tempo real.
A próxima mudança de status da sessão envia webhooks normalmente.

```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 status definido pela simulação, e `previous_status` é o status que a sessão tinha antes.
* `scenario` repete o seu slug e `risk` é o caso de risco aplicado; cada um é `null` quando não há nenhum.
* `send_webhooks` repete o valor aplicado.
* Retorna `400` para um cenário ou risco desconhecido, quando nenhum `new_status` pode ser derivado, para qualquer outro valor de `new_status` e quando a sessão já está no status solicitado (`["The new status is the same as the current status."]`).

### 5. `sandbox_scenario` na API de AML independente

A análise AML feita pelo back-end não tem usuário final nem sessão para armar, então o slug vai na própria requisição de análise (`POST /v3/aml/`):

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

* `decline_aml_hit` retorna uma ocorrência no mesmo formato de produção e conclui a análise como `Declined`; `review_aml_possible_match` a conclui como `In Review`. Um cenário que não arma nenhum resultado de AML deixa a análise sem ocorrências.
* Com `save_api_request: true` (o padrão), a análise é armazenada exatamente como seria com uma chave de produção, de modo que o `request_id` retornado pode ser consultado por `GET /v3/session/{request_id}/decision/` e `GET /v3/session/{request_id}/generate-pdf/`.
* Retorna `400` para um slug de cenário desconhecido e `400` quando a chave de API pertence a uma aplicação de produção.

## Onde `sandbox_scenario` aparece

O slug do cenário armado (`null` se nenhum estiver armado) é retornado em alguns locais e intencionalmente omitido em outros:

| Local | Exposto? |
| - | - |
| Payload da etapa atual (KYC e KYB) | Sim, como `sandbox_scenario` |
| `GET /v1/session/{id}/decision/` | Sim, como `sandbox_scenario` |
| `GET /v3/session/{id}/decision/` (consulte [Recuperar sessão](https://docs.didit.me/pt-br/sessions-api/retrieve-session.md)) | Sim, `sandbox_scenario` no nível superior (null quando não há cenário armado) |
| Webhooks da sessão (`status.updated`, `data.updated`) | Sim, como `sandbox_scenario`, `null` em sessões de produção ou em sessões de sandbox sem cenário armado |

Se a sua integração precisa executar lógica condicional no servidor com base no cenário ativado, leia-o no envelope do webhook ou em qualquer um dos endpoints de decisão (`v1` ou `v3`).

## Uso e faturamento

O uso no sandbox é registrado, mas nunca cobrado:

* Toda chamada simulada continua registrando um evento de uso (`is_sandbox: true`, com preço `0.0000`), para que o volume do sandbox fique visível para depuração. Esse uso, porém, nunca é somado aos seus totais de uso, nunca é descontado do saldo e nunca aparece em uma fatura.
* As telas de saldo, recarga e uso em produção do Business Console filtram o uso do sandbox por padrão. Os endpoints de uso de recarga aceitam um parâmetro `environment` (`live`, o padrão, ou `sandbox`) para que o volume do sandbox possa ser consultado separadamente, sempre com custo zero e sem consumir o plano gratuito.
* A verificação de e-mail e a verificação de telefone são cobradas por requisição, e não pelo resultado da sessão, e o sandbox não tem como reproduzir isso totalmente na camada de webhook. As verificações de e-mail e telefone no sandbox continuam registrando um evento de uso por requisição com preço `0.0000`, como todos os outros recursos simulados. Essa é uma divergência conhecida e aceita em relação ao faturamento em produção, e não um bug.
* O formato da resposta da validação de banco de dados no sandbox diverge intencionalmente do formato de cada provedor em produção, já que não existe um provedor real para reproduzir. Trate os payloads de validação de banco de dados no sandbox como uma representação do resultado (status e código de aviso), e não como uma prévia byte a byte da resposta de um provedor em produção.


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