EA033637B1 - System for controlling a pos terminal network - Google Patents

Abstract

The present technical solution relates, in general, to the field of computer technology, in particular to a system for controlling a POS terminal network. The technical result consists in providing centralized control of POS terminals under the control of a UPOS standard, with update functions being realized by means of a software component of a multiplicity of POS terminals. The claimed technical result is achieved by a system for controlling a POS terminal network which comprises at least one UPOS server linked by a data transmission channel to a device for carrying out financial transactions, to which device one or more POS terminals operating by means of UPOS software, a UPOS agent module and a server for authorizing transactions are connected, in which system the UPOS agent module can route data between the UPOS server, the POS terminals and the device for carrying out transactions; a POS terminal can receive client requests for performing transactions, can verify clients and can encrypt the transaction data of client requests; the UPOS server can monitor and check the parameters of the POS terminals, can control the operation of a POS terminal, can generate scripts for processing transactions and interchanging data with the server for authorizing transactions, and can update the parameters of a POS terminal.

Description

Technical field

This technical solution, in General, relates to the field of computer technology, in particular to a system for controlling a POS terminal network.

State of the art

The prior art solution for the effective management of POS-terminals using the universal protocol Unified POS (UPOS) (US 7889384, published 02/15/2011, patent holder: IBM Corporation), which discloses a mechanism for organizing commands transmitted from the cashier device to POS- terminal when performing transactions. In particular, this solution is aimed at reducing the information printed by the POS terminal printer when recognizing complex transactional transactions, which significantly increases the processing time and can lead to the loss of some or all of the information identifying the transaction.

One example of the solution to this problem proposed in the above patent is the transfer of a part of the functionality executed by the POS terminal program logic to the host to which it is connected for processing based on the identifiers of the corresponding operations by the host software, which will reduce the computational load and chance occurrence of errors in the recognition and processing of transaction parameters.

A significant drawback of this solution is the configuration of the transaction execution system, since transferring a part of the functionality to the host partially solves the problem of reducing the computational load and increasing the stability of POS terminals, but does not avoid the problem of managing the technical state of the terminals.

Also, the existing system of registration and management of a network of POS-terminals does not allow to update UPOS software on the entire terminal fleet with the help of a single node generating appropriate information commands.

Today, software updates lead to a large number of errors when replicating software versions. As a result, legacy software versions work on many terminals, which leads to an increase in transaction processing time, incompatibility of functional execution, etc. In addition, the procedure for updating software and settings often leads to a malfunction of the terminals. At the same time, the development of acquiring functionality requires regular operational updating of terminal software.

UPOS software has evolved over the years. During this time, a large number of improvements have accumulated in the software, which are superimposed on each other, which reduces the readability of program texts and, as a result, negatively affects the possibility of making changes, and also increases the number of errors that arise in the process of making changes.

The presence in the UPOS software code of both functions for working with POS terminal devices and business logic leads to increased consumption of terminal resources (processor, operational and long-term memory), which leads to increased requirements for the technical configuration of the terminals.

Disclosure of Invention

The technical problem that can be solved with the help of the claimed solution is the elimination of existing shortcomings in terms of centralized management of POS-terminals while reducing the computational load during transaction processing.

The technical result is the provision of centralized management of POS-terminals under the control of the UPOS standard with the implementation of the update functions of the software component of many POS-terminals.

An additional technical result is the reduction of the computational load during transaction processing by transferring part of the POS terminal functionality to the UPOS server and using the UPOS agent on the cashier’s device to which the POS terminal performing transactions is connected.

The claimed technical result is achieved due to the control system of the POS-terminal network, which contains at least one UPOS server, connected by a data transmission channel with a financial transaction device, to which one or more POS terminals operating through the UPOS software are connected, the UPOS module an agent and a transaction authorization server, in which the UPOS agent module is configured to provide data routing between the UPOS server, POS terminals, and the transaction processing device;

The POS terminal is configured to receive client requests for transactions, verify clients, encrypt transaction data of client requests;

The UPOS server is configured to monitor and control POS terminal parameters, control the operation of the POS terminal, generate transaction processing scripts and exchange data with the transaction authorization server, and update the POS terminal parameters.

In a particular embodiment of the system, the UPOS agent module implements the generation of a transaction processing interface using a financial transaction device.

In a particular embodiment of the system, the UPOS agent and its associated POS terminals are connected through a local network connection or through a computer network.

