M-PESA · KENYA · MERCHANT PAY-INS

M-Pesa payment gateway for Kenyan merchants

Accept M-Pesa payments from customers in Kenya through Payment Gateway Kenya and move each order to paid only when your system receives a successful transaction status by postback. Your connection route, API (H2H) or Hosted Payment Page, is agreed during onboarding.

Accepting M-Pesa online involves three jobs: connecting your checkout, handling transaction statuses in your order system and reconciling merchant settlements. Payment Gateway Kenya is a payment gateway in Kenya that processes M-Pesa pay-ins; this page explains the payment journey, the two connection routes and what your team builds on its side.

M-Pesa illustration
M-Pesa pay-ins for Kenyan merchants
Connection route agreed at onboarding:
API (H2H) or Hosted Payment Page
Postbacks deliver transaction status to your system
Merchant settlements are sent on the same day (T+0)

M-Pesa through Payment Gateway Kenya: method profile

M-Pesa is Safaricom's mobile money service in Kenya. For a merchant, its purpose is simple: a customer chooses M-Pesa at checkout and approves the payment, and your order moves to paid only after your system receives a successful transaction status.

M-Pesa is the payment method Payment Gateway Kenya supports in Kenya. Cards, other mobile wallets and bank transfer options exist in the Kenyan market, but Payment Gateway Kenya does not offer them. You can read about them in our overview of payment methods in Kenya, which is market context only.

How an M-Pesa payment moves through your checkout

The exact steps depend on your connection and account setup. The outline below is a neutral journey to help you plan order handling on your side. It is not a technical specification.

  1. Checkout

    The customer chooses M-Pesa at checkout, either on your website or platform or on the Hosted Payment Page, depending on the route agreed for your account. Record the order on your side before any payment step begins, so every later message can be matched to it.

  2. M-Pesa payment request

    A payment request for the order amount is created through the gateway. At this point your order should be awaiting payment, not paid.

  3. Customer confirms

    The customer confirms the payment on their side. A customer returning to your site or closing the page is not proof that the payment succeeded.

  4. Postback to merchant

    The gateway sends the transaction status to your system. This is a message to you, not a notification to the customer. Keep the order open until the postback arrives.

  5. Order paid

    Your system marks the order as paid only when the status it received is successful, then decides what the customer sees next, such as your own confirmation page.

Illustrative flow. Stage names are journey labels, not transaction statuses or API values.

What "M-Pesa STK Push" means in the market

Merchants often search for "M-Pesa STK Push" because this prompt-style experience is familiar to customers. The terminology helps when you talk to your developers and your payment provider.

This description does not define Payment Gateway Kenya's flow. If your checkout needs a particular M-Pesa experience, such as a phone prompt, PayBill or Till, ask the Payment Gateway Kenya team what applies to your account before you build around it. For the difference between going direct to Daraja and using a gateway, see Daraja vs a payment gateway.

M-Pesa integration options: API (H2H) or Hosted Payment Page, agreed at onboarding

Payment Gateway Kenya offers two ways to connect: API (H2H) and a Hosted Payment Page. Both lead to the same gateway. They are integration arrangements, not separate products, and H2H does not mean a white-label service. Which route applies to your M-Pesa setup is agreed with the team during onboarding.

In general, with API (H2H) your own system talks to the gateway and you control more of the checkout logic. With a Hosted Payment Page, the customer is taken to a payment page hosted by the gateway, which can mean less build work on your side. Share your team's skills and checkout design with the team so the right route can be agreed.

Comparing the two general connection routes
QuestionAPI (H2H)Hosted Payment Page
Who builds the payment step?Your developers integrate directly with the gatewayThe payment step runs on a hosted page
Suited toPlatforms and teams with in-house developersStores that want a lighter integration
How you receive statusPostbacks to your systemPostbacks to your system
Question to confirmIs this route available for my M-Pesa setup, and which documentation applies?Is this route available for my M-Pesa setup, and how will it fit my checkout and return flow?

Status handling, payouts and settlements

An M-Pesa pay-in is a customer payment to your business. A customer payout is a separate transfer from your business to a customer and must be confirmed for your account. A merchant settlement is another separate flow: your funds are sent to you. Postbacks do not move money; they send transaction status to your system.

