Skip to main content
Both Rach products have a sandbox and a production environment. You don’t change your integration to switch — you swap the API key.

​
Payments sandbox

test_sk_ keys use testnet addresses — no real funds move and no on-chain confirmations are required. The environment is stamped onto every checkout and wallet operation at the moment the request is authenticated, so it can’t drift mid-flow.

​
What the Payments sandbox does not cover

WaaS transfers are live-only. Creating wallets, deriving addresses and reading balances all work on a test key, but POST /wallet/{id}/transfer is refused with 400 in test mode. Build the send path against a live key with small amounts.
Only some networks have a testnet configured. On a test key you get ETH, BSC, POL, SOL, TRX (USDT only), BTC, LTC and BCH — and BASE, ARB, AVAX, CELO and XRP are live-only. Asking for an asset your environment has not configured is refused with … is not configured for this environment. GET /wallet/assets answers both questions for the key you are holding: it lists that environment’s assets and reports transfers_enabled. Read it at startup instead of hard-coding a chain list.

​
CaaS sandbox

rach_sk_test_ keys put B2B mutations in test mode. Supported mutations are simulated without live on-chain execution; unsupported mutations are refused with SANDBOX_UNSUPPORTED. Simulator responses do not establish that every live validation has run. Reads pass through to their normal handlers and are not backed by a separate persistent sandbox datastore.

​
Two switches, either one is enough

CaaS gives you a second, account-wide switch alongside the key:

The key switch

Use a rach_sk_test_… key. Per-credential, so one service can be live while another is sandboxed. This is the normal way to build.

The account switch

PUT /v1/dashboard/account/mode with test. Covers your whole business at once, whatever key is presented.
If either switch says test, mutating requests use test behavior. auto — what every account starts as — simply defers to the key.
GET /v1/dashboard/system/mode reports your effective mode. Every simulated response also says so in its own body, so if you’re unsure what just happened, the response already told you.

​
Sandbox activity never reaches your dashboard

Wallet-provisioning and escrow-create simulators store no customer wallet or deal. They return deterministic synthetic addresses, not funded custody wallets, and those simulated records will not appear in your dashboard. Never pay a simulated address. That’s deliberate: a test key cannot pollute your production data. But it does mean your dashboard and your sandbox calls show different customers, and neither is broken. Escrow simulation is not a complete lifecycle sandbox: reads cannot fetch a simulated deal, release/refund simulations skip the pending state, and no deposit or settlement webhooks are emitted. See the escrow limitations.

​
Going live

1

Build against sandbox

Wire up your integration end-to-end with the test_* key.
2

Swap the key

Confirm product and rail enablement, complete the required acceptance checks, then use a live key with an account mode that permits live execution. Escrow also requires the agreed pilot prerequisites; swapping a key does not establish production readiness.
Use the same base URL in both environments — only the key changes.