What is isolated
Sandbox accounts, keys, intents and events are stored in separate tables from live gateway payments. Test keys begin with sk_test_ and are accepted only under /v1/sandbox/. They are rejected by live merchant authentication. Live keys are rejected by sandbox authentication. No listener or outbound webhook is invoked by this simulator.
Available scenarios
A waiting test intent can succeed or fail. A succeeded intent can be reversed. Repeating the same completed transition returns the existing result without another event. Other state transitions return a conflict. Events use payment.succeeded, payment.failed and payment.reversed; the live matching flow instead uses payment.matched. Treat these schemas as separate interfaces.
API workflow
POST /v1/sandbox/intents accepts amount, currency and reference with an Idempotency-Key header. POST /v1/sandbox/intents/{id}/simulate accepts a scenario of success, failure or reversal. GET /v1/sandbox/intents and GET /v1/sandbox/events return the latest 50 records belonging to your account. Authenticate using Authorization: Bearer followed by your test key.
Limits and realistic testing
Use synthetic references and amounts, not personal or wallet data. Each account is limited to 1,000 test intents. Test key rotation is available in the sandbox workspace and revokes previous test keys immediately. Sandbox success is not settlement, regulatory approval, or proof that a provider receipt will parse correctly.
curl https://ispbillingpay.com/v1/sandbox/intents \
-H "Authorization: Bearer $ISP_TEST_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: test-purchase-001" \
-d '{"amount":"1000.00","currency":"UGX","reference":"test-001"}'KEEP EXPLORING