M-Pesa integrations are one of the most common technical projects for Kenyan businesses โ and one of the most commonly done wrong. Not wrong in a way that stops the integration working. Wrong in a way that leaves it open to fraud, manipulation or data exposure.
Most integrations are built to go live fast. The business needs to accept payments. The developer builds the Daraja API integration, tests the happy path, and deploys. Security is an afterthought โ or not a thought at all.
The Daraja API requires a Consumer Key and Consumer Secret. These credentials authenticate your application to Safaricom's servers. In a staggering number of Kenyan applications, these credentials are hardcoded directly into the source code โ sometimes committed to public GitHub repositories.
A hardcoded API credential in a codebase that has ever been shared, pushed to a repository, or accessed by more than one developer is effectively a public credential. Anyone with access to that code can impersonate your application, initiate transactions and drain your Paybill balance.
The fix: credentials stored in environment variables or a secrets manager, never in code. Rotation policy defined. Access logged.
When a customer pays via M-Pesa STK Push, Safaricom sends a callback (webhook) to your server to confirm the transaction. Many integrations simply trust this callback โ if it arrives at the right URL, the system marks the order as paid.
The problem: anyone who knows your callback URL can send a fake payment confirmation. Your system marks orders as paid without any money moving. This is not a theoretical attack โ it is a well-documented fraud pattern in Kenyan e-commerce.
Fraud in M-Pesa integrations doesn't always happen via the API. Sometimes it happens in the gap between what Safaricom reports and what your system records. Without automated reconciliation, that gap goes undetected.
A Kenyan logistics company we reviewed had been processing transactions for 14 months without reconciliation. When we ran the first reconciliation report, there was a KES 380,000 discrepancy. Half of it was a system bug. The other half was unexplained.
You should conduct a security review of your M-Pesa integration if:
A security review doesn't require taking the integration offline. We audit what's live, identify vulnerabilities, and provide a prioritised remediation report.
We identify the gaps and tell you exactly what to fix first.