Sandbox configuration

Configure sandbox-only testing utilities to simulate flows that differ from production behavior.

Overview

Use the sandbox environment to test onboarding, KYC/KYB, pay-ins, webhooks, and transfer flows without triggering production money movement or production verification decisions.

Sandbox utilities are only available for testing. Do not use sandbox command URLs or simulation endpoints in production integrations.

Stub KYC applicant approval

In sandbox, you can stub a Sumsub applicant review and mark the applicant as approved.

You can approve the applicant in either of these ways:

1. Call the sandbox endpoint directly with the account ID whose KYC/KYB status you want to approve:

POST /dev/sumsub/applicants/{{accountId}}/approve

Replace {{accountId}} with the sandbox account ID.

2. Use the sandbox approval tool:

https://dev.sandbox.due.network/commands/sumsub/approve-applicant

Use this when you need to test flows that depend on a completed KYC/KYB status, such as:

• creating gated virtual accounts after KYC/KYB approval;
• testing endorsement flows;
• testing post-KYC onboarding steps;
• validating webhook handling for status changes.

This endpoint and tool are sandbox-only. In production, KYC/KYB status is determined by the normal verification review process.

Simulate fiat pay-ins

In sandbox, you can simulate an incoming fiat pay-in instead of sending funds from an external bank.

Use the sandbox pay-in simulation endpoint:

POST /dev/payin

The request can include the pay-in amount, currency, rail, reference, sender, and recipient details used for the test scenario.

Example shape:

{
  "currency": "EUR",
  "rail": "sepa",
  "amount": "100.00",
  "reference": "test-reference",
  "sender": {
    "schema": "bank_sepa"
  },
  "recipient": {
    "schema": "bank_sepa"
  }
}

Use pay-in simulation to test:

• virtual account deposit handling;
• transfer status updates after funds are received;
• webhook delivery for incoming payment flows;
• reconciliation logic in your application.

The exact sender and recipient schema fields depend on the rail you are simulating. Use the same schema structure that applies to the relevant payment method.

Test crypto legs

/dev/payin cannot simulate crypto funding. Fund crypto legs yourself on the sandbox chain with test USDC issued by the sandbox.

1. Get test USDC. Mint it to your sender wallet from the Stub Admin. Select the network (for example, Base Sepolia), USDC, your sender wallet address, and the amount.

   Mint to the sender wallet, never to the funding address. Do not use public testnet faucets: they issue a different token that the sandbox does not recognize, so deposits of that token are never matched.

2. Fund the transfer. Create the transfer with your wallet as the sender, then request a funding address:

   HTTP

   POST /v1/transfers/{transferId}/funding_address

   The response returns details.address. Send the exact source.amount of USDC from the sender wallet to that address in a single transaction before expiresAt. The sender wallet must also hold enough native token to pay gas.

3. Follow the matching rules. The deposit is matched to the transfer by sender address and amount. The sending address must exactly match the sender set on the transfer.

   If you use a contract wallet, such as a Safe or smart account, set that contract address as the sender and send from it. Funds sent from another address, with a different amount, split across multiple transactions, or sent after expiry remain in awaiting_funds and are not credited.

4. Wait for processing. After the deposit is confirmed, the transfer moves through approved and payment_submitted to payment_processed automatically. You do not need to simulate the payout.

Funding addresses are supported for USDC on EVM networks (Ethereum, Polygon, Avalanche, Arbitrum, and Base) and their sandbox equivalents.

Production differences

Sandbox commands and simulation endpoints replace external actions for testing only.

Recommended testing flow

1. Create a sandbox account.
2. Start KYC/KYB for the account.
3. Call /dev/sumsub/applicants/{{accountId}}/approve or use the sandbox approval tool when you need the applicant to be approved.
4. Create the virtual account, transfer, or endorsement you want to test.
5. Call /dev/payin for fiat flows that depend on incoming funds.
6. For crypto legs, mint test USDC from the Stub Admin to the sender wallet, request a funding address, and send the exact amount from that wallet.
7. Verify webhook delivery and update your internal records from the webhook payloads.