Techzim

Zimbabwe and regional technology news and updates

advertisement
Nyaradzo logo

University student develops EcoCash internet payments proof of concept

EcoCash internet payments

EcoCash internet paymentsOne of the things that came out of the EcoCash tour that we were part of recently was that internet payments are not near the top of their priority list in terms of the roll out of payments. Understandably so actually; there are bigger, immediate and bankable needs to address away from the web. Needless to say though, this left the internet entrepreneurs among you feeling somewhat dejected. The only other alternative, ZimSwitch’s Vpayments, is asking that you go talk with your bank first, and maybe it’s just us but that spells ‘long winding processes’.

Eventually of course, both and more will come around, and integrating local payments to a website will be a breeze. But some local geeks are not waiting for that. A first year computer science student at the University of Zimbabwe, Sam Takunda, has developed a skeletal proof of concept system to accept EcoCash payments on the internet. Using an Android application and what he’s are calling an ‘EcoCash-End-Server’, he has shown that it’s possible to accept EcoCash payments made via mobile and verify the money transfer automatically after it’s made. All without needing an official API from Econet. This, conceptually, would allow a merchant’s website to proceed with a sale.

Sam Takunda, says a few organisations looking for a way to collect payment online have expressed interest in this concept already and he may develop the solution further. He also says he plans to provide the code on GitHub freely so other local developers can develop it further if they so wish.

The concept system was made available two days ago and this writer had the opportunity to test it. It worked like a breeze. For a prototype that is. Takunda explained he understands that to make it suitable for use, a lot needs to be done to make the process as secure as possible; the script he made available was just for proving the concept. In fact, instead of a merchant number, their system was using a phone number so transactions were basically peer to peer transfers.

Just to emphasize, any merchant would be ill-advised to just blindly jump onto the concept and ask their average developer to make them such a system. There are a number of things that could go wrong with the communication of messages across the different systems to confirm a successful or failed money transfer. On the merchant side for example, it’s possible for an unscrupulous hacker to send fake notifications of successful transfers and gain access to the merchant’s products. Transacting securely online is a fairly complex affair.

The one advantage is the offline component of the process.  It ensures that a customer is paying a real EcoCash merchant and, if the user checks the confirmation messages they get before they approve a transaction, they can also know they are paying the right merchant. But even that is not foolproof.

Update: Details of the project have been posted on this GitHub page. According to the page, the core system itself is not being open sourced but developers can try out an API that’s been made available.


Quick NetOne, Econet, And Telecel Airtime Recharge

