In September of this year, Safaricom announced to the world that they had opened up their APIs (see here for a previous blog in this series which explains what open APIs are, and why they are important). This announcement came just 6 months after Safaricom upgraded its platform to GIn Sep2, which apparently allows for more seamless integrations, and moved their servers from Germany to Kenya. Although this announcement was met by excitement in the global financial inclusion world, there was some skepticism at home in Kenya. Some people cynically remarked that this was nothing more than a marketing ploy, resulting from increasing pressure on Bob Collymore (Safaricom’s CEO) to better collaborate with the market, and to extend the quasi-monopolistic platform to developers. Others commented that the return on the investment Safaricom would gain from opening up was not worth the risk associated with a critical mass of developers plugging into their platform and possibly compromising the entire service. Due to this significant risk, Safaricom would most likely limit the API functionality released, and control the number of players who could access the API. In short, the API would not be the game changer global observers hoped for to move the market towards greater openness.
To get a better sense of what was going on, we visited some of Nairobi’s innovation hubs and spoke to developers. What we expected to see, post the Safaricom announcement, was a critical mass of these developers coding away frantically at their latest FinTech innovation, with ambitions to create the next big thing in digital finance. But after speaking to a few developers, we only heard of one start-up who was integrating their solutions into Safaricom’s mobile money API. Although most of the developers we spoke to were aware that Safaricom had opened up their systems, and even mentioned that they had received several visits from Safaricom staff to discuss the functionality available for integration, they still had not started their integration efforts.
There are several reasons why this is the case. Firstly, the systems are not yet in place to facilitate seamless integration into Safaricom’s platforms. To this point, there is a lot Safaricom can learn from Google Play, the world’s largest open API environment which allows access to nearly 2 million Android apps and solutions. Google Play has created a developers’ portal that allows developers to register, login and then access a slew of documentation, from processes for approval to IP rights, revenue share agreements and all the technical scripts needed for integration. The processes and rules outlined in the documentation are standardized. Google does not have to negotiate different terms with each and every developer that links into their platform. This standardization is designed to handle scale and efficiency, and to make it easy for developers to plug in and launch their solutions to millions of customers.
At Safaricom, things are not yet so seamless. Safaricom has posted its API documentation on its website for the APIs that have been released (B2B, B2C, C2B, pay bill, buy goods). But each company linking into the API still needs to pitch their idea and be approved by the Safaricom team. Revenue share arrangements are negotiated on a case by case basis during the pitch. Safaricom also has provided the community of developers with an email address which they can use to schedule pitches and receive technical support. They have also created an API team to support M-PESA and other API integrations (i.e. SMS). Although developers appreciate having a direct touch-point with Safaricom, to facilitate a critical mass of linkages it is vital to move towards standardized legal processes, technical arrangements and revenue share agreements as some of the world’s largest platforms have already done.
When we spoke to Safaricom, they were aware that standardization was vital to creating a powerful and expansive open API solution. And they also seemed aware that they needed to do a lot more work to get there, and even seemed to have a roadmap towards openness. It is likely that the most recent announcement was a strategic move to create some hype around the API, and to start engaging the developers, with the aim that they would start to explore and learn more about the APIs and the integration possibilities that they enable. Such exploration allows for a modest level of innovation, and integration, until Safaricom moves to a technical platform that really supports openness and allows developers to plug and play to develop their solutions.
We hope that this is just the beginning of Safaricom’s journey to openness, and that they continue to engage the community of developers and build the platforms that facilitate seamless integration. Safaricom has no benchmark in our industry on how to do this well, although they can look to Google play and others for lessons. And as has been the case before, they are the ones setting the precedent. This is why we hope that they continue with rigor and dedication because the world is watching. If this goes well, and they start setting some best practices around openness, we will most likely see many more providers moving towards environments that foster open innovation. And such a move will have drastic impact that will not only reshape our industry by opening up the space for innovation, but also lead to the development of solutions that are beyond our wildest imagination today.
Beautiful article, at least worth reading. From my own experience trying to apply for the Safaricom API, the process is tedious. Email followed by email and the fact that they are still swinging on SOAP requests kinda put me off. I'd expect at the least they'd be able to accommodate PHP. In their defense, I'm only conversant with PHP and just now reading up on WSDL and SOAP requests. Their documentation though is very basic and not exactly friendly to a newbie developer. They'd put in some time in making a more friendlier way for guys interested in the API to contact and reach out to them