Travel Rule Sandbox testen: Leitfaden

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

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

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

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

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 (für Sie ausgestellt, solange auto_wallet_verification aktiv ist) oder mit POST .../travel-rule/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 an. Die Überweisung wird über denselben eingehenden Pfad entschieden wie eine echte, anhand Ihres Adressbuchs, Ihres Eigentumsmodus und Ihrer Namensregeln.

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 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/, 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/ 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 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. 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.

Erste Schritte

Funktionen

Referenz

Konsole

Travel Rule Sandbox testen: Leitfaden

Bevor Sie beginnen

Der Didit Test VASP

Ausgehende Szenarien

Eingehende Überweisungen vom Test-VASP

Webhooks in der Sandbox

Was die Sandbox nicht beweist

​Bevor Sie beginnen

​Der Didit Test VASP

​Ausgehende Szenarien

​Eingehende Überweisungen vom Test-VASP

​Webhooks in der Sandbox

​Was die Sandbox nicht beweist

Bevor Sie beginnen

Der Didit Test VASP

Ausgehende Szenarien

Eingehende Überweisungen vom Test-VASP

Webhooks in der Sandbox

Was die Sandbox nicht beweist