The New Sandbox

Test the full onboarding and payment lifecycle with automatic verification, funded test wallets, simulated fiat deposits, and signed webhooks. These features apply only to sandbox. All balances and transfers are test-only and have no monetary value. Production behavior is unchanged.

Use the sandbox dashboard or https://orchestration.seismictest.net/api with your sandbox credentials.

Supported networks and assets

• Base Sepolia only for the initial release: chain ID 84532. The dashboard labels this network Base Sepolia (testnet). Sandbox API requests accept either base or base-sepolia for the same rail. Responses continue to use base. The base-sepolia input alias is sandbox-only.
• Standard ERC20 test USDC for crypto payments; ETH for gas. Read the token contract and account address from API responses instead of hardcoding them.
• Ethereum Sepolia, Ethereum mainnet, Polygon, Solana, USDT and Seismic transactions are not enabled in this phase.
• Standard ERC20 balance reads need no decryption key. Account funding remains subject to limits and available test reserves.

Organization settlement tokens

Configure a token once for each chain and currency; new accounts inherit the organization selection. Organizations without a selection keep the default token. Existing accounts and payments retain their original token contract. A conflicting selection is rejected and requires an account migration; configuration does not rewrite existing accounts.

• GET /v0/sandbox/settlement-assets/catalog lists enabled contracts and their funding capabilities.
• GET /v0/sandbox/settlement-assets lists your organization's explicit selections.
• PUT /v0/sandbox/settlement-assets selects a contract. Organization owner or admin access is required.

const tokens = await client.sandbox.settlementTokenCatalog();
const selected = tokens.find((token) => token.contract_address.toLowerCase() === desiredContract.toLowerCase());
if (!selected) throw new Error("Token is not enabled");
await client.sandbox.configureSettlementAsset({
  chain_id: selected.chain_id,
  currency: selected.currency,
  contract_address: selected.contract_address,
});

If automatic_funding is false, fund the account externally using the exact contract returned in the catalog. Circle USDC still supports fiat-to-token test payouts, subject to available test reserves; other tokens without automatic funding do not. Test reserves of Circle USDC are limited, so keep Circle USDC test payments small, for example 1 to 5 USDC. Organizations that select Circle USDC can make payments from 1 USDC; rail minimums, such as the wire minimum, still apply. If reserves run low, a fiat-to-token payment stays in progress and completes once they are restocked. Read funding_instructions before testing. Transfers between different token contracts require conversion and are rejected; selecting two contracts does not create a swap route.

These endpoints are available only in sandbox.

Customer onboarding

• Create draft individuals and businesses, save profiles and attach synthetic test documents using the normal API and dashboard.
• Eligible KYC and KYB submissions are approved immediately on explicit submission by default. Creating or saving a draft does not submit it.
• Set customer sandbox_auto_approve_kyc to false to exercise randomized background progression instead. Both modes emit status webhooks; webhook delivery is asynchronous even when approval is immediate.
• Profile, document, jurisdiction and account-eligibility validation still apply. Automatic approval does not bypass required information.
• Approval also sends customer.virtual_account_approval.changed for USD (status: approved, banks: ["PORTAGE_BANK"]), so an integration that requests the USD virtual account on that event can be tested end to end.

Test a rejection

To exercise the rejected path automatic approval never reaches, reject a customer whose KYC or KYB was submitted:

• POST /v0/sandbox/customers/{id}/kyc/rejection

curl --fail-with-body -X POST \
  "https://orchestration.seismictest.net/api/v0/sandbox/customers/$CUSTOMER_ID/kyc/rejection" \
  -H "Api-Key: $SANDBOX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "rejection_reason": "Proof of address is unreadable"
  }'

await client.sandbox.rejectKyc(customer.id, {
  rejection_reason: "Proof of address is unreadable",
});

rejection_reason is optional. Status webhooks move the customer through submitted and under_review to rejected, carrying the reason, as a real decision would. Edit the profile and submit again to have it approved. A customer whose verification hasn't been submitted returns 404.

Fiat accounts and corridors

• USD virtual accounts use the Portage Bank profile with ACH, wire and SWIFT.
• EUR virtual accounts use Banking Circle's German branch with SEPA.
• GBP virtual accounts use ClearBank with BACS and Faster Payments.
• AED virtual accounts use the Zand Bank profile with NPSS.
• Virtual accounts include account_holder.name when a recorded holder or customer-profile name is available. Existing accounts receive the same representation on reads; no account replacement is required.
• Register external bank accounts using the returned currency, rail and field requirements. Supported external corridors include ARS through COELSA and BRL through PIX or TED; these do not introduce ARS or BRL virtual accounts.
• Organization permissions and transaction-document requirements still apply. Bank details in sandbox are for testing, not instructions for real transfers.

