Most of the spectacular successes of mobile money initiatives were built on person to person (P2P) payments. This is a transaction were money is "pushed" from one wallet to another in an instant. The recipient of the money is informed immediately that he/she received a payment. Of course, nothing stops one utilising this kind of transaction in a retail environment. One may as well just send money to a shopkeeper's mobile phone to complete a payment.So what is the relevance of the recent mPesa announcement that mPesa can now also be used in supermarkets? (Read here). Well, it is because using mobile payments in supermarkets (or formal retail environments) are much more complex and difficult. Much more have to be catered for that does not just exist in P2P payments. Below is a sample of some of the things that one has to consider:
- The system will have to cater for multiple roles in relationship to a retail account. For instance, one would not want the receiver of funds (the till operator) to also have the ability to pay from this account. Some roles will have more functions while others may have to restricted.
- In order to support the way that a retailer works (and when fully integrated with the store automation), one may want the system to support a "pull" payment, rather than a "push" payment as is the case with P2P. This is much more complex to implement.
- The system will have to cater for other types of transactions, like for instance: refund or reversal transactions.
- The owner of the supermarket typically requires more comprehensive management information and the data stored and displayed will have to be developed in such a way that the information available caters for the need of the retailer. For instance, data may have to carry information related to the types of goods purchased.
- Furthermore, if the system is really advanced and architected well, it would already position the automation for future functionality like NFC for instance.