- 1 033637

In a particular embodiment of the system, a local connection is selected from the groups: RS-232, USB,

LAN or their combination.

In a particular embodiment of the system, the computer network provides a connection via the TCP / IP protocol.

In a particular embodiment of the system, the connection is made through a network data transmission device of the POS terminal, which is selected from the group: GPRS modem, GSM modem, 4C modem, Wi-Fi adapter, Ethernet adapter.

In a particular embodiment of the system, the UPOS server is further configured to interrogate the POS terminals connected to it and collect a common hash value of the local file set for each terminal.

In a particular embodiment of the system, the server compares the received hash value of each POS terminal with the reference value stored on the server. In a particular embodiment of the system, during comparison, the server determines at least one file from each hash value of the POS terminal, which does not correspond to the reference value.

In a particular embodiment of the system, in response to a discrepancy in the hash value, the server transmits the reference version of the file to the POS terminal.

In a particular embodiment of the system, the UPOS server contains a module for configuring the parameters of the POS terminals. In a particular embodiment of the system, the UPOS server contains a module for processing rules for interacting with bank cards.

In a particular embodiment of the system, the UPOS server contains a module for generating financial contributions, configured to generate, in response to transaction processing through POS terminals, additional financial movements on the client’s account.

In a particular embodiment of the system, additional financial movements are selected from the group: discounts, accounting for bonus funds in the client’s account, return of a portion of the spent payment amount, or a combination thereof.

In a particular embodiment of the system, the UPOS server contains a check generation module.

Brief Description of the Drawings

FIG. 1 illustrates a General view of the claimed system.

FIG. 2 illustrates a module diagram of a POS terminal and an UPOS agent.

FIG. 3 illustrates a diagram of the modules of an UPOS server.

FIG. 4 illustrates an example of the operation of a crypto module of a POS terminal.

FIG. 5 and 6 illustrate an example of data encryption.

FIG. 7 and 8 illustrate a flowchart of a transaction.

FIG. 9 illustrates a diagram of a computing device.

The implementation of the invention

The following terms and designations will be used in these application materials:

EMV (Europay + MasterCard + VISA) is an international standard for operations with bank cards with a chip.

POS-terminal (trading terminal) - an electronic device installed near the cash register of a trade and service company and which allows reading information from a magnetic strip or chip of a card and communicating with a bank for authorization with the purpose of conducting a bank card transaction. They can be used for calculations using both magnetic cards and microprocessor cards.

CVM or CVM-list (Cardholder Verification Method) - information of the card issuer bank recorded on the card's EVM chip.

UnifiedPOS (UPOS) is a universal POS terminal interface management standard that provides a single software control interface for POS terminals of various manufacturers.

UPOS agent - a software module installed on the device for transactions, providing at least routing data between the POS terminal and the management server.

Software - software.

Transaction execution device - a cashier's computer device with a connected UPOS agent. As a transaction execution device, cash register equipment with an operating system (for example, Windows Embedded) or a device based on a personal computer can be used.

As shown in FIG. 1, in general terms, the claimed POS terminal network control system comprises a plurality of devices, such as a POS terminal (100), an UPOS agent (200) connected to a processor (250) of a transaction execution device (300), an UPOS server (400 ) and a transaction authorization server (500).

In FIG. 2 is a diagram of the modules included in the POS terminal (100) and the UPOS agent (200). POS-terminals (100) provide work with customer payment cards for the implementation of the transaction process.

- 2 033637

The POS terminal (100) contains a verification module (101), which provides verification of the client based on the data of the card with which the transaction process is performed. Module (102) provides reading of the card parameters and transfers them via the universal bus to module (101). Payment cards can be made with a magnetic stripe or chip.

The key storage module (103) provides storage of keys in a protected area of the POS memory of the terminal, and also provides an implementation of the key management interface in an unprotected area of memory.

The EMV module (104) provides processing of transactional data in accordance with the EMV standard when processing data on payment cards equipped with a chip.

The encryption module (105) provides encryption of terminal data (100), PIN pad (109) and data for transmission to the server (400). Module (105) also decrypts data received from the UPOS server (400).

The receipt printing module (106) performs the output of the check to the printer integrated in the terminal (100).

The interface module (107) provides interaction with the client of the terminal (100) by generating a display on the display of the terminal (110) of the required information on the implementation of the transaction process.

