WhatsApp AI Agents in Kenya: Architecture, Costs and M-Pesa

A WhatsApp AI agent for a Kenyan business works when it stays inside Meta's messaging rules, hands conversations to people at clear points, and treats every M-Pesa payment as an event that can arrive late, arrive twice, or never arrive. Much of the build effort tends to sit in conversation design, the payment integration and operations, rather than in the language model call itself. This guide sets out the architecture, the cost categories and the M-Pesa and consent steps for a WhatsApp chatbot in Kenya.

How the WhatsApp Business Platform sets the rules

Two platform rules shape almost every design decision: the 24-hour customer service window and the template and opt-in requirements. Meta describes the window in its send messages documentation. When a customer messages you, a 24-hour timer starts. If the customer messages again before it expires, the timer resets to 24 hours.

Inside that window, a business can send service messages such as text, images, documents, location messages and interactive reply buttons or lists. When the window closes, the business can only send pre-approved template messages. Meta also states that businesses can only message WhatsApp users who have opted in to receive messages from them.

The practical consequence for an AI agent is that it should not be designed as a sender of proactive marketing. Its strongest use is answering inbound questions, collecting details, taking an order and confirming a payment, all inside the window the customer opened. A reminder after the window has closed needs a template and a recorded opt-in.

Architecture of a WhatsApp AI agent

A production agent usually has more parts than the chat interface suggests. The components below are the ones that have to exist, whatever vendor or framework you choose.

• Inbound webhook receiver. Accepts messages from WhatsApp, verifies the request, stores the raw event and returns a success response quickly.
• Queue and worker. Processes each message asynchronously so that a slow model call or payment request does not block the webhook.
• Conversation state store. Holds the customer's current intent, collected fields, open orders and the timestamp of the last inbound message, which tells you whether the service window is still open.
• Orchestration layer. Calls the language model with a bounded set of tools, such as a product catalogue lookup, order status and the payment service. The model should not hold business rules that the database already enforces.
• Payment service. Owns the M-Pesa integration, the payment records and reconciliation, described below.
• Handoff queue. Routes a conversation to a named person with the full context attached.
• Audit and consent log. Records what the agent said, what the customer agreed to and when.

Keep the model layer replaceable. The rules for prices, stock, eligibility and payment status belong in your own systems, so that a change of model provider does not change what the business has promised a customer.

Conversation design and human handoff

Conversation design decides whether customers finish their task or give up. Start with a short list of intents that matter to the business, such as checking an order, booking a visit, asking for a quote or paying an invoice. Each intent needs a defined set of fields, a confirmation step before anything irreversible, and a clear exit.

Handoff rules should be written before launch, not improvised afterwards. Common triggers include:

• The customer asks for a person, in English, Kiswahili or Sheng.
• The agent fails to classify the intent after two attempts.
• The customer reports a complaint, a payment that did not go through, or a dispute over an amount.
• The conversation touches health, legal or financial advice that the business has not authorised the agent to give.
• The customer's payment amount does not match the order.

A handoff should pass the transcript, the collected fields, the payment reference if one exists, and a one-line summary to the person taking over. Passing this context on means the customer does not have to repeat their order number. Decide who covers handoffs outside working hours and what the agent says in that case.

M-Pesa Daraja STK push and callback reconciliation

Safaricom's Daraja developer portal gives developers access to Safaricom and M-Pesa APIs. For a WhatsApp checkout, the usual pattern is an STK push: the business asks the customer's phone to show a payment prompt, the customer enters their M-Pesa PIN, and the result is returned to the business through a callback.

The callback is an asynchronous notification. The design rules below follow from that, and they do not depend on any single vendor's implementation.

• Create the payment record first. Before the STK push request is sent, store an order payment record with your own reference, the amount, the phone number and a status of pending.
• Treat the callback as evidence, not as the only source of truth. Match the callback to your pending record using the reference fields you sent. A callback that matches no record should be stored and flagged, not ignored.
• Store the raw payload before acknowledging. If processing fails after acknowledgement, the raw payload is what lets you recover.
• Make the callback endpoint reachable and secured. Plan for a public HTTPS endpoint, and restrict or verify inbound requests according to the access controls your integration documentation specifies.
• Run a reconciliation job. A scheduled job should find pending payments older than a threshold you choose, check their status through the transaction status process, and update or flag them. The threshold is a product decision. An illustrative starting point for a small shop might be 10 minutes, to be tuned against observed callback delays.
• Tell the customer what happened. After a successful payment, confirm the order in the chat. After a failure, say so and offer one retry. Do not tell the customer a payment succeeded until your record shows that it did.

