--- updatedAt: 2026-11-03T11:53:26.000Z agentTools: projectIndex: https://due.readme.io/llms.txt --- # Sandbox configuration Sandbox-only commands and simulation utilities for testing KYC/KYB, fiat pay-ins, crypto funding, webhooks, and transfer flows. 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. ## Sandbox KYC In sandbox, KYC is simulated by Due and does not go through Sumsub. As a result: * `POST /v1/kyc/session` does not return a usable Sumsub SDK access token in sandbox. You can test the Sumsub SDK only in production. * The link returned by the same call opens Due’s sandbox KYC page, where you can approve the applicant or simulate Sumsub review events. It does not open the Sumsub verification flow. * Applicants approved in sandbox are not reviewed against real documents. Use production for end-to-end verification testing. KYC sharing from your own Sumsub account is not affected and continues to use Sumsub’s sandbox. ## Stub KYC applicant approval In sandbox, you can simulate an applicant review in Due and mark the applicant as approved without a Sumsub review. 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: ```http POST /dev/sumsub/applicants/{{accountId}}/approve ``` Replace `{{accountId}}` with the sandbox account ID. 2. Use the sandbox approval tool: ```text 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: ```http 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: ```json { "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. `/dev/payin` supports fiat pay-ins only. It cannot simulate crypto funding. ## 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](https://dev.sandbox.due.network/commands/crypto/mint-token). 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. | Flow | Sandbox behavior | Production behavior | | ---------------- | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ | | KYC/KYB approval | You can stub applicant approval with `/dev/sumsub/applicants/{{accountId}}/approve` or the sandbox approval tool. | Approval is determined by the verification review process. | | Fiat pay-ins | You can simulate incoming funds with `/dev/payin`. | Funds must arrive through the external bank or payment rail. | | Crypto legs | Fund the registered sender wallet's transfer address yourself on the corresponding sandbox chain. | Funds must arrive on the corresponding production chain. | | Webhooks | Use simulated actions to trigger and validate webhook handling. | Webhooks are triggered by real production events. | ## 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.