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
For a Rwanda shop, ask a prospective payment provider which Mobile Money networks, currencies and 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.
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.