test and live — and they are separate Postgres schemas, not a flag on a row. A test key cannot read, write, or bill anything in live.
How mode is chosen
| Caller | Mode comes from |
|---|---|
| Secret/publishable key | the prefix (_test_ / _live_) |
| OAuth token | the client id prefix |
| Hosted checkout | the token (cs_<mode>_…) |
| Customer portal | an explicit ?mode= (defaults to live) |
mode parameter to the merchant API — it’s implied by your key. Use a test key while building, swap to a live key to go to production. The request bodies and responses are identical.
Because the data is physically partitioned, there’s no “test transaction” cluttering your live tables and no risk of a forgotten filter exposing test data to production reads. The isolation is structural. See the data model.
Going live
- Complete KYC in the dashboard (CAC, MEMART, status report). An unverified tenant is capped at ₦1,000,000 in total revenue.
- Once approved, your tenant’s tier becomes
verifiedand the cap lifts. - Mint a
sk_live_key and point your integration at it. Nothing else changes.