Test in Sandbox

Use a Sandbox secret key and set sandboxScenario on a transaction request. Start with these scenarios:

• Travel Rule not required for an explicit below-threshold result.
• Missing beneficiary information to test the information collection loop.
• Travel Rule potential sanctions to test a review outcome and specialist investigation.
• Travel Rule confirmed sanctions to test a stopped transfer.

After the request completes, open the transaction, inspect the summary, submit missing information when requested and verify the matching webhook deliveries. Scenario traffic is labelled and non-billable, but it still uses the governed Travel Rule assessment path.

Travel Rule scenarios require a compatible published policy. Install the Sandbox Travel Rule preset under Risk Intelligence → Rules & Policies → Fraud rules → Travel Rule, then publish its draft before testing.

For an API-driven deterministic test, set the top-level sandboxScenario to TRAVEL_RULE_MISSING_BENEFICIARY, only in this recovery test. The scenario is included in the request hash, follows the real policy and evidence path, and is non-billable. It is accepted only in Sandbox and development. Production returns 422 sandbox_scenario_not_available_in_production; remove the field for live traffic. Ordinary Sandbox requests without a scenario use configured pricing and are billable.

Acceptance checklist

• Complete data: one transaction, no duplicate information submission.
• Missing data: collect only the named fields and retain the original transaction.
• Response loss: reuse the exact request and idempotency key; do not charge or execute twice.
• Information accepted: still check current clearance and wallet authorisation.
• Invalid or expired webhook signature: reject it without changing customer access.
• Review or block: enforce the outcome in your application and make the reason visible to authorised staff.
• Live activation: test an actual institution channel and your wallet enforcement separately from synthetic scenarios.