Are we in the Platform Phase Yet?

A few days ago an old client reached out to me with a request for a recommendation for a good point of sale, POS, provider for a chain of stores they are planning to open.

My first question was whether they were looking for a solution that also integrated payments as well as being eTIMS compliant.

As might have been expected they did want a single offering with all the bells, whistles and nyatitis meaning that checkout for customers would be smooth and transparent irrespective of the clients particular requirements.

Now if this request was made a few months ago the answer from me would have been that that was not possible and they would need multiple devices at each location such as a PDQ for card transactions, a feature phone for mpesa, and an ETR/ESD register to sign tax receipts at the bare minimum.

What that would have meant was that there would either have to be a number of people responsible for handling the different kind of transactions or having to train the cashier to handle the multitude of devices.

Armed with the information provided by our client I started calling around as I know of a large number of colleagues who have developed point of sale solutions.

All of them did not have one component or the other with none being able to provide a single turn-key solution for my client. The component that all did not have was the ability to process credit/debit card transactions while the second most common missing component was eTIMs integration which is the new KRA(KENYA REVENUE AUTHORITY) invoice/receipt signing platform.

On eTIMS the most difficult was processing payments for those who needed the transaction uploaded to their KRA account.

However much that the software based eTIMS solution has spared many businesses the hefty cost of having to purchase the physical device, for some strange reason someone decided that it was a brilliant idea for KRA to also run a national ERP solution with standardised product codes for everyone even the KDF cake maker.

I do not know why they did not just integrate to the GS1 system thus allowing one to scan product barcodes therefore making the whole process of capturing transactions much easier but I digress from the main objective of me writing this as I am sure this was just an oversight by KRA whose teams are working tirelessly to ease the process of them collecting revenue.

So now back to my client, after most of the developers I know telling me that they lacked one component or the other I decided to search for a likely solution online.

Most of the products I found had the same issues I have mentioned above apart from Pesapal (this post is not sponsored or influenced by the organisation) who I have mentioned not because they had ticked all the boxes but because they had an open platform that allowed other developers to plug in to access all the complex components.

PesaPal, from what I read online, allow any 3rd party software developer who needs the various integrations to install their application onto the PesaPal terminal thus eliminating the need to go through all the approvals required to receive payments from across the diverse number of services.

After reading through the PesaPal literature I called back a few of the POS developers I had contacted earlier and asked them to look at what PesaPal was offering and maybe they could find a quick way to meet my clients requirements as well as that of their own existing customers.

All this took place on the Friday before I penned this article but I am almost certain that the response from the POS developers come Monday will be that they would rather build the integrations themselves instead of sitting ontop of the PesaPal platform with fears such as they will steal their clients or it will make them seem like less competent developers.

In the event that PesaPal decides to develop a full POS compliment to their other services then my developers first fear will be realised as happened to me years back when 谷歌 stole my email clients as I slept.

The work that the likes of PesaPal have done now puts them in the same league as Safaricom PLC mPesa which is as a platform and the sooner most of our so called fully stuck developers realise this inalienable fact the sooner they can move on to providing their clients with truly competitive solutions of which payment processing or tax compliance are not as they are now nothing more than commodities.

What PesaPal has done is levelled the playing field for developers in the retail space ranging from those offering solutions to the estate kiosk to the high end steak house therefore allowing the developer to concentrate on the more vertical customisations.

The platform revolution is finally here with us and luckily because of our peculiar requirements and processes it is currently only open to the local developer, so as the likes of Safaricom and our large banks chase after SuperApps the space for integrated all services terminals remains fairly wide open.

Even though the space is wide open the bigger challenge will be the paradigm shift required from our application developers who will need to become comfortable with the fact that another layer no longer provides a competitive edge and that it is not belittling to connect to it but it is a spring board for them to use so as to concentrate on developing more features that give them and their clients a truly competitive edge.

But will they?