Sandbox, UAT & Go-Live
Test mode is a complete, parallel world: same endpoints, same objects, same checkout —
simulated money. Build everything against sk_test_, then go live by switching one key.
How the sandbox behaves
| Thing | Sandbox behaviour |
|---|---|
| Payments | Auto-settle ~18 seconds after creation, so you can watch the full pending → paid arc. Codes still expire after 10 minutes if unpaid. |
| Withdrawal codes | Stay pending until claimed via the instant-settle hook (they simulate a customer action). |
| Payouts | Submit instantly, settle ~20 s later, confirm on the next processor pass (~1–2 min end to end). |
| Webhooks | Fire exactly as in production, signed with your endpoint secret. |
| Balances & ledger | Fully separate from live. Nothing in test mode can ever touch real money. |
Instant settle (skip the 18 seconds)
Demos and automated tests should not wait. Any test payment can be settled instantly:
# settle now
curl -X POST https://omniway.online/checkout/{payment_id}/mockpay
# or force the expiry path instead
curl -X POST https://omniway.online/checkout/{payment_id}/mockpay \
-H "Content-Type: application/json" -d '{"outcome": "expired"}'mockpay returns 403 for anything created with a live key. It exists purely so
your CI and demos are deterministic.
Simulating failures
Real integrations must survive the unhappy paths. The sandbox gives you deterministic levers:
| Scenario | How to trigger it in test mode | What you should observe |
|---|---|---|
| Payment never paid | Create a payment and wait 10 minutes (or mockpay with outcome: "expired") | status: "expired", a payment.expired webhook, no ledger movement |
| Payout rejected | Ask the platform admin to point your test payout destination at an account ending 0000 | status: "failed", your balance automatically restored, a payout.failed webhook |
| Transient gateway flake | Test payout destination ending 0096 | First attempt retries internally; payout still completes — you see nothing but a short delay |
| Insufficient funds | Request a payout larger than your test balance | HTTP 402, error.code: "insufficient_funds", nothing debited |
| Idempotent retry | Re-send any money POST with the same Idempotency-Key | The original response is returned; no duplicate movement |
UAT with InnBucks
Before production credentials are issued, InnBucks reviews a sign-off pack. If you integrate only through
this platform you inherit most of it — the platform records every gateway interaction (references,
stan/authNumber, trace IDs) and the hosted checkout already satisfies the InnBucks
branding requirements. A typical merchant UAT is simply:
Run your flows in test
Payment paid, payment expired, payout, refund-path you care about.
Capture references
Keep the payment_ids and references from each run.
Hand them over
The platform team assembles the evidence pack and walks InnBucks sign-off with you.
Go-live checklist
- ✅ Whole flow green in test mode — including the expired and failed-payout paths.
- ✅ Webhook endpoint deployed over https with signature verification (guide).
- ✅ Fulfilment keyed off
payment.paid(webhook or server-sideGET) — never off the browser redirect. - ✅ Payout destination verified (your dashboard shows payout verified).
- ✅ Mint a
sk_live_key from the dashboard, set it in your server env, deploy. - ✅ Make one small real payment, watch it land in the dashboard, request a small payout.
Test mode never expires. Run your end-to-end suite against sk_test_ on every deploy — with
mockpay your suite is fast and deterministic.