Sandbox Testing

What the sandbox is

https://sandbox.rasto.co with an sk_test_ key serves the same endpoints, objects, statuses, and signed webhooks as live. Wallets and on-chain deliveries run for real on testnets. The parts with no testnet (bank rails, verification decisions, and exchange rates) are simulated, and you drive them through endpoints under /api/sandbox/*. Each one mirrors the resource it acts on, so POST /api/sandbox/virtual_accounts/{virtual_account_id}/deposits reads like the virtual account path with sandbox in front.

On the live host every simulator returns 403 sandbox_only.

Sandbox and live, precisely

Sandbox and live keys, wallet keys, and webhook endpoints are separate, so nothing you register in sandbox carries over to live.

Verification decisions

You make the verification decision in sandbox. After a submit, the endorsement sits pending until you decide, and the decision applies to the customer's latest submitted review. The simulator runs the same decision path a real review takes, so statuses, requirement buckets, and webhooks behave as they do in live.

curl -s $BASE/api/sandbox/customers/cus_.../verification_decisions \
  -H "Api-Key: $KEY" -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{"decision": "approved"}'

The call returns the decided verification round. You can also decide an approved endorsement, which rehearses the review asking for more, or refusing the customer, after approval.

Two refusals apply:

• 400 verification_not_started: the customer was never submitted. Call POST /api/customers/{customer_id}/verifications first.
• 400 verification_not_under_review: no review is running, for example while the endorsement is in issues. Answer the ask with a PATCH, which resubmits, then decide again.

Document reading

At submit, sandbox reads every document as fixed sample values, for an individual, a business, and each controller alike. The reading fills only fields you left empty, as in live.

A business created without business_kind therefore reads as a corporation, and the submit asks for a corporation's documents. Send business_kind to rehearse another legal form's list.

Sandbox reading never finds a problem with a document, so the document checks only refuse in live.

Treasury funding

Deliveries come from prefunded inventory, and the sandbox treasury starts empty. Fund the asset and chain you are testing first.

curl -s $BASE/api/sandbox/treasury/deposits \
  -H "Api-Key: $KEY" -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{"asset": "usdc", "chain": "solana", "amount": "10000"}'

Without it, a deposit waits in orchestrating for inventory, as it would in live during an inventory gap, for at most one hour. After that it stays in orchestrating for our team to resolve, so fund first.

Bank deposits

curl -s $BASE/api/sandbox/virtual_accounts/va_.../deposits \
  -H "Api-Key: $KEY" -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{"amount": "100.00", "sender_name": "ANA SILVA", "remittance_info": "invoice 42"}'

The deposit arrives on the account's primary rail, or on the payment_rail you name (one of the account's payment_rails), and runs the real pipeline: deposit, conversion, payout, with every webhook. Assert on the conversion's fee_lines and delivered_amount in your integration tests.

Magic amounts

Specific amounts trigger the failure paths.

For the two magic amounts, no conversion runs.

Wallet deposits

Wallets have no simulator. Sandbox wallets live on Solana devnet, so you fund one by sending devnet USDC to its address, from a devnet faucet or any devnet wallet. The sandbox mint is in the Signing Guide. wallet_transaction.created (with kind: "deposit") fires when the deposit lands, and balances are read from the chain, as in live.

A complete test checklist

When all five pass in sandbox, work through Going Live.