This installment continues a mini-series of articles, dedicated to the insights of payment gateway development. We continue to review different aspects, allowing to improve the efficiency of a payment gateway performance and the overall quality of its service.
Payment processing in today’s world has become a necessary service for increasing numbers of emerging online businesses. One of the critical payment gateway quality factors is availability of the gateway 24/7.
However, issues occur from time to time, and the best thing you can do is to be aware of these issues as early as possible to be able to take action swiftly, minimizing potential downtime.
There are two strategies that we recommend when it comes to potential issue detection.
Internal audit of payment gateways
The first mechanism is the internal audit mechanism (self-diagnosing system). This mechanism is “responsible” for detecting any functional problems or errors within the system. Detection of errors can be performed in one of two ways: either through analysis for errors of logs, generated by different components of the system (in special log files or database tables), or through active health checks of various services (this can be accomplished by executing a kind of ping operation on every particular service to verify that it is functioning without errors). If any problems or errors are detected, the internal audit subsystem can notify the administrators about them (using e-mail alerts, SMS etc).
Transaction velocity tracking in payment gateways
In some situations a problem may occur not within the system, but either somewhere along communication channels or on the customer’s end. Instead of pushing the responsibility to other entities, most payment gateway systems try to resolve or at least detect the reason of such a problem. Consequently, a need for a special detection mechanism arises. The mechanism has to detect the situations when transaction flow from a particular client is interrupted, or changes its typical behavioral pattern.
The approach used for detection of such situations is called “transaction velocity tracking”. The idea is to monitor transaction volumes usually received from a particular client during a certain period of time.
Example
Before you develop specific velocity tracking mechanism, you should define which criteria you are going to use to track the transaction volumes, i.e. how you are going to quantify them. While tracking by MID can seem the most obvious approach, sometimes it is not the best one. In many cases instead of tracking specific MIDs it might be more relevant to track specific integrations. Say, if a gateway is integrated with ten different POS systems, it might be appropriate to track each of them as opposed to their individual merchants.
MID-level tracking is more relevant for desktop applications and individual payment terminals. However if you are dealing with a web-application with a centralized server, which uses the same credentials for processing transactions on behalf of hundreds of merchants, tracking by MID is not justifiable. In such cases, it is better to introduce the notion into the gateway, represented by this integrated software package, and then track velocity based on that.
Obviously, the two mechanisms become absolutely critical to the payment gateway, and any malfunction in these mechanisms can cause significant impact. In order to ensure proper functioning of these audit mechanisms, an additional audit service might be required on top of them. This extra layer would allow some external monitoring services, such as Pingdom or Nagios, to do health verifications on the internal audit and velocity tracking mechanisms. Health verification system is going to ping the payment gateway every 5 minutes or so, verifying that the entire gateway system is functional and operational; as part of the process it will verify that audit and velocity tracking systems are functioning properly. While this mechanism is also not a bullet-proof one, it significantly reduces the possibility of something going wrong and you not knowing about it.
Conclusion
The architecture, described above, is suitable for large-scale enterprise systems. If you are dealing with a smaller-size payment system, you do not actually need such a high level of complexity. However, make sure that you do make some provisions, similar to the ones, we’ve mentioned, before you actually go live.
Visit the UniPayGateway website if you are interested in the diagram illustrating this topic.
Recommended to you
