--
You received this message because you are subscribed to the Google Groups "Google Developer Group(GDG) Dar es Salaam " group.
To unsubscribe from this group and stop receiving emails from it, send an email to dargtug+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Do you know the procedure to get access to the APIs you listed?
Tony
IT Consultant
8gig Consulting
vodacom does not have an mpesa api.their was a failed attempt to get it live. companies after getting a business account are given a web portal auth by browser certificates.solution is to create webscrappers to automate login and read contents in transaction histories page and push them to the app for collection.disbursment involves a more different process.those who are interested in the solution can contact me.and will see prospects of doing business.
tigo only offers a collection api by doing an xml over http post.same applies to airtel.they do not have a disbursment solution
news flash...vodacom now has a collection api.disbursment still not out
--
--
You received this message because you are subscribed to the Google Groups "Google Developer Group(GDG) Dar es Salaam " group.
To unsubscribe from this group and stop receiving emails from it, send an email to dargtug+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Hello,
I think developing a standard API to MPESA and other such mobile payment systems is an excellent idea. Frankly I am a bit surprised that the telecommunication companies have not done this or somthing like it themselves.
Making the project open-source is also nice as it allows us to collectively work together to solve this problem as I'd imagine there will be a number of technical hurdles to overcome. Ideally the solution would be simple enough such that anyone should be able to adopt it and use it.
With the caveat that I have never actually used MPESA here are my thoughts on the problem:
From what I understood of the suggestion by @Banga, it seems like the onus is on the user to initiate payment, which generates an SMS message that's eventually received, parsed and processed on the server. This is a good approach and for an initial implementation, it's probably the way to go.
That said, it did occur to me that there is a bit of friction in the process for the user. Specifically, they have to get the transaction details right each time they buy something. An improvement of the approach would be something like this:
* User Bob visits site X and wants to buy item Y
* Site X lookups Bob's phone number and sends him/her a payment request to deliver the requested goods / service
* Bob receives the message and responds YES / NO to the request. A non-response is also considered as a NO.
* Site X processes Bob's reply and then responds accordingly.
As I stated, I don't have actual experience with MPESA so I don't know if the above scenario is technically possible (i.e. can a user request payment from another user, and can the receiving user of that payment request just respond with a YES/NO?), but it will help simplify the transaction flow from the user's perspective.
- Jervis
Sent on the go.
Hello,
That's a good idea. I would also suggest you to chek on a system called Centili, it offers a mobile payment but for virtual goods only.. we can use their idea to implement our system.