Postbacks: status to your system

Postbacks (webhooks) send transaction status to your system so you can update orders. They do not notify the customer. Your own platform is responsible for showing a confirmation page or sending any receipt.

Customer payouts: availability by account

Payment Gateway Kenya handles payouts as well as pay-ins. Whether customer payouts can be enabled for a Kenyan business is agreed with the team, so ask before you plan around them.

Merchant settlement: same day (T+0)

Merchant settlements are sent on the same day (T+0). This describes when the settlement is sent, not when funds are credited. The time it takes for funds to appear in your account may vary.

Plan your reconciliation around the statuses your system receives. Ask the team which reporting options apply to your account.

For developers: M-Pesa API logic in outline

Your developers will work from the documentation provided for your account. The outline below shows only the order-handling logic most teams build, whichever route is agreed.

Conceptual pseudocode
on checkout(order):
    create payment request for order via gateway
    mark order as awaiting payment

on postback received(message):
    verify message as instructed in your account documentation
    find order linked to message
    if status means successful:
        mark order as paid (only once)
    else:
        keep or update order state as needed
    respond to postback as documentation requires

show customer your own confirmation page or message

Conceptual only. Not real endpoints, fields, statuses or authentication methods. Use the documentation provided for your account.

For background on M-Pesa API terms, read our M-Pesa API guide for Kenya. For a planning view of the whole website setup, see how to accept M-Pesa on your website.

Getting set up and pricing

Access depends on a KYB review, your business type and the requirements that apply. Eligibility for M-Pesa is confirmed during onboarding. No approval or launch time is fixed in advance.

  • Tell us about your business and how you sell online.
  • Complete the KYB checks we ask for.
  • Agree with the team which route, API (H2H) or the Hosted Payment Page, applies to your M-Pesa setup.
  • Build your integration using the documentation provided for your account, then go live once your account is ready.

To start, visit get started with Payment Gateway Kenya. For how pricing is structured, see our pricing page.

M-Pesa payment gateway FAQ

Can I accept M-Pesa in Kenya through Payment Gateway Kenya?

Yes. M-Pesa is the payment method Payment Gateway Kenya supports in Kenya. Your access depends on KYB, your business type and the requirements that apply.

Does Payment Gateway Kenya use M-Pesa STK Push?

The exact M-Pesa flow for your checkout is agreed with our team during setup. “STK Push” is the market term for the prompt-style payment that Safaricom's public Daraja documentation describes as M-PESA Express (Lipa na M-PESA Online), a payment request started by the business. If your checkout needs a specific experience, such as a phone prompt, PayBill or Till, confirm what applies to your account before you build around it.

Should I choose API (H2H) or the Hosted Payment Page?

Both are ways to connect to the same gateway. In general, API (H2H) suits teams that want more control and have developers, while a Hosted Payment Page suits merchants who want a lighter integration. Which route applies to your M-Pesa setup is agreed with the team during onboarding.

Who receives the postback?

Your system does. Postbacks send transaction status to you as the merchant. They do not notify the customer, so your platform handles customer confirmations.

Can I pay customers out as well as accept M-Pesa pay-ins?

Payment Gateway Kenya handles payouts as well as pay-ins, but a customer payout is a separate flow from an M-Pesa pay-in. Whether customer payouts can be enabled for your Kenyan business must be confirmed with the team before you plan around them.

How do M-Pesa pay-ins relate to merchant settlement?

An M-Pesa pay-in is your customer's payment; a merchant settlement is a separate flow in which your funds are sent to you. Merchant settlements are sent on the same day (T+0). This describes sending, not crediting, so the time it takes for funds to reach your account may vary.

Is there a Shopify or WooCommerce plugin?

Check with our team before you plan around an app or plugin. Our Shopify and WooCommerce M-Pesa integration pages describe the connection scenarios, and the team confirms what is available for your specific store during onboarding.

Start accepting M-Pesa online

Ready to add M-Pesa to your checkout? Begin onboarding, check pricing, or have your developers read up on the logic first.