RU2723459C1 - Method and system for payment for services - Google Patents

Abstract

FIELD: method and system of payment for services.SUBSTANCE: method comprises steps of: generating a request for transfer of funds from the account of the payer to the account of the recipient of funds; generating and sending an authorization request on the payer card to the issuing bank; signing generated request for transfer of funds by electronic digital signature (EDS) and sending it to payment system; obtaining, by means of a payment system, data on the successful status of processing an authorization request on the payer card; based on the request for money transfer from the account of the payer to the account of the recipient of money, signed by the EDS, and data on the successful status of processing the request for authorization on the card of the payer by means of the payment system, transfer of funds from the account of the payer to the account of the recipient of funds is confirmed.EFFECT: technical result consists in improvement of speed and reliability of data processing when transferring funds from the account of the payer to the account of recipients of funds, including service providers directly.7 cl, 2 dwg

Description

FIELD OF TECHNOLOGY

[001] This technical solution, in General, relates to the field of computer technology, and in particular to methods and systems for paying for services through a hybrid technology of billing and acquiring.

BACKGROUND

[002] Under the prior art, billing is understood to mean a set of processes and solutions at communications enterprises responsible for collecting information on the use of telecommunication services, their billing, billing subscribers, and processing payments. Acquiring is the acceptance of payment cards as a means of payment for goods, work, services. Using 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. A bank card holder can pay for goods and services without the required amount of cash. Although paying for services and goods with a bank card may seem simple from the point of view of a bank card holder, the logistics and details that make up a successful bank card transaction are far from simple.

[003] The prior art system for simplifying 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 corresponding functional capabilities on which various types of applications related to processing bank card transactions can be implemented and executed.

[004] A disadvantage of the known solution is the inability to make secure non-cash payment for services provided by third-party suppliers, including state and municipal services, fee payment services, etc., at the time of their execution and, if necessary, receipt of the check, and also online information transfer to the State information system of city and interdepartmental payments (GIS GMP).

ESSENCE OF TECHNICAL SOLUTION

[005] The technical problem or task set in this technical solution is to create a reliable way to pay for any categories of services.

[006] 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 account of recipients of funds, including service providers directly.

[007] The specified technical result is achieved due to the implementation of the method of payment for services performed by at least one computing device, comprising the steps of:

- form a request for the transfer of funds from the payer's account to the account of the payee;

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

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

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

- on the basis of the data of the request for the transfer of funds signed by the EDS and the data on the successful status of the processing of the request for authorization, they confirm the transfer of funds from the payer's account to the account of the payee.

[008] In one particular embodiment of the method, a request for money transfer is additionally accepted and a new message is generated for the incoming request in the message queue for further processing of the request according to the queue.

[009] In another particular embodiment of the method, in addition to generating a new message 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.

[0010] In another particular embodiment of the method, information of said request is additionally extracted from the body of said message and EDS from the header, the reliability of the request is verified by EDS and the said request is distributed depending on the operation to be performed. [0011] In another particular example of the method, the authenticity of the request by EDS is verified using cryptoservice.

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

[0013] In another preferred embodiment of the claimed solution, there is provided 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, perform the above method.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] 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:

In FIG. 1 - an example of the implementation of a service payment system is presented.

In FIG. 2 is an example of a general view of a command processing device.

DETAILED DESCRIPTION OF THE INVENTION

[0015] Below will be described the concepts and terms necessary for understanding this technical solution.

[0016] In this technical solution, a system is meant, including 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 defined sequence of operations (actions, instructions).

[0017] An instruction processing device is understood to mean an electronic unit or an integrated circuit (microprocessor) executing machine instructions (programs).

[0018] The command processing device reads and executes machine instructions (programs) from one or more data storage devices. Hard disk drives (HDD), flash memory, ROM (read-only memory), solid-state drives (SSD), optical drives can act as storage devices.

[0019] A program is a sequence of instructions for execution by a computer control device or an instruction processing device.

