> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Travel Rule sandbox: guida ai test

> Testa in sandbox gli esiti della Travel Rule con il VASP Didit: accettazione, rifiuto, nome errato, timeout, wallet in autocustodia.

Un'applicazione sandbox scambia dati Travel Rule con una sola controparte: il **Didit Test VASP**, un VASP di test integrato nella piattaforma. Risponde a ogni trasferimento come gli chiedi tu, attraverso lo stesso codice che gestisce una controparte reale, così puoi osservare ogni stato, ogni voce della cronologia e ogni webhook di uno scambio prima di andare in produzione.

Nulla di ciò che invii in sandbox lascia Didit. Non viene mai contattata alcuna rete, nessun destinatario email né altro cliente Didit, e nulla viene addebitato.

## 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:

```bash theme={null}
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

`GET /v1/sandbox/scenarios/` restituisce il profilo del VASP di test e ogni scenario nel suo oggetto `travel_rule`, così i tuoi test possono leggere i valori di trigger invece di scriverli nel codice:

| Campo | Valore |
| - | - |
| `legal_name` | `Didit Test VASP` |
| `lei` | `DIDITESTVASP00000001`, ben formato ma non registrato |
| `jurisdiction` | `GB` |
| `compliance_email` | Un indirizzo in `didit.test`, a cui non viene mai inviata posta |
| `travel_address` | Un Travel Address su un host con dominio `.test`, mai raggiungibile |
| `network_codes` | Codici di test, mai contattati |
| `default_scenario` | `accept` |
| `inbound_scenarios` | `["accept", "name_mismatch"]` |

Ogni valore è un dato di test. Il VASP di test non è membro di alcuna rete Travel Rule, e nessun risultato in sandbox dimostra che una controparte o una rete reale sia raggiungibile.

## Scenari in uscita

Ogni transazione `travelRule` in uscita di un'applicazione sandbox che richiede uno scambio va al VASP di test. Scegli l'esito tramite l'indirizzo wallet del beneficiario (non conta la distinzione tra maiuscole e minuscole) oppure tramite un nome del beneficiario nella forma `Didit Test VASP <suffix>`; se sono impostati entrambi, prevale il wallet. Se non c'è né l'uno né l'altro, oppure se il suffisso non compare nella tabella, il trasferimento si completa (`accept`).

Un trasferimento che non richiede uno scambio non raggiunge mai il VASP di test: uno al di sotto della tua `threshold_amount`, uno verso il wallet verificato del tuo utente e uno il cui wallet della controparte hai dichiarato in autocustodia. Un VASP controparte che tu o il tuo utente finale avete scelto manualmente dalla directory è valutato con le stesse rotte di un'applicazione in produzione: se la sua voce ne ha una (un endpoint `TRP` verificato, una rete su cui invia la tua applicazione oppure un contatto di compliance), il trasferimento va al VASP di test; se non ne ha, il trasferimento termina con `COUNTERPARTY_VASP_NOT_FOUND`, come accadrebbe su un'applicazione in produzione.

| Scenario | Suffisso del nome | Wallet (ETH) | Termina con |
| - | - | - | - |
| `accept` | nessuno | `0xc00c4cd93ff83953ce3347b33656d68ab8f35cfb` | `COMPLETED`, poi `FINISHED` dopo che comunichi `payment_txn_id` |
| `decline` | `Decline` | `0x7694c5b0213859ef409107853a36ff7c85835f18` | `COUNTERPARTY_VASP_GENERAL_DECLINE` |
| `name_mismatch` | `Name Mismatch` | `0x501b7a0886e31f516aaf54fa99107d2377bd2d3e` | `COUNTERPARTY_MISMATCHED_DATA`, secondo la tua regola sul nome (con `NONE` il trasferimento si completa) |
| `not_reachable` | `Not Reachable` | `0xf0e986c1a1c3ae41629bf5cdcee0a67dd1eb0cce` | `COUNTERPARTY_VASP_NOT_REACHABLE` dopo la pianificazione reale dei nuovi tentativi (30 secondi, poi 2, 10, 30 e 60 minuti, circa un'ora e 45 minuti in totale), poi reinviabile |
| `timeout` | `Timeout` | `0xb63a1b1d4bee82d109332187cbf5b657eb7da498` | `EXPIRED` al primo controllo successivo alla scadenza di un minuto, quindi entro circa 15 minuti; si applica poi il tuo `timeout_outcome` |
| `self_hosted` | `Self Hosted` | `0x33dcc2a7e69cf965f7f4eaf6ba657bcb078a2b65` | `UNCONFIRMED_OWNERSHIP`, poi `COMPLETED` una volta registrata la prova di proprietà del wallet |

```bash theme={null}
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"
      }
    }
  }'
