Introducing Judopay's API Bridge
Welcome to the first blog in our mini-series on Judopay’s API Bridge.
We are super proud to be able to write about our API Gateway. Philip, one of Judopay's Senior Software Engineers, will take you through the circumstances that brought the API Bridge to life, its development and how it has ultimately evolved to become our stand out product…
The Problem...
It's a disastrous situation for a merchant if an API breaks. Functionality that they rely upon no longer works. Adapting to new API requirements requires effort and money. Indeed, if the change is significant enough some merchants may need to reassign engineering resources away from other planned work.
Merchants of an established Payments Service Provider, were faced with the ultimate API breakage:
Its owners were looking to wind down its operations, resulting in their merchants needing to migrate elsewhere. As integral as payments is, an API breakage means loss of business and potentially trading stops if they have no other means to accept payments.
We were acutely aware of just how painful this could be for these merchants, many of whom had integrated with their current API many years earlier, with the original developers no longer around.
Challenge Accepted…
We were willing to take on this challenge, with the aim to make the migration process to Judopay’s Transaction API as straightforward and seamless as possible.
Firstly and importantly:
Their current API consisted of a single endpoint that accepted XML. The XML needed to specify the nature of the request, whether the customer wanted to:
- Take a payment
- Refund money
- Check if a card is working
As well as including any necessary information for the request.
In contrast, Judopay exposes a host of different endpoints, each dedicated to a different operation. We have an endpoint for:
- Payments
- Refunds
- CheckCard
- Voids
- Collections
In addition, our endpoints expect JSON, not XML.
For these merchants, it was going to require significant developer effort to move from their current API to Judopay’s Transaction API. Not because our APIs are complex, but rather they have been built using more modern (and now prevalent) API design techniques.
What made the situation worse was that they were in this position through no choice of their own. We needed a way to make the shift less painful.
A Solution
Our solution was the API Bridge:
The API Bridge would faithfully convert these into equivalent Judopay-style requests and pass these on to our public API.
It would also take Judopay's reply and convert it to the equivalent old-style response.
To give an example, a merchant might send the following XML for a preAuth request:
As mentioned earlier, as well as converting the incoming request, the API Bridge would also take Judopay's reply and convert it to the equivalent current response style.
Their payments requests should still work using their current style. Development effort for the merchant would therefore be minimal.
Rather than have the merchants try to integrate with us, we would try to integrate with the merchant.
The next few blogs in Judopay’s API Bridge mini-series, I will be diving deeper into our solution to showcase:
- The translation work of the API Bridge:
- How it validates requests
- How it converts requests and responses
- Security considerations
- Future possibilities
