How to add mobile money payments to an ecommerce site
Updated 2026-09-23
Adding mobile money to a store is more than putting an operator logo beside a pay button. The store must know which methods are actually enabled, keep the buyer on a clear payment path and decide when an order is safe to fulfil. Here is an order-to-payment workflow you can use to plan an integration without assuming that every rail is available to every merchant.
Choose the payment path that fits your store
A payment link works for an invoice, assisted sale or small catalogue when you can create a payment for the correct amount and share the hosted page. A hosted checkout fits a store that wants to send a buyer from its cart to a payment page. A payments API fits a custom back end that needs to create and track payments alongside its own order records.
These are integration paths, not promises that a particular mobile-money operator is live. Complete business onboarding and inspect the methods enabled for your account, market, currency and transaction before advertising one to buyers. ZyndPay does not currently advertise a maintained public WooCommerce or WordPress plugin; plan around the verified link, checkout or API paths instead.
Create the order before opening checkout
Your store should own the cart total, currency, tax, delivery choice and a unique order reference. Create the payment against that reference and retain the payment identifier returned to your system. A support agent should be able to move from the order to its payment attempt without searching by the buyer’s name or copying a screenshot.
Keep the amount and reference stable for that attempt. If the cart changes, create the appropriate new attempt under the store’s order policy rather than silently reusing a payment for a different total. Show the buyer the amount and method selected from the live checkout, not an operator list hard-coded from a marketing page.
Design for a pending mobile-money result
Mobile-money payment flows can involve a customer authorization step and an asynchronous result. The GSMA merchant-payment specification describes pending requests that later complete, fail or time out. It is an industry reference, not a statement that ZyndPay implements that specification or a promise about any particular operator.
Tell the buyer when an attempt is still pending. Do not label an order paid merely because a request was accepted, the browser returned, or the buyer shared a confirmation message. If the buyer closes the page, keep the order reference available so your system can check the authoritative payment state and show the next appropriate action.
Fulfil once from confirmed server-side state
Use the authenticated payment status and signed webhook events available to your integration. Verify each event as documented, then make the order update idempotent: a repeated delivery must not trigger a second shipment, entitlement or account credit. Keep pending, failed, expired and confirmed attempts distinct.
A return page can reassure the buyer, but it does not replace that server-side decision. If a webhook is delayed, reconcile by payment and order reference instead of assuming that no event means failure. See the separate webhook guide for the verification and retry principles.
Reconcile exceptions before calling the order complete
Store the order reference, payment identifier, selected method, amount and each resulting state so support and finance can explain an attempt later. A refund, dispute or settlement entry is related to the original payment but is not the same event. Compare the records before changing a customer’s order or telling them that funds have been returned.
Before live launch, test the ordinary completion, a buyer who abandons checkout, a pending authorization, a failed or expired attempt, a duplicate webhook and an unavailable callback endpoint. Use only the test flows exposed to your account; sandbox completion does not establish that a live rail or market is approved.
Primary sources
FAQ
- Can I accept mobile money without installing an ecommerce plugin?
- Where mobile money is enabled for your approved account, a payment link or hosted checkout may fit without a store plugin. A custom store can use the supported payments API. ZyndPay does not advertise a maintained public WooCommerce or WordPress plugin today.
- Which mobile-money operators will appear at checkout?
- The live checkout or API response shows the methods available for the account and transaction. Availability depends on the market, currency, customer context and rail status; a generic country or operator list is not authoritative.
- When should my store mark an order paid?
- Apply your fulfilment policy only after checking confirmed server-side payment state and processing signed events safely. An accepted request, browser return or customer screenshot is not enough.
- What if a buyer closes the payment page?
- Keep the order and payment references, show a pending state where appropriate, and reconcile against the authenticated payment status. Do not create a second charge merely because the page closed.