EA045477B1 - TRAFFIC PROCESSING SYSTEM FOR PAYMENT SYSTEMS TRANSACTION DATA - Google Patents

Description

Technical field

This technical solution generally relates to the field of computational data processing, and in particular to systems for processing transaction data traffic of payment systems.

State of the art

The exchange of money in our time has become much easier for all parties: buyers, sellers, banks and even government agencies. Thanks to the transfer of money from a physical object to an information product, everything happens in seconds, so the overall money supply increases. You no longer need to count banknotes or make sure they are in your pocket at the right time. Everything happens through communication channels, and the name of this global system is payment card processing. Since it can be banking and non-banking, it covers almost all areas where finance appears.

Processing is the process of processing information that exists at the time of a monetary transaction. In other words, this is a technology for delivering money from the buyer to the seller. Behind the usual actions of sending and receiving payments is a complex system that communicates with various participants, verifies, transmits and records data. Since each person makes payments several times a day, and enterprises perform thousands and millions of transactions, processing systems represent a complex, multifunctional mechanism.

Such systems are widely known from the prior art, for example, the front component SmartVista Front - End https://www.bpcbt.Com/m/smartvista-solutions/ has the ability to receive and process traffic from payment systems (MasterCard, Visa, MIR, JCB, UPI, Amex) with subsequent transfer for authorization to the processing solution that performs holding and settlement. The component also has the ability to receive and process traffic from acquiring terminals (ATMs, POS, Kiosks for making payments and collections, payment gateways) with subsequent transmission for authorization to International payment networks or to the bank’s processing solution for authorization.

The disadvantage of existing solutions in this area is the low fault tolerance and speed of system scaling.

The essence of the technical solution

The claimed technical solution offers a new approach in the field of processing transaction data traffic of payment systems.

The technical problem or technical task being solved is the creation of a new system for processing transactional data traffic of payment systems, which has a high degree of fault tolerance.

The main technical result achieved by solving the above technical problem is increasing the fault tolerance and speed of system scaling.

The stated result is achieved through a system for processing transaction data traffic of payment systems, containing two interconnected data centers, each of which contains at least one server for processing and balancing incoming traffic, configured to receive and send messages when interacting with external consumers;

transmitting messages between internal system components in an internal format;

queuing system component processes in accordance with the specified recipient;

logging operations and subsequent sending messages to a distributed message broker; managing timers for processing operations between servers;

at least one processing server configured to reformat and send messages for routing to an external system;

interact with secure hardware storage (HSM), manage cryptographic operations, and perform cryptographic checks;

copying data between data centers;

converting messages into a specified network exchange format;

queuing system component processes in accordance with the specified recipient; logging operations and subsequent sending messages to a distributed message broker; scripted processing of messages and control of script execution, including at least control of the timing of sending messages and checking for data duplication;

identification of bank cards and routing of messages in accordance with identified bank card data; setting a sign that a transaction needs to be verified, as well as sending the transaction for verification to the fraud monitoring system;

managing message processing timers between servers and system components;

implementation and cancellation of scenarios for processing the issuer's operations;

checking transaction objects for restrictions;

at least one server for interaction with external systems, configured to

- 1 045477 data exchange with external systems;

user authentication and authorization;

a distributed message broker configured to transfer data between system components;

at least one long-term data storage server;

at least one online data storage server;

at least one server for storing historical system logs.

In one of the particular embodiments, the server for processing and balancing incoming traffic is configured to process network traffic from external systems and generate an operation identifier.

In another particular embodiment, the processing server is configured to replicate data in the form of two counter independent streams.

In another particular embodiment, each server of the system is additionally configured to transmit metrics to external monitoring systems.

Description of drawings

The features and advantages of the present invention will become apparent from the following detailed description of the invention and the accompanying drawings, in which:

fig. 1 illustrates the general diagram of the proposed system for processing transaction data traffic of payment systems;

fig. 2 illustrates an example of a computing device on the basis of which system servers can be implemented.

Carrying out the invention

