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

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.

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; 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”.

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, 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 vai para UNCONFIRMED_OWNERSHIP sem nenhum envio, e você pode concluí-la no sandbox pelo widget de propriedade de carteira, ou por meio de confirmar propriedade 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 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 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 lista a carteira de cada cenário e o seu resultado exato. O gatilho de entrada do Test VASP aceita apenas accept e name_mismatch no seu campo scenario.

Como testar uma regra antes de ela entrar em produção. Use o Backtest: 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 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 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 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; 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 para ver todas as terminações e uma conta válida para cada formato. A API de verificação de conta retorna, para uma chave de sandbox, respostas com base nas mesmas terminações.

Documentos de exemplo

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`

{
  "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.

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

{
  "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 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>

{
  "scenario": "decline_document_expired"
}

Resposta 200:

{
  "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.

{
  "scenario": "decline_aml_hit",
  "send_webhooks": false
}

Resposta 200:

{
  "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/):

{
  "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)	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.

Guias

Autenticação

Model Context Protocol (MCP)

SDKs web

SDKs nativos

SDKs de servidor

Integrações

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

Modelo de ambientes

Monitoramento de transações no sandbox

Cenários do Test VASP da Travel Rule

Como alternar entre produção e sandbox

Sandbox no fluxo de verificação hospedado

Cenários

Valores mágicos

Consulta sem documento e carteiras de identidade

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

Documentos de exemplo

Identidade de exemplo: testando `expected_details`

O que o documento gerado não contém

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

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

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

2. Valores mágicos digitados manualmente

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

4. O endpoint de simulação

5. `sandbox_scenario` na API de AML independente

Onde `sandbox_scenario` aparece

Uso e faturamento

​Modelo de ambientes

​Monitoramento de transações no sandbox

​Cenários do Test VASP da Travel Rule

​Como alternar entre produção e sandbox

​Sandbox no fluxo de verificação hospedado

​Cenários

​Valores mágicos

​Consulta sem documento e carteiras de identidade

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

​Documentos de exemplo

​Identidade de exemplo: testando expected_details

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

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

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

​1. sandbox_scenario na criação da sessão

​2. Valores mágicos digitados manualmente

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

​4. O endpoint de simulação

​5. sandbox_scenario na API de AML independente

​Onde sandbox_scenario aparece

​Uso e faturamento

Modelo de ambientes

Monitoramento de transações no sandbox

Cenários do Test VASP da Travel Rule

Como alternar entre produção e sandbox

Sandbox no fluxo de verificação hospedado

Cenários

Valores mágicos

Consulta sem documento e carteiras de identidade

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

Documentos de exemplo

Identidade de exemplo: testando `expected_details`

O que o documento gerado não contém

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

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

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

2. Valores mágicos digitados manualmente

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

4. O endpoint de simulação

5. `sandbox_scenario` na API de AML independente

Onde `sandbox_scenario` aparece

Uso e faturamento