Home Sms code Without the proper local payment API, Zim’s e-commerce and fintech companies resort to workarounds

Without the proper local payment API, Zim’s e-commerce and fintech companies resort to workarounds

0


If you are South African or South Africa and want to buy something from a local ecommerce store such as Takealot, you have plenty of payment options to go to checkout. In addition to the standard Visa / MasterCard options, there are:

  • The possibility of paying locally using Visa / MasterCard. By locally I mean the transaction is settled locally in Rands. There is no need for money to leave South Africa for this to happen.
  • You can pay by instant EFT. It’s kind of a cross between ZIPIT and RTGS, except that funds are instantly transferred from your account to that of the payment provider from where they can then be transferred to the merchant’s account at will. You can choose from several payment providers:
  • You can pay with eBucks
  • You can pay with the Nedbank personal loan
  • There is Mobicred
  • You can also use MasterPass, whatever happened to the Ecobank MasterPass?
  • There is Snapscan
  • Celbux electronics voucher
  • Zap

I probably missed a few more, but the point of this exercise is to let you understand that Zimbabwean institutions are used to not sharing APIs. Look at Ecocash, even now joining the API is a tedious process. If you want to sign up quickly, you have to go through a third party like PayNow and pay a hefty fee in the process. I also want you to understand how incredulous it is that even in 2021 it is easier, even with all those pesky penalties, to integrate an international payment gateway like PayPal into your ecommerce store than if you mean accept ZIPIT or RTGS transfers.

The problem 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
  • Payments

Now let’s see what’s wrong with each method:

  • Ecocash – is very popular and for a while it seemed to be the solution. Their integration process leaves a lot to be desired. I mean they should now have their own WooCommerce gateway and a simple sign-up page for potential merchants given the rise of ecommerce. If they’ll let you in, you’ll have to code the gateway for yourself. The easiest way is to go through a third-party fintech like ContiPay and Paynow. This was sufficient until the RBZ decided to limit transactions to 5,000 ZWL. Now you need jujitsu Ajax or some other nifty trick to collect payouts if you want to capture payouts instantly and automatically. However, this is still your best bet.
  • OneMoney – Share the same problems with Ecocash. It’s pretty much a USSD service. Unlike Ecocash, they didn’t even bother creating an app. Again, if you want an API, you have to go through some obscure process and probably physically visit someone’s desktop. Forget the WooCommerce or Shopify gateway. If you want an API, go through a third party, but they also have the ZWL 5,000 per transaction against them.
  • Telecash – has even fewer users compared to OneMoney. They were more willing to allow people to use their API, but again they have the limit of ZWL 5,000 per transaction that works against them. Again very few people use Telecash.
  • ZIPIT – this one has very generous limits and would be the perfect solution, unless you thought getting the Ecocash API was difficult, getting the ZIPIT API turned out to be pretty much impossible. When I tried to ask them, I was referred to my bank. Where to start ? The people who run the information desks at API don’t even know what an API is. Not only is it impossible to get API access from banks, but it looks like 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 don’t have to travel much as I’ve never seen it in the wild and in action.
  • RTGS – This cave man solution was never designed for the modern world. In 2021, it is still not a real-time payment method despite what its acronym says. This makes it unsuitable for real-time / automated e-commerce payments.
  • Local transfers – each bank has its own implementation. These are transfers made between accounts of the same bank. Even if a bank were to give you API access, which we have already established is not possible, it limits your customers to one bank. You should register with each bank and do the impossible each time by convincing them to give you access to their APIs
  • Payments- let’s not waste time flogging a horse that is really dead. All the information desks I have spoken to in various banks barely understand e-commerce, they don’t even know what Vpayments is.

Fintechs use workarounds

Frustrated FinTechs are now using smart workarounds to accept local payments automatically and in real time when it comes to local payments. Here are some of the tips I have seen in nature:

  • When purchasing using apps, some apps ask for phone permissions and try to initiate the ZIPIT transaction on their own.
  • In an attempt to bypass the ZWL 5,000 mobile money limit, companies like TelOne and Topup are now allowing split payments. This often involves using timed Ajax requests to test and see if each payment was successful. As a fallback, customers also have a refresh / check payment button they can click, which initiates a background process to check the status of the last payment.
  • Use of unique reference identifiers that can be authenticated against the order after payment has been made. This is a semi-automated process. The payment provider eg ContiPay gives you a unique reference to use when making your RTGS / ZIPIT / Cash deposit. Some guy somewhere enters the reference number on the payment provider’s side as soon as the money arrives in the payment provider’s account. The customer then connects and clicks on the payment confirmation button, the gateway checks if this is true based on the references in the database of the payment provider.
  • The payment provider puts their online bank line in a device plugged into their computer. The gateway scans all incoming SMS for a payment that matches recent transaction details. This is dangerous because SMS can be easily spoofed, but it can and does work. Sometimes banks do not send SMS on time or even at all for some transactions.
  • Same process but with e-mail. An analysis program looks for a unique reference and tries to validate the transaction

These are all workarounds and there are probably many more such ways out there, but it’s just plain sad. For a country that desperately wants us to accept local currency, our government has dropped the ball. The RBZ should do something about it.

Shocking stuff from DPO

So while on the issue of workarounds, I recently observed something really shocking about DPO’s SiD Secure EFT Gateway. When triggered it launches an iFrame, from the iFrame the user chooses their bank, for example FNB, then you are presented with a username and password field and you are supposed to use your Internet banking credentials.

Once you have done that, a loading spinner will appear on the screen above a transparency, under this overlay you can see the actual FNB internet banking platform, some form of script starts browsing clicking on options, goes to EFT option, fills in transaction details, paid clicks, then you are prompted to enter an OTP to confirm the transaction and immediately the overlay also requests an OTP. When you enter your OTP, the transaction is complete.

The platform does the same with other South African banking platforms. How they accomplish this feat is beyond me. Everything is done in an overlay, but such a workaround would be powerful and allow Zim Fintechs to overcome the reluctance of our local banks to solve the e-commerce problem.

You should also check


Fast NetOne, Econet and Telecel airtime recharge


LEAVE A REPLY

Please enter your comment!
Please enter your name here