Without proper local payments API, Zim’s eCommerce & Fintech companies resort to workarounds

If you are South African or in South Africa and want to buy something from a local eCommerce shop such as Takealot you have so many payment options when it comes to checking out. Besides the standard Visa/MasterCard options there is:

• The option to pay locally using Visa/MasterCard. By locally I mean the transaction is settled locally in Rands. There no need for money to leave South Africa for this to happen.
• You can pay using instant EFT. This is kind of a cross between ZIPIT and RTGS except funds are instantly moved from your account to that of the payment provider from which they can then be moved to the merchant’s account at their pleasure. They are several payment providers you can choose from:
  • Peach Payments
  • Pay.at
  • Ozow-which is free for small merchants
  • and Payfast/SiD by DPO
• You can pay using eBucks
• You can pay using Nedbank Personal Loan
• There is Mobicred
• You can also use MasterPass-by the way whatever happened to Ecobank’s MasterPass?
• There is Snapscan
• Celbux eVoucher
• Zapper

I have probably missed a few more but the point of this exercise is to impress upon you the fact that Zimbabwean institutions have a habit of not sharing APIs. Look at Ecocash, even now joining the API is a cumbersome process. If you want to sign up quickly you have to go through a third party like PayNow and pay steep fees in the process. I also want you to appreciate how incredulous it is that even in 2021 it’s easier, even with all those pesky sanctions, for you to incorporate an international payment gateway like PayPal into your eCommerce store than if you want to say accept ZIPIT or RTGS transfers.

The trouble with ZIPIT and EFT

When it comes to accepting local payments for an eCommerce store you have the following options:

• Ecocash
• OneMoney
• Telecash
• ZIPIT
• RTGS Transfer
• Local Transfer
• Vpayments

Now let us look at what’s wrong with each method:

• Ecocash – is very popular and for a while, it looked like the solution. Their onboarding process leaves a lot to be desired. I mean by now they should have their own WooCommerce gateway and a simple sign up page for potential merchants given how eCommerce is booming. If they let you in you will have to code the gateway to yourself. The easier way is to go through third-party fintech like ContiPay and Paynow. It was adequate until the moment the RBZ decided to limit transactions to $5 000ZWL. Now you need Ajax jujitsu or some other clever trick to collect payments if you want to instantly and automatically capture payments. This however remains your best bet.
• OneMoney – Shares the same issues with Ecocash. It’s pretty much a USSD service. Unlike Ecocash they have not even bothered with creating an App. Again if you want an API you have to hop through a murky process and probably physically visit someone’s office. Forget about WooCommerce or Shopify gateway. If you want an API go through a third party but they also have the $5 000ZWL per transaction working against them.
• Telecash – has even fewer users compared to OneMoney. They were more open to allowing people to use their API but again they have the $5 000 ZWL per transaction limit working against them. Again very few people use Telecash.
• ZIPIT – this one has very generous limits and would be the ideal solution except if you thought getting the Ecocash API was hard, getting the ZIPIT API has proven pretty much impossible. When I tried to ask for it from them I was referred to my bank. Where does one even begin? The people who man information desks at API don’t even know what an API is. Not only is it impossible to get API access from the banks it seems no one is even bothered or working on a solution. Instead, ZIMSWITCH is busy pushing an Ecocash/OneMoney/Mobile Money clone called ZIPIT Smart. I hear they have thousands of merchants but I must not get around much because I have never seen it in their wild and in action.
• RTGS – This cavemen solution was never meant for the modern world. In 2021 it’s still not a real-time payment method despite what its acronym says. That makes it unsuited for real-time/automated eCommerce payments.
• Local transfers – each bank has its own implementation of this. It refers to transfers done between accounts under the same bank. Even if a bank was to give you API access, something we have already established is impossible, it limits your customers to one bank. You would have to sign up with each bank and do the impossible each time by convincing them to grant you access to their APIs
• Vpayments- let us not waste time flogging a horse that’s really dead. All the information desks I have talked to at various banks, barely understand eCommerce, they don’t even know what Vpayments is.

Fintechs resort to workarounds

Frustrated Fintechs are now resorting to clever workarounds in order to accept local payments automatically and in real-time when it comes to local payments. Here are some of the tricks I have seen in the wild:

• When shopping using apps, some apps request phone permissions and attempt to initiate the ZIPIT transaction themselves.
• To try and get around the $5 000ZWL mobile money limit, companies like TelOne and Topup now allow split payments. Often this involves the use of timed Ajax requests to test and see if each payment has been successful. As a fallback, customers are also presented with a refresh/check payment button they can click on which initiates a background process to check on the status of the last payment.
• Use of unique reference IDs which can be authenticated against the order once payment has been made. This is a semi-automated process. The payment provider e.g. ContiPay gives you a unique reference to use when you are making your RTGS/ZIPIT/Cash Deposit. A guy somewhere enters the reference number on the payment provider’s side as soon as the money gets into the payment provider’s account. The customer then logs in and click the confirm payment button, the gateway checks if this is true based on the references in the payment provider’s database.
• The payment provider puts their internet banking line into a device plugged into their computer. The gateway parses all incoming SMS looking for a payment matching the details of recent transactions. This is dangerous as SMS can be easily spoofed but it can and does work. Also sometimes banks don’t send SMS on time or even at all for some transactions.
• Same process but with email. A parsing program looks for a unique reference and tries to validate the transaction

All these are workarounds and there are probably plenty more other such ways but this is just sad. For a country that desperately wants us to accept the local currency, our government has dropped the ball. The RBZ should do something about this.

Shocking stuff from DPO

So while on the issue of workarounds I recently observed something truly shocking from DPO‘s SiD Secure EFT gateway. When triggered it launches an iFrame, from the iFrame the user chooses their bank e.g. FNB, you are then presented with a username and password field and you supposed to use your internet banking credentials.

Once you do, a loading spinner appears on the screen on top of a transparent, beneath that overlay you can see the actual FNB Internet Banking platform, some form of script starts to actual navigate clicking on options, gets to the EFT option, fills in the details of the transaction, clicks pay, you are then prompted for an OTP to confirm the transaction and immediately the overlay also asks for an OTP. When you enter your OTP the transaction completes.

The platform does the same with other South African banking platforms. How they accomplish this feat is beyond me. It’s all done in an overlay but such a work around would be powerful and would allow Zim Fintechs to power beyond the reluctance of our local banks to fix the eCommerce issue.

You should also check out