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

> Alle Travel-Rule-Ergebnisse in der Didit-Sandbox testen, End-to-End gegen den Didit Test-VASP: Annahme, Ablehnung, Namensabweichung, Timeout.

Eine Sandbox-Anwendung tauscht Travel-Rule-Daten nur mit einer Gegenpartei aus: dem **Didit Test VASP**, einem in die Plattform integrierten Test-VASP. Er beantwortet jede Transaktion so, wie Sie es vorgeben, und zwar über denselben Code, der auch eine echte Gegenpartei verarbeitet. So können Sie jeden Status, jeden Verlaufseintrag und jeden Webhook eines Austauschs beobachten, bevor Sie live gehen.

Nichts, was Sie in der Sandbox senden, verlässt Didit. Kein Netzwerk, kein E-Mail-Empfänger und kein anderer Didit-Kunde wird je kontaktiert, und es fallen keine Kosten an.

## Bevor Sie beginnen

1. Verwenden Sie den API-Schlüssel einer **Sandbox**-Anwendung. Live-Anwendungen erreichen den Test-VASP nie.
2. Aktivieren Sie die Travel Rule mit einem rechtlichen Namen:

```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. Optional können Sie ein Webhook-Ziel für `travel_rule.status.updated` abonnieren. Die Sandbox stellt es zu und kennzeichnet es mit `"environment": "sandbox"`.

## Der Didit Test VASP

`GET /v1/sandbox/scenarios/` gibt das Profil des Test-VASP und alle Szenarien in seinem Objekt `travel_rule` zurück. So können Ihre Tests die Auslösewerte auslesen, statt sie fest zu codieren:

| Feld | Wert |
| - | - |
| `legal_name` | `Didit Test VASP` |
| `lei` | `DIDITESTVASP00000001`, korrekt aufgebaut, aber nicht registriert |
| `jurisdiction` | `GB` |
| `compliance_email` | Eine Adresse unter `didit.test`, an die nie eine E-Mail geht |
| `travel_address` | Eine Travel Address unter einem `.test`-Host, nie erreichbar |
| `network_codes` | Testcodes, die nie angewählt werden |
| `default_scenario` | `accept` |
| `inbound_scenarios` | `["accept", "name_mismatch"]` |

Alle Werte sind Testdaten. Der Test-VASP ist keinem Travel-Rule-Netzwerk angeschlossen, und kein Ergebnis in der Sandbox zeigt, dass eine echte Gegenpartei oder ein echtes Netzwerk erreichbar ist.

## Ausgehende Szenarien

Jede ausgehende `travelRule`-Transaktion einer Sandbox-Anwendung, für die ein Austausch nötig ist, geht an den Test-VASP. Wählen Sie das Ergebnis über die Wallet-Adresse des Begünstigten (Groß- und Kleinschreibung spielt keine Rolle) oder über einen Begünstigtennamen in der Form `Didit Test VASP <suffix>`. Sind beide gesetzt, hat die Wallet Vorrang. Ohne beides oder mit einem Suffix, das die Tabelle nicht aufführt, wird die Transaktion abgeschlossen (`accept`).

Eine Transaktion, für die kein Austausch nötig ist, erreicht den Test-VASP nie: eine unterhalb Ihres `threshold_amount`, eine an die eigene verifizierte Wallet Ihres Benutzers und eine, deren Gegenpartei-Wallet Sie als selbstverwahrt angegeben haben. Eine Gegenpartei-VASP, die Sie oder Ihr Endbenutzer manuell aus dem Verzeichnis ausgewählt haben, wird nach den Wegen beurteilt, die auch eine Live-Anwendung hätte. Hat ihr Eintrag einen solchen Weg (einen verifizierten `TRP`-Endpoint, ein Netzwerk, über das Ihre Anwendung sendet, oder einen Compliance-Kontakt), geht die Transaktion an den Test-VASP. Hat der Eintrag keinen, endet die Transaktion mit `COUNTERPARTY_VASP_NOT_FOUND`, wie es auch bei einer Live-Anwendung wäre.

| Szenario | Namenssuffix | Wallet (ETH) | Endet bei |
| - | - | - | - |
| `accept` | keiner | `0xc00c4cd93ff83953ce3347b33656d68ab8f35cfb` | `COMPLETED`, danach `FINISHED`, sobald Sie `payment_txn_id` melden |
| `decline` | `Decline` | `0x7694c5b0213859ef409107853a36ff7c85835f18` | `COUNTERPARTY_VASP_GENERAL_DECLINE` |
| `name_mismatch` | `Name Mismatch` | `0x501b7a0886e31f516aaf54fa99107d2377bd2d3e` | `COUNTERPARTY_MISMATCHED_DATA`, bei Ihrer Namensregel (bei `NONE` wird sie abgeschlossen) |
| `not_reachable` | `Not Reachable` | `0xf0e986c1a1c3ae41629bf5cdcee0a67dd1eb0cce` | `COUNTERPARTY_VASP_NOT_REACHABLE` nach dem echten Wiederholungsplan (30 Sekunden, dann 2, 10, 30 und 60 Minuten, insgesamt etwa eine Stunde und 45 Minuten), danach erneut sendbar |
| `timeout` | `Timeout` | `0xb63a1b1d4bee82d109332187cbf5b657eb7da498` | `EXPIRED` bei der ersten überfälligen Prüfung nach Ablauf der Ein-Minuten-Frist, also innerhalb von etwa 15 Minuten; danach gilt Ihr `timeout_outcome` |
| `self_hosted` | `Self Hosted` | `0x33dcc2a7e69cf965f7f4eaf6ba657bcb078a2b65` | `UNCONFIRMED_OWNERSHIP`, danach `COMPLETED`, sobald der Nachweis der Wallet-Eigentümerschaft erfasst ist |

```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"
      }
    }
  }'
