Laravel with Horizon
A common choice for Kenyan developers. The callback route stores the payload and dispatches a job; Horizon manages Redis queue workers and retries. Needs PHP-FPM, Redis and Supervisor or systemd to keep workers running.
M-Pesa Daraja app hosting Kenya
Every STK Push needs a callback URL that never misses a call
Host your shop, ticketing site, utility portal or subscription app on a VPS built for Daraja: a public HTTPS address for callbacks, queue workers that retry failed jobs and full root access to see exactly what Safaricom sent you, request by request.
500 payments
We suggest
VPS V3
KES 7,000/mo
Four cores for more PHP or app workers and separate queue workers, so callbacks stay fast during a sale or ticket release. Its 16 GB of RAM leaves room for WooCommerce and Redis caching too.
Order VPS V3M-Pesa payments are asynchronous, and that changes your hosting
When a customer taps "Pay" on your site, the Daraja STK Push request only starts the payment. The customer enters their PIN on the phone, and seconds later Safaricom posts the result to the callback URL you supplied. If that URL is slow, unreachable or returns an error, the money has left the customer but your system never marks the order as paid. Most M-Pesa support complaints trace back to that gap.
So the server matters as much as the code. The callback must be public, served over HTTPS with a valid certificate, and answered quickly. The heavy work, such as updating stock, issuing a ticket, sending an SMS receipt or creating an eTIMS invoice, should go to a background queue, not happen while Safaricom waits. Queues need long-running workers and usually Redis, which shared hosting rarely allows.
A VPS gives you that control. You choose the PHP, Python or Node.js version, run Laravel Horizon, Celery or BullMQ under a process manager, read the raw callback logs and add a scheduled job that checks the status of any payment still pending. HostingKE VPS plans include full root access, and our support team can help with DNS, certificates and firewall settings.
The problem
Why M-Pesa integrations break in production
Paid, but the order still says pending
The customer has the M-Pesa SMS, your system shows nothing. Usually the callback timed out, hit a firewall or failed on a code error. Log every raw callback before processing it, and query the transaction status for anything left pending.
Duplicate processing
Callbacks can be retried, and impatient customers press Pay twice. Without an idempotency check on the M-Pesa receipt number or checkout request ID, one payment can issue two tickets or credit a wallet twice.
Credentials in the wrong place
Consumer keys, passkeys and B2C initiator credentials end up in code repositories or shared hosting file managers. On a VPS they live in environment files readable only by the application user, and you can rotate them cleanly.
Peak-hour slowdowns
Ticket releases, flash sales and month-end utility payments bring hundreds of STK requests in minutes. Dedicated cores, enough PHP or app workers and a queue absorb the spike so callbacks are still answered promptly.
What runs on it
Stacks that work well with Daraja
Any language that can make HTTPS requests can call Daraja. What matters on the server is a reliable web endpoint and a background worker.
Django with Celery
Django receives the callback and hands processing to Celery workers through Redis or RabbitMQ. Celery Beat can run the periodic status checks for stuck payments. Runs under Gunicorn behind Nginx.
Node.js with BullMQ
An Express or Fastify app takes callbacks and pushes jobs to BullMQ, a Redis-backed queue with retries and delayed jobs. Keep the processes alive with PM2 or systemd.
WooCommerce
The WordPress shop plugin, used with an M-Pesa payment gateway plugin. Large catalogues and busy checkouts need PHP workers and object caching that shared hosting limits, and the callback URL must stay reachable through any security plugins.
Redis
In-memory store that backs most of these queues and caches. It is small but must run continuously, with persistence enabled so queued payment jobs survive a restart.
Sizing
Size by daily M-Pesa transactions
Estimate the number of STK Push, C2B and B2C transactions on a busy day, not an average one.
- 10–300 payments VPS V1 A small shop, school fees portal or subscription app with a lean framework, a queue worker and Redis. Enough to answer callbacks quickly at a few hundred payments a day.
- 310–3,000 payments VPS V3 Four cores for more PHP or app workers and separate queue workers, so callbacks stay fast during a sale or ticket release. Its 16 GB of RAM leaves room for WooCommerce and Redis caching too.
- 3,010–15,000 payments VPS V4 Six cores and 24 TB of transfer for a busy ticketing, utility or e-commerce platform, with several queue workers, a status-check scheduler and room for logs.
- 15,010+ payments VPS V5 Ten cores and 40 GB of RAM for high-volume platforms combining checkout, B2C payouts, reporting and large Redis and database caches on one server.
This is a starting point: real load depends on how spiky your traffic is and on the work each payment triggers, such as SMS, PDFs or eTIMS invoices.
VPS V1
KES 2,000/mo
- 1 Core
- 1 GB RAM
- 40 GB NVMe
- 1 TB transfer
VPS V2
KES 5,000/mo
- 2 Cores
- 8 GB RAM
- 160 GB SSD
- 8 TB transfer
VPS V3
KES 7,000/mo
- 4 Cores
- 16 GB RAM
- 320 GB SSD
- 16 TB transfer
VPS V4
KES 15,000/mo
- 6 Cores
- 24 GB RAM
- 480 GB SSD
- 24 TB transfer
VPS V5
KES 20,000/mo
- 10 Cores
- 40 GB RAM
- 800 GB SSD
- 40 TB transfer
Before you go live
Taking a Daraja integration live
0 of 8 done. Tick them off as you go.
Built for Kenya
Daraja details Kenyan developers run into
Callbacks must reach you from the internet
Safaricom posts STK, C2B and B2C results to URLs you provide, and they must be publicly reachable over HTTPS. Tunnels from a laptop work for testing, but production needs an always-on server with a fixed address and a valid certificate.
B2C needs careful credential handling
Payouts use an initiator name and a security credential encrypted with the M-Pesa public certificate. Keep the encrypted value and certificates on the server, out of your repository, and limit who has shell access to that VPS.
Receipts may need to reach KRA
Many businesses now issue invoices through KRA eTIMS. If your app generates them after payment, do it in the background queue so a slow tax system never delays the response to the M-Pesa callback or the customer confirmation.
Questions
M-Pesa payment apps: your questions, answered
Why does my M-Pesa callback URL not receive anything?
Common causes are an HTTP rather than HTTPS URL, an invalid or self-signed certificate, a firewall or security plugin blocking the request, or a URL containing words Daraja rejects. Check your web server access log first: if the request never arrived, the problem is reachability, not your code.
Can I use shared hosting for an M-Pesa integration?
Simple STK Push can work on shared hosting, but you usually cannot run Redis or long-running queue workers there, and you have little control over timeouts or firewall rules. A VPS lets you process callbacks in the background and see full logs when something goes wrong.
What should my callback endpoint do?
Validate the request shape, save the raw payload, queue a job and respond immediately. The job then matches the payment to the order, checks it has not been processed before and triggers receipts or fulfilment. Keeping the endpoint short avoids timeouts when your app is busy.
How do I handle STK Push payments that never get a callback?
Run a scheduled job that finds requests still pending after a few minutes and calls the STK Push Query or Transaction Status API. Update the order from that answer. This catches callbacks that were lost and payments the customer cancelled or let time out.
Do I need a VPS for B2C payouts?
B2C requests and their result callbacks need the same public HTTPS endpoint as other Daraja APIs, plus secure storage for your initiator credential. A VPS lets you lock that down with restricted users, firewall rules and environment files, which is harder on shared hosting.
Which plan suits a WooCommerce shop with M-Pesa?
A small shop with a modest catalogue can start on VPS V1. As products, plugins and traffic grow, WooCommerce benefits most from memory for PHP workers and object caching, so VPS V2 is a good next step. V4 suits shops with heavy promotions.
Also on VPS Hosting
VPS hosting for the systems Kenyan businesses run
Ready to host your m-pesa payment apps?
Plans from KES 2,000 a month, paid by M-Pesa or card.
Size your server