The system for processing transaction data traffic of payment systems is designed to interact with electronic service channels and operations coming from them.

The declared solution supports the ability to work with the following service channels:

payment systems (Mastercard, VISA, MIR, CUP, JCB);

acquiring channels (POS terminals, payment and e-commerce hubs, ATM hub and ATMs).

In this case, the claimed system provides the following functionality.

Converting payment network formats into an internal format, as well as supporting formats for working with acquiring terminals, acquiring terminal hubs, and payment gateways.

Execution of business logic scripts and message routing through channels; Ensuring service availability of at least 99.99%.

Ensuring high speed and ease of scalability (proportional addition of servers without additional work on preparing and transferring data). This is achieved due to the fact that the system components act as separate standard units and the system is horizontally scaled by increasing the number of such units. Thanks to the connection to unified servers for data storage, all settings and processed information are automatically transferred to the newly connected system components.

Setting up business functionality without stopping the system; Work with L3 level networks.

Support for work on X86 architecture servers.

Support for working with several data processing centers (DPCs) in Active-Active mode (a system operating mode in which two arms operate in parallel and simultaneously process traffic from payment networks, and switching between arms of the system is carried out when any of them fails) .

Support for the functionality of the system user’s workplace through a WEB interface with a role model.

The declared system implements a number of solutions aimed at achieving the set objectives.

Equivalent worker nodes have been introduced, and storage of operational information in NoSQL (key-value database) has been applied.

NoSQL databases have the following properties:

basic availability - each request is guaranteed to complete (successfully or unsuccessfully);

flexible state (English soft state) - the state of the system can change over time, even without entering new data, to achieve data consistency;

eventual consistency - data may be inconsistent for some time, but come to agreement after some time;

no dependence on storage types;

linear scalability (adding processors increases performance).

Introduced long-term storage on a sharded database based on Oracle technology

- 2 045477

Sharding, using a replication mechanism, to maintain the system's ability to operate in Active-Active mode.

The solution uses a mechanism for working with a description of the business logic of the application in a declarative style based on a scripting language (Lua is a multi-paradigm programming language) to provide flexibility in setting up the execution of business scenarios without stopping the system and the possibility of using canary releases to test new business functions on a limited volume and load.

The system also uses the BGP dynamic routing protocol, which ensures operation with L3 networks.

Increased system fault tolerance is achieved due to the fact that the system is divided into two parallel operating data centers that perform all functions synchronously. Thanks to the connection to unified data storage servers and the implementation of the data replication function between data centers, if one of the components fails, the system continues to operate as before without failures or data loss. This architecture also allows you to upgrade components or increase their number without shutting down the entire system.

In fig. 1 shows a general diagram of the proposed system for processing traffic of transactional data of payment systems (100).

The claimed system (100) represents two parallel operating interconnected data processing centers, each of which contains at least one server for processing and balancing incoming traffic (200), at least one processing server (900), at least one long-term storage server data (600), at least one online data storage server (700), at least one server for interaction with external systems (400), distributed message broker (500), at least one server for storing historical logs (800). All components of the system are interconnected by channels for data transmission.

Servers for processing and balancing incoming traffic (200) are designed to balance incoming traffic depending on the load and availability of application servers within several data centers.

The servers for processing and balancing incoming traffic (200) are configured to transmit messages between internal components of the system in an internal format.

The servers (200) perform: connecting to external systems, opening a logical connection, closing a logical connection, processing network traffic from external systems, sending messages to external systems, generating a transaction ID.

Also, the servers (200) are configured to queue system component processes in accordance with the specified recipient.

Servers (200) process incoming messages from the queue and send messages for processing to the process queue of system components in accordance with the specified recipient.

Servers (200) log operations and send messages to a distributed message broker (500).

Each server in the system (100) writes its own log file, which is stored in the local directory of the server (800). The log is recorded line by line. The amount of data output to the log is determined by the server settings.

At a specified frequency, local log files are separated into a separate file and archived on a separate server (800).