As indicated above, the functionality of the terminal (100) contains only basic functions that allow the collection of primary information about the client and the transaction execution tool (for example, the card) for further transmission to the UPOS agent (200) located on the transaction processing device (300 )

The UPOS agent (200) interacts with the POS terminal (100) using the interface module (203). The terminal (100) can be connected to the UPOS agent (200) using a local network, for example USB, RS-232, LAN, or via a wireless network using the Bluetooth or ZigBee data transfer protocols. A LAN connection can be implemented using the TCP / IP or UPD transport protocol. Also, the connection can be made through a wireless network using such means as a GPRS modem, GSM modem, 4G modem, Wi-Fi adapter, Ethernet adapter.

The main function of the UPOS agent (200) is the routing of data and server commands (400), POS terminals (100) and a transaction processing device (300). UPOS agent (200) provides management of operations in active mode.

In a particular embodiment, the UPOS agent (200) may be a software or hardware part of the POS terminal (100) itself.

Using the routing module (201), the server data (400) is routed between the UPOS agent (200) and the POS terminal (100). Communication with the server (400) is carried out through the corresponding interface module (202) for interaction on receiving commands from the server (400) and transmitting the response of the server (400) to the device (300).

The cashier's interface module (204) provides the display on the display of the device (300) of an interface for processing transactions carried out using the POS terminal (100).

The processing of commands for operations with POS terminals (100) is performed using a processor (250) of a transaction execution device (300) with their subsequent transmission through a network device (260) to a server (400). The network device (260) must provide an Internet connection between the device (300) and the server (400).

In FIG. 3 shows a diagram of a UPOS server (400). The POS terminal parameter settings module (401) is designed to check the current status of POS terminals (100) connected to the corresponding agent (200). Module (401) provides diagnostics of the technical condition of POS terminals (100) and updating their software to eliminate errors in the processing of transactional messages.

The UPOS server (400) establishes a connection with one or more POS terminals (100) and polls them, requesting the general hash values of the local set of files contained on the POS terminals (100).

The server (400) contains a connected database (450), which stores the reference hash values of the parameters of the POS terminals (100). Receiving information from POS-terminals (100), the server (400) checks the received values from terminals with reference values. If the values do not match, the UPOS server (400) transmits to the terminal (100) a list of files and the expected hash value of each of them. The POS terminal (100) in response checks the received list and compares the required hash values with its local files. Files with a mismatching hash value or missing on the POS terminal (100) are immediately downloaded from the UPOS server (400) via HTTP.

Module (402) of the card servicing rules provides for the formation of transaction execution rules, as well as decision-making on the execution of a transaction. If during this process there are any suspicions about fraud, then the transaction is refused.

Also a lot depends on the type of bank card. For example, servicing debit and credit cards has certain differences. The priority set by the bank for automation of 3,033,637 also matters. If the card passes all the checks successfully, then the issuer can approve the transaction as part of the transaction, and the response itself goes directly to the POS terminal (100). For example, transferring funds from card to card, making a purchase of goods, returning funds to a card, canceling a transaction, etc. Module (402) also takes into account the type of card and the process of interacting with them.

Module (403) of financial contributions provides the formation of rules for changing the amount of a transaction based on information about a client’s card (discounts, commissions, fines, bonuses, etc.). Also, with the help of this module, additional contributions are generated that are not related to the main transaction, in particular tips, donations to charity funds, a part of the amount is returned to the client's account (cashback), etc.

The check generation module (404) generates data transmitted for printing by the POS terminal check printer (100).

The details generation module (405) generates payment information for transmission to the bank.

Module (406) provides network interaction via the Internet with a transaction authorization server (500). Module (406) can be implemented as an Ethernet adapter, GSM module (GPRS, LTE, 5G), Wi-Fi module, satellite communications module, etc.

The database (450) of the server also contains a terminal database and corresponding parameters, which is used to update the software of POS terminals (100).

An important part of the claimed system is also to protect data from unauthorized access to transactional information or data on a customer’s card. The following authentication and authorization methods are used for this.

The POS terminal (100) is additionally equipped with a PIN pad (109) with a built-in crypto module, which provides safe storage of the KLK key, as well as the PIN key and MAC key. KLK-key is a transport key for remote downloading of cryptographic keys (master keys). The length of each key can be either single (DES) or triple (Triple DES).

