Travel Rule sandbox: guida ai test

​

Prima di iniziare

1. Usa la chiave API di un’applicazione sandbox. Le applicazioni in produzione non raggiungono mai il VASP di test.
2. Attiva Travel Rule con un nome legale:

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. Facoltativamente, iscrivi una destinazione webhook a travel_rule.status.updated. La sandbox la consegna, contrassegnata con "environment": "sandbox".

​

Il Didit Test VASP

​

Scenari in uscita

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 confronta il nome del beneficiario che hai inviato con il nome del titolare che il VASP di test restituisce, secondo la tua regola sul nome per il tipo di entità del beneficiario (matching_rules.individual.name oppure matching_rules.company.name, che seguono name_matching_strictness finché non le imposti). Il trasferimento e la voce della cronologia che lo ha deciso riportano name_match (con compared_with: "counterparty_vasp") e data_match con mismatched_fields: ["name"].
• not_reachable mantiene il trasferimento in AWAITING_COUNTERPARTY mentre riprova, con delivery.status RETRYING e last_error test VASP is not answering, poi lo porta a COUNTERPARTY_VASP_NOT_REACHABLE. Invia successivamente {"action": "resend"} per eseguirlo di nuovo.
• self_hosted fa rispondere al VASP di test che il wallet è in autocustodia. Registra la prova con il widget di verifica della proprietà del wallet (generato per te finché auto_wallet_verification è attivo) oppure con POST .../travel-rule/ownership/ inviando {"confirmed": true}: il wallet viene aggiunto alla tua rubrica degli indirizzi con il nome del beneficiario e il confronto del nome determina l’esito del trasferimento. Una corrispondenza lo completa e contrassegna il wallet come verificato; {"confirmed": false} lo rifiuta.

​

Transferencias entrantes desde el VASP de prueba

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

​

Lo que el sandbox no demuestra

• Que una contraparte real, una pertenencia a una red o el host público TRP de Didit funcionen. No se contacta con ninguno de ellos.
• Que tus credenciales de red sean válidas. Una membresía conectada queda demostrada mediante su primer intercambio en producción.
• Las rutas del directorio de VASP reales: en una aplicación sandbox cada ruta aparece como unavailable con reason: sandbox_application, y cada fila con reachable: false.