Antes de começar
- Use a chave de API de uma aplicação de sandbox. Aplicações de produção nunca se conectam ao VASP de teste.
- Ative a Travel Rule com uma razão social:
- 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çãotravelRule 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.
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_mismatchcompara 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.nameoumatching_rules.company.name, que seguemname_matching_strictnessaté você defini-las). A transferência e a entrada da linha do tempo que determinou esse resultado trazemname_match(comcompared_with: "counterparty_vasp") edata_matchcommismatched_fields: ["name"].not_reachablemantém a transferência emAWAITING_COUNTERPARTYenquanto tenta novamente, comdelivery.statusRETRYINGelast_errortest VASP is not answering, e depois a coloca emCOUNTERPARTY_VASP_NOT_REACHABLE. Envie{"action": "resend"}em seguida para executá-la novamente.self_hostedrecebe do VASP de teste a resposta de que a carteira é autocustodiada. Registre a prova com o widget de propriedade de carteira (gerado para você enquantoauto_wallet_verificationestiver ativado) ou comPOST .../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ê comPOST /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
unavailablecomreason: sandbox_application, e toda linha comoreachable: false.