The eComCharge team has launched a system for finding and displaying server transaction processing logs for its customers: every PSP, running on the beGateway platform, in their back-office now has access to a log of requests and responses between its leased processing system and the acquiring banks with which it works.
“Each of our customers has received an opportunity to view the logs of communication between its processing system and acquiring banks on the transactions of interest to them in a back-office of the leased online payments receiving and processing system, without recourse to our Technical Support,” comments the Chief Product Officer of eComCharge UAB, Alexander Mihailovski.
What are logs?
The log is information about some event, recorded in chronological order, from which you can see how it all began and how it ended.
Any interaction between the processing system and the acquiring bank consists of a chain of requests and responses between the server of the processing system, the server of the payment gateway of the acquiring bank, and very often with the servers of third-party information systems.
It all begins with the initiating request of the processing system to the payment gateway of the acquiring bank. During this and subsequent requests and responses, the servers exchange transaction and service data necessary to make a payment, cancel it, or take any other action provided for by the communication protocol.
During transaction processing, there may be requests to third-party information systems, for example, to verify the payer via 3D secure, conduct the transaction through the risk management system, or the routing system to select the right payment gateway. In the course of all these requests and responses, data is exchanged and each action is recorded in the server log (event log). At any time you can see from this log where and when the request was sent, what it consisted of, how it ended, when, and what response was received.
“The ability to view the log of server requests and responses is very important,” adds the expert. Any transaction that does not end successfully is lost revenue for the merchant and a lost profit for the payment service provider that serves them. The transaction processing itself is a fast but rather complex process, involving 2, 3, or more participants. If a transaction hangs in the incomplete state or fails, it is important to be able to quickly identify what caused this result and, if necessary, take steps to eliminate this cause as quickly as possible.
For example, there are situations when a transaction was initiated but never received its final status, remaining in the pending status. Without access to the server logs, all that a PSP employee can see in their back-office is that the transaction is “pending”. But it is not clear why it is in this status. Maybe the payer was redirected for a 3-D Secure verification and did not return. This sometimes happens, and although it is unpleasant, no action on the part of the PSP is required. Or maybe something went wrong on the side of the payment gateway of the acquiring bank or somewhere else, and it requires an immediate request to the partner’s technical support to fix the problem.
Only the logs of the acquiring bank server can show the whole picture of what happened and help to understand the causes of the problem.
Before the new feature was introduced, only the eComCharge team, as the owner of the beGateway platform, had access to the server logs. This was due to the fact that the storage of all logs in the beGateway cloud platform was organized centrally in one database, with no differentiation of access to the logs of different instances of processing systems within the platform.
Granting access to logs to one customer meant that the customer could get access to logs of all payment processing systems based on the beGateway platform. Therefore, every time any platform tenant needed to understand what happened to a transaction, they had to contact eComCharge’s 24/7 Technical Support.
What updates have been made
“We have changed the way we store and search the logs in the database. We have significantly accelerated its work. We have created a system of access to logs that allows you to give access at the right level, for example, at the level of PSP or at the level of an individual merchant. As a result, the beGateway platform log repository is now able to work with a huge amount of information, quickly search for the necessary data and return the logs only to the customer that makes the request,” explains Alexander Mihailovski.
Thanks to this, now every beGateway platform tenant in their back-office has the ability to view all the logs of communication and interaction between its processing system and acquiring banks with which it works, regarding the transactions of interest to them, without recourse to our Technical Support. This in turn has a positive impact on the response rate of our customers to requests of their customers and to possible incidents with the processing of transactions.