PIN block generation (ANSI X.9.8) is performed using a PIN key. Traffic data is encrypted using the MAC code (ANSI X.9.19) and TripleDES encryption. In some embodiments of the technical solution for encrypting a PIN key, one of the following key management schemes can be used: Derived Unique Key Per Transaction (ANSI X9.24), Fixed Key, Master Key / Session Key. The PIN block is transmitted using RSA encryption keys with a key module length of at least 1024 bits.

As shown in FIG. 4, the KLK key is used to generate a PIN key and a MAC key. The POS terminal (100) can store several pairs of PIN / MAC keys in accordance with the number of specified departments. Each department creates its own pair of PIN / MAC keys. All keys and their components are generated according to a random (pseudo-random) law. The random number generation algorithm passes statistical tests in accordance with FIPS 140-2 (Level 3). Due to this, the compromise of the generated key becomes possible only with the collusion of at least two authorized persons.

To protect the integrity of messages transmitted between the POS terminal (100) and the server (400), MAC encoding is used. To generate / verify the MAC code, it is necessary to perform the ANSI X9.19 procedure on the data block of the transmitted parameters.

For a single-length MAC key (8 bytes), the procedure has the form shown in FIG. 5. For a double-length MAC key (16 bytes), the procedure has the form shown in FIG. 6.

There are four main modes of using MAC coding:

1) do not use;

2) use only for basic operations;

3) use for all operations (except for changing keys);

4) use encrypted formats.

If the server (400) detects a mismatch when checking the MAC code of the request, it generates a response with code 98 and the message M. CODE INCORRECT (if this is the main operation) to the POS terminal (100), or '9' (if it is a reconciliation totals), or 'RB ... 599' (if it is a packet unloading). The POS terminal checks the MAC code in the server response (400) and, if it matches, processes the response code in a regular way. Otherwise, the POS terminal responds to the server (400) with the nak symbol, through which the server (400) repeats the transmission of the response. When you receive a response with an incorrect MAC code again, the POS terminal disconnects and then checks the response code. If code 98 is received (either 9 to verify the results, or RB..599 to download the packet), the POS terminal gives the operator a message received from the server, after which it returns to its original state, considering the operation failed. Otherwise (the MAC code in the response did not match and the response code is not 98), the POS terminal acts as if the server response was not received at all.

In the settings of the POS terminal (100), it is possible to set any of these modes, which is implemented due to the crypto module of the PIN pad (109).

When using public communication channels that are easily exposed to the threat of data interception (GSM modem, GPRS modem, Internet), between the terminal (100) and the UPOS server (400) are used 4,033,637 secure (encrypted) data exchange formats based on VISA-II formats.

The encryption of the original VISA-II (V) block is performed as follows: The POS terminal (100) calculates the sequence S as the first 8 bytes from the hash value of block V calculated by the SHA-1 algorithm: S = [SHA1 (V)] 0. .7.

Using the PIN pad (109) or another crypto module storing the MAC key M, the terminal (100) calculates the MAC code K over the sequence S: K = MACM (S) = DESM (S).

The obtained value of K is used as a key for software encryption of block V in the SHS mode: b = DESK (V).

When decrypting the message, the server (400) performs similar actions. Using a software or hardware cryptomodule, it calculates the value: K = MACM (S) = DESM (S).

Using computational processing, it decrypts the data block B: V = DESK-1 (B).

When working in encrypted mode, the MAC code inside the VISA-II block is not used. To verify the decryption of the request, the server (400) verifies the received parameters with the POS terminal number (100) with data identifying the POS terminal number (100) inside the decrypted block, and also calculates the hash value from the decrypted message, V and compares its first 8 bytes with the value S. If a mismatch is detected, the server (400) responds to the POS terminal (100) about the need to retransmit the request. If after a request is sent three times, the server (400) cannot decrypt it correctly, then the connection between the server (400) and the POS terminal (100) is disconnected.

The POS terminal (100) verifies the response received from the server (400) as follows. If in the decrypted answer the fields inside the block characterizing the first and second parts of the terminal number do not coincide with the details of the POS terminal (100), the POS terminal performs further operation in normal mode without any action.

When using encrypted formats in conjunction with a dynamic key scheme, the request and response to the change of keys are always transmitted in unencrypted form. This is the only type of request for which neither the MAC code nor encryption is applied. A request for reconciliation of totals with a simultaneous change of keys (transaction 5F) follows the usual rules for reconciling totals (i.e. contains a MAC code or is encrypted). The described interaction formats of the POS terminal (100) with the server (400) allow two schemes for using keys for the MAC code and PIN block.

