In the previous article, we reviewed the different options to get notified of customer payments. In this article, we will focus on how to reach a decision about the solution to use for payment notifications. You will also find a few real world examples from implemented projects, to illustrate some of the challenges of the process.
Let’s dive in!
A few questions to ask ourselves
First, the type of integration we need strongly depends on the business model. In the end, we need to balance the following criteria in our decision making process:
- What are our minimum and “nice to have” requirements in terms of real time notifications?
- What is our current and expected volume of transactions?
- What is our budget for the integration?
- How long can we spend on the integration process?
Do we need real-time or near real-time notification of transactions? If we are operating a pay-as-you-go model where the customer devices are switched off when the payments are overdue, we probably want to switch them back on as soon as our customers pay. In that case, getting closer to real time is important, and an FTP or API integration would be interesting.
What volume are we looking at? The volume is indeed also important. In practice, if we are dealing with a small volume of clients, manually checking transactions is fine. If we have 500 customers paying every month, it starts to be painful. But if we are handling 20,000 customers, suddenly things become very difficult if we have to manage them manually.
What is our budget for the integration? If we want to start with a low cost integration, moving forward with what the mobile money operator is giving for free would be the way forward. This would avoid the sometimes high upfront fees that they require.
About trying to get an API integration
If a real time API integration with the partner is what we will need long term, it can pay to try to get it from the beginning. However, my experience is that it only works if the mobile money partner has already done that type of integration before, and is performing the integration with its internal IT team. This is rare, and, if those criteria are not met, delays often occur.
A scenario that happened to me a few times is that we asked for an API integration, and our partner agreed. We started the process, and then problems arose. Little progress was made on the project. A typical scenario was that we had to write a full specification for the API, but this document did not seem to leave the management layer of our partner. Aiming for a lower touch integration allowed to build momentum again.
How to get started
If we are reaching for a solution that is not a long term one but would allow a quick start, the following questions can be useful:
- What is already available from the mobile money operators?
- What have they done previously with other customers that they could reuse with us easily?
- What is the bare minimum that we need to get started?
To move quickly, a solution would be to start with what is available on the shelf, and grow from there. By asking “what have you done for other customers that you could just reuse for us?”, and wrapping our own solution around this, things can get done quickly. This might introduce some constraints in the early stages, by doing things that don’t scale, but it allows building a relationship with the mobile money supplier and gets them interested.
So, the final answer? Most often than not, the answer is: we actually don’t really choose. We take what is available and fits in our timeline. Starting small and doing things that don’t scale gets the ball rolling quickly. On the contrary, undertaking a more formal integration is likely to take months.
Some practical examples from the field
Need to just get it done? To make things more practical, here are some examples from the field.
For the first example, we needed real time notifications, but the API integration was not doable in the time scale of our project. The mobile money supplier was offering SMS notifications to a phone number of our choice as part of his standard package. So, what did we do? We used a SMS server to forward those SMS notifications to our database, and we processed them online ourselves. This allowed us to start quickly, and get the real time notifications we needed. After a few months running the operations like this, we then worked on an FTP integration with the partner. We are now moving towards an API integration.
In another case, the only option to receive payment notifications quicker than a weekly email was to manually check the notifications on the web portal of the mobile money supplier. We therefore developed a scrapper that collected the payments data automatically from the web portal. As the operator also had a limit of only 30 logins per hour per user to their portal, this gave us a 2 minute delay for the notifications. It was not perfect, not very robust, not very scalable, but was still acceptable as a first version. We could start processing our customers’ payments. And, a few months later, we are now discussing a full API integration.
The main three criteria – speed of notifications, cost, time of implementation – should be the main drivers in the decision about which integration to go for with the mobile money partner. However, in the end, being pragmatic is the key: adapting to the constraints set by the partner will allow progressing quickly if need be.
We are small, they are big. Getting them interested requires a high low touch approach,but can allow to get into a closer relationship at a later stage.