47 thoughts on “University student develops EcoCash internet payments proof of concept

  1. Quite an interesting concept, and I hope Econet is keeping an eye open; they should consider snatching up Sam before he graduates and they would have real talent in their IT department.

    1. @708bcb9dc403357faa30ee4bdeba7ff3:disqus i think they should engage him now he’s only in his first year and the tech is pertinent, tech won’t wait

  2. Way to go Sam. I hope Econet will engage you on working an API for Ecocash as soon as yesterday- i’ve got several ideas on what could be done with such an API

  3. Good on ya Sam. They say (they the Chinese) the journey of a thousand miles begins with a small step. I wish you the bet of success and i urge you not to give up on this one.

    There are a number of things that could go wrong with the communication
    of messages across the different systems to confirm a successful or
    failed money transfer. On the merchant side for example, it’s possible
    for an unscrupulous hacker to send fake notifications of successful
    transfers and gain access to the merchant’s products. Transacting
    securely online is a fairly complex affair.

    I wanted to integrate one of my websites with a local mobile payments solution from one bank and they highlighted the same fear you have. (oh yeah, i even demonstrated how it works to them. That’s for those who fear ideas being stolen.) It is possible, with a manual system to pick out “unscrupulous hackers” you talk about. In fact, they would not be hackers but fraudsters. all you need to do is develop a system that is able to separate the wheat from the chaff in near real-time or on demand. Only when a payment has been registered on both systems will it be confirmed as successful. Well, that was my solution and it works. If you want to see the website you will have to wait a while.

    However, what interests me is sam’s android application. Love that one.

    1. We enjoy the hacking our systems part more than we love the building part. As long as it’s a merchant account you’re using, we are yet to hack ourselves. More on the security when we put the libraries on GitHub.

  4. Exciting indeed…if only Econet saw the true potential of opening up payment gateways on the web for Zimbos as soon as possible!! I’m working on 2 websites that could really use this but Im sure the final product is still months away but when it is finally here I can guarantee I will be one of the first people to sign up! If had the money I’d even donate to get things moving alot faster..lol.

    Good Luck!!

  5. Finally some light at the end of the tunnel. Great work Sam. How about we “crowd-source” or “crowd fund” this project and make it a success?

    The Zimswitch one is hopeless. How can you ask a would be merchant to engage their bank to go on Vpayments. Does Zimswitch know it can cost up to $100,000 just to integrate vPayments on to a banking platform?

    1. If what you say is true, then Zimswitch provides a half-baked service. Payment gateways should be the ones to handle relationship(s) with the banks. Not have the merchant try and convince a bank to interface services

      1. I would not think the problem is Zimswitch. From experience (because i approavhed a number of banks about integrating mobile payments to my website) the problem is the Reserve Bank of Zimbabwe and its over-regulations of everything. Zimswitch may not have a choice. The RBZ is probably trying to force the “Ecocash regulation model” on Zimswitch in the sense that TN bank handles banking regulation compliance while Econet handles the mobile payments technology.

        1. If its RBZ then it would require a change in financial law to be more accomodative of such transations. That means it would be legislative. RBZ is just an instrument of law-ish.

          1. HA! HA! Indeed the financial regulation laws need to be changed. There should be an independent financial services regulator like in the UK and RSA in line with global trends. The RBZ has too much power and little competence. In the UK there is the Bank of England and the Financial Services Authority. If you want to start your own “Paypal” you don’t need the Bank of England. I have had banks tell me that the RBZ has even “vetoed” even what you and I would call “basic” technological advancements. There is a need to restrict the activities of monetary policy from financial regulation

    2. But from their page Vpayments is already integrated with CABS, CBZ, POSB and Trust banks. The merchant has to interface with Vpayments and his customers can then be from any of those banks…

      The merchant has to sign up with a bank, but this is so he has an account for the money to be deposited into, he does not need to integrate with the bank, he only needs to integrate with Vpayments using the API they provide in their documentation.

      1. Below is my discussion with ZSS’s Adam recently. My company banks with MBCA Bank.

        From: Adam Roscoe
        Sent: 23 October 2012 05:17 PM
        To: xxxxxx; Mura Nhekairo
        Subject: RE: vPayments

        Hi xxxxxxx

        [some text removed]

        To summarise, in order to link up for Zimbabwean payments, MBCA will need to complete a Vpayments integration. You will need to speak to them and enquire as to when they expect to do this.

        Best regards

        Adam Roscoe
        ZimSwitch Shared Services – ZSS
        Cell: +263 772 644 144
        Skype: roscoe.adam

        1. MBCA will need to be on the vPayments platform same staera as TN bank is integrated with Ecocash. After the bank is integrated with Ecocash, you can then open a merchant account with them. you do not need to interface with the bank’s system but with Zimswitch’s vPayments. It’s like paypal and your bank account.

          1. Exactly my problem! As a merchant I should never be told to talk to my bank about integration. That’s ZSS’s role not me! (unless its a free service)

        2. But you can integrate right now from the four banks listed on their homepage. As a customer of MBCA threatening to move to another bank may spur them on to engage Vpayments and integrate. CABS and CBZ are the biggest merchant banks so it makes sense for Vpayments to start with them.

          1. “threatening”??? that’s wishful thinking. You think Zim banks care? And i fdont wish to change banks at this moment. Anyway, Zimswitch already has ATM integration with over 80% of banks, they should have used the same channel to model their vPayments…case of poor design or lack there of.

            1. I do not know of any Zimswitch enabled ATMs that let you deposit funds you can only withdraw, so no way of sending someone money using that technology. The Zimswitch webpage talks of ZIPIT as a cross bank payment mechanism, while the physical integration may be into the banks from ATM and POS there is still the need to integrate this at a software and business level so that the banks are happy to deposit money into a customer’s account before they receive the funds themselves (from another bank which settles end of day). I think none of us appreciate the complexities of trying to get the banks to enable such functionality. Simply saying do it by ATM is not viable.

              What would be nice is an indepth explanation from Zimswitch on how and where each bank is integrated, but I very much doubt they can make this info public.

              1. Depositing cash on the ATM is a totally a different story for another day. Zimswitch currently has ATM/POS intergration with most Banks and they should use that same intergration layer to develop vPayments, the same way they are modelling ZIPit along the ATM/POS grid.

                I have been in the Banking ICT sector for the last 8 years and I know what I am talking about. Right now I am writing an API to enable ZIPIT on our core banking system.

        3. If they have implemented the integration with particular banks. It would only make sense to make use of those banks. It is highly unlikely that a corporate entity as big as a bank would be swayed to implement something because of one customer request. It is almost impossible unless it is internally suggested as a business case. Looking at your scenario, I think it will be best to open an account with the specific banks that have that integration completed. The process sounds cumbersome but it’s certainly better than waiting for MBCA to integrate. Not much you can do if you really want the service

      2. But from their page Vpayments is already integrated with CABS, CBZ, POSB and Trust banks

        vPayments is not intergrated with any of those yet. i can tell you that for a fact. From what i found out a week or so ago, all of them and even Zimswitch are awaiting RBZ approval. I asked Trust Bank and POSB and I can tell you for a fact that even their people know nothing about vPayments.

  6. A pitty it’s too late to be entered into ZOL’s Jumpstart Challenge to receive the additional funding to get it to the next level and possibly a working prototype.

    Well done though and glad it’s a Zimbabwean that’s getting it done not geek for hire from India.

    1. Maybe he could approach Zol for some sponsorship of sorts or if he wants possibly find a venture capitalist to back him though I know in Zim we don’t really like to give away portions of our company to other people. 🙂

      1. Last time I heard there was Econet Capital that was a venture capital company. maybe find out about that one. i understand it is the one that holds the stake in Mutare Bottlers.

  7. Thumbs up to Sam Takunda, this is what Zimbabwe wants, we can’t rely on paypal or who else outside for our local transactions. If this masterpiece gets refined, I think this system will be a success especially to the retail sector, the arts industry and content providers. Also making integrations with other international content providers.

  8. Econet pliz this prototype is a message to you. you should not ignore this because its a leap-frog in the right direction

  9. Genius concept, when are you planning to have this on Github & what scripting language are you using? Please update with the Github link, well done man.

  10. Nice one @twitter-235487886:disqus. Make sure you patent your ideas as soon as possible before the vultures land. Even though they are still unrefined and require massive development they are worth protecting! Good luck mate we will keep watching the space.

    1. What? Software patents are evil. Besides, without taking anything away from his talent & ingenuity, I doubt its worth all that hassle…and he is opening up the source thru github

  11. i feel and see so much energy and drive from you guys and i feel compelled to jump in and get involved somehow. So first thing i would like to do is find some developers to work with me on developing some solutions that can put Zim on the map.Please send emails and areas of interest project wise to ndinimotto@hotmail.com

  12. this is not a very well written article. grammar + a lot of obscure and unnecessarily verbose statements. explain the peer to peer phone number part. clear it out i for one don’t really get and believe me i am not really that dumb

    1. peer to peer transfers are those between two ordinary mobile phone subscribers. Peer to merchant on the other hand are those from an ordinary phone user to a merchant or agent. merchants are those that have EcoCash as one of their means of collecting payment for goods or services being sold to a customer. Agents are EcoCash branches that can take in EcoCash deposits abd withdrawals.

  13. i know am late in the game – but Great work Sam! How about looking at Zong.com and seeing how they did it re:security. I think you should honestly put this project on Kickstart and we can not only congragulate but pitch with some cash!

  14. The reason Econet is taking the back seat is common in our country – they have some elements of “Technophobia” and some myths surrounding ecommerce. They want to reduce risk (a fact but impractical because they surpress tech) thereby avoiding those “spicy” avenues of technology. Transacting over 128 bit encryption etc over GSM is a lot safer than the internet thats why they avoid the internet avenue (but the internet is safe as well).

    Econet has to simply avail an API representing the EcoCash functionality. This “hide away” attitude must come to an end. The same reason someone can avoid EcoCash (pin being compromised with access to the EcoCash sim card) still apply in the internet API case. EcoCash can further enhance security by using usernames and passwords for internet API case rather than 4 digit pin which will definately be hacked into in just a blink of an eye. They can further limit API authentication attempts just as they do with recharge cards etc. Econet just apply ecommerce best practices which see to the multi-billion dollar ecommerce industry worldwide and you be home and dry.

    EcoCash has to avail the API. Any other innovations are not that secure if not insecure (unless they not realtime with human intervention somehow – making them unusable for serious business then). Generally anything without an official EcoCash API would open security loopholes like spoofing, forgery of confirmation messages, impersonation etc.

Comments are closed.