The first scheme is static, which assumes that the formation of the MAC code and encryption of the PIN block is carried out directly on the master keys, unchanged during the entire period of operation of the POS terminal.

In the second (dynamic) scheme, the POS terminal (100) regularly performs an auxiliary key change request and receives, in response from the server (400), new values of working keys for the MAC code and PIN block, encrypted under the corresponding master keys. The received encrypted values are stored by the POS terminal outside the crypto module and transferred to it when performing operations with the MAC code or PIN block. In the terminology of international payment systems, such a scheme is called master / sessionkey and is one of the standard ones. In the settings of the POS terminal (100) there should be a parameter that determines whether the POS terminal works with keys - static or dynamic. If the use of a dynamic scheme is enabled, the algorithm of the POS terminal changes as follows:

1. The POS terminal should have an internal flag indicating whether session keys were received or not. This flag should be reset when loading software or parameters into the POS terminal (100), and set after the first successful key change operation (or reconciliation of results with simultaneous key change, transaction 5F). Before starting a payment operation, the POS terminal must check this flag and, if it is not set, display a message. Verify the totals.

2. The used key length (single or double) the POS terminal automatically determines based on the response to the key change.

3. When using a dynamic scheme, upon receipt of a response to any request, the MAC code is incorrect. The POS terminal (100) must perform a key change (if possible without breaking the connection) and repeat the original request (also if possible without breaking the connection). When a response is received again, the MAC code is incorrect. The POS terminal should act as if the response to the original request had not been received at all.

4. When using a dynamic scheme together with encrypted formats, a situation is possible when, due to the discrepancy between the session keys, the server (400) cannot decrypt the request and determine its type. In this case, the server (400) returns an empty response consisting of three stxetxetx characters. Such a response, the POS terminal (100) should interpret the answer as the MAC code is incorrect and act as described above (initiate a key change and a second request).

5. When reconciling totals, instead of transaction 50, the POS terminal (100) must use transaction 5F. In this case, a separate key change request (transaction 51) will be required only in emergency cases (for example, when a connection is lost at the time of transaction 5F).

6. PIN-pad (109) of the POS terminal allows you to remotely download master keys encrypted on some KLK super-master key.

- 5,033,637

7. Transaction 51 (key change) is performed as follows:

The POS terminal (100) polls the PIN pad (109) and finds out which keys are loaded into it and which are not. If it turns out that the PIN pad (109) does not have KLK, or that both master keys (PIN and MAC) are already loaded, then the POS terminal (100) performs a change of session keys, indicating the Type of key to be changed field character 'A';

if the PIN pad (109) reports that it has KLK, but there is no PIN or MAC master key, then the POS terminal (100) performs a change of master keys, indicating the symbol 'in the Type of field to be changed field' F ';

no matter what shift the POS-terminal (100) tried (session or master keys), it should be prepared for the fact that in the response it will receive zero, two or four keys, i.e. on the initiative of the server (400), it is possible to change the master keys in response to a request to change session keys;

if there are no keys in the response, the POS terminal (100) leaves the current session and master keys unchanged, if the response code is not equal to '0', the POS terminal (100) displays the message Key change error and stops the current operation;

if the POS terminal (100) received two keys, then these are session keys. The POS terminal (100) must save them in its settings. Master keys stored in the PIN pad (109) do not change;

if the POS terminal (100) received four keys, then the first two are session keys (the POS terminal saves them in its settings and then uses them as usual), and the second two are master keys (the POS terminal should load them into the PIN pad) .

8. The session key has the same length as the master key (single or double). If the key length is double, then the session key is encrypted with the master key.

Further, let us consider an example of the beginning of interaction between a POS terminal (100) and a UPOS server (400).

The server (400), upon installation, generates an RSA key pair with a module length of 2048 bits. The public key of the Spub server is included in the distribution kit for the POS terminal software (100) along with the IP address and server port number (400).

The software of the POS terminal (100) at the first start generates its own RSA key pair with a given module length less than Spub, for example 1536 bits. The generated key pair is stored in the memory of the POS terminal (100) in local files that are not accessible for external reading.

