MPESA AND MQTT

At the recent Sarit (TEMS ICT Expo 2024), attendees were captivated by the rapidity of our Mpesa payment option. Transactions unfolded almost instantly, with confirmation flashing on the device screen moments after users keyed in their PINs. Intrigued by this efficiency, I felt compelled to explore our system's capabilities further...???

As of now, our backend and device communication heavily rely on the REST API. However, we've encountered notable performance shortcomings with this setup. Data must navigate through the API endpoint before reaching the backend, triggering an additional call to the Mpesa Daraja API. This dual interaction significantly hampers speed. Given that the protocol of the payment API lies beyond our control, our focus has shifted to optimizing the elements within our grasp to mitigate these bottlenecks.?

Hence, we're actively considering a transition to MQTT as our next upgrade, envisioning a leap forward in both speed and resilience. MQTT, renowned as the IoT standard for communication, promises to revolutionize our system's performance.

Upon implementation, users will still engage with the Mpesa option, entering their phone numbers as usual. However, the device controller will then expedite the process by promptly publishing data to an STK push topic. The backend, eagerly awaiting this signal, will swiftly initiate the STK push upon receiving the publication from the device. Upon the user's confirmation of payment, the Mpesa API will promptly deliver a callback, thereby marking the transaction as successful.?

??

Anticipated improvements in performance are substantial. We expect this enhanced system to dramatically reduce potential delays, with only one conceivable point of slowdown: the Mpesa API provider.???

Furthermore, this transition would optimize resource utilization. The device's subscription to MQTT topics would not be as resource-intensive, thereby enhancing efficiency, especially in the case of successful transactions. Any post-processing tasks, such as handling failed or suspicious transactions, could be offloaded to the backend cloud, further streamlining operations.?

??

In the proposed setup, the device can subscribe to a select few topics, primarily focusing on confirming the success and legitimacy of transactions. This includes subscribing to the Daraja topic and potentially other custom topics as deemed necessary.?

??

However, before implementation, we must address significant security challenges. During our preparatory phase, we've identified potential vulnerabilities, particularly concerning message integrity and confidentiality. To mitigate these risks, we're planning to implement robust security measures. This includes ensuring Quality of Service (QoS) 2 for message delivery and leveraging the retain message option to optimize performance and resilience. Moreover, we'll prioritize security by implementing MQTT communication over TLS (MQTTS) to fortify against eavesdropping and message manipulation.?

??

Navigating the delicate balance between performance and security remains our overarching objective. While the initial implementation of Mutual TLS was considered, its resource demands proved unsuitable for devices with limited computational capabilities. Consequently, we're exploring alternative solutions, such as a shared SSL certificate, to strike a harmonious equilibrium between performance and security.?

?In tech, there are always trade-offs. For us, balancing performance and security is crucial, especially when dealing with financial transactions. For us, this prospective upgrade to MQTT signifies not just a leap in speed, but also a significant step towards enhanced resilience. Thank you for your continued support as we strive to innovate and optimize our systems.?

?

?Thank you for reading. Until next time...?