Read the catalog and eligibility responses for the accounts and directions available to your organization; do not assume every production corridor is enabled.

Test funding

• Eligible new Base Sepolia crypto accounts receive test USDC and ETH gas, subject to limits. Virtual wallets and registered external EVM addresses are supported; outgoing transfers from external wallets require the owner's key.
• Active fiat virtual accounts support simulated deposits through the dashboard, API and TypeScript client. External bank accounts are not fiat balance ledgers and cannot receive these simulated deposits.
• Deposits use positive decimal currency amounts, up to 1,000,000 per request with at most two decimal places. The currency must match the account.
• Reuse the same idempotency key and body on retry. Conflicting reuse is rejected; replaying a deposit does not create a second credit or fund a later payment.
• Deposits can advance a uniquely matching waiting payment when sufficiently funded. Deposits remain as balance unless matched to a payment or swept by configured automatic liquidation. payment_advanced is not proof of settlement.

Add a simulated fiat deposit

• POST /v0/sandbox/accounts/{id}/deposits

curl --fail-with-body \
  "https://orchestration.seismictest.net/api/v0/sandbox/accounts/$ACCOUNT_ID/deposits" \
  -H "Api-Key: $SANDBOX_API_KEY" \
  -H "Idempotency-Key: sandbox-deposit-001" \
  -H "Content-Type: application/json" \
  --data '{
    "amount": "100.00",
    "currency": "USD"
  }'

This endpoint is authenticated, organization-scoped and unavailable in production. POST /v0/deposits is not a deposit-creation endpoint; use the sandbox route above and read the resulting record through GET /v0/deposits.

New simulated deposits report a test source.rail: ach for USD, sepa for EUR, fps for GBP, and npss for AED. These are simulated bank credits, not on-chain transfers, so they do not include a blockchain source.chain or transaction hash. Historical credits may omit source details when none were recorded.

Choose a deposit currency

On the sandbox Deposits page, choose a currency, then an eligible active virtual account or waiting payment. Enter an amount for account deposits; payments use the full quoted amount and currency. If there is no eligible target, create an account or accept a fiat-to-crypto quote first. Available accounts and payment corridors still depend on your organization's permissions.

The selector reads its supported currencies and deposit capabilities from:

• GET /v0/sandbox/deposit-currencies

const currencies = await client.sandbox.depositCurrencies();

Each entry includes currency, virtual_account_deposits, and order_funding. Virtual-account deposits and direct payment funding are separate operations; external bank accounts do not hold a simulated deposit balance.

Simulate funding of a fiat payment

Create and accept a fiat-to-USDC quote, then select the waiting payment on the Deposits page, use Simulate payment funding on the payment page, or call:

• POST /v0/sandbox/orders/{id}/funding

curl --fail-with-body -X POST \
  "https://orchestration.seismictest.net/api/v0/sandbox/orders/$ORDER_ID/funding" \
  -H "Api-Key: $SANDBOX_API_KEY" \
  -H "Idempotency-Key: sandbox-funding-001"

const funding = await client.sandbox.fundOrder(order.id, {
  idempotencyKey: "sandbox-funding-001",
});

This simulates receipt of the full quoted fiat amount, up to 1,000,000 with at most two decimal places. It does not credit a virtual account or transfer real money. Only unfunded fiat-to-crypto orders in your organization are eligible. The currency cannot be changed after accepting a quote.

Reuse the same idempotency key on retries. The same key returns the original receipt; another key cannot fund the order again. Funding acceptance is not settlement confirmation: follow the normal payment status and webhooks, or read GET /v0/customers/orders/{id} for completion and the test transaction hash. Settlement remains subject to available test reserves.

Automatically settle deposits to crypto

USD, EUR, GBP and AED virtual accounts support automatic liquidation to an eligible USDC account on Base Sepolia. Register the crypto destination for the same customer, then check GET /v0/customers/{id}/liquidation-destinations?currency={currency} for the available destinations.

USD, EUR and GBP virtual accounts require a liquidation target when they are created, as in production. AED accounts may be created without one; their deposits remain as balance until a target is set.

Create the virtual account with a liquidation target:

{
  "currency": "EUR",
  "liquidation": {
    "account_id": "<crypto-account-id>"
  }
}