Data is encrypted between the POS terminal (100) and the server (400) on a 24-byte K key using the TripleDES algorithm with a triple key length. The current value of the key K is also stored in the local file of the POS terminal (100), inaccessible for external reading. On the server side (400), the value of the key K is stored in a secure database storage (450).

After the key pair is generated, the POS terminal is activated. During the activation procedure, the TerminalID value is entered into the POS terminal and the activation code (KA) is a unique password for this TerminalID.

The POS terminal (100) combines the entered values of TerminalID and KA into a buffer. There POS terminal (100) adds its public key Tpub, serial number SN and the control value of the current key K (KCVK). Since, as such, the key K is absent in the POS terminal, the value of KCVK = 000000.

The formation of WK (Working Key) = TerminalID | | SN | | KA | | Tpub | | KCVK. The total length of the WK must not exceed the length of the Spub key module. Therefore, it is necessary that the length of the Tpub module be at least 27 bytes less than the length of the Spub module.

Next, the POS terminal (100) encrypts block A with the public key of the server and receives block B: B = RSASpub (A).

POS terminal (100) establishes communication with server (400) and sends block B. Server (400) decrypts block B with its secret key, using the value of TerminalID, server (400) detects the necessary record in the database (450) and checks the sent SN value with stored in the database. If the values do not match (and this will be necessary during initial activation), then the server (400) checks the value of the spacecraft. If it is correct, then the new SN value is stored in the database (450) and the verification of the serial number is considered successful.

Next, the server (400) checks the KCVK value stored in the database (450). If it does not match (and it will be necessary for the initial activation), the server (400) generates a new random key K, stores it in the database (450), encrypts it with the Tpub key and returns it to the POS terminal (100).

The POS terminal (100) decrypts the key K and stores it in its local file. Now the POS terminal (100) can receive commands encrypted with key K from the server (400).

In the future, the execution of each operation on the POS terminal (100) will begin with the same exchange. Only the POS terminal (100) will substitute 0 instead of the KA value. Since TerminalID and SN have not changed since the initial activation, the server (400) will consider the SN check to be successful, not paying attention to the knowingly incorrect value of the KA. The KCVK value will also match, but the server (400) has the right to generate and send to the POS terminal (100) a new value of the key K at any time if the procedure for processing transaction parameters requires it.

Next, we consider an example of a transaction (600) using the claimed system with reference

- 6,033,637 kami in FIG. 7 and 8.

On the transaction execution device (300), the operator initiates the payment process, and the corresponding data is transmitted using the UPOS agent module (200) to initiate recognition of the payment method at the POS terminal (100) under the control of UPOS (step 601). The transaction POS is displayed on the POS display of the terminal (100), and the device operator (300) enters it into the terminal (step 602). Next, the POS terminal (100) generates a transaction request that contains the type of operation and the amount (step 603). The request is transmitted through the UPOS agent module (200) to the UPOS server (400).

In the next step (604), based on the received request from the POS terminal (100), the server (400) generates a command to process the transaction data and sends it to the POS terminal (100). In response to the received server command (400), the POS terminal (100) initiates the verification process of the client’s payment means (card) and generates a corresponding message displayed on the display of the POS terminal (100). After that, the user card is recognized (605), in particular, the processing of the PAN number (Primary Account Number) of the card. After receiving the card data at the POS terminal (100), the information is encrypted and transmitted over a secure data channel (for example, SSL secure channel) to a server (400).

In response to the received data on the client card received from the POS terminal (100), the server (400) analyzes the BIN of the card (bank identification number) (step 606). Based on the results of checking the BIN of the card number, the server (400) generates a command for generating the ARQC (Authorization Request Cryptogram) cryptogram (607) and transmits it to the POS terminal (100). The POS terminal (100) using the encryption module (105) initiates the formation of a cryptogram. In the process of generating the cryptogram, the POS terminal (100) determines the zerification process for the type of client card, for which CVM card analysis is performed (step 608).

The formation and verification of cryptograms is based on the 3DES algorithm. The issuer and the card own a shared secret key MKac (Application Cryptogram Master Key). At the beginning of the transaction, the card generates an SKac (Application Cryptogram Session Key) based on MKac. An ARQC cryptogram, for example, 8 bytes long, is generated by the card using the MAC algorithm on the SKac session key using transaction data.

