Tester la Travel Rule en sandbox : guide des scénarios

​

Avant de commencer

1. Utilisez la clé API d’une application sandbox. Les applications de production n’atteignent jamais le VASP de test.
2. Activez Travel Rule avec un nom légal :

curl -X PUT https://verification.didit.me/v3/travel-rule/settings/ \
  -H "x-api-key: YOUR_SANDBOX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"is_enabled": true, "legal_name": "Example CASP Sandbox"}'

3. Vous pouvez éventuellement abonner une destination de webhook à travel_rule.status.updated. Le sandbox l’envoie, marqué "environment": "sandbox".

​

Le Didit Test VASP

​

Scénarios sortants

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_SANDBOX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "sbx-tr-accept-001",
    "transaction_category": "travelRule",
    "transaction_details": {
      "direction": "outbound",
      "action_type": "transfer",
      "amount": "0.25",
      "currency": "ETH",
      "currency_kind": "crypto"
    },
    "subject": { "entity_type": "individual", "vendor_data": "user-042", "full_name": "Jane Doe" },
    "travel_rule_details": {
      "status": "AWAITING_COUNTERPARTY",
      "beneficiary_data": {
        "wallet_address": "0xc00c4cd93ff83953ce3347b33656d68ab8f35cfb",
        "name": "Carlos Ruiz"
      }
    }
  }'

• name_mismatch compare le nom du bénéficiaire que vous avez envoyé avec le nom du titulaire que le VASP de test renvoie, selon votre règle de nom pour le type d’entité du bénéficiaire (matching_rules.individual.name ou matching_rules.company.name, qui suivent name_matching_strictness tant que vous ne les définissez pas). Le transfert et l’entrée de chronologie qui l’a décidé portent name_match (avec compared_with: "counterparty_vasp") et data_match avec mismatched_fields: ["name"].
• not_reachable maintient la transaction en AWAITING_COUNTERPARTY pendant les nouvelles tentatives, avec delivery.status à RETRYING et last_error à test VASP is not answering, puis la passe en COUNTERPARTY_VASP_NOT_REACHABLE. Envoyez ensuite {"action": "resend"} pour la relancer.
• self_hosted fait répondre au VASP de test que le portefeuille est auto-hébergé. Enregistrez la preuve avec le widget de vérification de propriété du portefeuille (généré pour vous lorsque auto_wallet_verification est activé) ou avec POST .../travel-rule/ownership/ et {"confirmed": true} : le portefeuille est ajouté à votre carnet d’adresses sous le nom du bénéficiaire, et la correspondance des noms décide de la transaction. Une correspondance la complète et marque le portefeuille comme vérifié. {"confirmed": false} la refuse.

​

Transferts entrants depuis le VASP de test

curl -X POST https://verification.didit.me/v3/travel-rule/test-vasp/inbound/ \
  -H "x-api-key: YOUR_SANDBOX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "beneficiary_wallet_address": "0xYourDepositWallet",
    "scenario": "accept",
    "reference": "sbx-inbound-001"
  }'

​

Webhooks en sandbox

​

Ce que le sandbox ne prouve pas

• Qu’une contrepartie réelle, une adhésion à un réseau ou l’hôte TRP public de Didit fonctionne. Aucun d’entre eux n’est contacté.
• Que vos identifiants réseau sont valides. Une adhésion connectée est confirmée par son premier échange en production.
• Les routes de l’annuaire des VASP réels : sur une application sandbox, chaque route affiche unavailable avec reason: sandbox_application, et chaque ligne affiche reachable: false.