```

Il `rail` del trasferimento è `TEST_VASP`, e nell'elenco dei trasferimenti `Didit Test VASP` compare come VASP beneficiario. Seguilo nei webhook `travel_rule.status.updated`, oppure leggi `GET /v3/transactions/{transaction_id}/`.

* **`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](https://docs.didit.me/it/transaction-monitoring/wallet-ownership-widget.md) (generato per te finché `auto_wallet_verification` è attivo) oppure con [`POST .../travel-rule/ownership/`](https://docs.didit.me/it/management-api/travel-rule/confirm-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

Para probar el lado receptor, pide al VASP de prueba que te envíe una transferencia con `POST /v3/travel-rule/test-vasp/inbound/`. Indica una de las wallets de tu propio [libro de direcciones](https://docs.didit.me/it/transaction-monitoring/travel-rule.md#rubrica-degli-indirizzi-wallet) de la aplicación: la transferencia se decide con la misma ruta entrante que una real, contra tu libro de direcciones, tu modo de titularidad y tus reglas de nombre.

```bash theme={null}
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"
  }'
```

| Campo | Descripción |
| - | - |
| `beneficiary_wallet_address` | Obligatorio, hasta 128 caracteres. Usa una de tus propias wallets del libro de direcciones: cualquier otra wallet se registra como `ON_HOLD`. |
| `scenario` | `accept` (predeterminado): el VASP de prueba nombra al propio titular de la wallet. `name_mismatch`: indica a alguien con quien ningún titular coincide. |
| `chain`, `amount`, `currency` | Opcionales. Los valores predeterminados son `ETH`, `1` y `ETH`. |
| `reference` | Opcional, hasta 128 caracteres. Enviar de nuevo la misma `reference` devuelve la primera respuesta (`201`) y no registra nada nuevo. |

La respuesta `201` incluye `transaction_id`, `txn_id`, `scenario`, `travel_rule_status`, `detail`, `test_vasp: true` y la transferencia `travel_rule`. Una aplicación en producción recibe `400` (`"The Didit Test VASP is only available on sandbox applications."`), otro `scenario` recibe `400`, y una aplicación con Travel Rule desactivada recibe `409`.

| Tu entrada de wallet | `accept` | `name_mismatch` |
| - | - | - |
| Ninguna en esa cadena | `ON_HOLD` | `ON_HOLD` |
| Titularidad no demostrada para tu [modo de titularidad](https://docs.didit.me/it/transaction-monitoring/travel-rule.md#modalità-di-validazione-dell’assetto-proprietario) | `UNCONFIRMED_OWNERSHIP` | `UNCONFIRMED_OWNERSHIP` |
| Verificada | `COMPLETED` mientras `inbound_auto_accept` esté activado; en caso contrario, `ON_HOLD` | `COUNTERPARTY_MISMATCHED_DATA` (con la regla de nombre `NONE`, igual que `accept`) |

Decide una transferencia pendiente mediante [`POST .../travel-rule/ownership/`](https://docs.didit.me/it/management-api/travel-rule/confirm-ownership), igual que con una real: `{"confirmed": true}` la completa y `{"confirmed": false}` la rechaza.

Un depósito que tú mismo registras con `POST /v3/transactions/` no es uno que haya enviado el VASP de prueba: permanece en `AWAITING_COUNTERPARTY` a la espera de su VASP originador, y su cronología menciona el endpoint anterior. No envía ningún webhook hasta que caduca tras `confirmation_timeout_hours`. [`POST /v3/travel-rule/inbound/`](https://docs.didit.me/it/management-api/travel-rule/register-inbound) sigue liquidando un registro posterior al depósito contra tu libro de direcciones, como en una aplicación en producción.

## Webhooks en sandbox

`travel_rule.status.updated` se envía para las aplicaciones sandbox en cada cambio de estado, con `"environment": "sandbox"`. Una transferencia a la que respondió el VASP de prueba incluye además `rail: "TEST_VASP"`, `test_vasp: true` y `test_vasp_scenario`. El resto del sandbox se comporta como se describe en [Monitorización de transacciones en sandbox](https://docs.didit.me/it/integration/sandbox-testing.md#monitoraggio-delle-transazioni-nella-sandbox): las reglas no se evalúan, no se envían `transaction.created` ni `transaction.status.updated`, y no se factura nada.

## 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](https://docs.didit.me/it/transaction-monitoring/travel-rule.md#directory) de VASP reales: en una aplicación sandbox cada ruta aparece como `unavailable` con `reason: sandbox_application`, y cada fila con `reachable: false`.

Consulta [Redes de Travel Rule](https://docs.didit.me/it/transaction-monitoring/travel-rule-networks.md) para ver a qué alcanza cada canal en producción hoy.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.