```

Der `rail` der Transaktion ist `TEST_VASP`, und in der Transaktionsliste ist `Didit Test VASP` als Begünstigten-VASP angegeben. Verfolgen Sie die Transaktion in den Webhooks `travel_rule.status.updated`, oder lesen Sie `GET /v3/transactions/{transaction_id}/`.

* **`name_mismatch`** vergleicht den Begünstigtennamen, den Sie gesendet haben, mit dem Kontoinhabernamen, den der Test-VASP zurückmeldet. Maßstab ist Ihre Namensregel für den Entitätstyp des Begünstigten (`matching_rules.individual.name` bzw. `matching_rules.company.name`, die so lange `name_matching_strictness` folgen, bis Sie sie setzen). Die Transaktion und der Verlaufseintrag, der die Entscheidung getroffen hat, enthalten `name_match` (mit `compared_with: "counterparty_vasp"`) und `data_match` mit `mismatched_fields: ["name"]`.
* **`not_reachable`** hält die Transaktion im Status `AWAITING_COUNTERPARTY`, solange sie wiederholt wird, mit `delivery.status` `RETRYING` und `last_error` `test VASP is not answering`. Danach wechselt die Transaktion in den Status `COUNTERPARTY_VASP_NOT_REACHABLE`. Senden Sie anschließend `{"action": "resend"}`, um sie erneut auszuführen.
* **`self_hosted`** lässt den Test-VASP bestätigen, dass die Wallet selbstverwahrt ist. Erfassen Sie den Nachweis mit dem [Widget zur Wallet-Eigentumsprüfung](https://docs.didit.me/de/transaction-monitoring/wallet-ownership-widget.md) (für Sie ausgestellt, solange `auto_wallet_verification` aktiv ist) oder mit [`POST .../travel-rule/ownership/`](https://docs.didit.me/de/management-api/travel-rule/confirm-ownership) und `{"confirmed": true}`. Die Wallet wird dann unter dem Namen des Begünstigten in Ihr Adressbuch aufgenommen, und der Namensabgleich entscheidet über die Transaktion. Eine Übereinstimmung schließt sie ab und markiert die Wallet als verifiziert. `{"confirmed": false}` lehnt sie ab.

## Eingehende Überweisungen vom Test-VASP

Um die Empfangsseite zu testen, lassen Sie den Test-VASP mit `POST /v3/travel-rule/test-vasp/inbound/` eine Überweisung an Sie senden. Geben Sie dabei eine der eigenen Wallets Ihrer Anwendung aus dem [Adressbuch](https://docs.didit.me/de/transaction-monitoring/travel-rule.md#wallet-adressbuch) an. Die Überweisung wird über denselben eingehenden Pfad entschieden wie eine echte, anhand Ihres Adressbuchs, Ihres Eigentumsmodus und Ihrer Namensregeln.

```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"
  }'