During the transaction, the ARQC cryptogram generated by the card is sent to the server (400), which checks the incoming ARQC with the cryptogram that it calculated on its own. For this operation, the server (400) generates a session key, then, based on the received transaction data, its own ARQC is calculated. If your own (generated by the issuer) ARQC and ARQC cards converge - the card is genuine.

Here is an example of a classic CVM: 4403410342031E031F02.

The decryption is as follows:

1 4403 Enciphered PIN - if terminal supports the CVM 2 4103 Offline Plain text PIN - if terminal supports the CVM 3 4203 Online PIN - if terminal supports the CVM 4 1E03 Signature - if terminal supports the CVM 5 1F02 No CVM - If not unattended cash and not manual cash and not purchase

When performing CVM analysis, it is determined whether a request for entering a PIN code is installed on the client’s card. If a code entry is necessary, then it is entered (610) into the POS terminal (100). In response to receiving the PIN code in step (610), it is checked for correctness. If the PIN code is entered correctly (612) or the PIN input request is not installed on the card, then a cryptogram (609) is generated using the encryption module (105) of the POS terminal (100).

The prior art distinguishes between two methods for verifying a PIN code: an online PIN when the PIN code is verified by the card issuer or an authorized issuer by the server, and an offline PIN when the PIN code is verified by the microprocessor card. The PIN code value is transmitted for verification to the server or card in the form of a PIN block of 8 bytes in size. In accordance with ISO 9654-1, the formats ISO-0, ISO-1, ISO-2, ISO-3 should be used for this purpose.

At step (611), it is checked whether the PIN code is entered online or offline. If the PIN code is entered offline, it checks the code on the microprocessor card, otherwise a cryptogram is generated for sending to the server (400).

A microprocessor card is called a Chip & PIN card if the method for checking the PIN code is an offline PIN (regardless of whether the PIN code is transmitted in a secure or insecure form) is the highest priority in the CVM List under the conditions of this operation. The POS terminal supports the offline PIN method if it supports secure and open transfer of the PIN code to the card. Then the Chip & PIN Liability Shift liability transfer is formulated as follows: if

- 7 033637

Chip & PIN-KapTa is used in a POS terminal that does not support offline PIN, then all responsibility for lost / stolen (Lost / Stolen) cards, as well as non-received cards (NRI) is transferred to the acquirer bank.

As a result, the priority of payment card verification rules recommended by payment systems in the CVM List when performing an operation using a DDA / CDA card in a POS terminal has the following form:

1. Enciphered Offline PIN.

2. Plaintext Offline PIN; 3. Online PIN.

4. Signature.

5. No CVM.

During the PIN check, the number of attempts to enter the code is also checked (613). And if the number of attempts is exhausted when the PIN code is entered incorrectly, then the POS terminal generates a parameter indicating that the client is not verified (614).

The generated cryptogram is transmitted to the server (400) to generate an autorotation request (615), which is transmitted from the UPOS server (400) to the transaction authorization server (500) (processing server) (step 616).

The transaction authorization server (500) processes the request (617), during which, on the basis of the received data, the server (500) approves the transaction or refuses to complete it.

If the transaction data is processed positively, the authorization server (500) generates a message to the UPOS server (400). Based on the received message from the authorization server (500), the UPOS server (400) generates a command to create a second cryptogram (618) with information confirming the completion of the transaction, which is transmitted to the POS terminal (100).

In response to the received command from the server (400), the POS terminal (100) generates a second cryptogram (619).

The generated cryptogram is transmitted to the UPOS server (400) through the UPOS agent (200). The obtained cryptogram is analyzed by the server (400) (step 620). Server (400), using a similar algorithm for generating cryptograms based on dynamic transaction data and response data, generates an ARPC (Authorization Response Cryptogram) and sends this cryptogram back to the map. At the moment when the card is confirmed by the incoming ARPC, mutual authentication of the card and the issuer is completed.

Upon positive verification of the cryptogram, the server (400) generates a command to prepare the check (621), which is transmitted to the POS terminal (100). In response to the received server command (400), the POS terminal (100) displays the status of the transaction and, through the printer, prints the receipt. If the cryptogram was not verified, the server (400) generates a request to cancel the transaction (623), which is transmitted to the authorization server (500). Server (500) processes the received request (624) and generates a response message for the UPOS server (400).

The UPOS server (400), in response to the operation cancellation authorization message, generates a command (625) for the POS terminal to cancel the transaction. The mentioned command is sent to the terminal (100), in response to which the client receives a message about the refusal of processing the card (626).

