Test data exchanges in Sandbox

Sandbox provides a test VASP that you can use to test Travel Rule data exchanges. The test VASP is a Sumsub-hosted counterparty available only in Sandbox and reachable through the Sumsub protocol.

Transactions submitted to the test VASP follow the same request structure as production transactions, allowing you to test exchange statuses, lifecycle transitions, and incoming request handling before enabling the integration in production.

Before you start

Before testing Travel Rule exchanges, configure your Sandbox environment as follows:

1. Switch your account to Sandbox mode.
2. Make sure your organisation is linked to a VASP and that the Sumsub protocol is enabled for that VASP. If your organisation is not linked to a VASP, contact your Customer Success Manager.
3. Install and activate the required Travel Rule rules in Sandbox. Sandbox uses its own rules, Travel Rule settings, and app tokens.
4. Configure your Sandbox webhook endpoint and verify that it receives events.
5. Configure the confirmation timeout required for your test scenarios.

The request structure is the same as for production flows. For the required transaction fields, refer to this article.

Test scenario values

Use the following counterparty values to trigger specific Sandbox scenarios.

Recommended test sequence

Start with the successful flow and then test waiting, decline, timeout, and finalisation scenarios. This makes it easier to identify which configuration or request change caused an unexpected result.

1. completed — Verify that the exchange completes successfully, the expected webhook events are received, and your integration reads the status correctly.

2. awaitingCounterparty — Verify that your integration correctly handles an exchange that is waiting for a counterparty response.

   📘

   Note

   Disable any rule that immediately handles wallets not associated with the counterparty VASP before running this test. Otherwise, the transaction may transition before you can observe awaitingCounterparty.

3. unconfirmedOwnership — Verify that your integration treats the status as final and does not retry the exchange.

4. counterpartyVaspNotReachable — Verify that your integration treats the status as final when the VASP can be identified but cannot be reached through a mutually supported protocol.

   📘

   Note

   In production, Sumsub also sends an email notification to the unreachable VASP and records the attempt under Events → Emails. Emails are not sent in Sandbox, so only the status can be tested.

5. counterpartyVaspNotFound — Verify that the appropriate rules for unhosted wallets are applied.

6. awaitingCounterparty → expired — Configure a short confirmation timeout, create the transaction, and verify that the exchange transitions to expired when no response is received.

   📘

   Note

   Only exchanges in awaitingCounterparty or onHold can transition to expired.

7. completed → finished — Verify the finalisation flow. For an exchange initiated before settlement, submit the blockchain transaction ID after broadcasting the transfer using this API method.

8. completed → cancelled — Complete the Travel Rule exchange, then cancel it instead of broadcasting the transfer. Verify that the exchange transitions to cancelled.

Testing exchange after settlement

To test an exchange created after settlement, use the same counterparty values and provide info.paymentTxnId when creating the transaction. For more information, see this article.

The exchange follows the same Travel Rule data exchange process. After the counterparty responds successfully, Sumsub can associate the exchange with the blockchain transaction ID supplied at creation and transition the exchange to finished automatically.

Testing incoming request

To test how your integration handles an incoming Travel Rule request, use the test VASP to generate a request for your organisation.

1. Go to Transactions and travel rule → Transactions.

2. Click Create sample transaction.

3. Select Travel rule (simulate inbound transfer). This option is available only in Sandbox.

4. Enter the transaction information as an incoming transfer to your organisation:

   • Select the counterparty VASP.
   • Provide both wallet addresses.
   • Provide the applicant's name — first and last name for an individual or the full company name for a legal entity.

5. Submit the transaction.

You cannot select an existing applicant in this form. The entered values are used to create the simulated scenario.

Sumsub creates the corresponding transaction on the test VASP account, which then initiates a Travel Rule exchange with your organisation. The resulting request is processed by your integration in the same way as an incoming production request.

Handle the request using the standard incoming request flow: retrieve the transaction information, confirm or reject wallet ownership, and provide the required participant data.

What to validate

Validate the following for each test scenario:

• The exchange reaches the expected status.
• Your webhook handler receives and processes the complete event sequence.
• Webhook processing is idempotent, because a single exchange may generate multiple events.
• Your integration distinguishes between open and final statuses and closes its internal records when the exchange reaches a final status.
• Failed webhook deliveries trigger monitoring or alerts so that missed updates can be identified and resent from the Dashboard.