In parallel with the main log entry, messages marked with the AUDIT label are written to the local queue/csaudit of the servers (200). Servers (200) when a message appears in the queue/csaudit, read it and convert it into json format.

The converted message is sent to the distributed message broker (500). After transmitting the message to the distributed message broker (500), the message becomes available for viewing in the system interfaces.

Servers (200) manage timers for processing transactions between servers. When an operation enters the system, a timer is triggered, which determines the time interval for the operation to be active in the system. The servers (200) are configured to reset the timer for processing operations between servers and stop the timer if the operation is executed by the system.

The processing servers (900) are configured to reformat and send messages for routing to an external system.

The servers (900) provide interaction with the secure hardware storage device (HSM) and management of cryptographic operations. Processing servers (900) manage the rules for working with HSM, connect to HSM, encrypt and decrypt messages and data in messages, control connection to HSM, parse different types of messages (requests), generate commands to devices (change network session keys like Key Pin Encryption, signature of the issuer script command, encryption of the issuer script command), sending commands to the HSM device, receiving command responses from the HSM device.

- 3 045477

Processing servers (900) also provide data copying between data centers. Replication is a mechanism for synchronizing the contents of multiple copies of an object (for example, the contents of a database). Replication is a process that refers to copying data from one source to another (between data centers). This function ensures the synchronization of two parallel operating data centers, which allows the entire system to remain operational in the event of a failure of any component in the system. Also, if it is necessary to modify the system, this feature allows you to transfer all functionality to one data center while equipment is being replaced in the second data center.

Servers (900) convert messages into a given network exchange format (convert messages from international payment systems (IPS) (Mastercard, Visa, Mir, etc.) into the internal format of the system, as well as convert the system response message into the IPS format).

The servers (900) are configured to queue system component processes in accordance with the specified recipient. The servers (900) process incoming messages from the queue and send the messages to the component process queue for processing according to the specified recipient.

Processing servers (900) perform logging of operations and then send messages to a distributed message broker (500). Servers (900) perform: parsing process log files, receiving messages from system components, sending received messages to a distributed message broker (500). Each system component writes its own log file, which is stored in the local server directory. The log is recorded line by line. In this case, the amount of data output to the log is determined by the server settings. At a specified frequency, local log files are separated into a separate file and archived on a server to store historical system logs (800). In parallel with the main log entry, messages marked with the AUDIT label are written to the local queue/csaudit of the server. When a message appears in the server's queue/csaudit (900), it reads it and converts it to json format. The converted message is sent to the distributed message broker (500). After transmitting the message to the message broker (500), it becomes available for viewing in the system interfaces.

Servers (900) perform scripted processing of messages and control of script execution, including at least control of the timing of sending messages and checking for data duplication.

The servers (900) are configured to identify bank cards and route messages in accordance with the identified bank card data. Servers (900) provide verification of the ownership of bank cards against the Bank Identification Number (BIN) directory, selection of a message recipient, and return of the message to the system for processing.

The servers (900) are configured to set a sign that a transaction needs to be verified, as well as send the transaction for verification to the fraud monitoring system. A fraud monitoring system designed to evaluate financial transactions on the Internet for suspicion from a fraud point of view and offer recommendations for their further processing.

Servers (900) manage timers for processing transactions between servers. When an operation enters the system, a timer is triggered, which determines the time interval for the operation to be active in the system. The servers (900) are configured to reset the timer for processing operations between servers and stop the timer if the operation is executed by the system.

The servers (900) are configured to implement and cancel scripts for processing issuer operations. Servers (900) carry out logging of actions, caching of rules for automatic delivery of messages, checking the compliance of message parameters with the parameters of rules for automatic delivery of messages, generating messages for automatic delivery, maintaining automatic delivery counters.

The servers (900) are configured to check transaction objects for restrictions (checking the transaction amount, checking the counterparty for restrictions, etc.).

Servers (900) carry out: checking transaction objects in stop lists, and also informing about the results of the check.

Servers for interaction with external systems (400) interact with external systems and are configured to exchange data with external systems, authenticate and authorize the system user.

