Skip to main content
Numero has no separate sandbox host. You test against the same base URL and the same endpoints — the key you send decides the mode: So the switch from testing to going live is: change the key. Nothing else.

​
What test mode gives you

  • Simulated providers — transfers, collections and card calls resolve against simulators, so nothing leaves your account.
  • An isolated test wallet — separate from your live balance. Your live money is never read or moved in test mode.
  • Mode-aware webhooks — test events are delivered only to webhook subscriptions registered as test, and carry livemode: false.
The sandbox endpoints below require a test_key_. Calling them with a live key returns a clear rejection — they can never touch live balances.

​
Test data

Test mode is deterministic: the input you send decides the outcome. No special headers, no dashboard toggles — send one of the values below and you get that result, every time. For a simulated operation, any input value not listed here takes the happy path, so the success case needs no magic values.
That applies to the values you send, not to every endpoint. An operation Numero does not yet simulate returns HTTP 501 naming the gap, rather than a fabricated success — so a green test run means the call was actually exercised, not merely that nothing objected. If you hit a 501, tell us; it is a missing simulation, not your bug.
Use these to build a test suite that covers your failure handling, not just the path where everything works.

​
Verification & credit — the BVN decides

11111111111 is the one worth testing against. The fields are present and null — a bureau returning “we hold no score for this person” is an answer, not an error, and your code has to survive it. See Reading normalizedResult. What you get back. These are the real responses, not illustrations — POST /business/verification/credit-score: Note the middle row: a thin file is a successful, billable verification whose answer happens to be “no score”. Branch on the field being null, not on success. Full bodies for all three are on the Credit page.
A 200 does not mean the verification passed. The HTTP status describes the call; data.success and data.statusCode describe the outcome. A not-found is a perfectly successful API call reporting a negative result.
Test mode mirrors what each product really returns — including that credit-first-central returns no score. If you need a number to derive a lending band, use credit-score or credit-summary. We’d rather the sandbox tell you that now than have you discover it in production.

​
Transfers & payouts — the amount decides

​
Account validation (name enquiry)

​
Bills & airtime

These values are test mode only. In live mode they are ordinary inputs with no special meaning — 1000.99 is just an amount. Never ship them to production.

​
Fund your test wallet

Top up your test balance with simulated money.
Your test wallet starts at ₦1,000,000 and is capped at ₦10,000,000 — a top-up that would exceed the cap is rejected.

​
Reset your sandbox

Wipe your test transactions and virtual accounts and reset the test balance to its default.
Test transactions are capped at 30 per merchant — the oldest are pruned automatically. Reset whenever you want a clean slate.

​
Fire a test webhook

Send a sample event to your registered test webhook endpoint(s) to exercise your handler without waiting for a real payment.
The delivery is signed exactly like a live webhook, so you can verify your signature check end-to-end — see Webhook verification. It carries livemode: false.

​
Going live

  1. Build and verify everything with your test_key_.
  2. Swap in your live_key_ — same base URL, same endpoints.
  3. Register your live webhook URL and confirm you’re handling livemode: true deliveries.