Glossary

Terms Kenyan merchants meet on DukaBot.

15 plain-English definitions of the M-Pesa, Safaricom Daraja, and WhatsApp Business Platform concepts that show up when you run a shop on DukaBot.

STK Push: STK Push (SIM Toolkit Push) is the M-Pesa payment prompt that Safaricom sends directly to a customer's phone. The customer sees a request for the amount in KES and enters their M-Pesa PIN to authorise the payment. DukaBot sends the STK Push through IntaSend, its payments partner, when a customer pays in the WhatsApp chat, so the customer never leaves the WhatsApp Business Platform conversation. IntaSend then calls DukaBot's webhook when the payment completes or fails. Before it marks an order paid, DukaBot asks IntaSend again whether the payment really completed.
Daraja: Daraja is Safaricom's official HTTP API for M-Pesa. It exposes endpoints for STK Push, C2B (Customer-to-Business), B2C (Business-to-Customer), transaction status queries, and reversal requests. Every Daraja call is authenticated with an OAuth token derived from a consumer key and consumer secret, and runs against either the Daraja sandbox or the production environment. A business that integrates Daraja itself needs its own Till or Paybill and its own Safaricom developer credentials. A DukaBot merchant needs none of this. DukaBot collects M-Pesa payments through IntaSend, its payments partner, so the merchant builds no integration with Safaricom's API.
M-Pesa: M-Pesa is Safaricom's mobile money service, the dominant way Kenyan customers pay in KES. On DukaBot it is the default checkout: a customer adds items to a WhatsApp cart, DukaBot sends an M-Pesa STK Push through IntaSend, and once the customer enters their PIN and the payment completes, it lands in the shop's DukaBot wallet at IntaSend. The merchant then cashes out to their own M-Pesa from the DukaBot dashboard. When IntaSend reports an M-Pesa receipt code for a payment, DukaBot keeps it, and the merchant can see it on the payment page of the dashboard.
Till Number (Buy Goods): A Till number is the Buy Goods short code that Safaricom issues to a merchant for M-Pesa payments. Customers pay by selecting Lipa na M-Pesa > Buy Goods and entering the Till and amount in KES. Tills are usually the simpler choice for a single shop without account-number-style references; Paybill is used when sub-accounts matter. A shop on DukaBot needs neither to get paid. DukaBot collects M-Pesa payments through IntaSend into the shop's own DukaBot wallet, and the STK Push prompt reaches the customer's phone while they stay in the WhatsApp Business Platform conversation, so they type no short code at all.
Paybill: A Paybill is a Safaricom short code that lets M-Pesa customers pay with an extra account number, useful when a merchant needs to route funds to sub-accounts, invoices, or branches. The account number tells the business which invoice or branch a payment is for. A shop on DukaBot does not need one to get paid. DukaBot collects through IntaSend, and each payment carries its order id as the reference, which DukaBot checks against the order when IntaSend reports the payment. The customer never types an account number: the STK Push prompt reaches their phone while they stay in the WhatsApp Business Platform conversation.
WhatsApp Business Platform (Cloud API): The WhatsApp Business Platform (formerly WhatsApp Business API), specifically the Cloud API hosted by Meta, is the API surface DukaBot uses to send and receive WhatsApp messages on behalf of a merchant. Unlike the consumer WhatsApp app, the Cloud API supports automated replies, message templates, catalogs, and webhooks. DukaBot reads inbound customer messages, sends the shop's products as an interactive list, and triggers M-Pesa STK Push through IntaSend inside that same conversation, all through the WhatsApp Business Platform endpoints. A business that onboards its own number needs a verified Meta Business Manager, a phone number that is not in use on the consumer WhatsApp app, and an access token scoped to the Cloud API. On the Free, Starter and Growth plans a shop needs none of this: it uses DukaBot's shared, verified number, and the bot routes each customer to the right shop by its shop code; a Scale shop that brings its own number meets those requirements itself.
Opt-in / Opt-out: Opt-in is the customer's explicit consent to receive WhatsApp messages from a merchant. The WhatsApp Business Platform requires merchants to log a clear opt-in source (a checkout box, a USSD acknowledgement, a written reply) before sending any non-template message outside the 24-hour customer service window. Opt-out is the customer asking to stop receiving messages, which DukaBot honors by suppressing further marketing sends. Failing to track opt-in correctly is one of the fastest ways to get a WhatsApp Business Platform number flagged by Meta.
24-hour customer service window: When a customer sends a message on WhatsApp, the merchant has 24 hours to reply freely with any text. After that window closes, the WhatsApp Business Platform only allows messages built from pre-approved message templates. DukaBot's WhatsApp router tracks every inbound message timestamp so automated replies, order confirmations, and M-Pesa STK Push prompts go out inside the free window, and only template-based reminders go out after. Mishandling this window is the most common cause of failed sends on a freshly onboarded Cloud API number.
Message templates: Message templates (sometimes called HSMs, Highly Structured Messages) are pre-approved WhatsApp message bodies that a merchant can send outside the 24-hour customer service window. Meta reviews each template for category (utility, marketing, authentication) before it can be used on the WhatsApp Business Platform. DukaBot ships default order-status and payment-reminder templates that variable-substitute the customer name, order ID, and M-Pesa receipt so a merchant does not need to author them from scratch. Templates with promotional language usually require longer review than utility ones.
Webhook callback: A webhook is an HTTP endpoint that an external service POSTs to when an event happens. In production DukaBot uses webhooks for WhatsApp Business Platform messages (inbound messages, status updates), for IntaSend payment callbacks, and for IntaSend payout callbacks that report cash-outs and refunds. The WhatsApp webhook checks Meta's signature on every delivery, and both IntaSend webhooks reject any callback that does not carry the secret set for the deployment. Even an authentic payment callback does not mark an order paid on its own: DukaBot first asks IntaSend again. A repeated WhatsApp message or payment callback is acted on once, so a retry cannot double-post an order or count a payment twice.
Shop code: A shop code is the short identifier DukaBot assigns to every merchant business: for example, the slug visible at /s/<shopCode>. Customers reach a shop through that code, which is how many merchants can share the same WhatsApp Business Platform number. Shop codes are also embedded in the shop's WhatsApp order link, which on the Free, Starter and Growth plans opens a chat with DukaBot's shared number, and in the shareable storefront URL at /s/<shopCode>, which is how customers discover and bookmark a merchant's DukaBot page. Payments are matched by order, not by shop code: DukaBot creates each M-Pesa payment through IntaSend for 1 order and sends that order's id as the reference.
WhatsApp catalog: A WhatsApp catalog is a structured product list that lives inside a merchant's WhatsApp Business Platform account and can be browsed by customers inside the chat. On DukaBot, the merchant adds products in the DukaBot dashboard, one by one or by pasting the text of an existing WhatsApp catalog into the import page, and customers browse and order those products in the WhatsApp chat. Each order DukaBot records keeps the products the customer picked, and the order's payment keeps its M-Pesa receipt number, so a merchant can trace an order from the products chosen to the payment.
Reconciliation: Reconciliation is the process of matching every M-Pesa payment to the WhatsApp order it paid for. Every payment DukaBot collects is one it created for a specific order, and DukaBot looks it up by its own stored IntaSend reference. Before an order is marked paid, DukaBot asks IntaSend itself whether that payment completed, and only a completed answer marks the order paid in the DukaBot dashboard. When IntaSend reports a payment to DukaBot, DukaBot also compares the order reference with the order, and the amount when IntaSend sends one. If they do not match, the order stays unpaid and the mismatch is recorded.
Daraja sandbox vs production: Safaricom runs two Daraja environments: sandbox for testing and production for live M-Pesa traffic. Sandbox accepts STK Push requests against test phone numbers but never moves real KES; production touches the real M-Pesa rails and a real Till or Paybill. The consumer key, consumer secret, and webhook URLs are separate between the two: never share sandbox credentials with production. DukaBot itself collects through IntaSend, which has its own practice and live environments. A DukaBot deployment runs on one of them as a whole, never shop by shop.
M-Pesa reversal / refund: An M-Pesa reversal is Safaricom's mechanism for returning a paid amount to a customer, either initiated by the customer's Safaricom support call or by the merchant via the Daraja Reversal API. On DukaBot, customer refunds are issued by DukaBot support through IntaSend, in part or in full, for M-Pesa and card orders. DukaBot records the refunded amount against the payment, and an order refunded in full has its DukaBot per-order fee reversed. When IntaSend reported an M-Pesa receipt code for the payment, the merchant can see it on the payment page of the dashboard, which is the reference Safaricom asks for.