[0020] In accordance with the scheme shown in figure 1, the service payment system includes: a workstation (AWP) 10; payment gateway 20; agent agent adapter 30; payment system 40; payment terminal 50; an application server 60 for interacting with a payment processing device 70; and a payment processing device 70.

[0021] 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 module 11 web connection with a web application that provides services for searching, preparing and conducting budget and other payments. Also, the AWP 10 is equipped with a communication module 12 with a terminal for interacting with the front of the AWP 10 with a payment terminal 50, and the payment terminal 50 can be connected to the AWP 10 through a local network or through an additional communication device, for example, a client machine with appropriate software for interaction with communication module 12 through the Socket interface in case of connection via the Internet (Ethernet).

[0022] Payment gateway 20 (or payment gateway) is a hardware-software complex that automates the process of receiving payments on the Internet. A payment gateway is developed by the Bank, which determines 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 a request queue. 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-software complex.

[0023] The adapter of the agent circuit 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 includes: a request processing module 31 and a request data validation module 32, and a payment system 40 includes a request distribution module 41 and a money transfer request processing module 42.

[0024] In an alternative embodiment of the service payment system, the payment system 40 can perform the functions of the payment gateway 20 and the adapter of the agent circuit 30. Accordingly, all data from the AWP 10 will directly go to the payment system 40 and processed according to the algorithm described below.

[0025] Payment terminal 50 is an electronic software and hardware device for accepting payment cards.

It can accept cards with a chip, magnetic stripe and contactless cards, as well as other devices that have contactless pairing. For example, the payment terminal 50 may be a POS terminal or any other similar terminal designed to accept payment card data.

[0026] The application server 60 can be implemented on the basis of at least one server containing an application that performs the data processing functions assigned to it in accordance with the functional specification, obtains the data necessary for processing and ensures the provision of processing results.

[0027] The payment processing device 70 can be implemented on the basis of SmartVista or any other integrated full-featured system designed to organize and conduct the entire spectrum of electronic business operations, from contracting to payments in the Internet space, as well as for processing authorization requests by cards payers.

[0028] At the first stage of the system of payment for services using AWP 10 form a request, signed by electronic digital signature (EDS), to complete the transfer of funds in favor of the recipient of funds from the account and on behalf of the payer. The generated request is sent via 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 may be, for example, a service provider who provided or in the future will provide the MFC applicant with the service they require.

[0029] In the particular case of the implementation of the stated decision, the AWP 10 may be the arm of the bank located in the Multifunctional Center for the provision of state and municipal services (MFC). The payer may be an MFC applicant who wants to receive any service provided at the MFC, for example, a public service. MFC employees advise the applicant, form an application for transferring money to the recipient of the money, print it out if necessary, the payer checks all the details in the application, puts his signature and the MFC employee sends this application via AWP 10 and web-based communication module 11 in the form of a request to make a money transfer in favor of the money recipient via the API protocol (application programming interface) to the Bank, in particular, to the module 42 for processing requests to make money transfers in favor of the money recipient according to FIG. 1 circuit. The request may also contain a service identifier, including information about its cost, payer identifier, MFC and EDS employee identifier. The said EDS is issued by methods known from the prior art for the MFC employee responsible for it.

[0030] Accordingly, after receiving a command from the MFC employee at AWP 10, the web communication module 11 generates a request to make a money transfer from the payer's account, signs a request for an electronic digital signature, in particular, an electronic digital signature issued for the said MFC employee, and transfers the generated request to payment gateway 20. After sending the request, the web communication module 11, using methods known from the prior art, generates and, through the terminal communication module 12, sends an authorization request to the payment terminal 50 on the payer's card, and the payer confirms the payment of the service by attaching a payment card to the terminal 50 and by entering a PIN code or by close presenting or touching a payment card or other payment instrument, such as a telephone or keyring, to a reading payment terminal for reading card data.

