Kenyan WordPress hosting where payment happens on a phone.
Checkout here often ends with the customer entering a PIN on their handset. Your site is not part of that step, and it has to survive not being part of it.
The payment leaves your site entirely.
A mobile money transaction happens between the customer and their operator. Your order is waiting for a message afterwards.
A callback endpoint that is always reachable
Confirmation arrives as a request from the payment operator, not from the customer's browser. If that endpoint is cached, throttled or behind a challenge, the payment succeeded and the order did not.
Orders that wait patiently
A customer may take a minute to find their phone and enter a PIN. Pending orders are held for a realistic human interval rather than a network timeout.
Pages built for the connection people have
Traffic is overwhelmingly mobile and often on variable networks, so reducing round trips matters more than shaving kilobytes.
Reconciliation you can run
Operators occasionally deliver a callback late or twice. Records are kept so a payment can be matched to an order rather than guessed at.
Origin placement stated
Kenya is far from most infrastructure, so where the origin sits is a decision we make with you rather than a default.
The order completes without the customer.
Every mobile money failure looks the same from the outside: money left the customer's account and the shop has no order. Almost always the callback never arrived.
- Callback endpoint exempt from caching and throttling
- Pending orders held for a human interval
- Duplicate and late callbacks reconciled
- Pages optimised for round trips
The measure is orders, not milliseconds.
A fast storefront that loses payment confirmations has failed at the only step that mattered. Callback reliability is the number here.
What we change for Kenyan stores
Payment happening off-site drives most of this, and network conditions drive the rest.
| Setting | What we do | Why |
|---|---|---|
| Callback endpoint | Exempt from caching, throttling and bot challenges | Confirmation arrives as a machine request from the payment operator, and anything that blocks or caches it produces a paid customer with no order. |
| Pending order window | Sized for somebody finding their phone and entering a PIN | The wait includes a human action on a separate device, which is far longer than any timeout written for a network response. |
| Callback reconciliation | Late and duplicate messages matched to orders | Operators sometimes deliver confirmations twice or minutes late, and without records those become either double orders or lost ones. |
| Round trips | Reduced ahead of payload size | Traffic is mobile and network quality varies, so an extra sequential request costs more than the bytes it would have carried. |
| Origin placement | Decided explicitly rather than inherited | Kenya is distant from most infrastructure, so accepting a default origin means accepting a latency nobody measured. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Why do some mobile money payments not create an order?
How long should a pending order wait?
What if the operator sends a confirmation twice?
What should I optimise first for Kenyan mobile traffic?
Take the payment and keep the order.
Move the store across. Migration is free, payment callbacks tested.