The distributed message broker (500) is configured to transfer data between system components (100) and is implemented as a server.

Long-term data storage servers (600).

Built on Oracle sharding technology, these servers store transactional configuration data, directories, and data about completed transactions.

Online data storage servers (700).

Built on the Apache Ignite product (GridGain company), servers (700) are required to store operational data that is used to process incoming/outgoing traffic. This operational data includes: directories, intermediate transaction steps.

Servers for storing historical system logs (800). All components of the system (100) write a log and send it to the server for storing historical logs of the system (800).

-

Claims (1)

In addition, the incoming traffic processing and balancing server (200) is configured to process network traffic from external systems and generate an operation identifier. The processing server (900) is designed to replicate data in the form of two counter independent streams. Each system server is additionally configured to transmit metrics to external monitoring systems. In fig. 5 shows an example of a computing device on the basis of which system servers (100) can be implemented. In general, a computing device (300) contains one or more processors (301), memory devices such as RAM (302) and ROM (303), input/output interfaces (304), and input/output devices connected by a common data exchange bus. (1105), and a networking device (306). The processor (301) (or multiple processors, multi-core processor, etc.) may be selected from a variety of devices commonly used today, for example, from manufacturers such as: Intel™, AMD™, Apple™, Samsung Exynos™, MediaTEK ™, Qualcomm Snapdragon™, etc. The processor or one of the usable processors in the device (300) must also include a graphics processor, such as an NVIDIA or Graphcore GPU, the type of which is also suitable for running all or part of the execution of the servers of the system (100), and can also be used for training and application machine learning models in various information systems. RAM (302) is a random access memory and is designed to store machine-readable instructions executed by the processor (301) to perform the necessary logical data processing operations. RAM (302) typically contains executable operating system instructions and associated software components (applications, program modules, etc.). In this case, the available memory capacity of the graphics card or graphics processor can act as RAM (302). ROM (303) is one or more permanent storage devices, such as a hard disk drive (HDD), a solid state drive (SSD), flash memory (EEPROM, NAND, etc.), optical storage media (CD-R) /RW, DVD-R/RW, BlueRay Disc, MD), etc. To organize the operation of the components of the computing device (300) and organize the operation of external connected devices, various types of I/O interfaces (304) are used. The choice of appropriate interfaces depends on the specific design of the computing device, which can be, but is not limited to: PCI, AGP, PS/2, IrDa, FireWire, LPT, COM, SATA, IDE, Lightning, USB (2.0, 3.0, 3.1, micro, mini, type C), TRS/Audio jack (2.5, 3.5, 6.35), HDMI, DVI, VGA, Display Port, RJ45, RS232, etc. To ensure user interaction with the computing device (300), various I/O information tools (305) are used, for example, a keyboard, a display (monitor), a touch display, a touch pad, a joystick, a mouse, a light pen, a stylus, a touchpad, trackball, speakers, microphone, augmented reality tools, optical sensors, tablet, light indicators, projector, camera, biometric identification tools (retina scanner, fingerprint scanner, voice recognition module), etc. The networking facility (306) provides data transmission via an internal or external computer network, for example, an Intranet, the Internet, a LAN, etc. One or more means (306) may be used, but not limited to: Ethernet card, GSM modem, GPRS modem, LTE modem, 5G modem, satellite communication module, NFC module, Bluetooth and/or BLE module, Wi-Fi module and etc. The submitted application materials disclose preferred examples of implementation of a technical solution and should not be interpreted as limiting other, particular examples of its implementation that do not go beyond the scope of the requested legal protection, which are obvious to specialists in the relevant field of technology. CLAIM 1. A system for processing transaction data traffic of payment systems, containing two interconnected data centers, each of which contains at least one server for processing and balancing incoming traffic, configured to transmit messages between internal components of the system in an internal format; queuing system component processes in accordance with the specified recipient; logging operations and subsequent sending messages to a distributed message broker; managing timers for processing operations between servers; at least one processing server configured to replicate data in the form of two counter independent streams; not reformatting and sending messages for routing to an external system; -