[0031] Next, the generated request to complete the transfer of funds from the payer's account through the request receiving module 21 is sent to the request validation module 22, which validates the received request, for example, according to the XSD scheme. In the case of a successful validation of the request, the request validation module 22 sends this request to the request queue control module 23, which generates a new message in the message queue for the incoming request for further processing of the request according to its queue, moreover, the module 23 stores 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 query data and the system as a whole is further increased. If the received request does not pass validation, then a corresponding notification may be sent to AWP 10 to output notification information to the information display device.

[0032] At the second stage of the system operation, the adapter of the agent circuit 30, in accordance with the algorithm laid down in it, is connected to the message queue formed in the request queue control module 23 by the request processing module 31, extracts the request information from the body of the message and the digital signature from the header, checks the reliability of the request by digital signature by means of the validation module 32 of the request data, for example, using a crypto service (for example, Bicrypt). The methods for verifying the authenticity of requests are widely known in the prior art (see, for example, the article “Basic Integration Methods with PayAnyWay”, p. 11, available 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 digital signature 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 the electronic signature data, because EDS is extracted from the message header. In this regard, the speed of message processing and the operation of the system as a whole is further increased.

[0033] Also, the request data validation module 32 identifies the type of service based on the request data and checks the availability of the given workstation AWP 10, in particular the MFC, by means of which the generated digital signature request was generated and signed. For this, the request data validation module 32 refers to the database, which it can be additionally equipped with, and extracts information about available services for a given digital signature. Information about the available types of services for EDS can be pre-recorded in the data validation module 32 by methods known in the art. If the validation of the request was successful and the service is accessible by AWP 10, then the module 32 sends the request to the request distribution module 41 of the payment system 40. If the request does not pass the validation of the request or the service, the information about which is contained in the request data, is not available to this agent, then the module 32 sends a corresponding notification to the AWP 10 by methods known in the art for outputting it to the information display device.

[0034] The request distribution module 41 distributes all incoming requests depending on the operation that needs to be carried out, in particular: receiving payments, replenishing accounts and cards. Since the request was formed specifically for payment for services, in particular for the transfer of funds from the payer's account, information about which is contained in the request body of the message, the request distribution module 41 identifies the request as “receiving payments” and sends it to the request processing module 42 to complete a money transfer that is awaiting confirmation of authorization by card from the payment processing device 70.

[0035] After the payer confirms the payment, the payment terminal 50 sends a request for authorization by card through the application server 60 to the payment processing device 70, and at this stage, the authorization request includes information about the payee’s account, data about the payer, in particular the card identifier payer and, if necessary, information about the PIN code and the amount of payment. Next, the payment processing device 70, based on the identifier of the payer card, determines the issuing bank that services this card and sends a request for authorization on the payer's card to this bank. If authorization on the payer's card is successful, then the issuing bank sends confirmation of authorization to the said device 70.

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

[0037] The request processing module 42 based on the request data for the transfer of funds, in particular, according to information about the payer and EDS, which checked the availability of the AWP service 10, and the above data on the successful status of the processing of the request received from the processing device 70 payments, determines the team for the transfer of funds and confirms 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 transfer of funds received from validation module 32 earlier.

[0038] After confirming the success of processing the request for the transfer of funds, the request distribution module 41 sends the data about the completed operation to the adapter of the agent circuit 30, which generates and sends to the request queue control module 23 a command to exclude messages from the request queue from the request queue . Information confirming the success of processing a request to make a money transfer can also be displayed on the information display device AWP 10 or transmitted online to the State Information System of City and Interdepartmental Payments (GIS GMP).

[0039] Thus, due to the fact that the payment system 40 processes only the request data for the transfer of funds from the payer's account to the account of the payee, and the authorization request is processed on the payer's card to transfer them to the payee’s account on a separate communication channel, i.e. It is performed by the payment processing device 70, which subsequently interacts with the issuing bank and sends the authorization results to the payment system, the processing speed of the request for money transfer, electronic digital signature and authorization request by the payer's card is increased. Also, through 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 request queue control module 23 is reduced and the processing speed of new messages in the message queue is increased, since said module 23 does not analyze already processed requests.

[0040] In a general view (see FIG. 2), the command processing device (200) comprises one or more processors (201) combined by a common information bus, memory means such as RAM (202) and ROM (203), input interfaces I / O (204), input / output devices (205) and a device for network communication (206).

[0041] The processor (201) (or multiple processors, a multi-core processor, etc.) can be selected from a variety of devices that are currently widely used, 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 a graphic processor, for example, NVIDIA, AMD Radeon or Graphcore GPUs, the type of which is also suitable for complete or partial execution of the method, and can also be used for training and application of models machine learning in various information systems.

[0042] RAM (202) is a random access memory and is intended to store machine-readable instructions executed by the processor (201) to perform the necessary data processing operations. RAM (202), as a rule, contains executable instructions of the operating system and corresponding software components (applications, program modules, etc.). In this case, the available memory capacity of the graphics card or graphics processor may act as RAM (202).

[0043] The ROM (203) is one or more permanent storage devices, for example, 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.

[0044] Various types of I / O interfaces (304) are used to organize the operation of system components (200) and organize the operation of external connected devices. The choice of appropriate interfaces depends on the particular computing device, which can be, but 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.

[0045] Various means (205) of I / O information, for example, a keyboard, a display (monitor), a touch screen, a touch pad, a joystick, a mouse, a light pen, a stylus, are used to provide user interaction with a computing system (200), touchpad, trackball, speakers, microphone, augmented reality, optical sensors, tablet, light indicators, projector, camera, biometric identification tools (retina scanner, fingerprint scanner, voice recognition module), etc.

[0046] The network interaction tool (206) provides data transmission via an internal or external computer network, for example, an Intranet, the Internet, a LAN, and the like. As one or more means (206) may be used, but not limited to: Ethernet card, GSM modem, GPRS modem, LTE modem, 5G modem, satellite communications module, NFC module, Bluetooth and / or BLE module, Wi-Fi module and other

[0047] Additionally, satellite navigation systems as part of the system (200), for example, GPS, GLONASS, BeiDou, Galileo, can also be used.

[0048] The specific selection of device elements (200) for implementing various hardware and software architectural solutions may vary while maintaining the required functionality.

[0049] Modifications and improvements to the above described embodiments of the present technical solution will be apparent to those skilled in the art. The preceding description is provided as an example only and is not subject to any restrictions. Thus, the scope of the present technical solution is limited only by the scope of the attached claims.

Claims (17)

1. An automated method of payment for services performed by at least one processor of a computing device, comprising the steps of:

- form a request for the transfer of funds from the payer's account to the account of the payee;

- 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 by electronic digital signature (EDS) and send it to the payment system;

- receive through the payment system data on the successful status of processing the request for authorization on the payer's card;

- based on the data of the request to complete the transfer of funds from the payer's account to the payee’s account signed with an electronic digital signature and the data on the successful status of processing the authorization request on the payer's card through the payment system, the transfer of funds from the payer's account to the payee’s account is confirmed.

2. The method according to p. 1, characterized in that it further comprises stages in which:

- accept a request for the transfer of funds from the payer's account to the account of the payee;

- form for the incoming request a new message in the message queue for further processing of the request according to the queue.

3. The method according to p. 2, characterized in that when forming a new message for an incoming request, information about the received request is entered into the message body, and information about the digital signature in the message header.

4. The method according to p. 3, characterized in that it further comprises stages in which:

- extract the information of the request from the body of the message and the digital signature from the header;

- check the reliability of the request by digital signature;

- distribute said request depending on the operation that must be carried out.

5. The method according to p. 4, characterized in that the reliability of the request by EDS is checked using cryptoservice.

6. The method according to p. 3, characterized in that it further comprises the step of, 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, perform the method according to any one of claims. 1-6.

Images