Payment Integrations - the perspective of a frustrated backend developer

By Ansel Melly
iHub Consultancy
  Published 26 Apr 2018
Share this Article

~ a backend dev's perspective~

As backend developers,  we can all agree that payment integrations are a pain when it comes utilizing third-party gateways. Here is my experience with several third-party API’s that I have come across.

My main focus is on regional/local gateways e.g. Pesapal, Iveri, oxygen8, Lipisha, and the new kid on the block Daraja by Safaricom to name a few.

A Brief History of Local Payment APIs

We have come quite a long way to where we are now. A long time ago, not that long, there was something called SOAP. You know the XML format of old, yes that is where it all started. To this day I hear gateways that still use soap I cringe, but that is how it all started. This was a strongly typed specification with a strict schema that one needed to adhere to. You had to make sure that every required parameter was as defined. Case sensitive and all that. Hard times, indeed!

Read it here https://www.xml.com/pub/a/ws/2001/04/04/soap.html.

SOAP served us well because we had no choice. To this day some companies still implement this protocol.

Where we are now

In the recent past, we have seen a shift to JSON which is a more flexible, easy to use, pretty straightforward, platform agnostic and developer friendly.

Side Note: To be honest as long as you follow the set rules, respect the process and after hitting the wall, a few rocks and drowning a couple of times you will get to integrate something or at least a subset of the gateway.

My top 5 challenges so far in payment integration

Limited or no documentation

A number of these gateways have little documentation online or even in the pdf spec document. You have to go through the whole pdf, press a few CTRL+F to find what you are looking for, then when you find it, it’s not even what you were looking for. I remember trying to integrate a certain gateway, the documentation was incomplete and the examples provided were just not enough. FYI it’s still soap protocol “hard” is the word

Limited or no support

The next pain point is support. I remember this one time we wanted to use Lipisha for a client project, the emails started out fine, we were happy. Then it came the time to dive into the real code, this is where it became a nightmare. We tried to get a dev guy to sort us out with sandbox credentials/API keys. The response email came but after a month. By then we had already moved on. Support is very important. It gives us devs a sense that things are not going to be that bad. Hah!

Stringent requirements even for testing “sandbox”

Some gateways require one to register an account, give a full history of their dev work, where you were born, when and if it rained the day you were born. LOL!! Just kidding. I have come across some pretty stringent rules for one to even get sandbox access. I guess it because we are dealing with money? :) As a dev, this should not be your headache. Just that your payday will delay by a few million years. I think there should be at least some way for devs to test the gateway without stringent rules when it comes to sandbox access. Daraja or M-Pesa gateway has handled this very well with the latest release of their API. Did I mention it’s in JSON https://developer.safaricom.co.ke/

No sandbox

This one I will not even talk about it. No sandbox? How? Why?

Poorly coded endpoints

Broken endpoints. This happens if there are bad coding practices or someone slept on the job and delivered broken URLs/endpoints. And assuming there is no support it takes forever to resolve this issues.

My take on all this.

In conclusion, Backend devs go through some of the most daring endeavors so that a client can rest easy, ship their products on time and hassle free especially when it comes to third-party API Integrations.

Stay tuned for more updates.


iHub Software Consulting is a design-led company that offers “best in class” software development and design consultancy. Our services include user experience research, design thinking facilitation, and software development. Interested in learning more about our work? Talk to us on[email protected]

comments powered by Disqus