EA038762B1 - Method and system for the payment of services - Google Patents

Abstract

The invention relates in general to the field of computer engineering, and more particularly to methods and systems for the payment of services using hybrid billing and acquiring technology. The technical result is an increase in the speed and reliability of data processing during the transfer of funds from a payer account to a payee account, inter alia, to service providers directly. This technical result is achieved by means of a method for the payment of services which is implemented using at least one computing device and comprises the steps of: generating a request for the transfer of funds from a payer account to a payee account; generating and sending a request for authorization on the basis of the payer's card; signing the generated request for the transfer of funds with an electronic digital signature (EDS) and sending the request to a payment system; receiving, via said payment system, data about the successful processing status of the request for authorization; confirming the transfer of funds from the payer account to the payee account on the basis of data on the request for the transfer of funds signed with the EDS and the data about the successful processing status of the request for authorization.

Description

Technology area

This technical solution, in general, relates to the field of computing, and in particular to methods and systems for paying for services using hybrid billing and acquiring technology.

State of the art

In the prior art, billing is understood as a set of processes and solutions at telecommunications enterprises responsible for collecting information about the use of telecommunications services, billing them, invoicing subscribers, and processing payments. Acquiring is an acceptance of payment cards for payment as a means of payment for goods, works, services. The use of a bank card greatly facilitated the process of paying for services and goods, at least from the point of view of the bank card holder. The holder of a bank card can pay for goods and services without having the required amount of cash. While paying for services and goods with a bank card may seem straightforward from the point of view of a bank card holder, the logistics and details that go into a successful bank card transaction are far from straightforward. A system is known from the prior art to simplify the processing of bank card transactions, disclosed in the application WO 03017055 (A2), publ. 02/27/2003 containing the presentation structure; application components; application servers; asset management tool and performance management tool. The known system provides a platform and associated functionality on which various types of applications related to the processing of bank card transactions can be implemented and executed.

The disadvantage of the known solution is the inability to carry out secure non-cash payment for services provided by third-party providers, including state and municipal services, services for payment of duties, etc., at the time of their registration and, if necessary, receipt of a check, as well as transfer of information online to the State Information System of Urban and Interdepartmental Payments (GIS GMP).

The essence of the technical solution

The technical problem or task posed in this technical solution is to create a reliable method of payment for any category of services. The technical result achieved by solving the above technical problem is to increase the speed and reliability of data processing when transferring funds from the payer's account to the recipients of funds, including service providers directly. The specified technical result is achieved due to the implementation of the method of payment for services, performed by at least one computing device, containing the stages, which form a request to transfer funds from the payer's account to the account of the recipient of funds;

form and send a request for authorization using the payer's card;

sign the generated request for the transfer of funds with an electronic digital signature (EDS) and send it to the payment system;

receive through the payment system data on the successful processing status of the authorization request;

on the basis of the data of the request for the transfer of funds, signed by an EDS, and data on the successful status of processing the request for authorization, the transfer of funds from the payer's account to the account of the recipient of funds is confirmed.

In one of the particular embodiments of the method, a request for making a money transfer is additionally received and a new message is generated for the received request in the message queue for further processing of the request according to the queue.

In another particular embodiment of the method, in addition, when a new message is generated for an incoming request, information about the received request is entered into the message body, and information about the digital signature is added to the message header.

In another particular embodiment of the method, the information of the said request is additionally extracted from the body of the said message and the EDS from the header, the validity of the request is checked by EDS, and the said request is distributed depending on the operation to be performed. In another particular embodiment of the method, the authenticity of the request by EDS is checked using a cryptoservice.

In another particular embodiment of the method, in addition, after confirming the transfer of funds, a message with information about the completed request is excluded from the request queue.

In another preferred embodiment of the claimed solution, a service payment system is provided comprising at least one computing device and at least one memory containing machine-readable instructions that, when executed by at least one computing device, perform the above method.

Brief Description of Drawings

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 shows an example of the implementation of the service payment system;

- 1 038762 in Fig. 2 is an example of a general view of a command processing device.

Detailed description of the invention

Below will be described the concepts and terms necessary to understand this technical solution.

In this technical solution, the system means, among other things, a computer system, a computer (electronic computer), CNC (numerical control), PLC (programmable logic controller), computerized control systems and any other devices capable of performing a given, clearly a certain sequence of operations (actions, instructions).

A command processing device means an electronic unit or an integrated circuit (microprocessor) that executes machine instructions (programs).

A command processor reads and executes machine instructions (programs) from one or more storage devices. The role of data storage devices can be, but are not limited to, hard drives (HDD), flash memory, ROM (read only memory), solid state drives (SSD), optical drives.

