The verdict in three sentences
Before any go-live, a mobile money checkout must go through test mode: that is where 70% of future bugs are decided. The golden rule: never mix test and live keys, and keep a separate staging environment — it cuts production incidents by 60%. Explicitly test failures (insufficient_funds, invalid_pin, transaction_declined), not just the happy path.
Test keys vs live keys: never confuse them
Each environment has its own key pair. Test keys move no real money; live keys do. A prefix distinguishes them — check it in your config before every deploy.
| Element | Test environment | Live environment |
|---|---|---|
| API key | sk_test_... | sk_live_... |
| Real money | No | Yes |
| Webhooks | to staging URL | to prod URL |
| Cards | test cards | real cards |
| Use | dev, CI, QA | customers |
The error codes you must simulate
A robust checkout handles every failure with a clear message. Simulate them in test mode before prod: it is the best way to avoid silent abandoned carts.
| Error code | Meaning | Suggested customer message |
|---|---|---|
insufficient_funds | Not enough balance | "Insufficient funds, try again" |
invalid_pin | Wrong PIN | "Incorrect PIN" |
transaction_declined | Operator decline | "Payment declined" |
timeout | Session expired | "Timed out, try again" |
limit_exceeded | Cap exceeded | "Amount too high" |
invalid_number | Invalid number | "Check your number" |
The pre-go-live checklist
A successful move to production follows a fixed list. Tick every line before opening the gates to real customers.
| Check | Done? |
|---|---|
| Webhook signed and verified | ☐ |
| HTTP 200 response < 2 s | ☐ |
| Dedup table active | ☐ |
| All error codes tested | ☐ |
| Switch test → live keys | ☐ |
| Monitoring and alerts in place | ☐ |
Mini case study
Need a professional website?
Kolonell builds websites that attract clients, optimized for the Sénégalese market. Free quote in 2 minutes.
David, developer of a streetwear store in Nairobi, launched a Paystack checkout without separate staging. In his first month, 70 of 900 orders broke (mishandled webhook) — 7.8% — at a KES 2,200 average basket = KES 154,000 in incident sales. Adding a staging environment and testing the six error codes brings the incident rate to ~3%, recovering about KES 92,400 the following month. Staging took one day to set up.
FAQ
Why do so many bugs come from webhooks?
Because they are asynchronous and hard to reproduce by hand: around 70% of payment production incidents come from untested webhooks. Simulating them in test mode is the only real defense.
Can I test without real money?
Yes: test keys and test cards let you walk the whole funnel — success, failure, timeout — with no money moving. That is exactly what test mode is for.
Do I really need a staging environment?
Yes. Staging separate from prod cuts incidents by about 60%, because it catches config errors (wrong keys, wrong webhook URL) before they reach customers.
Which error codes should I simulate first?
At minimum insufficient_funds, invalid_pin, transaction_declined and timeout. They are the most common in real conditions and cause the most abandoned carts when mishandled.
Let's talk about your project. We set up test mode, staging and a go-live checklist for a mobile money checkout with no surprises. WhatsApp +221 77 596 93 33.
Mohamed Bah
Fondateur, Kolonell
Passionate about digital and entrepreneurship in Africa, Mohamed has been helping Sénégalese businesses with their digital transformation since 2020. Founder of Kolonell, he believes every SME deserves a professional and accessible online présence.
