Skip to main content
POST
Create a sandbox deposit

Overview

This sandbox-only endpoint creates a mock deposit for an existing customer or merchant funding account, or creates or advances a bridge simulation. Set funding_account_scope to select the type of simulation:
  • BRIDGE: Creates a bridge receipt or advances its simulated payout or refund. Use bridge_id, not funding_account_id. See Bridge simulations.
  • CUSTOMER (default): Runs the simulated deposit through the customer funding-account settlement and webhook flow.
  • MERCHANT: Creates a merchant funding deposit. Include currency: NGN and amount to credit a specific amount to withdrawal_balance_ngn. Include currency: USD and an optional amount to credit withdrawal_balance_usd. Omitting both preserves the legacy 10 USD simulation.
For customer funding accounts, Daya runs the simulated deposit through the same processing pipeline as a real deposit:
  • Deposit creation
  • Settlement to internal balance, onchain payout, or NGN payout
  • Webhook dispatch
You can also pass scenario to trigger a specific sandbox lifecycle outcome. Use scenarios when you need to confirm your app handles specific deposit states without waiting for the sandbox processor to produce them naturally. For a customer funding account, create the receive instruction with /v1/funding-accounts, then pass its id. For merchant funding, call GET /v1/merchant/funding, pass data.id, and set funding_account_scope to MERCHANT.
This endpoint is available only in sandbox. Calls outside sandbox return 403 or 404.
For end-to-end guidance (recommended flow, what to validate, and common flagging scenarios), see Sandbox testing.

Authentication

string
required
Your merchant API key
string
Required when funding_account_scope is MERCHANT or BRIDGE. Use a unique value for each simulated deposit and reuse the same value when retrying that request. Retries with the same value resume the original deposit instead of creating another. Bridge advances keep the same deposit ID; see the behavior below.

Request Body

string
Required for CUSTOMER and MERCHANT; omit for BRIDGE. Funding account ID to simulate a deposit for. For customer funding, use the id returned by /v1/funding-accounts. For merchant funding, use data.id from GET /v1/merchant/funding.Example: 6b0e8400-e29b-41d4-a716-446655440000
string
default:"CUSTOMER"
Selects the funding account kind. Allowed values are CUSTOMER, MERCHANT, and BRIDGE. Omit this field for existing customer funding-account simulations.
string
Merchant funding simulations only. Allowed values are NGN and USD. NGN credits withdrawal_balance_ngn; USD credits withdrawal_balance_usd. Omit this field to preserve the legacy USD simulation.
string
For MERCHANT, a positive decimal amount in the selected currency. Required when currency is NGN; optional for USD, which defaults to 10 when omitted. NGN supports at most two decimal places and USD supports at most six. For a BRIDGE create, this is an optional positive decimal string with at most six digits before and after the point; it defaults to the bridge estimate and can test below-minimum or over-limit receipts. Omit it on advance. CUSTOMER does not accept this field.
string
Optional sandbox lifecycle outcome to trigger.CUSTOMER and MERCHANT values:
  • DEFAULT
  • PROCESSING
  • COMPLETED
  • REQUIRES_REVIEW
  • FAILED
Omit this field to use the default processing flow for the selected scope. For BRIDGE, use the additional scenarios below; its default leaves the payout waiting.
string
Optional linked payout outcome for customer funding accounts. Allowed values are DEFAULT, PROCESSING, SETTLED, and FAILED. This field is supported only when funding_account_scope is CUSTOMER.
string
Required UUID for BRIDGE. Must identify your sandbox bridge request.
string
BRIDGE advance only. The existing deposit must belong to your merchant and the named sandbox bridge. Omit to create a receipt.
string
BRIDGE create only. USDT or USDC; defaults to the request asset. WRONG_ASSET defaults to the other stablecoin.
string
BRIDGE create only. POLYGON, BSC, SOLANA, or APTOS; defaults to the request’s deposit chain. WRONG_CHAIN defaults to its destination chain.

Request Examples

Response

Returns a confirmation message and the simulated deposit status. For customer funding accounts, use /v1/deposits and webhook events to track the deposit.
  • message: Human-readable status message
  • deposit_id: Created deposit ID
  • status: Current deposit status
  • scenario: Scenario that was applied, if provided

Customer funding lifecycle outcomes

Use scenario to test the state machine in your integration:
Scenario outcomes are for testing a specific lifecycle state in sandbox. PROCESSING and COMPLETED still use the funding account’s active settlement destination, so the funding account must include any required rate_id, destination wallet, or destination bank details. To test the production-like settlement processor and any natural intermediate states, omit scenario.

Merchant funding outcomes

Merchant funding simulations do not use the customer settlement destination or payout_scenario. An NGN simulation directly credits the merchant’s NGN withdrawal balance and requires an active sandbox NGN merchant funding account.

Bridge simulations

First create a sandbox bridge with type: TEMPORARY and asset: USDT. Bridge simulations require both write and withdraw scopes. Send X-Idempotency-Key for each request. Use the bridge chain list; all payouts and refunds on this endpoint are simulated. For create, send funding_account_scope: BRIDGE, bridge_id, and optionally amount, asset, chain, and scenario. For advance, send only the scope, bridge_id, deposit_id, and scenario. Do not send funding_account_id, currency, or payout_scenario for either bridge operation.
Create a processing bridge deposit
Example 202 response for an eligible deposit:
Advance that deposit
Successful advance returns 202, message Sandbox deposit advanced., the same deposit_id, and the current status and selected scenario. An omitted or DEFAULT scenario is omitted from the response. 202 means the simulation was handled; read its status rather than assuming success. Scenarios follow the amount and timing rules. A deposit that needs review stays in review, even when COMPLETED is requested. Wrong-asset and wrong-chain simulations do not produce a bridge deposit or merchant webhook, and cannot be advanced. To test REFUNDED, contact support@daya.co to prepare a deposit with a refund in progress. Advance a PROCESSING deposit to COMPLETED, FAILED, or UNCERTAIN_PAYOUT. Repeating an applied outcome returns the current state. Invalid transitions return 409 without changing the deposit. Use a unique key for every new simulated deposit, even when repeating a test later. Retry with the same key and body to avoid a duplicate deposit. Changing receipt details or the scenario under a create key returns 409. When advancing, keep the same deposit ID on retries. Responses show the current state rather than a replay of an earlier response. Track results through bridge deposits and bridge events.

Error Responses

This endpoint may return:
  • 400: Invalid request
  • 401: Unauthorized
  • 403: Missing required scope, restricted access, or not available outside sandbox
  • 404: Funding account, bridge request, or deposit not found; endpoint unavailable outside sandbox
  • 409: Invalid transition or conflicting simulation
  • 503: Bridge simulation temporarily unavailable
  • 500: Internal server error

Next Steps

Get merchant funding

Get the merchant funding account ID and Base address

Webhooks Overview

Verify your webhook handling with sandbox events

Sandbox testing

Recommended end-to-end sandbox flow + common flagging scenarios