Pular para o conteúdo principal
Uma aplicação de sandbox troca dados de Travel Rule com uma única contraparte: o Didit Test VASP, um VASP de teste integrado à plataforma. Ele responde a cada transferência da forma que você pedir, pelo mesmo código que lida com uma contraparte real, para que você possa acompanhar cada status, entrada da linha do tempo e webhook de uma troca antes de entrar em produção. Nada do que você envia no sandbox sai da Didit. Nenhuma rede, destinatário de e-mail ou outro cliente da Didit é contatado, e nada é cobrado.

Antes de começar

  1. Use a chave de API de uma aplicação de sandbox. Aplicações de produção nunca se conectam ao VASP de teste.
  2. Ative a Travel Rule com uma razão social:
  1. Opcionalmente, inscreva um destino do webhook em travel_rule.status.updated. O sandbox entrega esse evento, marcado com "environment": "sandbox".

O Didit Test VASP

GET /v1/sandbox/scenarios/ retorna o perfil do VASP de teste e todos os cenários no objeto travel_rule, para que seus testes possam ler os valores de gatilho em vez de fixá-los no código: Todos os valores são dados de teste. O VASP de teste não é membro de nenhuma rede de Travel Rule, e nenhum resultado no sandbox demonstra que uma contraparte ou rede real pode ser alcançada.

Cenários de saída

Toda transação travelRule de saída de uma aplicação de sandbox que precisa de uma troca de informações vai para o VASP de teste. Escolha o resultado pelo endereço da carteira do beneficiário (maiúsculas e minúsculas não importam) ou por um nome de beneficiário no formato Didit Test VASP <suffix>; a carteira prevalece quando ambos são definidos. Sem nenhum dos dois, ou com um sufixo que a tabela não lista, a transferência é concluída (accept). Uma transferência que não precisa de troca nunca chega ao VASP de teste: uma abaixo do seu threshold_amount, uma para a carteira verificada do próprio usuário e uma cuja carteira da contraparte você declarou como autocustodiada. Um VASP de contraparte que você ou seu usuário final escolheu manualmente no diretório é avaliado pelas rotas que uma aplicação de produção teria: quando a entrada dele tem uma rota (um endpoint TRP verificado, uma rede pela qual sua aplicação envia ou um contato de conformidade), a transferência vai para o VASP de teste; quando não tem nenhuma, a transferência termina em COUNTERPARTY_VASP_NOT_FOUND, como aconteceria em uma aplicação de produção.
O rail da transferência é TEST_VASP, e a lista de transferências indica Didit Test VASP como o VASP beneficiário. Acompanhe-a pelos webhooks travel_rule.status.updated ou consulte GET /v3/transactions/{transaction_id}/.
  • name_mismatch compara o nome do beneficiário que você enviou com o nome do titular informado pelo VASP de teste, conforme sua regra de nome para o tipo de entidade do beneficiário (matching_rules.individual.name ou matching_rules.company.name, que seguem name_matching_strictness até você defini-las). A transferência e a entrada da linha do tempo que determinou esse resultado trazem name_match (com compared_with: "counterparty_vasp") e data_match com mismatched_fields: ["name"].
  • not_reachable mantém a transferência em AWAITING_COUNTERPARTY enquanto tenta novamente, com delivery.status RETRYING e last_error test VASP is not answering, e depois a coloca em COUNTERPARTY_VASP_NOT_REACHABLE. Envie {"action": "resend"} em seguida para executá-la novamente.
  • self_hosted recebe do VASP de teste a resposta de que a carteira é autocustodiada. Registre a prova com o widget de propriedade de carteira (gerado para você enquanto auto_wallet_verification estiver ativado) ou com POST .../travel-rule/ownership/ e {"confirmed": true}: a carteira é adicionada ao seu catálogo de endereços com o nome do beneficiário, e a correspondência de nome determina o resultado da transferência. Uma correspondência a conclui e marca a carteira como verificada; {"confirmed": false} a recusa.

Transferências recebidas do VASP de teste

Para testar o lado receptor, peça ao VASP de teste que envie uma transferência para você com POST /v3/travel-rule/test-vasp/inbound/. Indique uma das carteiras do catálogo de endereços da sua própria aplicação: a transferência é decidida pelo mesmo caminho de entrada de uma transferência real, com base no seu catálogo de endereços, no seu modo de propriedade e nas suas regras de nome.
A resposta 201 traz transaction_id, txn_id, scenario, travel_rule_status, detail, test_vasp: true e a transferência travel_rule. Uma aplicação de produção recebe 400 ("The Didit Test VASP is only available on sandbox applications."), outro valor de scenario recebe 400 e uma aplicação com a Travel Rule desativada recebe 409. Decida uma transferência em espera com POST .../travel-rule/ownership/, como faria com uma real: {"confirmed": true} a conclui e {"confirmed": false} a recusa. Um depósito que você mesmo informa com POST /v3/transactions/ não foi enviado pelo VASP de teste: ele permanece em AWAITING_COUNTERPARTY aguardando o VASP remetente, e sua linha do tempo indica o endpoint acima. Ele não dispara nenhum webhook até expirar após confirmation_timeout_hours. POST /v3/travel-rule/inbound/ continua liquidando um registro posterior ao depósito com base no seu catálogo de endereços, como em uma aplicação de produção.

Webhooks no sandbox

travel_rule.status.updated é disparado para aplicações de sandbox a cada mudança de status, com "environment": "sandbox". Uma transferência à qual o VASP de teste respondeu também traz rail: "TEST_VASP", test_vasp: true e test_vasp_scenario. O restante do sandbox continua se comportando como descrito em Monitoramento de transações no sandbox: as regras não são avaliadas, transaction.created e transaction.status.updated não são enviados e nada é faturado.

O que o sandbox não comprova

  • Que uma contraparte real, uma associação a uma rede ou o host TRP público da Didit funciona. Nenhum deles é contatado.
  • Que suas credenciais de rede são válidas. Uma associação conectada é comprovada pela sua primeira troca em produção.
  • As rotas do diretório de VASPs reais: em uma aplicação de sandbox, toda rota aparece como unavailable com reason: sandbox_application, e toda linha como reachable: false.
Consulte Redes da Travel Rule para saber o alcance de cada rail em produção hoje.
Última modificação em 1 de novembro de 2026