How to Test MoMo Payments in Sandbox Before Going Live

Payment integrations handle real money. A bug in your MoMo integration does not just cause an error message. It can mean: a customer pays and your system does not register it (you owe them a product or a refund), your system registers a payment that never happened (you ship a product without being paid), or a customer gets charged twice (the worst outcome).

The sandbox exists to prevent all of this. It simulates the full MoMo payment flow without moving real money. Every scenario you can encounter in production can be tested in sandbox first. The time you invest in thorough sandbox testing pays back in avoided production incidents.

1. Happy path (successful payment)

• Send a Request to Pay with valid parameters.
• Verify you receive a 202 Accepted response.
• Verify your callback endpoint receives the success notification.
• Verify your application correctly updates the order status to "paid."
• Verify the customer-facing UI shows the confirmation.

2. Failure scenarios

• Insufficient funds: Test with a phone number that simulates insufficient balance. Verify your application shows a clear, friendly error message.
• Timeout: Simulate a transaction where the customer does not confirm. Verify your application handles the timeout gracefully and offers a retry.
• Invalid phone number: Send a request with a malformed or non-existent phone number. Verify the error is caught and displayed appropriately.
• Network error: Temporarily disconnect your server from the internet during a request. Verify your error handling catches the network failure.

3. Callback reliability

• Verify callbacks arrive consistently for successful transactions.
• Simulate a callback failure (stop your server briefly, then restart). Verify your status polling fallback catches the missed callback.
• Verify your server responds with 200 OK to callbacks. If it does not, MoMo may not retry.
• Test with ngrok or your staging server to ensure callbacks work from outside your local network.

4. Edge cases

• Duplicate requests: Send the same payment request twice (same external ID). Verify your system handles the duplicate gracefully (idempotency).
• Very small amounts: Test with the minimum allowed amount.
• Very large amounts: Test near the maximum transaction limit.
• Concurrent transactions: Send multiple payment requests simultaneously. Verify each is tracked independently.
• Special characters: Test with transaction notes that include special characters or long strings.

5. Status polling

• Poll the transaction status endpoint using the reference ID.
• Verify the status matches what the callback reported.
• Verify polling works as a standalone mechanism (if the callback never arrives).

Apply for production credentials when:

• Every item on the testing checklist passes consistently (not just once, but repeatedly).
• Your error handling covers every failure mode you tested.
• Your callback handler and status polling fallback both work reliably.
• Your logging captures enough detail to debug production issues.
• You have environment-based configuration (environment variables for API keys, base URLs, and callback URLs) so switching from sandbox to production is a configuration change, not a code change.

After going live, run the first few production transactions with small amounts. Monitor your logs closely. Verify that production callbacks arrive, that orders are processed correctly, and that the customer experience is smooth. Only increase traffic after confirming everything works with real money.

For a structured approach to going from sandbox to production with confidence, the Deployment and Going Live course (KES 4,999, approximately RWF 50,000) covers environment management, production checklists, monitoring, and the specific considerations for payment-handling applications.