In FIG. 9 is a general diagram of a computing device (700) that can perform the functions of a transaction execution device, an UPOS server, and a transaction authorization server.

A computing device (700) generally comprises such components as one or more processors (701), at least one memory (702), data storage means (703), input / output interfaces (704), input / output means ( 705), a networking tool (706).

The processor (701) of the device performs the basic computing operations necessary for the functioning of the modules of the executing command of the device. The processor (701) executes the necessary computer-readable instructions contained in the random access memory (702).

Memory (702), as a rule, is made in the form of RAM and contains the necessary software logic that provides the required functionality.

The data storage means (703) can be implemented as HDDs, SSDs, RAID raids, flash memory, optical information storage devices (CD, DVD, MD, Blue-Ray-drives), etc. Means (703) allow the long-term storage of various types of information.

Interfaces (704) are standard tools for connecting and operating several devices, for example, USB, RS232, RJ45, LPT, COM, HDMI, PS / 2, Lightning, FireWire, etc.

The choice of interfaces (704) depends on the specific design of the device (700), which can be a personal computer, mainframe, server cluster, thin client, smartphone, cash register, etc.

The following can be used as input / output data (705): keyboard, joystick, display (touch screen), projector, touchpad, mouse, trackball, light pen, speakers, microphone, etc.

Networking tools (706) are selected from devices that provide network reception

- 8 033637 and data transmission, for example Ethernet card, WLAN / Wi-Fi module, Bluetooth module, BLE module, NFC module, IrDa, RFID module, GSM modem, etc. Using means (705), the organization of data exchange via a wired and / or wireless data channel, for example, WAN, PAN,

LAN, Intranet, Internet, WLAN, WMAN or GSM.

In the present application materials, a preferred disclosure of the implementation of the claimed technical solution was presented, which should not be used as limiting other, private embodiments of its implementation, which do not go beyond the requested scope of legal protection and are obvious to specialists in the relevant field of technology.

Claims (11)

CLAIM 1. The control system of the POS-terminal network, containing at least one UPOS server connected to the transaction authorization server, as well as combined by a data transfer channel with a financial transaction device containing an UPOS agent module to which one or more POS- terminals operating via UPOS software, in which the UPOS agent module is configured to provide data routing between the UPOS server, POS terminals and the transaction device; The POS terminal is configured to receive client requests for transactions, verify clients, encrypt transaction data of client requests; The UPOS server is capable of monitoring and controlling the parameters of POS terminals, controlling the operation of the POS terminal, generating transaction processing scripts and exchanging data with the transaction authorization server, updating the software settings of the POS terminal, moreover The UPOS server is capable of requesting and receiving the general hash values of the local set of files contained in the POS terminals, comparing the values received from the POS terminals with the reference values stored in the database of the reference hash values of the POS terminal parameters connected to the UPOS server, if the values do not match, transfer the list of files and the expected hash value to the POS terminal and, after the POS terminal checks the required hash values with its local files, upload files with the mismatching hash value to the POS terminal eat or missing files. 2. The system according to claim 1, characterized in that the UPOS agent module implements the generation of a transaction processing interface using a financial transaction device. 3. The system according to claim 1, characterized in that the UPOS agent and associated POS terminals are connected through a local network connection or through a computer network. 4. The system according to claim 3, characterized in that the local connection is selected from the groups RS-232, USB, LAN, or a combination thereof. 5. The system according to claim 3, characterized in that the LAN provides a connection via the TCP / IP protocol. 6. The system according to claim 5, characterized in that the connection is via a POS terminal network data transmission device, which is selected from the group: GPRS modem, GSM modem, 4G modem, Wi-Fi adapter, Ethernet adapter. 7. The system according to claim 1, characterized in that the UPOS server contains a module for setting parameters of POS terminals. 8. The system according to claim 1, characterized in that the UPOS server contains a module for processing rules for interacting with bank cards. 9. The system according to claim 1, characterized in that the UPOS server contains a module for generating financial contributions made with the possibility of generating, in response to transaction processing through POS terminals, additional financial movements in the client's account. 10. The system according to claim 9, characterized in that the additional financial movements are selected from the group: discounts, accounting for bonus funds in the client’s account, return of a part of the spent payment amount or a combination thereof. 11. The system according to claim 1, characterized in that the UPOS server contains a check generation module.