```

| Feld | Beschreibung |
| - | - |
| `beneficiary_wallet_address` | Pflichtfeld, bis zu 128 Zeichen. Verwenden Sie eine Ihrer eigenen Wallets aus dem Adressbuch. Jede andere Wallet wird als `ON_HOLD` gebucht. |
| `scenario` | `accept` (Standard): Der Test-VASP nennt den Inhaber der Wallet. `name_mismatch`: Er nennt eine Person, mit der kein Inhaber übereinstimmt. |
| `chain`, `amount`, `currency` | Optional. Standardwerte `ETH`, `1` und `ETH`. |
| `reference` | Optional, bis zu 128 Zeichen. Wenn Sie dieselbe `reference` erneut senden, wird die erste Antwort (`201`) zurückgegeben und nichts Neues gebucht. |

Die Antwort `201` enthält `transaction_id`, `txn_id`, `scenario`, `travel_rule_status`, `detail`, `test_vasp: true` und die Überweisung `travel_rule`. Eine Live-Anwendung erhält `400` (`"The Didit Test VASP is only available on sandbox applications."`). Ein anderer Wert für `scenario` ergibt ebenfalls `400`, und eine Anwendung mit deaktivierter Travel Rule erhält `409`.

| Ihr Wallet-Eintrag | `accept` | `name_mismatch` |
| - | - | - |
| Keiner auf dieser Chain | `ON_HOLD` | `ON_HOLD` |
| Eigentum für Ihren [Eigentumsmodus](https://docs.didit.me/de/transaction-monitoring/travel-rule.md#modi-der-eigentumsvalidierung) nicht nachgewiesen | `UNCONFIRMED_OWNERSHIP` | `UNCONFIRMED_OWNERSHIP` |
| Verifiziert | `COMPLETED`, solange `inbound_auto_accept` aktiviert ist, sonst `ON_HOLD` | `COUNTERPARTY_MISMATCHED_DATA` (bei Namensregel `NONE` wie bei `accept`) |

Entscheiden Sie über eine wartende Überweisung mit [`POST .../travel-rule/ownership/`](https://docs.didit.me/de/management-api/travel-rule/confirm-ownership), wie Sie es bei einer echten tun würden: `{"confirmed": true}` schließt sie ab, `{"confirmed": false}` lehnt sie ab.

Eine Einzahlung, die Sie selbst über `POST /v3/transactions/` melden, wurde nicht vom Test-VASP gesendet. Sie bleibt `AWAITING_COUNTERPARTY` und wartet auf ihren Ursprungs-VASP. Ihre Zeitleiste nennt den oben genannten Endpoint. Es wird kein Webhook ausgelöst, bis sie nach `confirmation_timeout_hours` abläuft. [`POST /v3/travel-rule/inbound/`](https://docs.didit.me/de/management-api/travel-rule/register-inbound) schließt eine Registrierung nach der Einzahlung weiterhin anhand Ihres Adressbuchs ab, wie auf einer Live-Anwendung.

## Webhooks in der Sandbox

`travel_rule.status.updated` wird für Sandbox-Anwendungen bei jeder Statusänderung ausgelöst, mit `"environment": "sandbox"`. Eine Überweisung, auf die der Test-VASP geantwortet hat, enthält außerdem `rail: "TEST_VASP"`, `test_vasp: true` und `test_vasp_scenario`. Der übrige Teil der Sandbox verhält sich wie in [Transaktionsüberwachung in der Sandbox](https://docs.didit.me/de/integration/sandbox-testing.md#transaktionsüberwachung-in-der-sandbox) beschrieben: Regeln werden nicht ausgewertet, `transaction.created` und `transaction.status.updated` werden nicht gesendet, und es fallen keine Kosten an.

## Was die Sandbox nicht beweist

* Dass eine echte Gegenpartei, eine Netzwerkmitgliedschaft oder der öffentliche TRP-Host von Didit funktioniert. Keines davon wird kontaktiert.
* Dass Ihre Netzwerk-Zugangsdaten gültig sind. Eine verbundene Mitgliedschaft wird erst durch ihren ersten Live-Austausch bestätigt.
* Die Routen echter VASPs im [Verzeichnis](https://docs.didit.me/de/transaction-monitoring/travel-rule.md#verzeichnis). Auf einer Sandbox-Anwendung hat jede Route den Status `unavailable` mit `reason: sandbox_application`, und jede Zeile hat `reachable: false`.

Welche Ziele die einzelnen Netzwerke heute in der Produktion erreichen, finden Sie unter [Travel-Rule-Netzwerke](https://docs.didit.me/de/transaction-monitoring/travel-rule-networks.md).


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