For an existing account, use PUT /v0/accounts/{id}/liquidation with account_id in the body. Simulate a deposit using the endpoint above: the available balance is converted to USDC at the current reference market rate and settled automatically, without a client quote or accept call. Processing is asynchronous; the worker normally checks for deposits every 60 seconds, followed by settlement and webhook delivery. The conversion runs at the reference rate with no processing fee, so a USD deposit converts to USDC 1:1. A USD account's developer_fee_bps is deducted from each liquidation before conversion, as in production, and is included in the liquidation's fee. For a 200.00 USD deposit:

• With no developer_fee_bps, 200.00 USDC is settled and fee is 0.
• With developer_fee_bps: 50, 199.00 USDC is settled and fee is 1.

Existing verification restrictions and minimum payment amounts still apply.

Follow GET /v0/liquidations?account_id={id} and the account.deposit_liquidated webhook, then verify the transaction receipt. payment_advanced: false is expected when no existing payment matched; it does not mean automatic liquidation failed. Use the completed liquidation and its transaction hash to confirm settlement. Replaying a deposit does not credit it again. On AED accounts, DELETE /v0/accounts/{id}/liquidation disables future automatic sweeps; a payment already in flight still completes. Automatic liquidation cannot be disabled on USD, EUR or GBP accounts.

Payments and recovery

A completed payment crediting a sandbox fiat virtual account also creates a deposit record for the credited amount and destination rail. Retrying settlement does not create another deposit or credit the balance again. External bank accounts do not have virtual-account deposit ledgers.

• Request a quote, accept it, follow the funding instructions, and track the resulting order through settlement. Quotes itemize a simulated processing fee under fees, and the quoted destination amount is already net of it. Sandbox exchange rates follow reference market rates refreshed about hourly, so new quotes move over time; a quote keeps its rate until it expires. If the reference rates cannot be refreshed for six hours, sandbox falls back to fixed test rates. Sandbox rates and fee amounts are test values, not production pricing.
• Test crypto-to-fiat and fiat-to-crypto. Each payment requires a crypto source or destination. To test fiat-to-fiat through crypto, use two separate payments and fund the second only after the first completes.
• Crypto-source payments require the specified test USDC on Base Sepolia. A wallet balance alone does not fund an externally signed payment; send to the returned order funding address. For virtual wallets, follow the accepted order's flow rather than sending a duplicate manual transfer.
• Fiat settlement is simulated. Fiat-to-crypto completion can be verified with the destination's on-chain receipt.
• Payment pages refresh nonterminal status automatically. Balance refresh and deposit history are available through the API and dashboard.
• Cancellation, overpayments and late deposits have recovery paths. Track any refund separately: payment completion does not prove that its refund completed.

Webhooks and integration contracts

The same authentication, request validation, account requirements, quote/order schemas and signed webhook patterns are used across environments. Verify webhook signatures, handle retries and reconcile events with current API state. Sandbox approval and settlement timing do not predict production timing, prices or eligibility.

• GET /v0/rails
• GET /v0/currencies
• GET /v0/eligible-rails
• POST /v0/quotes
• POST /v0/quotes/{id}/accept
• GET /v0/orders/{id}
• GET /v0/accounts/{id}/balance
• POST /v0/accounts/{id}/balance/refresh
• GET /v0/deposits

See the API reference, quote acceptance guide and webhook verification guide for complete request bodies and examples.

Existing customers, accounts and balances

• Approved verification status is carried over with customer identities; pending or rejected customers are not indiscriminately approved.
• Fiat virtual accounts retain their currency, bank details and verified opening balances. External fiat account details are preserved without creating artificial fiat balances.
• Legacy virtual crypto accounts require successor wallets with new addresses. Update stored references using the returned mappings and account details. Funding an old address does not make its signing key available.
• The migration targets verified snapshot-equivalent test USDC balances and separate ETH gas funding on Base Sepolia. Eligible external EVM addresses remain unchanged while their network/token configuration must reflect Base Sepolia.
• Unknown balances, unsupported wallet shapes and unresolved mappings must be reconciled before the affected accounts are activated; they are not silently treated as zero.

Consult the transition and compatibility guide before reusing existing accounts. Keep sandbox credentials, signing secrets, account identities and test assets separate from production.

Later phases

Seismic testnet with standard ERC20 USDC will be enabled separately, with sUSDC as its gas token. A later transition introduces SRC20, Seismic's shielded equivalent of ERC20, where balances are hidden and authorized signed reads are required.

SRC20 requires additional integration code. Code samples, worked examples and a transition period will be provided before activation. Neither Seismic transactions nor the SRC20 payment-asset transition is part of this initial phase.