In 2015, Safaricom relocated M-Pesa servers to Kenya from Germany at a cost of $75 million. The migration also saw the retirement of the initial M-Pesa build known as G1. G1, had several problems including delays in the process of cancelling a transmission of funds when a user has sent money to the wrong person. Such transfer reversals could take an hour.
In addition, the speed of notifications was slow taking up to 10 seconds to receive a confirmation message. The new build known as G2 saw improvements in the time taken to receive confirmation messages besides increasing the number of transactions per second to 900 from 450.
The G2 also allowed Safaricom to finally open up the M-Pesa API to 3rd party developers. The APIs available were a C2B that allows a business to charge a customer directly from their M-Pesa account, without the need for USSD prompts. There was also a B2B API that allowed clients to make direct bank transactions on the M-Pesa platform.
However, developers complained that the API (Application program interface) was not suitable for them. The API was not RESTful (Representational State Transfer) but in SOAP (Simple Object Access Protocol) which meant developers had to conform to the limits of the API in the creation of their solutions. Others complained that the documentation made it difficult to use the API altogether.
In the announcement of their HY’ 16 financial results, we posed the question to Safaricom’s CEO Bob Collymore who acknowledged a lot more needed to be done to make the API accessible to developers. In a recent interview with Safaricom’s head of financial services, Ronald Webb, we sought to understand what steps the telco was making with the view of making the M-Pesa API available to developers.
“We are continually evolving the API and at the moment undertaking a massive project to the make the API easier for all those who want to use it”, said Ronald. “The initial platform had no API, the second generation had an API meant for developers to integrate the way Safaricom exposes it to you, what we are working on will accommodate developers how they want,” he said of the current efforts.
According to Webb, the new API will have 20 different variants with methods for python, .net, ruby developers and much more. The documentation and methods will be better suited for the current environment. “Currently, you need to have excellent XML competence and conduct complex call backs to engage with the API. The goal is to simplify it for all devs,” he added.
The new API which will be available early 2017 will include several components such as a sandbox for testing, portal for developers and much more. “We want to lower the time from when a developer registers to when they test their code to minutes. After completing development, us conducting security checks and testing the behavior of the user interface, a developer should be able to finish this in a matter of days or hours from the current time frame of a month,” he says.
