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

Garikai Dzoma Avatar
WhatsApp Money exchanging hands, payments API PAYE

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:
  • 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

A Contipay workaround in progress

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

, ,

6 comments

  1. Allen Tatenda Chinodakufa

    It’s true that Econet is stingy and doesn’t share API to make eCommerce websites much easier to transfer funds, I looked into their API (paynow) and it seemed to have errors. I studied SDK and coded my own, it seems to be missing something, it works on everything but when it reaches the URLs, it will return errors. Fortunately its open source and it’s on Github https://github.com/AllenChinodakufa/Paynow_Node_Js_Sdk . Any developer can contribute to it

  2. Always off Topic

    Ecocash took a big blow when they were forced onto Zimswitch, along with the transaction limits.
    The reality in general is that the Zim monetary system is a mess and at anytime it can change from one extreme to another. If only there was some kind of predictability in this space so developers can invest time to making a mature payments api. Paynow have tried to shine some light into the opaque world of Zim financial system, but the problem here is that they are a third party. What is needed is for Zimswitch to pave the way.
    Another thing are in-house developers, i mean do you know any developer that is employed by Zimswitch or Ecocash, do they even have any develpers in their employ or they mostly outsource. Its the same for government as well , if there were developers working in these institutions we would not be in this situation.

  3. ScriptKiddie

    Maybe you should do an article on what an API is..how its conceptualised and developed..is API an acronym or what,..coz most of the readers who come to this blog are not as tech-savvy as you and me

  4. Prosper

    It is ok not to know everything.

    I have followed Techzim on and off over the years, even contributed some articles on payments, and about 10 years later now there are some things even I myself, and a lot of other people know, that you never write out and have never written about whenever the issue of online payments comes up. I also ask myself sometimes, why no one else is saying anything. The information you have written about is not exhaustive. Some week ago I sent an email to you guys asking a question about payments and I did not get a response and I said to myself nah, I think I know why. But it doesn’t matter, because one day, even 15 years from now, you may know and then realise that today you were writing incomplete information even 10 years latter since the pre-vPayments/EcoCash era.

    But I certainly understand people who don’t want to share what they know.

    Anyway, it doesn’t matter.

    1. Paul Walker
  5. Sagitarr

    Your article raises very interesting and valid points. Around 2000, the RBZ then came up with a NPS – Framework & Strategy document (a pdf is downloadable from the web). This was, in my view, a foundational initiative which should have various interfaces to it to achieve the RBZ and all other players’ objectives, including eCommerce. IMO, the missing dimension in Zimbabwe is trust. The ordinary citizens have been robbed by banks, incl RBZ as well as other financial companies, not once, twice or thrice but more times. Financial systems rely on some basic level of trust to function and this has been eroded in Zimbabwe, hence each bank is a silo with little or no seamless APIs between them. This retards growth in eCommerce and yes, what RTGS stands for and what it actually is on the ground shows you that we’re dealing with crooks. The synonym for Real Time is Real Time. Years back, when I was a developer in EFT banking systems, standard FI systems were based on Visa/Mastercard/Diners established transaction protocols. This space was never designed for sole operators, who are ubiquitous today, to write their own systems to interface the banks but messaging protocols were well documented e.g. ISO8583, Visa/MDC II/APACS 30/40 etc The RBZ could do well to come up with a standard protocol which all eCommerce system builders comply with. I doubt this initiative will come from the banks, which had to be forced by RBZ to pay credit balance interest yet they deduct astronomical service charges (for poor service) and make millions in profit yearly; paying interest on credit balances is something banks the world over do as part of their basic function.

Join Waitlist We will inform you when the product arrives in stock. Please leave your valid email address below.