How to reverse an old C2B transaction using Reversal API
Second Reversal Request sample
How to reverse an old C2B transaction using Reversal API
Second Reversal Request sample
How to create an app, perform an API request (B2C), and perform a quick trace the request from Proxy API to MPesa and back to your callback URL…
So, we have been working on a neat piece of art, an API for M-Pesa, named Proxy API.
And we are proud to announce it is ready!
For quite some time, Developers have been trying (and mostly succeeding) in integrating with the First and Second generation M-Pesa APIs (G1 and G2 respectively). It was quite the effort, requiring VPNs and knowledge of SOAP/XML for you to work with the APIs. Well, they are actually great APIs, the most stable,and the most powerful. as long as one was able use them.
Next came Daraja, their new REST/JSON API. Developers were happy that they finally had an easier option to work with, and most decided to try out the new, better option. It was great at first…
Then the issues began.
Most of us have seen complaints of missing callbacks, long Go Live processes, Forms to fill in and upload (in this time and age, imagine that), weird terminology used on the Documentation and API calls, no way to confirm what URLs are registered on their end e.t.c. That list can go on and on. So we decided to do something about it. We decided to create an M-Pesa API that could pretty much fix most of all issues. And that’s where the idea of Proxy API came from.
Proxy API was so named because it was designed to be literally a proxy: simply receiving requests, reformatting into the required XML format for M-Pesa, and forward the request to M-Pesa. But with that option came the capacity to do a lot more.
First, the API was designed to communicate directly with the M-Pesa Broker API, the most stable API and direct entry point into M-Pesa. Secondly, we decided to use REST/JSON to implement the Proxy API interface. This would make it easier to integrate into the API. We also decided, using the knowledge gained from working with Broker, to simplify the API interface facing the developers. Another feature we added was tracing; we could trace requests from developer to M-Pesa and back, then a developer and even business could see what happened when they made a request. Developers could even see the status returned by their services once a callback has been returned or their endpoints called by the API. This would give the developer more control on their integration process and increase the speed with which they integrated into the system.
Then, with tracing requests, came the capability to keep records temporarily for clients to confirm which records or callbacks reached them or not. Clients could place requests to have undelivered callbacks saved and fetched later on demand. Well, this was as long as Broker actually called us too :-).
Thus, the new Proxy API provides the following features:
We also have more features in the pipeline for all clients, all building on the simple capability of proxying requests. Please check out the new API at
https://api.proxyapi.co.ke. The documentation for the API is at
https://docs.proxyapi.co.ke/v1/ and we even have an openapi/swagger specification at
https://docs.proxyapi.co.ke/v1/swagger/ .
Hope you enjoy it!
For all M-Pesa APIs consultation, contact Peter via consult@peternjeru.co.ke