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.
M-PESA · KENYA · MERCHANT PAY-INS
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 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.
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.
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.
A payment request for the order amount is created through the gateway. At this point your order should be awaiting payment, not paid.
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.
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.
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.
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.
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.
| Question | API (H2H) | Hosted Payment Page |
|---|---|---|
| Who builds the payment step? | Your developers integrate directly with the gateway | The payment step runs on a hosted page |
| Suited to | Platforms and teams with in-house developers | Stores that want a lighter integration |
| How you receive status | Postbacks to your system | Postbacks to your system |
| Question to confirm | Is 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? |
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 (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.
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 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.
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.
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 messageConceptual 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.
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.
To start, visit get started with Payment Gateway Kenya. For how pricing is structured, see our pricing page.
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.
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.
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.
Your system does. Postbacks send transaction status to you as the merchant. They do not notify the customer, so your platform handles customer confirmations.
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.
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.
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.
Ready to add M-Pesa to your checkout? Begin onboarding, check pricing, or have your developers read up on the logic first.