Idempotency and failure cases

Idempotency means that performing the same action twice has the same effect as performing it once. In a payment flow, this is the difference between one charge and two. Each order should carry a single idempotency key, and every write to the payment and order tables should check that key first.

Test these cases before launch by replaying recorded callbacks, including duplicates and out-of-order arrivals, against a staging copy of the payment service.

Costs

Costs fall into two groups: the one-time build and the running costs. Pawanax's published rate card lists the WhatsApp Agent Factory at $48,000, or KES 6,192,000, over an estimated 5 to 7 weeks. The published scope includes intent taxonomy and conversation design, the WhatsApp Business API agent build, human handoff and escalation paths, an analytics dashboard, a playbook and an operations runbook, and 50 Personal Plus seats for 12 months. Evidence class: Proposed. The price and scope are published offer terms; the repository does not document a delivered client engagement for this package.

Running costs are separate and are set by different parties.

The handoff line is easy to leave out of a budget. The following is an illustrative assumption, not a forecast: 3,000 conversations a month, a 20% handoff rate and 4 minutes of staff time per handoff. That gives 600 handoffs and 2,400 minutes, or 40 staff hours a month. If a team can handle that load, the agent is saving time. If it cannot, the handoff rules need to be tighter or the staffing needs to change before launch.

Consent and the Data Protection Act

Kenya's Data Protection Act, No. 24 of 2019, governs the processing of personal data, including the phone numbers, names and payment details that a WhatsApp agent handles. Practical steps for a business deploying an agent include the following.

• Record the opt-in. Store the time, the channel and the wording the customer agreed to. A template message to a number with no recorded opt-in is a compliance gap as well as a platform risk.
• Collect only what the task needs. An order status check does not need a national ID number.
• Give a simple way to stop. Accept a clear opt-out word and act on it in the same conversation.
• Set retention rules. Decide how long chat transcripts, payment records and audit logs are kept, and delete them when the period ends.
• Plan for access requests. Be able to find and export one customer's messages and payment records.
• Get legal review. The lawful basis for each processing purpose, and any cross-border transfer, should be confirmed by counsel for your business before launch.

Frequently asked questions

Can a WhatsApp chatbot in Kenya message customers first?

Yes, but only in the way the platform allows. Inside an open 24-hour window, the business can send service messages. Outside it, the business can send only pre-approved templates, and only to customers who have opted in. An agent that waits for the customer to write first avoids most of this constraint.

Does an M-Pesa STK push confirm payment straight away?

Not reliably. The payment result comes back as a callback, and the callback can be delayed, duplicated or missing. Keep the order pending until your own record shows a matching, successful payment, and run a reconciliation job for orders that stay pending too long.

Does a WhatsApp AI agent still need people?

Yes. The agent should handle the repetitive and well-defined parts of a conversation and hand off complaints, disputes, unusual requests and payment mismatches. The handoff rules and the staffing to meet them are part of the design, not an optional extra.

What does it cost to build one?

Pawanax's published WhatsApp Agent Factory package is $48,000, or KES 6,192,000. Ongoing costs include message charges set by Meta, model usage, hosting, payment fees and handoff staff time. Each of these should be estimated from your own volumes.

Next step

If you are deciding whether a WhatsApp agent fits your customer journey, the WhatsApp AI consultancy page sets out the scope, the deliverables and how an engagement is structured. Bring your current volumes, your handoff capacity and the payment flow you want to automate.

Sources

• Meta, WhatsApp Business Platform: Send messages, customer service windows
• Meta, WhatsApp Business Platform: Messaging limits
• Safaricom, Daraja developer portal

Continue exploring

Why Most AI Pilots Fail Before Production: Evaluation Framework. Evaluating an AI Consultancy in Kenya: A Buyer Checklist.

Cover: Photo: Ivan Small, via Wikimedia Commons, licensed under CC BY-SA 2.0 (https://creativecommons.org/licenses/by-sa/2.0). Illustrative image; not a photograph of a Pawanax system or client. Credit: Ivan Small (Flickr: https://www.flickr.com/photos/imtfi/20421361873/), via Wikimedia Commons. CC BY-SA 2.0. Original source.