> ## 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. # Tester la Travel Rule en sandbox : guide des scénarios > Testez en sandbox Didit tous les résultats Travel Rule via le VASP de test : approuvé, refusé, nom non concordant, injoignable, délai dépassé. Une application sandbox n'échange des données Travel Rule qu'avec une seule contrepartie : le **Didit Test VASP**, un VASP de test intégré à la plateforme. Il répond à chaque transfert comme vous le lui demandez, par le même code que celui qui gère une contrepartie réelle. Vous pouvez ainsi observer chaque statut, chaque entrée de chronologie et chaque webhook d'un échange avant de passer en production. Rien de ce que vous envoyez en sandbox ne quitte Didit. Aucun réseau, aucun destinataire d'e-mail ni aucun autre client Didit n'est jamais contacté, et rien n'est facturé. ## 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 : ```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. Vous pouvez éventuellement abonner une destination de webhook à `travel_rule.status.updated`. Le sandbox l'envoie, marqué `"environment": "sandbox"`. ## Le Didit Test VASP `GET /v1/sandbox/scenarios/` renvoie le profil du VASP de test et chaque scénario de son objet `travel_rule`. Vos tests peuvent ainsi lire les valeurs de déclenchement au lieu de les coder en dur. | Champ | Valeur | | - | - | | `legal_name` | `Didit Test VASP` | | `lei` | `DIDITESTVASP00000001`, bien formé mais non enregistré | | `jurisdiction` | `GB` | | `compliance_email` | Une adresse sous `didit.test`, à laquelle aucun e-mail n'est jamais envoyé | | `travel_address` | Une Travel Address sous un hôte `.test`, jamais joignable | | `network_codes` | Codes de test, jamais composés | | `default_scenario` | `accept` | | `inbound_scenarios` | `["accept", "name_mismatch"]` | Toutes les valeurs sont des données de test. Le VASP de test n'est membre d'aucun réseau Travel Rule, et aucun résultat en sandbox ne montre qu'une contrepartie ou un réseau réel peut être atteint. ## Scénarios sortants Chaque transaction `travelRule` sortante d'une application sandbox qui nécessite un échange est envoyée au VASP de test. Choisissez l'issue avec l'adresse du portefeuille du bénéficiaire (la casse n'a pas d'importance) ou avec un nom de bénéficiaire de la forme `Didit Test VASP `. Si les deux sont renseignés, le portefeuille prime. Si aucun des deux n'est renseigné, ou si le suffixe ne figure pas dans le tableau, le transfert se termine avec `accept`. Un transfert qui ne nécessite aucun échange n'atteint jamais le VASP de test : c'est le cas d'un montant inférieur à votre `threshold_amount`, d'un transfert vers le propre portefeuille vérifié de votre utilisateur, ou d'un transfert vers un portefeuille de contrepartie que vous avez déclaré auto-hébergé. Un VASP de contrepartie choisi manuellement dans l'annuaire par vous ou par votre utilisateur final est jugé selon les routes qu'une application de production utiliserait. Si son entrée en comporte une (un endpoint `TRP` vérifié, un réseau sur lequel votre application envoie, ou un contact de conformité), le transfert est envoyé au VASP de test. Si elle n'en comporte aucune, le transfert se termine avec `COUNTERPARTY_VASP_NOT_FOUND`, comme il le ferait sur une application de production. | Scénario | Suffixe du nom | Portefeuille (ETH) | Se termine à | | - | - | - | - | | `accept` | aucun | `0xc00c4cd93ff83953ce3347b33656d68ab8f35cfb` | `COMPLETED`, puis `FINISHED` une fois que vous avez signalé `payment_txn_id` | | `decline` | `Decline` | `0x7694c5b0213859ef409107853a36ff7c85835f18` | `COUNTERPARTY_VASP_GENERAL_DECLINE` | | `name_mismatch` | `Name Mismatch` | `0x501b7a0886e31f516aaf54fa99107d2377bd2d3e` | `COUNTERPARTY_MISMATCHED_DATA`, selon votre règle de nom (avec `NONE`, il est complété) | | `not_reachable` | `Not Reachable` | `0xf0e986c1a1c3ae41629bf5cdcee0a67dd1eb0cce` | `COUNTERPARTY_VASP_NOT_REACHABLE` après le calendrier de nouvelles tentatives réel (30 secondes, puis 2, 10, 30 et 60 minutes, soit environ une heure et 45 minutes au total), puis renvoyable | | `timeout` | `Timeout` | `0xb63a1b1d4bee82d109332187cbf5b657eb7da498` | `EXPIRED` au premier contrôle en retard après son délai d'une minute, donc dans environ 15 minutes ; votre `timeout_outcome` s'applique ensuite | | `self_hosted` | `Self Hosted` | `0x33dcc2a7e69cf965f7f4eaf6ba657bcb078a2b65` | `UNCONFIRMED_OWNERSHIP`, puis `COMPLETED` une fois la preuve de propriété du portefeuille enregistrée | ```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" } } }' ``` Le `rail` de la transaction est `TEST_VASP`, et la liste des transferts indique `Didit Test VASP` comme VASP bénéficiaire. Suivez cette transaction dans les webhooks `travel_rule.status.updated`, ou lisez `GET /v3/transactions/{transaction_id}/`. * **`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](https://docs.didit.me/fr/transaction-monitoring/wallet-ownership-widget.md) (généré pour vous lorsque `auto_wallet_verification` est activé) ou avec [`POST .../travel-rule/ownership/`](https://docs.didit.me/fr/management-api/travel-rule/confirm-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 Pour tester le côté réception, demandez au VASP de test de vous envoyer un transfert avec `POST /v3/travel-rule/test-vasp/inbound/`. Indiquez l'un des portefeuilles du [carnet d'adresses](https://docs.didit.me/fr/transaction-monitoring/travel-rule.md#carnet-d’adresses-de-portefeuilles) de votre propre application : le transfert est traité par le même chemin entrant que pour un transfert réel, avec votre carnet d'adresses, votre mode d'actionnariat et vos règles de nom. ```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" }' ``` | Champ | Description | | - | - | | `beneficiary_wallet_address` | Obligatoire, 128 caractères au maximum. Utilisez l'un de vos propres portefeuilles du carnet d'adresses : tout autre portefeuille est enregistré `ON_HOLD`. | | `scenario` | `accept` (par défaut) : le VASP de test désigne le titulaire du portefeuille. `name_mismatch` : il désigne quelqu'un qui ne correspond à aucun titulaire. | | `chain`, `amount`, `currency` | Facultatifs. Valeurs par défaut : `ETH`, `1` et `ETH`. | | `reference` | Facultatif, 128 caractères au maximum. Envoyer à nouveau la même `reference` renvoie la première réponse (`201`) et n'enregistre rien de nouveau. | La réponse `201` contient `transaction_id`, `txn_id`, `scenario`, `travel_rule_status`, `detail`, `test_vasp: true` et le transfert `travel_rule`. Une application en production reçoit `400` (`"The Didit Test VASP is only available on sandbox applications."`), une autre valeur de `scenario` renvoie `400`, et une application dont Travel Rule est désactivée reçoit `409`. | Votre entrée de portefeuille | `accept` | `name_mismatch` | | - | - | - | | Aucune sur cette chaîne | `ON_HOLD` | `ON_HOLD` | | Actionnariat non prouvé pour votre [mode d'actionnariat](https://docs.didit.me/fr/transaction-monitoring/travel-rule.md#modes-de-validation-de-la-propriété) | `UNCONFIRMED_OWNERSHIP` | `UNCONFIRMED_OWNERSHIP` | | Vérifiée | `COMPLETED` tant que `inbound_auto_accept` est activé, sinon `ON_HOLD` | `COUNTERPARTY_MISMATCHED_DATA` (avec la règle de nom `NONE`, comme `accept`) | Prenez une décision concernant un transfert en attente avec [`POST .../travel-rule/ownership/`](https://docs.didit.me/fr/management-api/travel-rule/confirm-ownership), comme pour un transfert réel : `{"confirmed": true}` le finalise et `{"confirmed": false}` le refuse. Un dépôt que vous signalez vous-même avec `POST /v3/transactions/` n'est pas un transfert envoyé par le VASP de test : il reste `AWAITING_COUNTERPARTY` dans l'attente de son VASP d'origine, et sa chronologie cite l'endpoint indiqué plus haut. Il ne déclenche aucun webhook avant son expiration, après `confirmation_timeout_hours`. [`POST /v3/travel-rule/inbound/`](https://docs.didit.me/fr/management-api/travel-rule/register-inbound) finalise toujours un enregistrement post-dépôt par rapport à votre carnet d'adresses, comme sur une application en production. ## Webhooks en sandbox `travel_rule.status.updated` se déclenche pour les applications sandbox à chaque changement de statut, avec `"environment": "sandbox"`. Un transfert auquel le VASP de test a répondu porte aussi `rail: "TEST_VASP"`, `test_vasp: true` et `test_vasp_scenario`. Le reste de la sandbox se comporte comme décrit dans [Surveillance des transactions en sandbox](https://docs.didit.me/fr/integration/sandbox-testing.md#transaction-monitoring-in-sandbox) : les règles ne sont pas évaluées, `transaction.created` et `transaction.status.updated` ne sont pas envoyés, et rien n'est facturé. ## 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](https://docs.didit.me/fr/transaction-monitoring/travel-rule.md#annuaire) des VASP réels : sur une application sandbox, chaque route affiche `unavailable` avec `reason: sandbox_application`, et chaque ligne affiche `reachable: false`. Voir [Réseaux Travel Rule](https://docs.didit.me/fr/transaction-monitoring/travel-rule-networks.md) pour ce que chaque rail atteint en production aujourd'hui. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.