Testing Payment Gateway Sandboxes in Anglophone Africa 2026

The verdict in three sentences

Paystack, Flutterwave and M-Pesa all provide sandbox environments with test cards/numbers and error-triggering amounts (timeout, insufficient funds, customer cancellation). Testing these scenarios end-to-end before production prevents up to 90% of launch incidents. This guide lists the scenarios to cover, the Paystack/Flutterwave test cards and OTPs, and the exact order to switch keys from test to live.

The e2e scenarios to cover

A successful payment is not enough to validate an integration. You must simulate every failure path, because that is where a store loses sales or double-delivers. Each sandbox offers specific triggers.

Plan at least these 8 scenarios before any production launch. Each must leave your system in a consistent state: never a delivered order without confirmed payment, never a double delivery.

Sandbox per gateway and key switching

Each platform has its own testing specifics. For cards, Paystack and Flutterwave provide card numbers and test OTPs that simulate 3D Secure and authentication failures.

The order to switch to production is strict: first validate the 8 scenarios in sandbox, then swap test keys for live keys, then update webhook URLs to production HTTPS, and finally run a minimal real payment (NGN 100 to 500) that you refund, before opening to customers. Never switch all keys at once without this final real test.

Mini case study

Samuel is launching a bookstore in Nairobi and wants to integrate M-Pesa and Paystack. Without a sandbox phase, his previous launch generated 18 incidents on 200 orders in the first month (9%): orders delivered without payment, duplicates, unhandled timeouts. For the new project he covers the 8 e2e scenarios in sandbox over 2 days, then runs a real NGN 200 payment and refunds it. Result: 2 incidents on 200 orders (1%) at launch. On an average basket of NGN 12,000 equivalent, he avoids about 16 x 12,000 = NGN 192,000 in losses and disputes in the first month, for 2 days of testing recouped in the first week.

FAQ

Can I test a real payment without moving money? Yes, in sandbox: test numbers and amounts debit no real account. Card 3D Secure is simulated with test OTPs provided by Paystack and Flutterwave.

How many scenarios must I cover at minimum? At least 8: success, insufficient funds, timeout, cancellation, duplicate webhook, incorrect amount, expired token and 3D Secure. Each must leave the system consistent.

In what order do I switch test keys to live? Validate the sandbox, swap the keys, update the HTTPS webhooks, then run a minimal real refunded payment. Never all at once without a final test.

Should I re-run tests after every update? Yes for critical scenarios (success, duplicate webhook, timeout). A webhook regression can silently block every order.

How long should the test phase take? Ballpark: 1 to 3 days to cover the 8 scenarios across two gateways, an investment recouped in the first month through avoided incidents.

Let's talk about your project. We test your Paystack, Flutterwave, M-Pesa, Wave and MTN MoMo integrations in sandbox before any production launch. WhatsApp +221 77 596 93 33.