Agree on the payment provider and order workflow early. Test successful, failed, delayed and repeated payment responses before launch.
Choose the provider before designing checkout
In Rwanda, shoppers pay with Mobile Money on two networks: MTN MoMo and Airtel Money. A checkout that offers only one of them turns some customers away at the last step. Ask a prospective payment provider which of the two networks, which currencies and which payment methods it currently supports. Confirm merchant onboarding, settlement, fees, refunds and the support route directly with that provider. A plugin logo does not answer those questions.
Then confirm how the provider integrates with your version of WooCommerce. Ask whether it supports your checkout approach, how it verifies a payment and how it reports a delayed result. Credentials for live payments should be held by the business and installed securely; they should never appear in public page code.
MTN MoMo plugin, provider or custom integration?
There are three common ways to take MTN MoMo and Airtel Money on WooCommerce. Each one suits a different shop, so choose deliberately rather than installing the first plugin a search returns.
| Route | When it fits | What to check |
|---|---|---|
| A ready made WooCommerce plugin for MTN MoMo | A shop that only needs MTN MoMo and is comfortable using the MTN MoMo API directly. | Whether the plugin supports Rwanda today, when it was last updated, whether it confirms payments with MTN rather than trusting the browser, and whether it covers Airtel Money. |
| A payment provider that combines networks | A shop that wants MTN MoMo, Airtel Money and possibly cards through one account and one integration. | Merchant onboarding, fees, settlement times and refunds, confirmed in writing with the provider, and its WooCommerce support. |
| A custom plugin | A shop with an unusual workflow, such as manual payment confirmation, deposits or matching payments to orders that were placed another way. | A written scope for the workflow, who maintains the code and how it is tested against each payment outcome. |
Answer buying questions before payment
A product page should state the price and currency, the available options, stock or lead time and how delivery or collection works. If the customer must contact you to discover every essential detail, decide whether the first release should use enquiries rather than pretend to offer a complete online purchase.
Set delivery zones, pickup options and fees to match what your business can fulfil. Show relevant costs before the customer commits. Test an address you can deliver to and one outside your delivery area. The second customer needs an explanation, not a broken checkout.
Keep the order form focused on information you actually use. A physical delivery needs different details from a downloadable product. Long forms create more opportunities for mistakes and more information for your team to handle.
Make order states clear to everyone
The browser returning to a success page should not be the only evidence of payment. The integration needs a trustworthy confirmation from the provider, matched to the correct order and amount. Delayed responses need a pending message that explains what to do next.
WooCommerce distinguishes states such as Pending payment, On hold, Processing, Completed and Failed. Confirm how the chosen gateway uses these states. The fulfilment team should know which state means payment has been confirmed and which still needs attention.
Test the awkward cases
| Scenario | What to check |
|---|---|
| Successful payment | The correct order is marked paid and the customer receives a useful confirmation. |
| Cancelled or rejected payment | The order does not appear paid; the customer can understand the failure and retry. |
| Delayed confirmation | A pending state is visible and the later provider response updates the right order. |
| Repeated response | The same confirmation does not create another order or repeat fulfilment. |
| Changed amount or wrong reference | The integration rejects a response that does not match the order. |
| Refund or manual intervention | The team follows a documented process and understands what the provider handles. |
Use the provider’s approved test environment and test credentials where available. Any real transaction used for a final check should be agreed with the business, including the amount and how it will be reconciled. Do not place live purchases merely to test a public shop.
Give the team an operating checklist
At handover, walk through a paid order, a payment still waiting for confirmation, a failed attempt and an order that needs a refund. Confirm who checks the dashboard, who contacts customers and who handles delivery problems.
- The business owns the store and provider accounts.
- Order notifications reach the people who act on them.
- Delivery and collection instructions are accurate.
- A backup and maintenance arrangement is agreed.
- The support route for the store and the provider is written down.
Further reading
Official documentation behind the technical guidance in this article.
