In this article, we’ll share with you our experience of building a lasting win-win relationship with a mobile money supplier. This story and our lessons learned will hopefully be helpful for your own mobile money integrations. In the article, we will cover the following:
- How it all started
- How we failed, and got back on track
- How the relationship developed over time
- And finally, what we learned in the process
How it all started
At the time, I was managing a pay-as-you-go solar home system project in Cambodia. To get the payment component of our project up and running, we decided to work with the leading mobile money supplier in Cambodia, WING.
How we got in touch with our mobile money supplier
Our first contacts with the partner occurred during the early stages of the project, and were very promising. We signed a Memorandum of Understanding, and, after the project started, added an NDA and started the commercial and technical discussions. After a few meetings together, our mobile money partner asked us to prepare a business description of how our system would work together with mobile money.
How we failed, and then got back on track
However, after we submitted this business description, the discussions stopped. Our business description might have been too ambitious; or maybe it was not aligned with the expectations of our partner. Anyway, the discussion went dead for several months. To get back on track, we made the decision to be much less ambitious, and asked our partner if we could just use the standard terms they offered. This allowed us to get the project going, with the following: we would use the bill payment option for our project, and, for notifications, simply receive SMS to a phone number of our choice. We had lost two months, but were back in business
But it does not scale!
Technically, what we needed was real time notifications of the mobile money transactions. At the time, a merchant web portal was not available, and more time intensive integrations, such as API or FTP would have to wait for later. All we got was the SMS notifications sent to a number of our choice. We solved our problem by sending the notifications to a specific SIM card installed into an SMS server in our office. We then forwarded the notifications automatically to our online platform, and processed them here. It was not ideal, not very reliable, and did not scale. But it answered the business requirements: it was enough to get started!
One year later, the relationship developed to a closer integration
One year later, the project had successfully been launched, and our customers were paying regularly using mobile money. With this reinforced credibility, we went back to our partner to discuss what was possible. After a short discussion, it was agreed that we would now receive payment notifications by FTP. As we were flexible on the format of data we could accept, just taking what already existed on their side allowed us to start in less than two weeks.
The next step will be either an instant payment notification integration, or a full API integration. Our partner requires more volume to start such an integration, but they will be happy to collaborate with us on that when the time comes.
In terms of lessons learned, two main things stand out. The first is that, looking back at the project, I realize that it would have been too early for us to design a long-term API integration in the early stages of the project. Indeed, we did not yet know what we needed, and the business model was untested. Now we know what the crucial parts are, and were we would benefit from a full integration.
The second lesson learned is that, by initially doing things that don’t scale, we were able to start the project on time, and start testing the business model. This is only after making sure the business model was valid, that we actually needed more automation. And, when we reached that stage, our partner was happy to work closer with us as we had now proven ourselves. We can only recommend that process!