Streaming information with websockets
Websockets have been around since the early versions of the HTML5 specs, and became a fully supported and standardized in 2011. This marked an end of an era of “heavy” HTTP polling - who would not remember implementing the AJAX calls with setInterval to get an update from a remote location!
With websockets entering the scene, we welcome an era where we can maintain a single duplex connection, sending and receiving at the same time. There is no need to start and end a regular HTTP request, as websockets connect with an HTTP 1.1 upgrade header, and then the line is open until one party decides to close it.
While you have the communication line open, you can not just send random messages, you can group them by ‘channels’. This is done by broadcasting messages and updates on the right channels from the server side, and then subscribing to these channels on the client side. Then it’s just a matter of handling the incoming messages, while these subscriptions are in use.
At The Payment Works, we've been working on a product for tech teams who are dealing with e-commerce related integrations and general payments products. We called the product TestingPays (it does exactly what it says on the pack!); we wanted to create a service to help developers, testers, automators, devops to integrate with payment and fraud APIs faster and more successfully, and once integrated, to maintain the payments code at the best level. We want to free tech teams from the frustration of working with payments and fraud. One way we sought to achieve this was by giving you tech folks the full visibility and insight into your transactions as they hit our service.
At the core of this all, we designed what we call the ‘Live Log Tail’ debug feature available on all our API sims. We share the internals of our API sims, and give you real time information about your requests, how they traverse our system and how and why you get the response you received. We do this with the help of websockets, publishing every event and logic check that happens. Then we setup our client code to subscribe to each of your sim logs, then give you full control how and when you start the following the logs, pause and play them as you like.
Our aim with this level of control and insight on test transaction is to shed more light on each payment API. The 'live' nature of the tools we think helps guide you through your integration work, making that bit more interesting and satisfying. Moreover, the API sims are perfect tool for you to run your Continuous Integration suites on payments code, giving you a better coverage of your code. TestingPays also gives you ability to trigger any possible API response ranging from successful transactions, through validation errors to specific server errors and latency/timeouts.
Using TestingPays you can now remove the various shortcuts in your tests - whether they are manual or automated. Now you can build and maintain applications that are sure to be ready for all scenarios that may happen on your production systems. The platform wraps up some of the knowledge and expertise on payments that we have gathered along the years; we're hoping it's useful to other engineers like you in helping to build better payment integrations.