Skip to main content
Hypermid has two environments. They share one hostname — https://server.hypermid.io — and are told apart entirely by the key you send.
There is no sandbox.hypermid.io. If you find yourself building a base-URL switch, you have the wrong model — swap the key, not the host.

​
Why the key and not the URL

A separate hostname makes the environment a property of your configuration, and configuration is exactly what gets copied wrongly between deploys. The usual failure is a staging box pointed at a production URL with a key that happens to work. Binding the environment to the key removes that class of mistake. The confinement is enforced server-side on the key itself, so:
  • A sk_test_ key asking for a mainnet chain is rejected. It cannot move real money regardless of what it requests.
  • A sk_live_ key asking for a testnet chain is rejected too, which catches the reverse mistake — a test config that quietly reached production.
The error says which direction you hit, because the two need opposite fixes:

​
What sandbox actually runs on

Three real public testnets. Nothing is simulated — these are genuine chains with genuine block times, so settlement takes as long as it really takes.

Base Sepolia

Chain id 84532. Same-chain swaps and cross-chain both available.

Sepolia

Chain id 11155111. Same-chain swaps and cross-chain both available.

BNB Smart Chain Testnet

Chain id 97. Cross-chain enabled; no same-chain swap router.
You will need testnet gas and testnet tokens from the usual public faucets; we do not mint them for you.
The catalog endpoints are environment-aware. Called with a sandbox key, /v1/chains and /v1/tokens return only these three chains and their tokens — even if you explicitly ask for mainnet. So a picker built against the catalog is automatically correct in both environments with no branching on your side.

​
Fiat in sandbox

Card and bank payments work in sandbox, but they need separate onramp credentials from your production ones — they are different tenants at the provider, with different merchant accounts behind them. Until sandbox onramp credentials are configured on your account, fiatEnabled comes back false on every session and the fiat option simply does not appear. That is the intended signal, not an error. Ask support@hypermid.io to set them up.

​
Moving to production

1

Build and test entirely on sandbox

Every product works there. There is nothing you can only learn in production except real liquidity.
2

Ask for production access

Email support@hypermid.io. Live keys are issued only once your account is approved.
3

Swap the key

Change sk_test_… to sk_live_… in your server config. That is the entire migration — the host, the paths, the payloads and the webhook format are identical.

​
Configuration is per environment

Everything your key resolves to is scoped the same way the key is. Register a webhook endpoint with a sk_test_… key and it belongs to sandbox: it receives sandbox completions only, and a live key can neither see it nor read its signing secret. The reverse holds too. That makes the endpoint list depend on which environment you configure: sandbox endpoints receive sandbox completions only, and production endpoints receive production completions only.
A new sandbox starts with no endpoints even if production has several. Configuration never crosses between environments, so there is nothing to inherit — register the sandbox one explicitly.
Fee overrides work the same way: your sandbox Hypermid fee and developer fee are set independently of production. A partner Hypermid override replaces the global rate outright; the developer fee defaults to 0, is limited to 0–100 basis points, and is added on the same base amount. The checkout payout allowlist is scoped too. A sandbox checkout may only pay a recipient allowlisted for sandbox, so testing on a testnet no longer means adding a testnet address to the list production pays out to.
The allowlist fails closed, per environment. A partner allowlisted before this existed has those entries as LIVE, and an empty sandbox list — so the first sandbox checkout is refused with RECIPIENT_NOT_ALLOWLISTED until a sandbox recipient is added. That is the intended direction for a control whose job is to stop funds reaching an address you did not name.
Add a sandbox recipient through Payout addresses in the partner portal. The portal sends an emailed verification code for the exact change; enter it before the recipient is added. Select sandbox before starting: the same control manages a separate production allowlist.
The environment comes from the key, never from the address or the chain. A live key adding a testnet address still writes a production entry — which will not satisfy a sandbox checkout, and is not what you want on the list your real payouts are checked against. Use the key for the environment you are configuring.
Still branch on the session you receive before crediting anything. Scoped endpoints mean a sandbox completion cannot reach your production URL, but a handler that serves both environments must tell them apart itself — a sandbox completion and a real one are the same shape.