Insights > Network Visibility + Security

Burger Satisfaction vs Card Transaction

2021-04-21  |  8 min read 

With lockdown easing, it was a pleasure to be able to meet up with friends finally at an outdoor area, after some beer and great conversation, it was a good time to procure some food, several options were available everything from salad or big juicy burgers, of course, I chose the juicy burger as the perfect accompaniment to the chilled beer.

Having ordered the full house double cheeseburger, I handed over my credit card to pay, only to find a few seconds later my card was rejected – I knew I had the funds and had successfully used the card a short while earlier without issue. The food was cooked and the burger outlet was card only. Embarrassed, I tried an alternative card, it was also rejected. I am now holding up the queue, is the problem my card, bank or something on the food outlets side? The manager checks the service status portal on the bank's website and it says everything is up. He then tries the next person in the queues card and it also gets rejected.

The card terminal has stopped working!.. it’s a big deal for him. He is now at risk of losing the day of trade, having to potentially discard fresh food and spend time on the phone to his bank, costing trading time in the peak trading window. 

This burger outlet makes great Burgers but as an independent trader, he is not an expert in troubleshooting network connectivity, protocols or APIs, so he goes to rule number one in technology, turn it off and turn it on, cross your fingers and toes...wait a few minutes and try again. Success, rule number one has resolved the issue. He is a very relieved man, as am I with my burger getting colder by the minute.

This got me thinking; How can you effectively pinpoint where this problem is occurring? 

A card transaction isn’t straight forward, there are multiple steps for a transaction to be approved or rejected, this spreads across the merchant’s bank, the card network, and the card issuer. Each of which will have its own APIs (Application Programming Interface – an interface with an application or service) and connecting each step you will also traverse network connections which could be fixed line, or becoming more common with the card terminals, a mobile 3G, 4G or 5G connection integrated into the terminal or piggybacking a phone via Bluetooth.

As one participant in the authorization chain, it is very hard, if not impossible, to be able to ensure that all elements of the authorization chain are up and speaking to their neighbours successfully – there are literally tens of thousands of possible permutations in the connections between the Card Networks and Card Issuers – think how many banks and stand-alone credit card providers there are, and the interfaces between are rarely open to the public internet? However, an outage or a problem should become evident to the Card Network fairly quickly, due to a spike in rejected and timed out connections, or a drop in the percentage of authorised transactions.

However, if you are a Merchant, it is easy to check that the connection between your location(s) and your bank is up and stable, the interface to send transactions to them is available and responding, and at the same time, you can also check the Card Networks service availability. Additionally, the Bank can validate the connection to both the Card Networks and Merchants.

There are several tools available in the market which allow you to test the network connectivity, service availability, either via a Web Portal or API connection, on a continuous basis, so you can be immediately notified when there is a problem and wherein the service chain it is occurring.

This proactive approach will usually provide you with the information to resolve the problem if it’s an issue on your side, or at worst case provides you with the information you can give the Bank if you’re a merchant, or if you’re the Bank the Card Network or Merchant to allow them to rectify the problem in a timely fashion.

One of the solutions which is available is Hawkeye from Keysight. Hawkeye proactively tests & monitors network and application availability and performance, when performance drops below a threshold or it goes offline you are notified of the change along with details of exactly what has changed, allowing you to establish where the fault is and troubleshoot more efficiently.

There are three tests available in the library of 90 test types that could immediately provide you with insight into the performance of a card transaction authentication flow, they are:

  • Rest API Test, to check the availability of an API from a test agent
  • Path Discovery, to monitor the path(s) between a test agent and network resource or service, QoS Changes and Packet Loss
  • HTTP(S) Server Test, to monitor Web Service Availability, Load time and associated performance statistics

Figure: Path Discovery output showing the path to keysight.com from a test agent.

Tests are initiated by Agents, which can either be hardware or software – available for most desktop, server & mobile Operating Systems and can test performance between agents or an agent and a network or application either inside or outside your network on a regularly scheduled biases or ad-hoc. Agents can also be deployed in the Public Cloud.

If you would like to find out more about Hawkeye, please feel free to drop me a message at joel.rudman@keysight.com

Thank you for reading