Test payments before real compute moves.
The sandbox lets you or your coding agent build and test the payment flow without real provider capacity, credits, or settlement. Everything is clearly marked as test data.
What you can test
- Payment requests and realistic API responses.
- Key handling and usage metering.
- Receipts and balance reconciliation.
- Webhook notifications for settlement events.
A simple test loop
- Start with the test-mode example. The SDK quickstart runs offline without real settlement.
- Make a test payment. Check the response, receipt, and any webhook your integration expects.
- Move to live when it works. Live keys are separate, so connect them only after the test flow works. Keep your first real payments small.
Sandbox labels and limits
Labeling
Every line produced in the sandbox is graded fixture or fixture-mechanism, and carries that label in every response and receipt. Fixture-mechanism means the fixture exercises the real settlement mechanism; fixture means test data. Neither represents real movement of value. The labels are not cosmetic and are never removed for convenience.
What the sandbox is not
The sandbox is not a performance environment and not a preview of live capacity. Conservation holds in the sandbox because the mechanism is real, but the credits are fixtures. Do not draw conclusions about live grades from fixture behavior.
Moving to live
Sandbox keys and live keys are separate. An integration that works in the sandbox still needs live keys, and its first live settlements should be small. Live lines are graded live, live-attested, or attested; fixtures never appear as live.