Simulators
SET API, SET Merchant API and SET Direct Deposit API · Staging only · Updated 2026-11-10
The provider's sandbox cannot move money, complete a hosted verification or send events. SET's staging host therefore adds simulators: calls that stand in for something outside SET, such as a bank transfer, a payee's verification or a payment on chain. A simulator gives the same answers and events production would give.
Every simulator answer says "Sandbox: simulated" and carries sandbox: true. No money moves. In production every simulator answers 404.
SET Direct Deposit API
| Call | Stands in for |
|---|---|
POST /api/partner/sandbox/cash_out_addresses {chain?, plan?} | A payee who set up a Cash-Out Address. You get an address that takes your payouts, with no bank behind it, to quote, check, reserve and pay. Up to 25 per sandbox |
POST /api/partner/sandbox/payouts {chain, address, amount} | Your USDC reaching a payee's Cash-Out Address. It carries a simulated depositTxHash, so you can set your reference on it and see a payout intent paid |
POST /api/partner/sandbox/payouts/{id}/advance | The bank leg: payment_submitted, then payment_processed |
POST /api/partner/sandbox/payouts/{id}/return | The payee's bank refusing the payment: returned |
POST /api/partner/sandbox/unknown_sender | A payout from a wallet nobody registered: payout.unknown_sender |
POST /api/partner/sandbox/address_deactivated | An address that stops taking payouts: address.deactivated |
POST /api/partner/sandbox/payments {payeeId, amount} | Your USDC reaching the wallet SET created for a payee: payable_payment.in_wallet, under a simulated txHash |
POST /api/partner/sandbox/payments/batch {batchId} | One multisend paying a whole batch, as a Safe's would. Each item's reference is set |
Report a simulated payment as you would a real one. POST /api/partner/payments, or POST /api/partner/payments/batch, with the simulated txHash answers the payments it recorded.
SET API and SET Merchant API
| Call | Stands in for |
|---|---|
POST /v1/sandbox/customers/{id}/approve | The customer completing KYB or KYC |
POST /v1/sandbox/deposits, then …/{id}/advance | A bank transfer into a virtual account, step by step |
POST /v1/sandbox/cash_out_payments, then …/{id}/advance | Stablecoin into a Cash-Out Address and its bank payout |
POST /v1/sandbox/conversion_payments, then …/{id}/advance | A payment into a Conversion Address |
POST /v1/sandbox/static_memo_deposits, POST /v1/sandbox/static_template_transfers | A payment into a static memo or template |
POST /v1/sandbox/payouts/{id}/advance | A payout moving on: funds_received, payment_submitted, payment_processed |
POST /v1/sandbox/scenarios | Rare outcomes, such as a rejection, a request for information or a return (Sandbox scenarios) |
A simulated wallet balance
A simulated deposit into a virtual account that settles to a custodial wallet (settleTo: { "wallet": … }) fills that wallet on staging. GET /v1/wallets/{id} shows it as simulatedBalance: the simulated deposits delivered to the wallet, less the simulated payouts drawn on it. Payouts and payout batches draw on it as they would on a real balance. A payout it covers is simulated too: it starts at funds_received, and you move it on with POST /v1/sandbox/payouts/{id}/advance. The same dollars are never drawn twice: a second batch the balance cannot cover answers 409 balance_too_low.
What is never simulated
- A Safe's signature. SET checks a contract wallet's signature by asking the contract on chain (EIP-1271). On staging, the Payout Safe recipe registers an ordinary wallet instead, and its proof reads
eoa. - Production. No simulator exists there. A test key is refused by production.
A real payment of test USDC on Base Sepolia, from a wallet you registered, can still be reported on staging. SET reads it from the chain, as in production.