A program is a sequence of instructions intended for execution by a control device of a computer or a command processing device.

As shown in FIG. 1, the service payment system comprises an automated workstation (AWS) 10; payment gateway 20; agent schema adapter 30; payment system 40; payment terminal 50; an application server 60 for interacting with the payment processing device 70; and a payment processor 70.

AWP 10 can be implemented on the basis of at least one command processing device equipped with appropriate software for its operation. In more detail, the command processing device will be disclosed below in the description text. AWP 10 is equipped with a web communication module 11 with a web application that provides services for searching, preparing and conducting budgetary and other payments. Also, AWP 10 is equipped with a communication module 12 with a terminal for interaction of the front part of AWP 10 with a payment terminal 50, and the payment terminal 50 can be connected to AWP 10 via a local network, or through an additional communication device, for example, a client machine with appropriate software for interaction with module 12 for communication via the Socket interface in case of connection via the Internet (Ethernet).

Payment gateway 20 (or payment gateway) is a hardware and software complex that allows you to automate the process of accepting payments on the Internet. The payment gateway is developed by the Bank, which defines its specification and is responsible for its support. In the claimed solution, the payment gateway is additionally equipped with a module 21 for receiving payment requests, a module 22 for validating requests and a module 23 for managing the queue of requests. These modules can be implemented on the basis of the software and hardware of the payment gateway 20, for example, on the basis of at least one computing device that is part of the hardware and software complex.

The agent circuit adapter 30 and the payment system 40 can also be implemented on the basis of at least one command processing device with corresponding software. The agent circuit adapter 30 comprises a request processing module 31 and a request data validation module 32, and the payment system 40 comprises a request distribution module 41 and a funds transfer request processing module 42.

In an alternative embodiment of the service payment system, the payment system 40 can perform the functions of the payment gateway 20 and the agent scheme adapter 30. Accordingly, all data from the AWS 10 will directly enter the payment system 40 and be processed according to the algorithm described below. Payment terminal 50 is an electronic software and hardware device for accepting payment cards for payment. It can accept chip cards, magnetic stripe cards and contactless cards, as well as other devices that have contactless pairing. For example, payment terminal 50 may be a POS terminal or any other similar terminal for accepting payment card data for payment. The application server 60 can be implemented on the basis of at least one server containing an application that performs the functions assigned to it for data processing in accordance with the functional specification, receives the data necessary for processing and provides the processing results.

The payment processor 70 may be based on SmartVista or any other integrated, full-featured system designed to organize and manage the entire spectrum of e-business transactions, from contracting to payments in the Internet, as well as to process authorization requests for payer cards.

At the first stage of the operation of the service payment system using AWP 10, a request is generated, signed with an electronic digital signature (EDS), to transfer funds in favor of the recipient of funds from the account and on behalf of the payer. The generated request is sent through the web communication module 11 to the payment gateway 20 and may include data about the payer to whom the service will be provided, in particular his bank details, as well as the bank details of the recipient of funds to which the funds will be transferred. The recipient of the funds could be, for example, a service provider who has provided or will provide the MFC applicant with the service they require. In the particular case of the implementation of the declared solution, AWP 10 can be the AWP of the bank located in the Multifunctional Center for the Provision of State and Municipal Services (MFC). The payer can be an MFC applicant who wants to receive a service provided by the MFC, such as a government service. MFC employees advise the applicant, form an application for the transfer of funds to the recipient of funds, print it if necessary, the payer checks all the details in the application, puts his signature and the MFC employee sends this application through AWP 10 and the web communication module 11 in the form of a request to transfer funds in favor of the recipient of funds using the API (Application Programming Interface) protocol to the Bank, in particular, to the module 42 for processing requests to transfer funds in favor of the recipient of funds according to the one shown in FIG. 1 scheme. The mentioned request may also contain a service identifier, including information about its cost, payer identifier, MFC employee identifier and digital signature. The mentioned EDS is issued by methods known from the prior art to the MFC employee responsible for it.

Accordingly, after receiving a command from an MFC employee to AWP 10, the web communication module 11 generates a request to transfer funds from the payer's account, signs an EDS request, in particular an EDS issued for the said MFC employee, and transmits the generated request to the payment gateway 20. After sending the request, the web communication module 11, using methods known from the prior art, forms and through the communication module 12 with the terminal sends to the payment terminal 50 a request for authorization using the payer's card, and the payer confirms the payment for the service by attaching a payment card to the terminal 50 and entering a pin code or by bringing or touching a payment card or other payment instrument, such as a telephone or a key fob, to a reading payment terminal in order to read the card data.

