Crypto Payment Gateway Sandbox 2026: We Tested 9
We called nine crypto payment gateway sandboxes on 28 September 2026. Four run on real testnet, three only simulate, and two document none at all.
Key Takeaways
- Nine gateways, four real testnets. A crypto payment gateway sandbox from CoinGate, BitPay, Coinbase Business or a self-hosted BTCPay Server puts your test invoice on an actual chain. NOWPayments and OxaPay simulate. Cryptomus has no sandbox but does replay webhooks. Plisio and BlockBee document neither.
- The NOWPayments sandbox is still live and its own docs disown it. The collection header reads that since 2025 it is no longer actively maintained or kept in sync with Production, and that it remains available on an as-is basis. It answered HTTP 200 for us anyway.
- We measured the drift nobody else has. On 28 September 2026 CoinGate's sandbox currency endpoint returned 29 currencies against production's 68 — 43 missing, and 4 present in the sandbox that production does not list, including the retired MATIC ticker.
- A simulated sandbox cannot fail the way a chain fails. Confirmation timing, wrong-network sends, dust-level underpayments and a transaction stuck below the fee floor are the failures that reach your support inbox, and none of them exist where there is no blockchain.
- No sandbox does not mean no test. Cryptomus publishes test-webhook endpoints that will post any of 11 payment statuses to your callback URL and write nothing to its database — which is the single most useful thing a sandbox does.
Table of Contents
- Which crypto payment gateway sandboxes exist
- Testnet or make-believe: the distinction that decides what you catch
- NOWPayments' sandbox is live and disowned
- We diffed CoinGate's sandbox against production
- What each sandbox lets you force
- The gateways with no sandbox at all
- Funding the testnet side: faucets and their limits
- The test plan we would actually run
- FAQ
Which crypto payment gateway sandboxes exist
You wire the gateway in over a weekend, ship it, and the first real customer underpays by three percent down a code path nothing has ever exercised. The stakes are not hypothetical: of the nine processors we checked, only four will let you reproduce that on a real chain before a customer does it for you, and two publish no test environment at all. This article says which crypto payment gateway sandbox each processor actually gives you, what it can and cannot reproduce, and what to do about the ones that have none. Every row below comes from the company's own developer documentation read on 28 September 2026, and where the sandbox exposes a public endpoint we called it ourselves that day rather than taking the documentation's word for it.
Here is the whole finding in one table.
BTCPay Server is the outlier in that table because you host it, so the environment is whatever you configure; the project also runs a public testnet demo instance if you want to see the invoice flow before committing to a node, with the caveat that its docs make no uptime guarantee for it.
Two things in that table matter more than the yes-or-no column, and the rest of this article is about them: whether the sandbox is backed by a blockchain, and whether it still resembles the production system it is meant to stand in for.
Testnet or make-believe: the distinction that decides what you catch
OxaPay draws the line most starkly: its generate-invoice reference documents a single boolean, sandbox, that you set to true for testing and false for live, on the same endpoint and the same host. Nothing else changes, which tells you exactly how much of the system is being stood in for.
A simulated sandbox hands you a payment object with a status on it. A testnet sandbox hands you an address, and then you have to go and pay it. The second is slower and more annoying, and it is the only one that can fail in the ways that actually cost you money.
Think about what a simulator cannot produce. It cannot leave a transaction sitting unconfirmed for forty minutes because you set the fee too low. It cannot let a customer send USDT on the wrong network to an address that looks right. It cannot deliver a second confirmation after your invoice window has already closed, which is the collision behind most of the cases where a merchant swears the payment never arrived. Those are chain behaviours, and code that has only ever seen a mock will meet them first in production.
Your authentication works, your request bodies are shaped correctly, your callback endpoint is reachable from the outside, your signature verification matches, and your state machine advances when a status changes. That is most of an integration and it is worth having. It is just not the part that breaks at 2am.
So the useful reading of the table above is not four-good-five-bad. It is that the four testnet gateways let you write one class of test the other five cannot, and that if you have picked a simulated gateway you need to plan a small live-money rehearsal before launch to cover the gap.
NOWPayments' sandbox is live and disowned
NOWPayments runs the most complete simulated sandbox of the nine, with its own signup at account-sandbox.nowpayments.io, its own API host, and a case parameter on the create-payment call that decides which flow gets emulated. We called api-sandbox.nowpayments.io/v1/status on 28 September 2026 and it answered {"message":"OK"}, same as production.
It also carries a notice that no third-party guide we found mentions. The first heading of its own sandbox API documentation is Sandbox environment notice, and it says this:
“Since 2025, the Sandbox environment is no longer actively maintained or kept in sync with Production. As a result, API methods, responses, status transitions, and other behavior in Sandbox may differ from the current Production environment. Production should be considered the source of truth for the current API behavior. … The Sandbox environment remains available on an as-is basis.”
That is a fair warning and an unusually honest one, but it changes how you should use the thing. The sandbox is still the cheapest way to see the shape of a payment object and to prove your HMAC-SHA512 signature check against the x-nowpayments-sig header. It is no longer evidence that a status transition you handled correctly in test will arrive the same way in production. Build to the production documentation and use the sandbox for wiring, not for behaviour.
The case field is the part worth knowing. It takes success (the default), common, failed and partially_paid, and the documentation is explicit that in the sandbox you never send any funds — you name the case and the platform emulates the flow, IPN callbacks included.
We diffed CoinGate's sandbox against production
NOWPayments at least tells you its sandbox has drifted. Nobody else does, so we measured one. CoinGate's own environments documentation states that all sandbox operations execute on the testnet blockchain and that sandbox credentials must be generated separately, and its currency list is public and unauthenticated on both hosts, which makes it the one place a sandbox and its production twin can be compared from outside. We pulled both on 28 September 2026:
Forty-three currencies your customers can pay with in production do not exist in the sandbox, including DOGE, BNB, SHIB, ATOM, ARB, AVAX and thirty fiat settlement currencies. An integration that branches on currency — and most do, for decimals, for minimums, for which networks you display — has no way to exercise those branches in test.
The four going the other way are the more telling half. The sandbox lists MATIC, NANO, TUSD and USDT, none of which appear in production's list at all. MATIC is the retired Polygon ticker; production has moved to POL and the sandbox still carries both. That is a snapshot of an environment that stopped being updated at some point and was left running, which is exactly the failure mode NOWPayments documented and CoinGate has not.
Before you trust a sandbox, fetch its public list endpoint — currencies, networks, payment methods, whatever it exposes without a key — and fetch the production equivalent, then diff them. If the two disagree by more than a currency or two, the sandbox is a snapshot rather than a mirror, and you should assume the same is true of behaviours you cannot see from outside.
None of this makes CoinGate's sandbox a bad one. It runs on a real testnet, it needs no merchant verification, and it is the easiest of the nine to get into. It just is not the same system as production, and the gap is now a measured number rather than a suspicion.
What each sandbox lets you force
The reason to want a sandbox at all is usually one specific thing: making a failure happen on demand. Here is how each of the nine lets you do it.
Cryptomus is the odd one out and the most quietly useful. It has no sandbox, but its test-webhook endpoints will post a payload of any status you name straight at your callback URL, and its documentation states that no data is saved to the database and the received webhook is only stored in an array for testing. Eleven forceable statuses against your live integration beats four against a mock, and it costs nothing.
BTCPay Server on regtest is the strongest of the lot for a different reason: you control block production, so you can hold an invoice at zero confirmations for as long as you like and then confirm it on command. If your logic depends on confirmation depth, that is the only environment in this table that tests it properly, and our BTCPay Server setup guide covers getting a node up.
The gateways with no sandbox at all
Two of the nine document no crypto payment gateway sandbox, no testnet and no test mode. We checked both directly rather than inferring from silence.
Plisio publishes its API reference and a Swagger interface, and neither contains a sandbox host, a testnet ticker or a test-mode parameter. Its endpoints are the production ones and there is no documented alternative.
BlockBee exposes an unauthenticated /info/ endpoint that enumerates everything it supports. We called it on 28 September 2026: it returned 19 coin and chain groups — btc, bch, ltc, doge, zec, erc20, bep20, arbitrum, polygon, avax-c, bera, base, optimism, linea, eth, monad, sol, trc20, trx — and not one testnet ticker among them. There is no test chain to address even if you wanted one.
Create a real invoice for the smallest amount the gateway will accept, on the cheapest chain it supports, and pay it from your own wallet. You are out one network fee and you have exercised the genuine code path end to end. Do it twice more: once paying slightly under to trigger the underpayment branch, once letting the invoice expire untouched. Our notes on gateway minimum payment amounts and on how long each invoice window stays open will tell you what those two rehearsals cost and how long the second one takes.
This is worth weighing at selection time, not after. A gateway with no test environment is not disqualified — Plisio and BlockBee both have real merits — but it moves the cost of your first mistake from a faucet to your own balance sheet, and it should be priced into the decision alongside the fee percentage.
Funding the testnet side: faucets and their limits
If you picked one of the four testnet gateways, the next obstacle is getting coins that are worth nothing. Each gateway names the chains it supports in test, and only Coinbase publishes a hard limit on how much you can claim.
Two limits are worth planning around, and both come from Coinbase's own sandbox documentation. Coinbase's 10 USDC per day is generous for building and thin for a load test, and its sandbox also caps refunds at 2.00 dollars specifically to stop you burning testnet funds. Coinbase additionally purges sandbox data after 30 days, so a test suite that asserts against a checkout created last quarter will start failing for reasons that have nothing to do with your code.
BitPay's docs add a neat trick for the Bitcoin side: point your test settlement address at your own testnet wallet and set the payment split to 100 percent BTC, and the coins you spend paying test invoices come back to you when merchant payouts run. The faucet then only has to prime the loop once.
The test plan we would actually run
Whichever of the nine you chose, the same six rehearsals cover the failures that reach support. The environment changes; the list does not.
- Happy path, end to end. Create an invoice, pay it in full, confirm your order flips to paid from the callback and not from a redirect. The customer's browser closing is not a failure you get to lose an order over.
- Underpayment. Send 97 percent. Every gateway handles the shortfall differently and your tolerance logic has to agree with theirs, not with your own assumption.
- Expiry. Create an invoice and ignore it. Then pay it a minute after it lapses and see what you get, because that is the collision that produces a customer who has paid and an order that is cancelled.
- A callback your server rejects. Return a 500 deliberately and watch whether the gateway comes back. Retry policies vary from five attempts in under four hours to forty across six days, which we measured in our comparison of gateway webhook retry rules.
- A forged callback. POST your own endpoint with a valid-looking body and a wrong signature. If it is accepted, everything above is decoration.
- Reconciliation. Kill your app between receiving a callback and committing the write, then confirm a scheduled job catches the orphaned invoice by polling the gateway. No sandbox on this list simulates your own server crashing, and it is the failure no retry policy covers.
Test five, the forged callback. It takes ten minutes, it needs no sandbox, no faucet and no gateway account, and if your endpoint accepts a payload with a bad signature then none of the other five tests are measuring anything — an attacker can mark any order paid without sending a coin. Everything else on this list is about correctness. That one is about whether the integration is safe to have.
Tests one through five run anywhere. Test six is yours alone, and it is the one that makes the other five survivable. If you want the API-level detail behind each, our crypto payment API guide and the developer comparison of the major gateway APIs go a level deeper on request shapes and authentication.
Pick the gateway before you find out how it tests
We track fees, settlement models, supported chains, invoice windows and developer tooling for every processor in the directory, so the test environment is one more column you can weigh before you commit a checkout to it. NOWPayments is the directory's most-used gateway and still runs the most complete simulated sandbox of the nine.
Compare Crypto Payment Gateways →FAQ
Do crypto payment gateways have a sandbox?
Some do and the split is wider than you would guess. Of the nine we checked on 28 September 2026, four run a real testnet environment (CoinGate, BitPay, Coinbase Business and a self-hosted BTCPay Server), two run a simulated one with no blockchain behind it (NOWPayments and OxaPay), one offers webhook simulation but no sandbox (Cryptomus), and two document neither (Plisio and BlockBee). There is no industry default, so check before you pick the gateway rather than after.
Which crypto payment gateway sandbox uses a real testnet?
CoinGate, BitPay, Coinbase Business and BTCPay Server. CoinGate states that all sandbox operations execute on the testnet blockchain. BitPay's test environment runs on testnet4 for Bitcoin and Sepolia for Ethereum. Coinbase Business receives sandbox payments as USDC on Base Sepolia. BTCPay Server is your own node, so you choose testnet or regtest, and regtest lets you mine a confirmation whenever you want one.
How do I get testnet coins to test a crypto payment?
From a faucet for the specific chain, and the gateway's own docs usually name one. BitPay points at coinfaucet.eu and faucet.testnet4.dev for testnet4 Bitcoin and at Infura's Sepolia faucet for Ethereum. Coinbase runs its own faucet in the Developer Platform portal and caps it at 10 USDC per 24 hours. On a BTCPay regtest node you skip faucets entirely and generate coins yourself.
Can I test crypto payments without a sandbox?
Yes, with two techniques. The first is a live invoice for the smallest amount the gateway and the chain will accept, paid from your own wallet on a cheap network, which exercises the real code path at the cost of a network fee. The second is replaying callbacks: Cryptomus publishes test-webhook endpoints that post a payload of any status you name to your callback URL without writing anything to its database.
Is the NOWPayments sandbox still usable in 2026?
It answers, and its own documentation warns you off relying on it. The sandbox API returned HTTP 200 when we called it on 28 September 2026, and the header of its Postman collection reads that since 2025 the sandbox is no longer actively maintained or kept in sync with production, that production should be considered the source of truth, and that it remains available on an as-is basis. Treat it as a mock of the integration shape, not of current behaviour.
Does Coinbase Commerce have a sandbox?
Yes, under the Coinbase Business checkout APIs. You add a /sandbox path segment to the endpoint and the request and response schemas stay identical to production. The limits are documented and worth reading first: sandbox payments never appear in your Coinbase Business wallets, sandbox data is purged after 30 days, and refunds are capped at 2.00 dollars to conserve testnet funds.
How do I test an underpayment or an expired crypto invoice?
It depends on which kind of sandbox you have. On NOWPayments you set the case field to partially_paid when creating the payment. On Cryptomus you POST to the test-webhook endpoint with a status of wrong_amount or paid_over. On a testnet sandbox you simply send less than the invoice asks for, which is the only version of the test that also proves your own rounding and tolerance logic against a real transaction.
Affiliate disclosure: payyd.co earns a commission on sign-ups made through our /go/ links, including the NOWPayments link above. No gateway supplied, reviewed or saw these findings before publication. Method, so you can repeat it: every sandbox host, parameter, status list, limit and faucet above was read from the named company's own public developer documentation on 28 September 2026. The CoinGate currency counts and the BlockBee chain list are our own measurements, taken the same day by calling api.coingate.com/v2/currencies, api-sandbox.coingate.com/v2/currencies and api.blockbee.io/info/ unauthenticated. Where a gateway publishes no policy we say so rather than estimating. Last updated 28 September 2026.