Developers
A sandbox that only succeeds teaches you nothing
You already know your code works when the payment goes through. What you need to find out, before real money is involved, is what it does when the payment does not.
See it live
Trigger the failure, not just the success
Scoped keys, rate limits and the six failure triggers below are all visible from the same sandbox console you would use to run them.
Failures on demand
Six things you cannot reliably reproduce any other way
A hard decline with a stable reason code
A request that never answers, to test your retry
The nastiest case — it worked, you never heard
Less received than expected, inside and outside tolerance
The same event delivered twice, minutes apart
A crypto deposit that confirms hours later
The third one is the case most integrations get wrong, and the one you will never reproduce by waiting.
How it behaves
Three properties that decide whether a sandbox stays useful
Isolated per team
Your sandbox state is yours. Nobody else's test run changes a balance you were about to assert on, which is the reason shared test environments stop being trusted within a month.
Resettable on demand
Wipe back to a known state whenever you need to. A test suite that depends on accumulated history is a test suite that eventually only passes on one machine.
Same interface, same errors
The sandbox speaks the identical contract to production, including the error shapes. Anything you handle here you have genuinely handled.
FAQ
Sandbox: common questions
6 short answers to what teams ask before a demo.
Yes — that is the main point of it. Declines, timeouts, underpayments, duplicate callbacks and delayed confirmations are all reproducible on demand rather than waiting for one to happen naturally in production.
The request that timed out but actually succeeded. It is the case most integrations handle wrong, it is nearly impossible to reproduce by accident, and it is the one that produces duplicate charges. The sandbox lets you trigger it directly.
No. Each environment is isolated, so nobody else's test run changes a balance you were about to assert on. Shared test environments stop being trusted within about a month, and then people test in production.
Yes, back to a known state whenever you want. A test suite that depends on accumulated history is one that eventually only passes on the machine where that history exists.
It speaks the identical contract, including error shapes and callback structure. What it does not do is move real money, and network confirmations are simulated rather than waited for — which is a feature when you are testing a chain with slow finality.
No. Sandbox access comes before commercial conversations, because the sensible way to evaluate a payment interface is to integrate against it rather than to read about it.
Still have a question?
A specialist will answer it directly, with your set-up in mind.
Ask a specialistIntegrate first, talk commercially later
Sandbox access does not need a signed agreement. Evaluating a payment interface by building against it is more useful than any conversation we could have.