Further, the generated request to transfer funds from the payer's account through the module 21 for receiving requests is sent to the module 22 for validating requests, which validates the received request, for example, according to an XSD scheme. If the request is successfully validated, the request validation module 22 sends this request to the request queue management module 23, which generates a new message for the incoming request in the message queue for further processing the request according to its queue, and the module 23 enters information about the received request in the message body, and in the message header - information about the digital signature. Since the formation of new messages in the message queue is carried out only for requests that have passed validation, i.e. the structure of which corresponds to the structure of the XML-document, the speed of processing of data requests and the system as a whole is additionally increased. If the received request does not pass validation, a corresponding notification can be sent to the AWP 10 to output the notification information to the information display device. At the second stage of the system operation, the adapter of the agent circuit 30, in accordance with the algorithm laid down in it, by means of the request processing module 31, connects to the message queue formed in the request queue management module 23, extracts the request information from the body of the said message and the EDS from the header, checks the validity of the request by EDS by means of the request data validation module 32, for example, using a cryptoservice (for example, Bicrypt). Methods for checking the validity of requests are widely known from the prior art (see, for example, the article Basic Methods for Integration with PayAnyWay, page 11, posted on the Internet at: https://www.payanyway.rU/info/p/ru/public/merchants /PAWIntegrationOverview.pdf) and will not be disclosed in more detail in this application. Since information about the EDS is entered in the message header, the request data validation module 32 does not need to analyze the message text in the message body to search for EDS data, since EDS is extracted from the message header. In this regard, the speed of processing messages and the operation of the system as a whole is additionally increased.

Also, the request data validation module 32 identifies the type of service based on the request data and checks the availability of this service of the AWP 10, in particular the MFC, through which the generated EDS request was generated and signed. For this, the request data validation module 32 refers to the database, which it can additionally be equipped with, and extracts information on the available services for the given EDS. Information on the types of services available for the digital signature can be pre-entered into the data validation module 32 using methods known from the prior art. If the validation of the request was successful and the service is available to AWS 10, then the module 32 sends the request to the module 41 for distributing requests of the payment system 40. If the request does not pass the validation of the request or the service, information about which is contained in the request data, is not available to this agent, then the module 32 sends a notification to the AWS 10 using methods known from the prior art for outputting it to the information display device.

The module 41 for distributing requests distributes all incoming requests depending on the operation to be carried out, in particular, receiving payments, replenishing accounts and cards. Since the request was generated specifically to pay for services, in particular to transfer funds from the payer's account, information about which is contained in the request text of the message body, the request distribution module 41 identifies the request as accepting payments and sends it to module 42 processing requests for a money transfer, which is awaiting confirmation of card authorization from the device 70 processing payments.

After the payer confirms the payment for the service, the payment terminal 50 sends a card authorization request via the application server 60 to the payment processing device 70, and at this stage, the authorization request includes data about the account of the recipient of the funds, data about the payer, in particular the identifier of the payer's card and, if necessary, information about the pincode and the amount of the payment. Further, the payment processing device 70, based on the identifier of the payer's card, determines the issuing bank that serves the given card, and sends a request for authorization on the payer's card to this bank. If the authorization on the payer's card is successful, the issuing bank sends an authorization confirmation to the said device 70.

After successful processing of the authorization request, the payment processing device 70 via the application server 60 sends a notification about the successful processing status of the request to the payment terminal 50 for displaying on its display and transmission to the AWP 10. The notification may contain an authorization code, the transferred amount of funds, date, time , hashed card number and, if necessary, other data. Based on the notification received, the payment terminal 50 may issue a check. Also, the data on the successful processing status of the authorization request is sent by the payment processing device 70 to the payment system 40 to the request processing module 42.

The module 42 for processing requests based on the data of the request for the transfer of funds, in particular, according to the information about the payer and the EDS, which was used to check the availability of the AWP 10 service, and the above data on the successful status of processing the request received from the device 70 for processing payments, determines the command to transfer funds and confirm the transfer of funds from the account of the payer, in particular the MFC applicant, to the account of the recipient of funds, as well as the success of processing the request for the transfer of funds received earlier from the data validation module 32.

After confirming the success of the processing of the request for the transfer of funds, the request distribution module 41 sends data on the performed operation to the adapter of the agent circuit 30, which generates and sends to the module 23 for managing the queue of requests a command to dequeue a message with information about the completed request from the request queue. Information confirming the success of processing a request to transfer funds can also be displayed on the information display device AWP 10 or transmitted online to the State Information System of Urban and Interdepartmental Payments (GIS GMP).

