A customer reaches checkout with their phone in hand, ready to pay, but a slow or confusing payment process can interrupt the sale. In Kenya, STK usually means an M-Pesa STK Push: your website sends a payment prompt to the customer’s phone, where they enter their M-Pesa PIN to approve it.
If you’re a business owner hiring a Nairobi developer to add this option to your website or app, the payment prompt is only one part of the job. The site also needs to handle payment updates reliably, protect sensitive information, and guide customers when a payment is pending or fails. I’ll explain how the flow works, what developers need to build and test it, how security fits in, and what can affect project costs.
I’ll also share what to look for in a capable development partner, so you can compare proposals with clearer expectations. Start with this practical guide to M-Pesa STK Push integration in Kenya.
What STK Means for an M-Pesa Website Payment
In Kenyan website projects, “STK” usually refers to the M-Pesa prompt a customer approves on a phone. The letters can also describe a general phone feature, however, so I recommend confirming exactly what a developer means before you agree on the payment scope. That small clarification helps you distinguish a familiar customer experience from the technical work needed to make checkout reliable.
STK Push and the SIM Toolkit Are Not the Same Thing
The SIM Application Toolkit, often shortened to STK, is a feature that lets a SIM card display menus and interact with a mobile phone. Depending on the SIM and network, a customer may see a menu for services such as checking an account or buying airtime. That general phone feature is separate from a website’s M-Pesa payment integration.
In everyday Kenyan business conversations, “STK” often means the M-Pesa payment prompt sent to a customer’s registered phone. The customer sees a request to approve a specific payment, then enters their M-Pesa PIN on the phone. Safaricom describes the API-based flow through its Daraja developer portal, where businesses and developers can review M-Pesa integration options.
To avoid confusion, ask for M-Pesa STK Push or Lipa Na M-Pesa Online when discussing website payments. These terms give your developer a clearer direction than “add STK,” which could mean something else in a mobile or SIM context. I’d also ask whether the build will connect directly to Safaricom’s Daraja API or use a payment provider. Those approaches can differ in setup, fees, account requirements, and how your business receives transaction updates.
What Customers See During an STK Push Payment
The customer journey begins at checkout. They choose M-Pesa, enter the phone number they want to pay with, and submit the order. The website then requests a payment prompt for that number. If the request reaches the phone, the customer reviews the payment details and enters their M-Pesa PIN to approve it.
After approval, the customer returns to the website or sees a message that the payment is being checked. The final screen can show success, failure, or a pending status while the business waits for confirmation. The exact wording and sequence depend on the provider, the website, and the way the developer implements checkout. For example, some sites may display a waiting page, while others update the order screen automatically.
A customer’s experience can also change if the phone number is mistyped, the prompt expires, or they cancel before entering a PIN. That’s why I recommend asking the developer what customers will see in each case. A clear retry option and a useful pending message are better than a blank page that leaves someone wondering whether money was deducted.
What Happens Behind the Checkout Screen
When a customer submits the payment form, the website sends the payment details to its server. The server uses an API, a defined way for software systems to exchange requests and responses, to ask M-Pesa or a payment provider to send the prompt. In a well-planned integration, private credentials stay on the server rather than appearing in the customer’s browser.
The first response usually confirms whether the request was accepted for processing. It does not, by itself, prove that the customer completed the payment. The customer still needs to approve the prompt, and the payment system must report the resulting transaction status.
That later update often arrives through a callback, also called a webhook. It is a message sent from the payment service to a designated website address with the result. The website can then match that result to the correct order and update its status. Safaricom’s M-Pesa Express API information describes the network-initiated prompt and customer confirmation flow.
For your business, the order record is what connects checkout to fulfillment. A confirmed payment can move an order forward, while a canceled or failed transaction should leave it unpaid. If a customer closes the browser after approving a prompt, the callback still needs to reach the website so the order can be updated. I advise asking how the developer will handle delayed results, duplicate callback messages, and orders that remain pending.
If you’re comparing direct integration with a provider, consider how each option handles payment updates and order matching, not just how quickly it adds a button. This overview of payment providers for M-Pesa website payments can help you frame that conversation. When you hire a developer, ask them to name the exact integration, explain the customer flow, and show how the website confirms a successful payment before marking an order as paid.
How to Add STK Push to a Website or App in Kenya
Adding M-Pesa STK Push takes more than placing a payment button on a page. Your developer needs to connect the payment request to the right order, handle Safaricom or provider responses, and show customers what to do if a payment stalls. The right setup depends on your business, website platform, payment provider, and Safaricom’s current requirements.
Choose a Payment Setup That Fits the Business
You can connect directly to Safaricom’s Daraja APIs or use a third-party gateway that supports M-Pesa checkout. A direct integration can give your team more control over the payment flow and the way transaction details connect to your site. However, it also puts more setup, testing, and ongoing maintenance on your developer.
A gateway may reduce implementation work, especially when your site uses a supported plugin or platform integration. It can also offer other payment methods, such as cards or additional mobile money options, through one provider. In exchange, you may pay provider fees, accept the gateway’s checkout and reporting features, and rely on its support team when issues arise.
Neither route suits every business. A small service website with a few payments each week may value a ready-made integration, while a larger store with custom order rules may need more control. I recommend asking each provider about current business eligibility, transaction fees, settlement timing, refunds, support hours, and any setup or monthly charges. Those terms can change, so compare current quotes rather than relying on an old price list.
Your platform matters, too. A WooCommerce site may have a compatible plugin, while a custom app could need a tailored API connection. Safaricom’s Daraja API catalog is a useful starting point for confirming which integration options are available. If you are building an online store, review the wider requirements for e-commerce development in Nairobi before settling on a payment route.
Prepare the Details Your Developer Will Need
Before work begins, gather the business and payment information the developer may need. The exact account setup and credentials depend on whether you integrate directly or through a provider, so confirm the current requirements with Safaricom or your chosen gateway. Don’t assume every website needs the same account type or technical configuration.
I suggest preparing a short project brief with:
- Your registered business details and the payment account or provider you plan to use.
- The website platform, such as WooCommerce, Shopify, or a custom website or app.
- The checkout journey, including whether customers pay for orders, bookings, invoices, or donations.
- Typical payment amounts, currencies, and any deposits or partial payments.
- Your refund, cancellation, and payment-dispute rules.
- The staff member who will manage payment access, credentials, and provider support.
Also decide who owns the payment account and who can access its dashboard. That person should be available during setup and testing, especially if the provider requests business verification or account approval. Ask your developer to identify which credentials they need and how they will store them.
Never send an M-Pesa PIN, consumer secret, passkey, or other private credential through a public chat, email thread, or shared document. Use a secure method approved by your provider, restrict access to people who need it, and make sure credentials stay on the server rather than in browser code. That boundary protects both your payment setup and your customers.
Map the Payment Request to the Order Journey
A payment prompt must point to a specific record in your business system. Depending on your site, that record could be an order number, invoice, appointment, booking, or donation reference. Ask your developer how the site will create and store that reference before it sends a payment request. This connection helps you match the result to the right customer, even if they close the browser.
The request should carry the expected amount and the customer’s phone number. Your site should validate both before sending anything. For example, a phone field can accept a Kenyan number in supported formats, then normalize it consistently for the payment service. The amount should come from the server’s order total, not a value someone can freely change in the browser.
Checkout instructions also need to be plain and specific. Tell customers which number will receive the prompt, what amount to expect, and that they must approve it on their phone. Once the request starts, show a waiting message rather than suggesting payment has succeeded.
If the prompt expires or the customer cancels, explain what happened and offer a clear next step, such as trying again or choosing another method. Before retrying, the site should check the existing payment status. Otherwise, a customer could receive two prompts for one order. A useful checkout handles these moments without losing the order or leaving the buyer unsure what to do.
Plan for Payment Confirmation and Failed Requests
An accepted payment request is not proof that a customer paid. It only tells your site that the prompt was initiated or accepted for processing. The website should mark an order as paid only after it receives a confirmed transaction result and matches that result to the correct order.
Ask your developer how the integration will handle callbacks, delayed responses, duplicate requests, and timeouts. A callback can arrive after the customer leaves checkout, so the website must still update the order record. If the same result arrives more than once, the system should avoid creating duplicate payments or sending duplicate fulfillment instructions.
I also ask what happens when a callback doesn’t arrive or the result remains pending. The site may need to check status again or flag the transaction for manual reconciliation. Your team should be able to compare website records with provider or M-Pesa transaction reports, including the amount, order reference, transaction status, and receipt details where available.
Before launch, test more than the successful path. Ask the developer to test a canceled prompt, an expired request, a wrong number, a delayed response, and a repeated payment attempt. Then confirm that each outcome leaves the order in the correct state and gives the customer a useful message. A short test plan now can prevent a confusing checkout when real customers are waiting.
Keep STK Payments Secure, Reliable, and Easy to Test
A payment flow can look simple on a phone while depending on several systems behind the scenes: your website, hosting, network, payment provider, and M-Pesa. I ask developers to explain how each part protects customer details and keeps order records accurate. Security depends on sound implementation and current provider guidance, not just adding HTTPS or installing a payment plugin.
Protect Payment Credentials and Customer Data
Your website should send payment requests from its server, not directly from code running in a customer’s browser. API credentials, including keys and passkeys, belong in secure server-side configuration with access limited to the people and systems that need them. They should never appear in public code, browser tools, screenshots, or shared documents.
Use HTTPS across the entire website, including checkout and the callback address that receives payment updates. An SSL certificate for your website helps encrypt data between the browser and your site, but it does not replace secure coding, access controls, or a properly protected server. Keep your CMS, plugins, payment integration, and server software updated, and remove accounts or extensions your business no longer uses.
The payment callback also needs careful handling. Ask your developer how the site validates incoming results, records them for troubleshooting, and updates an order only after confirming payment success. The callback endpoint should stay reachable and respond reliably; if it is down, a customer may pay while your order remains marked pending.
Collect only the customer information needed to process and fulfill the order. For example, avoid keeping payment details that your business does not need after the transaction. Most importantly, customers should enter their M-Pesa PIN only in the official payment prompt on their phone, never in a form on your business website. Make sure checkout instructions say this plainly.
Test Success, Failure, Delay, and Duplicate Payments
A test that ends with a successful payment is only the start. Before launch, I ask the developer to test the situations that can confuse customers or leave orders in the wrong state. Use test credentials or an approved test environment where available, and follow the payment provider’s current instructions. Safaricom’s M-Pesa Express simulation documentation can help teams understand the simulated prompt flow.
Include at least these cases in the test plan:
- A successful payment that updates the correct order and stores its transaction reference.
- A declined or canceled prompt, as well as an incorrect PIN or insufficient funds where the test environment supports those cases.
- An invalid or mistyped phone number that receives a clear error before checkout gets stuck.
- A timeout or delayed callback, with the order staying pending until the site confirms the final result.
- A repeated click on the payment button, which should not create duplicate charges or duplicate orders.
- A successful payment after the customer closes the checkout page or leaves the website.
That last case matters because a customer can approve the prompt and move on before the website displays the result. The callback should still update the order, and the customer should be able to check the status later. Ask the developer to demonstrate what happens if the same callback arrives twice. The integration should process the payment once and ignore duplicates, rather than changing records or triggering fulfillment again.
After sandbox or approved test-environment checks pass, confirm the steps for production access and credential changes with the provider. Then run a controlled live test before opening checkout to everyone. I also recommend asking the developer to explain what they will monitor after launch, especially during the first busy sales period.
Make Payment Status Clear to Customers and Staff
Customers should see a status that matches what the website actually knows. A request accepted by the payment service means the prompt was sent, not that the payment succeeded. Until the callback confirms the result, show pending and explain that the site is checking the payment.
Use distinct states for pending, paid, failed, and canceled transactions. Each state needs a useful next step. A pending message can tell the customer to keep their phone nearby; a failed or canceled message can offer a retry or another payment method. Once payment is confirmed, send a confirmation and receipt with the amount, order details, and transaction reference where available. Update the order promptly so staff can begin fulfillment without relying on a customer screenshot.
Staff need a secure way to find the same information. Give authorized employees access to the transaction reference, order ID, amount, timestamp, and current status, while limiting access to payment settings and credentials. Clear records reduce avoidable support requests because customers and staff can see whether a payment is still processing or has failed. They also give your team concrete details to investigate a dispute instead of relying on memory or chat messages.
Prepare for Downtime and Payment Reconciliation
Before launch, ask what happens if the website, hosting, network, gateway, or payment service becomes unavailable. A sensible plan should tell customers what to do, prevent an outage from falsely marking an order as paid, and give staff a way to check transaction status when service returns.
Offer a fallback payment method that fits your business, such as a supported alternative gateway or clear instructions for paying through an approved business channel. Tell customers how to share an order reference, but never ask them to send an M-Pesa PIN. If a payment appears pending, give support staff a process for checking the provider’s transaction records before asking the customer to pay again.
Reconciliation is the routine of matching payment records to orders. Your team should be able to compare order IDs, amounts, timestamps, transaction references, and confirmed statuses against the provider’s report. This helps find mismatches, delayed callbacks, and payments that arrived after a customer left checkout. Keep a record of how staff should resolve each case and who can approve a manual order update.
For a Nairobi business, dependable payment handling is both a technical and an operational decision. Ask your developer to walk through a real example in plain language: a customer pays, the callback arrives late, and staff need to confirm the order. If the controls, status messages, and recovery steps are clear before launch, your team is better prepared when a real payment takes an unexpected turn.
Compare STK Integration Costs, Timelines, and Developer Proposals
An STK Push quote makes sense only when you know exactly what the developer plans to build. Two proposals may use different platforms, payment providers, testing plans, or support terms, so the lowest figure may cover less work. I compare them by scope, delivery steps, payment handling, and what happens after launch.
What Can Change the Project Price
A developer may add STK Push to an existing WooCommerce store using a supported plugin or gateway. That can be simpler than building checkout for a custom website or app, where the developer may need to create the payment flow, connect it to order records, and build an admin interface. Even within the same platform, design changes, older plugins, and unusual order rules can add work.
The payment features you need also affect the estimate. A basic checkout for one-time orders differs from a system that accepts several payment methods, supports recurring billing, or connects payments to inventory or accounting software. Custom receipts, staff reporting, refunds, and admin tools can add design, development, and testing time.
Ask the developer to separate one-time build costs from recurring or usage-based expenses. The written quote should identify what it includes, such as configuration, design, testing, training, and launch support. It should also name exclusions, including gateway transaction fees, hosting, domain renewals, maintenance, provider charges, and future changes. Gateway fees vary by provider and agreement, so confirm current terms directly rather than treating them as part of the development fee.
I prefer a quote in Kenyan shillings with clear milestones and payment terms. If a proposal bundles development, hosting, and support together, ask for each item separately. That makes it easier to compare bids and see what you will pay after the initial build. For more context on website development costs in Kenya, compare the scope and pricing model, not just the headline amount.
Questions to Ask Before Hiring a Nairobi Developer
A portfolio can show attractive websites, but payment work needs closer scrutiny. Ask whether the developer has completed an M-Pesa STK Push integration for a similar website or app. If they have, ask what platform and provider they used, what the customer sees, and how the site receives and records a confirmed result.
Then ask them to explain their proposed API approach in plain language. Will they connect directly to Daraja or use a payment gateway? What order reference will link a payment to the right purchase? How will the site handle pending, failed, or repeated responses? Safaricom’s M-Pesa Express simulation guidance is a useful reference when discussing test scenarios.
Ask for the planned test coverage, including canceled prompts, timeouts, duplicate callbacks, and successful payments after a customer leaves checkout. The proposal should also explain transaction logging, credential storage, backups, and how authorized staff can investigate a payment issue without exposing private access.
Before signing, confirm ownership and handover. Your business should control its payment provider account, website hosting, domain, and source code, subject to the contract. Ask what documentation, setup instructions, and staff training the developer will provide. Finally, get the post-launch response time in writing. A payment problem on a busy sales day needs a defined support route, not a vague promise to help later.
Warning Signs in an STK Integration Quote
Be cautious when a developer promises instant setup before asking about your platform, provider account, checkout rules, or order process. A simple plugin configuration may move quickly, but the developer still needs to confirm compatibility and test the payment flow. A quote that gives one unexplained total makes it hard to know what has been left out.
Other warning signs include no testing plan, no explanation of pending or failed payments, or a claim that the site can mark an order paid as soon as it sends a prompt. The payment request and the confirmed payment are different events. A reliable proposal should say how the website receives and records the final result.
Protect your credentials, too. Don’t send API secrets or payment access details through an insecure chat or an open document. A developer should explain how they will receive and store the credentials safely. If the proposal leaves account ownership, code handover, or post-launch support unclear, resolve those points before paying a deposit.
When comparing bids, check which proposal covers order matching, callback handling, testing, and handover. A higher quote may include work that a cheaper one omits. I would rather compare the deliverables and reliability than choose by price alone.
What to Include in the Project Brief
A short written brief gives developers the same starting point and reduces arguments about scope later. Describe the business goal, website platform, customer steps, and payment methods you want to offer. Explain whether customers pay for products, bookings, invoices, deposits, or subscriptions.
Also document how orders should behave. List the statuses your team needs, such as pending, paid, canceled, and failed, and explain what staff should see in payment reports. Include expected traffic, any inventory or accounting connection, receipt requirements, and the test cases you expect the developer to cover.
Add your target launch date, budget range, and ongoing support expectations. Ask for a proposed timeline by phase, with review and approval points for design, checkout testing, and launch. A timeline is more useful when it shows what depends on your feedback, provider approvals, or content delivery. Local website development timelines in Kenya can help you compare schedules for projects with different levels of complexity.
With those details on paper, a developer can estimate the work more accurately and identify decisions that could delay delivery. You can then compare proposals against the same requirements, rather than guessing what each price includes.
How Nairobi Web Experts Can Support an STK Payment Project
An M-Pesa prompt is one step in a larger customer journey. I recommend choosing a developer who can consider checkout alongside the website, hosting, security, and support your business needs around it. Nairobi Web Experts lists services in web development, hosting, cybersecurity, digital marketing, and business technology solutions, but you should confirm what its current proposal covers.
Connect Payment Work With the Rest of the Website
A customer may start checkout on a phone while standing in a shop, riding home, or comparing options between errands. The payment flow should work well on a small screen, load reliably, and explain what happens after the customer approves the prompt. If the payment succeeds, the order should update and the customer should receive a clear confirmation. If it remains pending, the site should say so rather than suggesting the order is paid.
That experience relies on more than checkout code. Hosting needs to keep the website and payment callback available, while HTTPS protects the connection between the site and its visitors. Order emails should reflect the actual payment status, and analytics should help you understand where customers abandon checkout without collecting unnecessary sensitive information.
Nairobi Web Experts describes a broader service mix that includes website development, hosting, SSL and security support, digital marketing, and business IT solutions. Those services may help you coordinate related work with one provider, but a company-wide service list does not mean every item is included in an STK project. I’d ask for the proposal to name each deliverable, such as mobile checkout changes, hosting setup, SSL configuration, order notifications, analytics, and maintenance.
Ongoing care matters after launch, too. Websites need updates, backups, and troubleshooting when plugins or payment services change. A website maintenance checklist for Kenya can help you define what regular upkeep should cover. Also ask whether the developer monitors callback failures and helps investigate payment records, or whether those tasks sit outside the support plan.
Review the Scope Before You Commit
Before agreeing to a project, ask Nairobi Web Experts for a written plan that explains how the STK payment work will fit your site. The integration could use Safaricom’s Daraja platform or a payment provider, and the best fit depends on your platform, account setup, and business requirements. You can refer to Safaricom’s Daraja developer portal when confirming available API options, but ask the team to explain which route it proposes and why.
The written scope should describe the customer flow, including what happens when a prompt succeeds, fails, times out, or stays pending. It should also explain how the site matches a confirmed payment to the correct order, what testing is included, and which party handles security responsibilities. Safaricom or a gateway may set account requirements, so clarify who will help with setup and who will manage credentials.
I’d also ask for an itemized estimate and delivery schedule. The proposal should separate development work from recurring costs such as hosting, provider fees, or maintenance. Confirm who owns the payment account, website, and code, and whether post-launch support includes fixes to the integration or only general website help. Ask the team to put response times and support limits in writing.
Finally, check recent examples of comparable work and speak directly with the team about your platform and checkout needs. Ask them to confirm their current M-Pesa integration experience, available provider options, testing approach, and handover process. A clear proposal lets you compare the promised work with your business requirements, rather than relying on broad service descriptions or assumptions.
Conclusion
A dependable M-Pesa STK Push takes more than sending a prompt. The website needs to match each confirmed payment to the right order, show customers whether it is pending or complete, protect their information, and give your team a clear way to handle failures. Above all, the site should treat a payment as pending until it receives confirmation.
Before hiring a developer, define your checkout needs and compare proposals by scope, testing, security, and support, not price alone. I recommend checking that the plan covers the customer journey and what happens when a payment is delayed or fails. For help assessing proposals, use this website development checklist for Nairobi businesses.
