By 
Integrating M-Pesa into a Kenyan application has never been easier. Safaricom's Daraja documentation is public, community guides walk through STK Push line by line, and a developer with a weekend to spare can have a working payment flow by Sunday evening. That ease of integration has created a new problem that has nothing to do with the API itself: a growing number of billing systems in Kenya accept an email and a phone number, generate a payment prompt, and process a transaction without ever confirming who is actually initiating it.
This shows up most often in two places. The first is digital course and content platforms, where a visitor enters an email and phone number, receives an STK Push prompt, pays, and gets an access link or the material emailed to them, all without creating an account or verifying either detail belongs to them. The second, more urgent given the campaign season, is political and civic fundraising. Several movements ahead of the 2027 General Election have opened public contribution channels asking only for a phone number and an amount.
Both are convenient. Both are also built on an assumption that the payment gateway alone is enough of a gatekeeper. It is not.
What an Open Gateway Actually Exposes
An STK Push endpoint, or a hosted checkout link from a provider like Pesapal or Paystack, does one job: it asks a phone number to authorise a payment. It does not verify that the person filling in the form owns that phone number. If a form on a website accepts any phone number and amount and fires a prompt, nothing stops someone from writing a script that loops through hundreds of numbers and floods each one with a payment request, all attributed back to the shortcode or till of the business running the form.
The consequences are not abstract. Three follow directly from that scenario:
Server and cost strain. A server built to handle normal traffic can be pushed into timeouts by a burst of requests, and on serverless or pay-per-invocation architectures, a scripted flood translates directly into a bill spike.
Provider-side fraud flags. Payment service providers in Kenya operate under obligations to screen and monitor transactions for suspicious activity. The National Payment System Regulations require a payment service provider to use systems capable of screening transactions for compliance with the Proceeds of Crime and Anti-Money Laundering Act and the Prevention of Terrorism Act, and licensing guidance from the Central Bank of Kenya requires providers to maintain fraud prevention tools and transaction limits as part of their ongoing compliance obligations. A shortcode generating an abnormal volume of prompts in a short window, especially with a high cancellation rate, is exactly the kind of pattern that monitoring is designed to catch.
Recipient-side damage. People who receive a prompt from a business they never interacted with are far more likely to cancel it and report the shortcode. Kenyans have already shown a low tolerance for unsolicited mobile prompts and messages; complaints about unsolicited SMS and prompts from unfamiliar shortcodes have been raised publicly and repeatedly by consumers and consumer groups over the past few years. Repeated reports against a till or paybill carry real regulatory weight, up to and including scrutiny of the account and the business behind it.
Why Account Verification Exists in the First Place
Every serious billing system that accepts real money requires some form of account creation and verification before it exposes its payment endpoints. That usually means an email or SMS confirmation step before the checkout page becomes reachable. This is not friction for its own sake. It exists so that any abuse of the billing system can be traced back to a real, verified identity rather than an anonymous form submission. Underneath that first layer, mature platforms add bot protection through services like Cloudflare Turnstile or reCAPTCHA, per-IP rate limiting, and temporary cooldowns after repeated failed or cancelled attempts.
Payment gateways were built to solve a specific problem: automatically linking a payment to an account so a business can identify a paying customer and grant access immediately, instead of the older paybill workflow where a customer pays, then calls or messages the business, reads out a transaction code, and waits for someone to manually confirm and unlock the service. That automation assumes the business has already done the work of confirming who is paying. Daraja and similar APIs were never designed to replace that identification step; they automate what happens after it.
What This Means for a Movement That Cannot Force Sign-Ups
Political and civic fundraising is a harder case, because forcing a citizen wanting to donate ten shillings to first create an account defeats the purpose of low-friction, small-donor fundraising. For that use case, two measures are close to mandatory if a payment gateway with an open form is used at all: bot protection on the donation form, and per-IP rate limiting on how many prompts can be triggered in a given window. Even together, these do not fully stop someone from entering a phone number that is not theirs and sending a single unwanted prompt to a stranger, but they do stop the automated, high-volume version of the abuse.
This is likely why the more prominent 2027 campaign fundraising efforts in Kenya have avoided open payment gateways altogether. Nairobi Senator Edwin Sifuna's Linda Mwananchi movement collects donations through an M-Pesa paybill number, asking contributors to use their own mobile phone numbers as the account reference, rather than through a hosted checkout form. Wiper leader Kalonzo Musyoka's Komboa Kenya campaign followed the same pattern, directing supporters to a paybill number and account number rather than a web-based STK trigger. Former Chief Justice David Maraga's 2027 campaign accepts contributions through a mix of channels, including a dedicated paybill alongside Stripe and PayPal for international donors, rather than a single open-ended prompt generator.
That approach removes the enumeration problem entirely. A paybill number requires the contributor to initiate the transaction themselves from their own phone, using their own M-Pesa PIN, at a paybill they chose to dial into. Nobody else can trigger a payment prompt to a stranger's phone through a paybill, because there is no server-side trigger to abuse in the first place.
The Practical Recommendation
For a business selling access to content or services, the fix is straightforward: verify the buyer, even lightly, through an email confirmation link or an OTP step, before the billing endpoint becomes reachable. A magic link tied to the email address, or a one-time code sent before the STK Push fires, is a reasonable middle ground between full account creation and an open field that accepts any phone number typed into it.
For a fundraiser or movement that cannot reasonably gate small, anonymous contributions behind an account system, the better move is usually to avoid building a payment gateway at all. A paybill or till number, published and shared, puts the burden of initiating the transaction back on the contributor's own phone, where it belongs. For platforms that specifically need a hosted, brandable donation experience, established fundraising infrastructure such as Buy Me a Coffee or Patreon already carries the compliance and abuse-monitoring overhead of running a payment gateway, and there is little reason for every individual site to rebuild that from scratch.
Where an open gateway is genuinely unavoidable, bot protection and rate limiting are not optional extras. They are the minimum a business owes to the people whose phone numbers might otherwise end up in someone else's script.
Further Reading: M-Pesa & Daraja Architecture
Integration Basics: How to Integrate M-Pesa STK Push Using Daraja 3.0: A Complete Guide for Kenya
State & Network Reliability: How to Properly Handle M-Pesa STK Push Timeouts and Disconnections Without Losing Transactions
Security & Callbacks: How to Secure Your M-Pesa Callback Endpoint Against Spoofed Requests
B2C Disbursements: How to Send Money From Your M-Pesa Business Account to Any Phone Using the B2C API
Comments