Thus, due to the fact that the payment system 40 processes only the data of the request to transfer funds from the payer's account to the recipient's account, and the processing of the request for authorization on the payer's card for transferring them to the recipient's account is carried out through a separate channel communication, i.e. is performed by the payment processing device 70, which further interacts with the issuing bank and sends the authorization results to the payment system, the processing speed of the request data for the transfer of funds, EDS data and the authorization request on the payer's card increases.

Also, due to the use of EDS, the integrity of the information of the request for the transfer of funds is ensured, as a result of which the reliability of the delivery of the data of the said request and the operation of the system as a whole is increased. Additionally, by removing messages from the message queue, the computational load on the module 23 for managing the request queue is reduced and the speed of processing new messages in the message queue is increased, since the said module 23 does not analyze the requests that have already been processed. In general form (see Fig. 2), the command processing device (200) contains one or more processors (201) united by a common data exchange bus, memory means such as RAM (202) and ROM (203), input / output interfaces ( 204), input / output devices (205), and a networking device (206).

The processor (201) (or several processors, multi-core processor, etc.) can be selected from a range of devices widely used at present, for example, such architectures as: CISC, RISC, MISC, VLIW, etc. Under the processor or one of the processors used in the system (200), it is also necessary to take into account the graphics processor, for example, GPU NVIDIA, AMD Radeon or Graphcore, the type of which is also suitable for full or partial execution of the method, and can also be used for training and applying machine models. training in various information systems.

RAM (202) is a random access memory and is intended for storing machine-readable instructions executed by the processor (201) for performing the necessary operations for logical data processing. RAM (202), as a rule, contains executable instructions of the operating system and corresponding software components (applications, software modules, etc.). In this case, the available memory of the graphics card or graphics processor can act as RAM (202).

- 4 038762

ROM (203) is one or more persistent storage devices such as hard disk drive (HDD), solid state data storage device (SSD), flash memory (EEPROM, NAND, etc.), optical storage media (CD-R / RW, DVD-R / RW, BlueRay Disc, MD), etc.

To organize the operation of system components (200) and to organize the operation of external connected devices, various types of B / B interfaces (304) are used. The choice of the appropriate interfaces depends on the specific version of the computing device, which can be, but are 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 system (200), various means (205) of B / B information are used, for example, a keyboard, display (monitor), touch display, touch pad, joystick, mouse manipulator, light pen, stylus, touch panel, trackball , speakers, microphone, augmented reality, optical sensors, tablet, light indicators, projector, camera, biometric identification (retina scanner, fingerprint scanner, voice recognition module), etc.

The means of networking (206) provides data transmission via an internal or external computer network, for example, Intranet, Internet, LAN, etc. One or more means (206) 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 dr.

Additionally, satellite navigation aids can be used as part of the system (200), for example, GPS, GLONASS, BeiDou, Galileo. The specific choice of elements of the device (200) for the implementation of various software and hardware architectural solutions can vary while maintaining the required functionality provided.

Modifications and improvements to the above described embodiments of the present technical solution will be apparent to those skilled in the art. The foregoing description is provided by way of example only and is not intended to be limiting in any way. Thus, the scope of the present technical solution is limited only by the scope of the attached claims.

Claims (7)

CLAIM 1. An automated method of payment for services, performed by at least one processor of a computing device, comprising stages, which form a request to transfer funds from the payer's account to the account of the recipient of funds; form and send a request for authorization on the payer's card to the issuing bank; sign the generated request for the transfer of funds with an electronic digital signature (EDS) and send it to the payment system; receive through the payment system data on the successful processing status of the authorization request using the payer's card; on the basis of the data of the request for the transfer of funds, signed by an EDS, and data on the successful status of processing the request for authorization through the payment system, the transfer of funds from the payer's account to the account of the recipient of funds is confirmed. 2. The method according to claim 1, characterized in that it further comprises the steps of receiving a request to transfer funds from the payer's account to the recipient's account; for the received request, a new message is formed in the message queue for further processing of the request according to the queue. 3. The method according to claim 2, characterized in that when a new message is generated for an incoming request, information about the received request is entered into the message body, and information about the EDS is entered into the message header. 4. The method according to claim 3, characterized in that it further comprises the steps of extracting the information of the said request from the body of the said message and the digital signature from the header; check the authenticity of the request by EDS; distribute the said request depending on the operation to be performed. 5. The method according to claim 4, characterized in that the authenticity of the request by EDS is checked using a cryptoservice. 6. The method according to claim 3, characterized in that it further comprises a stage at which, after confirming the transfer of funds, a message with information about the completed request is excluded from the request queue. 7. A service payment system comprising at least one computing device and at least one memory containing machine-readable instructions that, when executed by at least one computing device, execute the method according to any one of claims 1-6.