Skip to main content
OMS runs in two isolated environments: sandbox and production. Sandbox is a full copy of the API for building and testing against, with no real money and no mainnet settlement. You select an environment by its base URL and the credentials you send. The request and response shapes are identical, so code you build against sandbox runs unchanged in production.

​
Environments

EnvironmentBase URLCredentials
Sandboxhttps://sandbox-api.polygon.technology/v0.10Sandbox API key and secret
Productionhttps://api.polygon.technology/v0.10Production API key and secret
Credentials are scoped to one environment. A sandbox key never authenticates against production, and the reverse holds too. Request keys for both from the OMS Dashboard. See Get started for the full authentication flow. Two behaviors are specific to sandbox:
  • Endorsements are auto-approved. A customer’s basic, cryptoCustody, and usd endorsements move to ACTIVE without a live KYC integration, so you can exercise fiat and crypto flows immediately. Provisioning still reads the identifying fields, so include them in sandbox as you would in production. See Customer onboarding.
  • Blockchain activity settles on testnets. Every on-chain transaction executes on the equivalent testnet rather than mainnet, described next.

​
Networks map to testnets

In sandbox, keep using the standard network enum values in your requests. You do not change the network (or chain) field between environments. Under the hood, OMS routes every blockchain transaction to that network’s testnet.
Network valueProduction chainSandbox chain
polygonPolygonPolygon Amoy
ethereumEthereumEthereum Sepolia
baseBaseBase Sepolia
solanaSolanaSolana Testnet
A wallet you provision with "chain": "polygon" in sandbox holds funds on Polygon Amoy, and its blockchainAsset.chainId reflects the testnet. Your code still sends polygon. The mapping is automatic and applies everywhere a network appears: wallet provisioning, quotes, transactions, deposit addresses, and virtual accounts. Because these are testnet addresses, a sandbox wallet’s address resolves on the testnet’s block explorer, not on the mainnet explorer. To create inbound on-chain activity for a wallet or deposit address, use the simulation endpoints below rather than moving real testnet assets.

​
Simulating inbound events

Many OMS flows complete only when money arrives from outside the API: cash deposited at a retail location, a bank transfer landing in a virtual account, or crypto sent to a deposit address. Sandbox has no real counterparty to send those funds, so OMS exposes simulation endpoints that trigger the inbound leg on demand. Each simulation drives the same downstream behavior as the real event. It auto-creates the transaction, advances the transaction lifecycle, and fires the same webhook events. That lets you test reconciliation and webhook handling end to end without waiting on an external deposit.
FlowWhat you can simulateGuide
Cash-inAuthorize a barcode load, then commit or void the authorized cash deposit against a cash-in codeCash-in
Deposit addressAn inbound crypto deposit to a provisioned deposit addressDeposit addresses
Virtual accountAn inbound bank deposit to a virtual accountVirtual accounts
Simulation endpoints exist only in sandbox. The same calls against production return an error. For request and response details, see the endpoints grouped under the Sandbox and Simulation tags in the API reference.

​
What’s next

Get started

Request sandbox credentials, authenticate, and run your first transaction.

Webhook events

The delivery envelope and full catalog of events that simulations fire.

Transaction lifecycle

The statuses a transaction moves through, including auto-created ones.

Currencies and rails

Supported assets, networks, and payment rails across OMS.