RU2646335C1 - Method for online transfer of right of payment of goods or services to third payers - Google Patents

Abstract

FIELD: data processing.

SUBSTANCE: invention relates to a method for online transfer of the right to pay for goods or services from the buyer's device to third-party payers. In the method, a request is received from the buyer's device on the server for payment of the generated order at the expense of the funds of another payer, the buyer's order is made on the server, the order copy is assigned an order ID and order copy is saved in a database, authorisation of the buyer making the order through the buyer's device is performed, the server receives data of at least one payer, from the buyer's device, the server forms for at least one payer a unique link to the payment of the order formed by the buyer, pointing to the server, the link links the authorisation context, the order ID, the payer, the server sends at least one payer the order information, the unique link formed for payment of the order generated by the buyer, when a unique link is clicked, the payer is presented, on the payer's device, with a payment interface of the order made by the buyer without the need for authorisation and / or identification.

EFFECT: technical result automation of online transfer of the right to pay for goods or services.

7 cl, 8 dwg

Description

This technical solution relates to information methods and systems in computer technology, namely to methods and systems for transferring the right to pay goods or services to third-party payers.

BACKGROUND

Currently, a buyer may have a situation when they make online payments for a product or service when there are not enough funds in their current account or they have run out. In this case, you usually have to refuse to buy, which may entail the absence of a product or service when replenishing funds after some time.

There are situations when some categories of users (for example, children) do not have access to credit cards / settlement accounts and the possibility of making purchases becomes limited and problematic for them.

The prior art knows the technical solution described in US patent US 9355394 B2 "Systems and Methods of Aggregating Split Payments Using a Settlement Ecosystem", publication date 05/31/2016, copyright Visa International Service Association. This technical solution provides an opportunity to share a group of people paying for any action or event, for example, jointly pay a trip to a restaurant, rent a car and raise money for a gift. Initially, a person himself can pay for a product or service by, for example, a credit or debit card, and then settle financial relations with other members of the group using the means described in the invention.

This solution requires for the task of attracting payment by third parties the storage of payment details of buyers that fraudsters can access, and this increases the load on data storage in the system.

ESSENCE

This technical solution solves the problems of delegation existing in the prior art of the possibility of payment to an external payer of the order formed by the buyer.

A method of transferring the right to pay goods or services to third-party payers, characterized in that:

receive a request from the buyer to pay for the order at the expense of another payer; receive data from at least one payer; form for at least one payer a link to pay for the order formed by the buyer, send at least one payer order information, a link to pay for the order formed by the buyer; display to the payer the interface for payment of the order made by the buyer without the need for authorization and / or identification. In some embodiments, the payer data includes at least the name and telephone number.

In some embodiments, the identification and / or authorization of the buyer who sent the request to pay for the shopping basket is additionally performed;

In some implementations, payer data includes at least a full name and e-mail.

In some implementations, order information is sent to payers via sms or mms.

In some implementations, order information is sent to payers via an electronic messenger account associated with the payer's phone number.

In some implementations, order information is sent to payers via e-mail.

In some implementations, order information includes order description text and / or customer comments, order items.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a conceptual diagram of the interaction of devices according to the first embodiment of a method for transferring the right to pay goods or services to third-party payers.

FIG. 2 is a conceptual diagram of the interaction of devices according to the second embodiment of the method of transferring the right to pay goods or services to third-party payers.

FIG. 3A is the appearance of an authorization and customer identification form.

FIG. 3B is the appearance of the authorization and customer identification form with the authorization code input field.

FIG. 4 - appearance of the input form of payers.

FIG. 5 is an appearance of a customer order description interface.

FIG. 6 is a block diagram of an algorithm for transferring the right to pay goods or services to third-party payers.

FIG. 7 is a diagram of an online store with a payment gateway.

DETAILED DESCRIPTION

Below will be described the concepts and definitions necessary for the detailed disclosure of the ongoing technical solution.

The technical solution can be implemented as a distributed computer system.

In this solution, a system means a computer system, a computer (electronic computer), CNC (numerical control), PLC (programmable logic controller), computerized control systems and any other devices that can perform a given, well-defined sequence of operations (actions, instructions).

By a command processing device is meant an electronic unit or an integrated circuit (microprocessor) that executes machine instructions (programs).

The command processing device reads and executes machine instructions (programs) from one or more data storage devices. Storage devices may include, but are not limited to, hard disks (HDD), flash memory, ROM (read only memory), solid state drives (SSD), optical media (CD, DVD, etc.).

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

Buyer - an individual or legal entity that orders goods or services on an online resource and is the purchaser of goods or services.

Payer - an individual or legal entity that pays for a product or service to which the buyer delegates payment in this technical solution.

Payment group - a group of participants in the purchase process created by the buyer at the time the payers were invited to pay for the basket of goods or services in the interface of the solution installed on the integrator website, and the payment can be created in the interface of the member’s personal account on the decision side before the buyer is a payment request has been initiated on the side of any solution integrator site

Online store - a site selling goods or services via the Internet. It allows customers online, in their browser or through a mobile application, to create a purchase order, choose a method of payment and delivery of the order, pay for the order.

Cart - in online stores - a temporary storage of selected goods or services before ordering.

Payment gateway - a hardware-software complex that allows you to automate the process of accepting payments on the Internet. The payment gateway is developed by the payment system, which determines its specification.

Making purchases in the online store or mobile application, the buyer on the device (102) adds the purchased goods to the basket. After all the necessary goods are selected and added to the basket, the process of placing an order and its payment takes place.

In some implementations, product information in a basket is stored on a customer’s device (102). In some embodiments, information about the goods in the basket is stored on the server (103).

This technical solution provides the ability to pay for the generated order, at the expense of third parties - payers. During the checkout process, the buyer on the device (102) displays the purchase payment interface with the option of choosing to pay for goods at the expense of third parties - payers.

In some implementations (hereinafter, the text), the display of the interface includes the following steps: the server (103) generates a page view that is sent to the customer’s device (102), then the customer’s device (102) receives the generated view and displays it on the screen.

In some implementations, the page presentation is generated using html (xhtml) and / or css and / or js.

In some implementations, the page presentation is generated using xml.

In some embodiments, an interface representation has already been generated on the customer’s device (102) and displayed according to the logic of the software through which the customer purchases. When displaying the interface, interaction with the server (103) can be performed to obtain the information necessary for displaying.

When the buyer selects the payment option on the device (102) on the server

(103) a mold of the generated order is created and stored in the database

(104). At the same time, this mold of the generated order is assigned a unique identifier order_id.

In some implementations, the payment option may be in the form of a button or link.

In some embodiments, a nugget of the generated order is created at the stages preceding the display of the payment interface.

In some embodiments, a nugget of the generated order is created when forming the interface elements responsible for choosing this payment option (at the expense of third-party payers).

In some embodiments, the unique identifier is a numeric value.

In some embodiments, the unique identifier is an alphanumeric sequence.

In some embodiments, the alphanumeric sequence is a GUID or Uniqueidentifier type.

In some embodiments, the order nugget includes some (one or more) of the specified data: order number (OrderNumber), total order amount (OrderPrice), order currency code (OrrderCurrency), customer name (UserName), customer phone number (UserPhone), buyer's email address (UserEmail), list of position objects (OrderPositions) containing at least the following fields: absolute links to images of selected positions (PreviewLink), position names (Title), quantity of goods in a position (Quantity), price per unit of goods in position (Price).

In some implementations, order information is stored in the memory of the buyer’s device (102), then, when the buyer selects payment at the expense of third-party payers, this information is transmitted to the server (103), which creates an order nugget and stores this information in the database (104).

In some implementations, order information is stored in server memory (103). When the buyer chooses to pay at the expense of third-party payers, the buyer’s device (102) sends a request to the server (103), which creates a cast of the order and stores this information in the database (104).

In some implementations, a unique order_id is generated on the server (103).

In some implementations, the unique identifier order_id is generated by the database (104) when a new record is added.

Next, the process of authorization and customer identification begins. When authorizing the buyer on the device (102), an identification and authorization interface is displayed containing the data that the buyer must enter for identification and authorization.

In some implementations, the authorization interface is a form (FIG. 3A) that contains at least the name field (301) and the customer’s phone number (302).

In some implementations, the authorization interface is a form that contains at least the customer’s name and e-mail fields.

After entering the customer data on the device (102), they are sent to the server (103). Then, on the device (102), the authorization code input interface is displayed to the buyer.

In some embodiments, the authorization interface comprises a button (303), with which customer data is sent to the server (103).

The server (103) generates an authorization code (auth_code) and sends it to the customer at the phone number indicated by him. The buyer, having received an authorization code, enters it (auth_code) on the device (102) (Fig. 3B), after which the entered code is sent to the server (103). The server (103), having received the authorization code entered by the buyer, compares it with the one sent to the buyer. If both codes match, the buyer is authorized, otherwise authorization is denied. After successful authorization of the buyer, the generated order is associated with the customer identifier user_id defined in the authorization process.

In some implementations, the authorization code input interface contains at least the name field (301), the customer’s phone number (302), and the authorization code field (304).

In some implementations, if the buyer does not send an authorization code to the server (103) within a predetermined time, then this code is canceled for him and a new one is sent to him.

In some embodiments, the authorization code input interface contains an element (305), by clicking on which a request is sent to the server (103) to resend the authorization code.

In some embodiments, the authorization code is a sequence of numbers and / or letters.

Next, the buyer on the device (102) displays the interface (Fig. 4) for entering new or selecting previously entered data about third parties - payers (input interface of payers), who will be asked to pay for the order.

In some embodiments, payer data includes a name (403, 405), a phone number (404, 406). The interface may include input fields for at least one payer.

In some embodiments, the payer data includes a name, a phone number, a billing group name (402 or 401).

In some embodiments, the payer data input interface comprises an element for selecting payer groups previously created by the buyer. At the same time, the groups are loaded by the server (103) from the database (104).

After entering data on the customer’s device (102), the entered data is validated. Upon successful validation of the entered data, it creates an authorization context, a unique authorization context identifier auth_context_id is generated, which is associated with the payers and order identifier order_id.

In some implementations, data validation involves checking the data against a certain format. For example, the correspondence of the entered e-mail to the permitted format of e-mail (RFC 2822).

In some implementations, identifiers are linked by creating an entry in RAM or a database (104). An example would be to create an entry containing the fields auth_context_id, payer_id (payer), order_id.

Then, information about the order made by the buyer is sent to the indicated phone numbers (403, 406) and / or e-mail of the payers, with reference to the payment for this order.

In some implementations, order information is sent to a phone number via sms, mms.

In some implementations, order information is sent to a phone number to an electronic messenger account associated with that number.

In some implementations, when sending order information to the payer, the server (103) determines the accounts associated with the payer's phone number in electronic instant messengers (viber, telegram, whatsapp, etc.) and sends information to at least one associated electronic instant messenger account .

In some implementations, the identification of accounts associated with the number is carried out by using the messenger data API.

In some embodiments, the validation of the entered data occurs on the customer’s device (102).

In some implementations, the validation of the entered data occurs on the server (103), while the data about the payers entered on the device (102) is sent to the server (103), where they are validated.

In some embodiments, the sending of information about the customer’s order with reference to payment occurs on the customer’s device (102).

In some embodiments, when sending information about a customer’s order with reference to payment on the customer’s device (102), the following steps are performed:

- a description of the customer’s order is generated,

- a request is sent to the server (103) to generate at least one unique link to pay for the order by the payer

- the server (103), having received this request, generates at least one unique link for payment of the order by the pay_link payer pointing to the server, at the same time, the link connects the authorization context auth_context_id, the order identifier order_id and the payer

- send at least one pay_link to the buyer’s device (102)

- receive on the buyer's device (102) at least one generated pay_link link,

- send the generated order description and pay_link from at least one payer to the buyer’s device (102).

In some implementations, the sending of information about the customer’s order with reference to payment occurs on the server.

In some embodiments, when sending information about a customer’s order with reference to payment on the server (103), the following steps are performed:

- the server (103) based on the information about the goods in the order, generates a description of the customer’s order,

- the server (103) generates at least one unique link for payment of the order by the pay_link payer pointing to the server (103), while the link binds the auth_context_id authorization context, the order identifier order_id and the payer

- the server (103) sends the generated description of the order and the pay_link link to at least one payer using his phone number or e-mail.

In some implementations, link generation includes the following steps:

- Generate on the server (103) a unique identifier pay_code;

- On the server (103), the pay_code identifier is associated with the authorization context identifier auth_context_id, order identifier order_id.

- Form on the server (103) a link pointing to the server (103), in one of the parameters of which the value pay_code is transmitted.

An example of a link could be http://web-server.com/param1={pav_code} or http://web-server.com/param1/{pay_code}

Where instead of {pay_code} a specific value is substituted. The URI web-server.com is used as an indication of the server, which indicates the actual address of the server (103).

Payers indicated by the buyer receive order information on the device (Fig. 1, 105N or 105M). If the information was sent to the payer's phone number, the message received contains brief information about the order and a link to a page with a full description of the order and options for refusing and confirming payment of the buyer's order. When clicking on the link, the payer displays the interface of the order information (Fig. 5). If the information was sent to the payer's e-mail, the message contains information about the order, options for rejection and confirmation of payment of the buyer's order.

In some embodiments, the order information interface comprises at least a description of the order and / or customer comments (501), order items (502).

In some implementations, if the information was sent to the electronic messenger account associated with the payer’s phone number, the message contains information about the order, options for refusing and confirming payment of the payer's order.

In case of expressing consent to pay for this order (payment confirmation option) by the buyer, the payer (105N or 105M) is redirected to the payment interface of the order. If the consent to payment is made by more than one payer, then all subsequent payers, except the very first, refuse to make the payment.

In some implementations, consent to payment is expressed by clicking on the “Execute” / “Confirm” button (504).

In some implementations, when a payment is refused, the payer displays the payment rejection interface.

In some implementations, when processing a payment consent, the server (103) determines the value of the OrderNumber number associated with this order, then the payer displays the payment interface for this customer order for this payer.

In some implementations, server (103) processes the click through pay_link by the payer as follows:

- Gets the parameters and their value specified in the link, incl. value pay_code;

- Finds the values of the identifier auth_context_id, the order identifier order_id associated with the given pay_code value;

- Retrieves a copy of the order with the specified order_id from the database (104);

- Retrieves the value of OrderNumber;

- Makes the necessary settings for the payment of goods through a payment gateway.

In some implementations, the settings of the payment gateway mean the implementation of the sequence of actions (operations) necessary to effect payment, for example, registering an order with a payment gateway.

If necessary, the payer selects the payment medium in the payment interface. When the choice of means of payment is made, the payer enters the payment data and confirms the payment.

In some embodiments, the choice of means of payment includes the following options - plastic card, payment systems, payment via SMS, etc.

In some embodiments, the payment data includes a card number, CVC / CVC2 code, card expiration date, card holder.

After confirming the payment of the payer, the server (103) notifies the buyer of the payment of his order by the payer.

If it is not possible to complete the payment of the order by the payer, the server (103) notifies the buyer of a payment error.

In some embodiments, the server (103) is a virtual server.

In some embodiments, the server (103) is a distributed computer system including 2 or more servers.

In some embodiments, the database (104) is a distributed database.

In some embodiments, the database (104) is a key-value storage.

In some embodiments, the customer device (102) is a personal computer.

In some embodiments, the customer device (102) is a smartphone or tablet.

In some embodiments, the customer’s device is an electronic terminal located in a store. The terminal is connected to the Internet and has the ability to access the server (103).

In some embodiments, communication between the device 105 N and / or 105M and the server (103) is via the Internet. In some embodiments (Fig. 1), the server (103) is a web server on which an online store is located, in which the buyer selects the goods to order. The server (103) uses a database (104) to store data.

In some implementations, the http / https protocol and the methods implemented in them, get, post, put, etc. can be used to exchange data between the server (103) and the device of the buyer (102) and / or the payer.

In some implementations, an XML protocol or a binary protocol can be used to exchange data between the server (103) and the customer’s device (102) and / or the payer.

In one embodiment, the technical solution can be made in the form of a separate service that provides the buyer with the opportunity to pay for the order in the basket at the expense of third parties - payers.

When making purchases in an online store or mobile application, the buyer adds the items to be bought to the basket. After all the necessary goods are selected and added to the basket, the process of placing an order and its payment takes place.

Before displaying the payment interface, the order formed by the buyer is stored on the server (203) and is assigned a unique identifier OrderNumber.

In some implementations, an order includes some (one or more) of the specified data: order number (OrderNumber), total order amount (OrderPrice), order currency code (OrderCurrency), customer name (UserName), customer phone number (UserPhone), address Buyer's e-mail (UserEmail), list of position objects (OrderPositions) containing at least the following fields: absolute links to images of selected positions (PreviewLinks), position names (Title), quantity of goods in a position (Quantity), unit price product in position (Price).

In some embodiments, the order is stored in a database (206).

During the checkout process, the buyer on the device (102) displays the purchase payment interface with the option of choosing to pay for goods at the expense of third parties - payers.

When the buyer selects this option on the device (102), an order cast is generated on the server (203) and transmitted to the server (204). Having received the order cast, the server (204) saves it in the database (205). At the same time, this order nugget is assigned a unique order_id identifier.

In some embodiments, the payment option may be in the form of a button or link.

In some implementations, the server (203), together with the order nugget, transfers to the server (204) the token associated with this order. The token is stored along with the order nugget in the database (205). The token associated with this order is formed at the checkout stage.

In some implementations, the order nugget is formed in the form of an js object that is sent to the server when the buyer selects the option to pay for the purchase with the option of choosing to pay for goods at the expense of third parties - payers.

In some implementations, the order cast is formed in the form of associative arrays, the values of which are sent to the server when the buyer selects the purchase payment option with the option of choosing to pay for goods at the expense of third parties - payers.

In some embodiments, the unique identifier is a numeric value.

In some embodiments, the unique identifier is an alphanumeric sequence.

In some embodiments, the order nugget includes some (one or more) of the specified data: order number (OrderNumber), total order amount (OrderPrice), order currency code (OrderCurrency), customer name (UserName), customer phone number (UserPhone), Buyer's email address (UserEmail), list of position objects (OrderPositions), absolute links to images of selected positions (PreviewLinks), position names (Title), quantity of goods in a position (Quantity), unit price in a position (Price).

In some implementations, a unique identifier order_id is generated on the server (204).

In some implementations, a unique order_id is generated by the database (205) when a new record is added.

Next, the server (204) starts the authorization and customer identification process. During authorization and identification to the buyer, the identification and authorization interface is displayed on the device (102) containing the data that the buyer must enter for identification and authorization.

In some implementations, the authorization code input interface contains at least the name field (301), the customer’s phone number (302), and the authorization code field (304).

In some implementations, if the buyer does not send an authorization code to the server (204) within a predetermined time, then this code is canceled for him and a new one is sent to him.

In some embodiments, the authorization code input interface contains an element (305), by clicking on which a request is sent to the server (204) to resend the authorization code.

In some embodiments, the authorization code is a sequence of numbers and / or letters.

After entering the customer data on the device (102), they are sent to the server (204). Then, on the device (102), the authorization code input interface is displayed to the buyer.

The server (204) generates an authorization code (auth_code) and sends it to the buyer at the phone number indicated by him. The buyer, having received an authorization code, enters it (auth_code) on the device (102), after which the entered code is sent to the server (204). The server (204), having received the authorization code entered by the buyer, compares it with the one sent to the buyer. If both codes match, the buyer is authorized, otherwise authorization is denied. After successful authorization of the buyer, he is associated with the order identifier order_id.

In some implementations, data validation involves checking the data against a certain format. For example, the correspondence of the entered e-mail to the permitted format of e-mail (RFC 2822).

In some implementations, identifiers are linked by creating an entry in RAM or a database (205). An example would be to create an entry containing the fields auth_context_id, payer_id (payer), order_id.

Next, the buyer on the device (102) displays the interface for entering new or selecting previously entered data on third parties - payers, who will be asked to pay for the order.

In some implementations, payer information includes a name, a phone number.

In some embodiments, the payer data includes a name, a phone number, and the name of a payment group.

After entering data on the customer’s device (102), the entered data is validated. Upon successful validation of the entered data on the server (204), an authorization context is created, a code for simplified authorization of payers is generated, a unique authorization context identifier auth_context_id is generated, which is associated with the payers and order ID order_id. Then, to the indicated phone numbers or e-mails of the payers, the server (204) sends information about the order made by the buyer, with reference to the confirmation of payment of this order confirm_link.

In some embodiments, the validation of the entered data occurs on the customer’s device (102).

In some embodiments, the validation of the entered data occurs on the server (204), while the data about the payers entered on the device (102) is sent to the server (204), where they are validated.

In some embodiments, the sending of customer order information with reference to a payment confirmation occurs on the customer’s device (102).

In some embodiments, the sending of information about the customer’s order with reference to the payment confirmation takes place on the server.

In some embodiments, when sending information about a customer’s order with reference to a payment confirmation on the server (204), the following steps are performed:

- the server (204) based on the information about the goods in the order, generates a description of the customer’s order,

- the server (204) generates at least one unique link to confirm payment of the order by the payer confirm_link pointing to the server (204), while the link contains a code for simplified authorization of payers and links the authorization context auth_context_id, order identifier order_id and payer

- the server (204) sends the generated description of the order and the confirm-link to at least one payer using his phone number or e-mail.

In some implementations, generating a confirm_link includes the following steps:

- Generate on the server (204) a unique identifier pay_code (code for simplified authorization);

- Bind on the server (204) the pay_code identifier with the authorization context identifier auth_context_id, order identifier order_id

- Form on the server (204) a link pointing to the server (204) in one of the parameters of which the pay_code value is transmitted.

An example of a link could be http://web-server.com/param1={pay_code} or http://web-server.com/param1/{pay_code}

Where instead of {pay_code} a specific value is substituted. As an indication of the server, the URI web-server.com is used, which indicates the actual address of the server (204).

Payers indicated by the buyer receive order information on the device (Fig. 2, 105N or 105M). If the information was sent to the payer's phone number, the message received contains brief information about the order and a link to a page with a full description of the order and options for refusing and confirming payment of the buyer's order. When clicking on the link, the payer displays the interface of the order information (Fig. 5). If the information was sent to the payer's e-mail, the message contains information about the order, options for rejection and confirmation of payment of the buyer's order.

In some embodiments, the order information interface comprises at least a description of the order and / or customer comments (501), order items (502).

In some implementations, if the information was sent to an electronic messenger account associated with the payer’s phone number, the message contains information about the order, options for refusing and confirming payment of the payer's order.

In case of expressing consent to pay for this customer’s order, the payer (105N or 105M hereinafter does not make any fundamental difference which user performs this action) is redirected by the server (204) to the order payment interface formed on the server (203). If the consent to payment is made by more than one payer, then all subsequent payers, except the very first, refuse to make the payment.

In some embodiments, for redirecting the payer by the server (204) to the order payment interface generated on the server (203), a redirect_link link is generated, pointing to the server (203) and containing the order number OrderNumber and optionally a token.

In some implementations, the redirect_link link format is predefined when configured. As an illustrative example, when setting up, the address of the payment processor can be set, such as http://webshop.com/pay/order={OrderNumber►&token={Token}, where {OrderNumber} is the order number, and {Token} is token.

In some implementations, consent to payment is expressed by clicking on the “Execute” / “Confirm” button (504).

In some implementations, when a payment is refused, the payer displays the payment rejection interface.

In some implementations, when processing a payment consent, the server (204) determines the value of the OrderNumber associated with this order and sends this data to the server (203). After that, the payer on the device (Fig. 2, 105N or 105M) displays the payment interface of this customer order for this payer.

In some implementations, when processing a payment consent, the server (204) determines the token, the value of the OrderNumber associated with this order, and sends this data to the server (203). After that, the payer on the device (Fig. 2, 105N or 105M) displays the payment interface of this customer order for this payer. After receiving the data, the server (203) checks the token associated with the given order number OrderNumber and the received token, as well as the availability of the stored order with this orderNumber. In case of their mismatch and / or absence of an order with such an OrderNumber number, the payment operation is canceled. After that, the server (203) receives from the database (206) the data associated with the OrderNumber order and makes the necessary settings for the payment of goods through the payment gateway.

In some implementations, the settings of the payment gateway mean the implementation of the sequence of actions (operations) necessary to effect payment, for example, registering an order with a payment gateway.

If necessary, the payer on the device (Fig 2, 105N or 105M) in the payment interface selects the payment medium. When the choice of means of payment is made, the payer enters the payment data and confirms the payment.

In some embodiments, the choice of means of payment includes the following options - plastic card, payment systems, payment via SMS, etc.

In some embodiments, the payment data includes a card number, CVC / CVC2 code, card expiration date, card holder.

After confirming the payment of the payer, the server (203) notifies the buyer of the payment of his order by the payer.

If it is not possible to complete the payment of the order by the payer, the server (203) notifies the buyer of an error in payment.

In some embodiments, the database (205) may be a relational database or key-value storage, or a hierarchical database.

In some embodiments, the database (205) is located in the server RAM (204).

In some embodiments, the customer device (102) is a personal computer.

In some embodiments, the customer device (102) is a smartphone or tablet.

In some embodiments, the customer’s device is an electronic terminal located in a store. The terminal is connected to the Internet and has the ability to access the server (203).

In some embodiments, communication between the server (203) and the server (204) is via the Internet.

In some embodiments, communication between the device (105N) and / or 105M and the server (204) or (203) is via the Internet.

In some implementations, the protocol http and / or https is used to communicate the server (203) and the server (204).

In some implementations, a binary protocol is used to communicate the server (203) and the server (204).

In some embodiments (Fig. 2), the server (203) is a web server on which an online store is located, in which the buyer selects the goods to order. The server (204) hosts software that allows payment for the goods of the buyer at the expense of third-party payers. Server software (204) uses a database (205) to store data.

In some implementations, the http / https protocol and the methods implemented in them, get, post, put, etc., can be used to exchange data between the server (203) and the buyer’s device (102).

In some implementations, the http / https protocol and the methods implemented in them - get, post, put, etc. can be used to exchange data between the server (203) or (204) and the payer device (105N or 105M).

In one embodiment, the technical solution can be implemented as follows. Making purchases in the online store or mobile application, the buyer on the device (102) adds the purchased goods to the basket. After all the necessary goods are selected and added to the basket, the process of placing an order and its payment takes place.

In some implementations, product information in a basket is stored on a customer’s device (102). In some embodiments, information about the goods in the basket is stored on the server (103).

During the checkout process or when the formed basket is displayed, the buyer is presented with a payment payment interface on the device (102) with the option of choosing to pay for goods at the expense of third-party payers.

In some implementations (hereinafter, the text), the display of the interface includes the following steps: the server (103) generates a page view that is sent to the customer’s device (102), then the customer’s device (102) receives the generated view and displays it on the screen.

In some implementations, the page presentation is generated using html (xhtml) and / or css and / or js.

In some implementations, the page presentation is generated using xml.

The buyer, wanting third parties to pay for his goods, enters data on payers in the interface and selects the option to pay at the expense of third parties (payers input interface), which will be offered to pay for the order.

When the buyer selects this payment option on the device (102), a mold of the generated order is created on the server (103) and stored in the database (104). At the same time, this mold of the generated order is assigned a unique identifier order_id.

In some embodiments, a nugget of the generated order is created at the stages preceding the display of the payment interface.

In some embodiments, a nugget of the generated order is created when forming the interface elements responsible for choosing this payment option (at the expense of third-party payers).

In some embodiments, the unique identifier is a numeric value.

In some embodiments, the unique identifier is an alphanumeric sequence.

In some embodiments, the alphanumeric sequence is a GUID or Uniqueidentifier type.

In some embodiments, the order nugget includes some (one or more) of the specified data: order number (OrderNumber), total order amount (OrderPrice), order currency code (OrderCurrency), customer name (UserName), customer phone number (UserPhone), buyer's email address (UserEmail), list of position objects (OrderPositions) containing at least the following fields: absolute links to images of selected positions (PreviewLink), position names (Title), quantity of goods in a position (Quantity), price per unit of goods in position (Price).

In some implementations, order information is stored in the memory of the buyer’s device (102), then, when the buyer selects payment at the expense of third-party payers, this information is transmitted to the server (103), which creates an order nugget and stores this information in the database (104).

In some implementations, order information is stored in server memory (103). When the buyer chooses to pay at the expense of third-party payers, the buyer’s device (102) sends a request to the server (103), which creates a cast of the order and stores this information in the database (104).

In some implementations, a unique order_id is generated on the server (103).

In some implementations, the unique identifier order_id is generated by the database (104) when a new record is added.

In some embodiments, payer data includes a name, phone number, and / or e-mail. The interface may include input fields for at least one payer.

In some embodiments, the payer data includes a name, phone number and / or e-mail, the name of the payment group.

In some embodiments, the payer data input interface comprises an element for selecting payer groups previously created by the buyer. At the same time, the groups are loaded by the server (103) from the database (104).

After entering data on the customer’s device (102), the entered data is validated. Upon successful validation of the entered data, it creates an authorization context, a unique authorization context identifier auth_context_id is generated, which is associated with the payers and order-id order identifier.

In some implementations, data validation involves checking the data against a certain format. For example, the correspondence of the entered e-mail to the permitted format of e-mail (RFC 2822).

In some implementations, identifiers are linked by creating an entry in RAM or a database (104). An example would be to create an entry containing the fields auth_context_id, payer_id (payer), order_id.

Then, information about the order made by the buyer is sent to the indicated phone numbers and / or e-mails of the payers, with reference to the payment for this order.

In some implementations, order information is sent to a phone number via sms, mms.

In some implementations, order information is sent to a phone number to an electronic messenger account associated with that number.

In some implementations, when sending order information to the payer, the server (103) determines the accounts associated with the payer's phone number in electronic instant messengers (viber, telegram, whatsapp, etc.) and sends information to at least one associated electronic instant messenger account .

In some implementations, the identification of accounts associated with the number is carried out by using the messenger data API.

In some embodiments, the validation of the entered data occurs on the customer’s device (102).

In some implementations, the validation of the entered data occurs on the server (103), while the data about the payers entered on the device (102) is sent to the server (103), where they are validated.

In some embodiments, the sending of information about the customer’s order with reference to payment occurs on the customer’s device (102).

In some embodiments, when sending information about a customer’s order with reference to payment on the customer’s device (102), the following steps are performed:

- a description of the customer’s order is generated,

- a request is sent to the server (103) to generate at least one unique link to pay for the order by the payer,

- the server (103), having received this request, generates at least one unique link for payment of the order by the pay_link payer pointing to the server, while the link binds the authorization context auth_context_id, order identifier order_id and the payer,

- send at least one pay_link to the buyer’s device (102),

- receive on the buyer's device (102) at least one generated pay_link link,

- send the generated order description and pay_link from at least one payer to the buyer’s device (102).

In some implementations, the sending of information about the customer’s order with reference to payment occurs on the server.

In some embodiments, when sending information about a customer’s order with reference to payment on the server (103), the following steps are performed:

- the server (103) based on the information about the goods in the order, generates a description of the customer’s order,

- the server (103) generates at least one unique link for payment of the order by the pay_link payer pointing to the server (103), while the link binds the authorization context auth_context_id, order identifier order_id and the payer,

- the server (103) sends the generated description of the order and the pay_link link to at least one payer using his phone number or e-mail.

In some implementations, link generation includes the following steps:

- Generate on the server (103) a unique identifier pay_code;

- Bind on the server (103) the identifier pay_code with the identifier of the authorization context auth_context_id, the order identifier order_id;

- Form on the server (103) a link pointing to the server (103), in one of the parameters of which the value pay_code is transmitted.

An example of a link could be http://web-server.com/param1={pay_code} or http://web-server.com/param1/{pay_code}

Where instead of {pay_code} a specific value is substituted. The URI web-server.com is used as an indication of the server, which indicates the actual address of the server (103).

Payers indicated by the buyer receive order information on the device (Fig. 1, 105N or 105M). If the information was sent to the payer's phone number, the message received contains brief information about the order and a link to a page with a full description of the order and options for refusing and confirming payment of the buyer's order. When clicking on the link, the payer displays the interface of the order information (Fig. 5). If the information was sent to the payer's e-mail, the message contains information about the order, options for rejection and confirmation of payment of the buyer's order.

In some embodiments, the order information interface comprises at least a description of the order and / or customer comments (501), order items (502).

In some implementations, if the information was sent to the electronic messenger account associated with the payer’s phone number, the message contains information about the order, options for refusing and confirming payment of the payer's order.

In case of expressing consent to pay for this order (payment confirmation option) by the buyer, the payer (105N or 105M) is redirected to the payment interface of the order. If the consent to payment is made by more than one payer, then all subsequent payers, except the very first, refuse to make the payment.

In some implementations, consent to payment is expressed by clicking on the “Execute” / “Confirm” button (504).

In some implementations, when a payment is refused, the payer displays the payment rejection interface.

In some implementations, when processing a payment consent, the server (103) determines the value of the OrderNumber number associated with this order, then the payer displays the payment interface for this customer order for this payer.

In some implementations, server (103) processes the click through pay_link by the payer as follows:

- Gets the parameters and their value specified in the link, incl. value pay_code;

- Finds the values of the identifier auth_context_id, the order identifier order_id associated with the given pay_code value;

- Retrieves a copy of the order with the specified order_id from the database (104);

- Retrieves the value of OrderNumber;

- Makes the necessary settings for the payment of goods through a payment gateway.

In some implementations, the settings of the payment gateway mean the implementation of the sequence of actions (operations) necessary to effect payment, for example, registering an order with a payment gateway.

If necessary, the payer selects the payment medium in the payment interface. When the choice of means of payment is made, the payer enters the payment data and confirms the payment.

In some embodiments, the choice of means of payment includes the following options - plastic card, payment systems, payment via SMS, etc.

In some embodiments, the payment data includes a card number, CVC / CVC2 code, card expiration date, card holder.

After confirming the payment of the payer, the server (103) notifies the buyer of the payment of his order by the payer.

If it is not possible to complete the payment of the order by the payer, the server (103) notifies the buyer of a payment error.

In some embodiments, the server (103) is a virtual server.

In some embodiments, the server (103) is a distributed computer system including 2 or more servers.

In some embodiments, the database (104) is a distributed database.

In some embodiments, the database (104) is a key-value storage.

In some embodiments, the customer device (102) is a personal computer.

In some embodiments, the customer device (102) is a smartphone or tablet.

In some embodiments, the customer’s device is an electronic terminal located in a store. The terminal is connected to the Internet and has the ability to access the server (103).

In some embodiments, communication between the device 105N and / or 105M and the server (103) is via the Internet. In some embodiments (Fig. 1), the server (103) is a web server on which an online store is located, in which the buyer selects the goods to order. The server (103) uses a database (104) to store data.

In some implementations, the http / https protocol and the methods implemented in them, get, post, put, etc. can be used to exchange data between the server (103) and the device of the buyer (102) and / or the payer.

In some implementations, an XML protocol or a binary protocol can be used to exchange data between the server (103) and the customer’s device (102) and / or the payer.

In one embodiment, the technical solution can be implemented as follows. Making purchases in the online store or mobile application, the buyer on the device (Fig. 1, 102) adds the purchased goods to the basket. After all the necessary goods are selected and added to the basket, the process of placing an order and its payment takes place.

In some embodiments, information about the goods in the basket is stored on the device of the buyer (Fig. 1, 102). In some embodiments, information about the goods in the basket is stored on the server (Fig. 1, 103).

In the process of making a purchase or when displaying a formed basket, the buyer on the device (Fig. 1, 102) displays a purchase payment interface with the option of choosing to pay for goods at the expense of third-party payers.

In some implementations (hereinafter, the interface display) includes the following steps: the server (Fig. 1, 103) generates a page view that is sent to the customer’s device (102), then the customer’s device (Fig. 1, 102) receives the generated representation and produces its display on the screen.

In some implementations, the page presentation is generated using html (xhtml) and / or css and / or js.

In some implementations, the page presentation is generated using xml.

The buyer, wanting third parties to pay for his goods, enters data on payers in the interface and selects the option to pay at the expense of third parties (payers input interface), which will be offered to pay for the order.

In some embodiments, payer data includes a name, phone number, and / or e-mail. The interface may include input fields for at least one payer.

In some embodiments, the payer data includes a name, phone number and / or e-mail, the name of the payment group.

In some embodiments, the payer data input interface comprises an element for selecting payer groups previously created by the buyer. In this case, the groups are loaded by the server (Fig. 1, 103) from the database (Fig. 1,104).

After entering data on the customer’s device (Fig. 1, 102), the entered data is validated. Upon successful validation of the entered data, it creates an authorization context, a unique authorization context identifier auth_context_id is generated, which is associated with the payers and the order identifier CurrentOrder.

In some implementations, the CurrentOrder uses the order number OrderNumber or any other identifier that uniquely identifies the order.

In some implementations, data validation involves checking the data against a certain format. For example, the correspondence of the entered e-mail to the permitted format of e-mail (RFC 2822).

In some embodiments, identifiers are associated by creating an entry in RAM or a database (FIGS. 1, 104). An example would be to create an entry containing the fields auth_context_id, payer_id (payer), CurrentOrder.

Then, information about the order made by the buyer is sent to the indicated phone numbers and / or e-mails of the payers, with reference to the payment for this order.

In some implementations, order information is sent to a phone number via sms, mms.

In some implementations, order information is sent to a phone number to an electronic messenger account associated with that number.

In some implementations, when sending order information to the payer, the server (103) determines the accounts associated with the payer's phone number in electronic instant messengers (viber, telegram, whatsapp, etc.) and sends information to at least one associated electronic instant messenger account .

In some implementations, the identification of accounts associated with the number is carried out by using the messenger data API.

In some embodiments, the validation of the entered data occurs on the customer’s device (Fig. 1, 102).

In some embodiments, the validation of the entered data occurs on the server (Fig. 1, 103), while the data about the payers entered on the device (102) is sent to the server (Fig. 1, 103), where they are validated.

In some embodiments, the sending of information about the customer’s order with reference to payment occurs on the customer’s device (Figs. 1, 102).

In some embodiments, when sending information about a customer’s order with reference to payment on the customer’s device (Fig. 1, 102), the following steps are performed:

- a description of the customer’s order is generated,

- a request is sent to the server (103) to generate at least one unique link to pay for the order by the payer

- the server (103), having received this request, generates at least one unique link for payment of the order by the pay_link payer pointing to the server, while the link connects the authorization context auth_context_id, the order identifier of CurrentOrder and the payer;

- send at least one pay_link to the buyer’s device (102);

- receive on the buyer's device (102) at least one generated pay_link link,

- send the generated order description and pay_link from at least one payer to the buyer’s device (102).

In some implementations, the sending of information about the customer’s order with reference to payment occurs on the server.

In some embodiments, when sending information about a customer’s order with reference to payment on the server (103), the following steps are performed:

- the server (103) based on the information about the goods in the order, generates a description of the customer’s order,

- the server (103) generates at least one unique link for payment of the order by the pay_link payer pointing to the server (103), while the link connects the authorization context auth_context_id, the order identifier of CurrentOrder and the payer;

- the server (103) sends the generated description of the order and the pay_link link to at least one payer using his phone number or e-mail.

In some implementations, link generation includes the following steps:

- Generate on the server (103) a unique identifier pay_code;

- Bind on the server (103) the pay_code identifier with the authorization context identifier auth_context_id, the order identifier CurrentOrder.

- Form on the server (103) a link pointing to the server (103), in one of the parameters of which the value pay_code is transmitted.

An example of a link could be http://web-server.com/param1={pay_code} or http://web-server.com/param1/{pay_code}

Where instead of {pay_code} a specific value is substituted. The URI web-server.com is used as an indication of the server, which indicates the actual address of the server (103).

Payers indicated by the buyer receive order information on the device (Fig. 1, 105N or 105M). If the information was sent to the payer's phone number, the message received contains brief information about the order and a link to a page with a full description of the order and options for refusing and confirming payment of the buyer's order. When clicking on the link, the payer displays the interface of the order information (Fig. 5). If the information was sent to the payer's e-mail, the message contains information about the order, options for rejection and confirmation of payment of the buyer's order.

In some embodiments, the order information interface comprises at least a description of the order and / or customer comments (501), order items (502).

In some implementations, if the information was sent to the electronic messenger account associated with the payer’s phone number, the message contains information about the order, options for refusing and confirming payment of the payer's order.

In case of expressing consent to pay for this order (payment confirmation option) by the buyer, the payer (105N or 105M) is redirected to the payment interface of the order. If the consent to payment is made by more than one payer, then all subsequent payers, except the very first, refuse to make the payment.

In some implementations, consent to payment is expressed by clicking on the “Execute” / “Confirm” button (504).

In some implementations, when a payment is refused, the payer displays the payment rejection interface.

In some implementations, when processing a payment consent, the server (103) determines the value of the OrderNumber number associated with this order, then the payer displays the payment interface for this customer order for this payer.

In some implementations, server (103) processes the click through pay_link by the payer as follows:

- Gets the parameters and their value specified in the link, incl. value pay_code;

- Finds the values of the identifier auth_context_id associated with this pay_code value, the order identifier CurrentOrder;

- Retrieves a copy of the order with the specified CurrentOrder from the database (104);

- Retrieves the value of OrderNumber;

- Makes the necessary settings for the payment of goods through a payment gateway.

In some implementations, the settings of the payment gateway mean the implementation of the sequence of actions (operations) necessary to effect payment, for example, registering an order with a payment gateway.

If necessary, the payer selects the payment medium in the payment interface. When the choice of means of payment is made, the payer enters the payment data and confirms the payment.

In some embodiments, the choice of means of payment includes the following options - plastic card, payment systems, payment via SMS, etc.

In some embodiments, the payment data includes a card number, CVC / CVC2 code, card expiration date, card holder.

After confirming the payment of the payer, the server (103) notifies the buyer of the payment of his order by the payer.

If it is not possible to complete the payment of the order by the payer, the server (103) notifies the buyer of a payment error.

In some embodiments, the server (103) is a virtual server.

In some embodiments, the server (103) is a distributed computer system including 2 or more servers.

In some embodiments, the database (104) is a distributed database.

In some embodiments, the database (104) is a key-value storage.

In some embodiments, the customer device (102) is a personal computer.

In some embodiments, the customer device (102) is a smartphone or tablet.

In some embodiments, the customer’s device is an electronic terminal located in a store. The terminal is connected to the Internet and has the ability to access the server (103).

In some embodiments, communication between the device 105N and / or 105M and the server (103) is via the Internet. In some embodiments (Fig. 1), the server (103) is a web server on which an online store is located, in which the buyer selects the goods to order. The server (103) uses a database (104) to store data.

In some implementations, the http / https protocol and the methods implemented in them, get, post, put, etc. can be used to exchange data between the server (103) and the device of the buyer (102) and / or the payer.

In some implementations, an XML protocol or a binary protocol can be used to exchange data between the server (103) and the customer’s device (102) and / or the payer.

In one embodiment, the technical solution can be implemented as follows. Making purchases in the online store or mobile application, the buyer on the device (Fig. 1, 102) adds the purchased goods to the basket. After all the necessary goods are selected and added to the basket, the process of placing an order and its payment takes place, and the generated order is assigned the identifier CurrentOrder.

In some embodiments, information about the goods in the basket is stored on the device of the buyer (Fig. 1, 102). In some embodiments, information about the goods in the basket is stored on the server (Fig. 1, 103).

In some implementations, the CurrentOrder uses the order number OrderNumber or any other identifier that uniquely identifies the order.

During the checkout process or when the formed basket is displayed, the buyer is presented with a payment payment interface on the device (102) with the option of choosing to pay for goods at the expense of third-party payers.

In some implementations (hereinafter, the text), the display of the interface includes the following steps: the server (Fig. 1, 103) generates a page view that is sent to the customer’s device (Fig. 1, 102), then the customer’s device (Fig. 1, 102) receives the generated view and displays it on the screen.

In some implementations, the page presentation is generated using html (xhtml) and / or css and / or js.

In some implementations, the page presentation is generated using xml.

Buyers, wanting third parties to pay for the goods, enters data on payers in the interface and selects the option to pay at the expense of third parties (payers input interface), which will be asked to pay for the order.

In some embodiments, payer data includes a name, phone number, and / or e-mail. The interface may include input fields for at least one payer.

In some embodiments, the payer data includes a name, phone number and / or e-mail, the name of the payment group.

In some embodiments, the payer data input interface comprises an element for selecting payer groups previously created by the buyer. In this case, the groups are loaded by the server (Fig. 1, 103) from the database (Fig. 1, 104).

After entering data on the customer’s device (Fig. 1, 102), the entered data is validated.

In some implementations, data validation involves checking the data against a certain format. For example, the correspondence of the entered e-mail to the permitted format of e-mail (RFC 2822).

Then, information about the order made by the buyer is sent to the indicated phone numbers and / or e-mails of the payers, with reference to the payment for this order.

In some implementations, order information is sent to a phone number via sms, mms.

In some implementations, order information is sent to a phone number to an electronic messenger account associated with that number.

In some implementations, when sending order information to the payer, the server (103) determines the accounts associated with the payer's phone number in electronic instant messengers (viber, telegram, whatsapp, etc.) and sends information to at least one associated electronic instant messenger account .

In some implementations, the identification of accounts associated with the number is carried out by using the messenger data API.

In some embodiments, the validation of the entered data occurs on the customer’s device (Fig. 1, 102).

In some embodiments, the validation of the entered data occurs on the server (Fig. 1, 103), while the payer data entered on the device (Fig. 1, 102) is sent to the server (Fig. 1, 103), where it is validated.

In some embodiments, the sending of information about the customer’s order with reference to payment occurs on the customer’s device (102).

In some embodiments, when sending information about a customer’s order with reference to payment on the customer’s device (Fig. 1, 102), the following steps are performed:

- a description of the customer’s order is generated,

- a request is sent to the server (Fig. 1, 103) for generating at least one link to pay for the order by the payer,

- the server (Fig. 1, 103), having received this request, generates at least one link to pay for the order with the pay_link payer pointing to the server, and the link contains the CurrentOrder parameter.

- send at least one pay_link to the customer’s device (Fig. 1, 102)

- receive on the buyer's device (Fig. 1, 102) at least one generated pay_link,

- send the generated description of the order and the pay_link link to at least one payer from the buyer's device (Fig. 1, 102).

In some implementations, the sending of information about the customer’s order with reference to payment occurs on the server.

In some embodiments, when sending information about a customer’s order with reference to payment on the server (Fig. 1, 103), the following steps are performed:

- the server (103) based on the information about the goods in the order, generates a description of the customer’s order,

- the server (103) generates at least one link for payment of the order by the pay_link payer pointing to the server (103), and the link contains the CurrentOrder parameter.

- the server (103) sends the generated description of the order and the pay-link to at least one payer using his phone number or e-mail.

Payers indicated by the buyer receive order information on the device (Fig. 1, 105N or 105M). If the information was sent to the payer's phone number, the message received contains brief information about the order and a link to a page with a full description of the order and options for refusing and confirming payment of the buyer's order. When clicking on the link, the payer displays the interface of the order information (Fig. 5). If the information was sent to the payer's e-mail, the message contains information about the order, options for rejection and confirmation of payment of the buyer's order.

In some embodiments, the order information interface contains at least a description of the order and / or customer comments (FIGS. 5, 501), order items (502).

In some implementations, if the information was sent to the electronic messenger account associated with the payer’s phone number, the message contains information about the order, options for refusing and confirming payment of the payer's order.

In case of expressing consent to pay for this order (payment confirmation option) by the buyer, the payer (105N or 105M) is redirected to the payment interface of the order. If the consent to payment is made by more than one payer, then all subsequent payers, except the very first, refuse to make the payment.

In some implementations, consent to payment is expressed by clicking on the “Execute” / “Confirm” button (504).

In some implementations, when a payment is refused, the payer displays the payment rejection interface.

In some implementations, when processing a payment consent, the server (103) determines the value of the CurrentOrder order number associated with this order, then the payer displays the payment interface for this customer order for this payer.

In some implementations, server (103) processes the click through pay_link by the payer as follows:

- Gets the parameters and their value specified in the link, including CurrentOrder;

- Makes the necessary settings for the payment of goods through a payment gateway.

In some implementations, the settings of the payment gateway mean the implementation of the sequence of actions (operations) necessary to effect payment, for example, registering an order with a payment gateway.

If necessary, the payer selects the payment medium in the payment interface. When the choice of means of payment is made, the payer enters the payment data and confirms the payment.

In some embodiments, the choice of means of payment includes the following options - plastic card, payment systems, payment via SMS, etc.

In some embodiments, the payment data includes a card number, CVC / CVC2 code, card expiration date, card holder.

After confirming the payment of the payer, the server (103) notifies the buyer of the payment of his order by the payer.

If it is not possible to complete the payment of the order by the payer, the server (103) notifies the buyer of a payment error.

In some embodiments, the server (103) is a virtual server.

In some embodiments, the server (103) is a distributed computer system including 2 or more servers.

In some embodiments, the database (104) is a distributed database.

In some embodiments, the database (104) is a key-value storage.

In some embodiments, the customer device (102) is a personal computer.

In some embodiments, the customer device (102) is a smartphone or tablet.

In some embodiments, the customer’s device is an electronic terminal located in a store. The terminal is connected to the Internet and has the ability to access the server (103).

In some embodiments, communication between the device 105 N and / or 105M and the server (103) is via the Internet. In some embodiments (Fig. 1), the server (103) is a web server on which an online store is located, in which the buyer selects the goods to order. The server (103) uses a database (104) to store data.

In some implementations, the http / https protocol and the methods implemented in them, get, post, put, etc. can be used to exchange data between the server (103) and the device of the buyer (102) and / or the payer.

In some implementations, an XML protocol or a binary protocol can be used to exchange data between the server (103) and the customer’s device (102) and / or the payer.

In one embodiment, this technical solution can be implemented as described below.

When making purchases in an online store or mobile application, the buyer adds the items to be bought to the basket. After all the necessary goods are selected and added to the basket, the buyer displays the interface for paying for the order at the expense of third-party payers.

Before displaying the payment interface, the order formed by the buyer is stored on the server (203) and is assigned a unique identifier OrderNumber.

In some implementations, an order includes some (one or more) of the specified data: order number (OrderNumber), total order amount (OrderPrice), order currency code (OrderCurrency), customer name (UserName), customer phone number (UserPhone), address Buyer's e-mail (UserEmail), list of position objects (OrderPositions) containing at least the following fields: absolute links to images of selected positions (PreviewLinks), position names (Title), quantity of goods in a position (Quantity), unit price product in position (Price).

In some embodiments, the order is stored in a database (206).

The buyer, wanting third parties to pay for his goods, enters data on payers on the device (Fig. 2, 102) in the interface and selects the option of payment at the expense of third parties (payers input interface), who will be asked to pay for the formed order.

In some embodiments, payer data includes a name, phone number, and / or e-mail.

In some embodiments, the payer data includes a name, phone number and / or e-mail, the name of the payment group.

After entering data on the customer’s device (Fig. 2, 102), the entered data is validated. Upon successful validation of the entered data on the server (204), an authorization context is created, a code for simplified authorization of payers is generated, a unique authorization context identifier auth_context_id is generated, which is associated with the payers and order ID OrderNumber. Then, to the indicated phone numbers or e-mails of the payers, the server (204) sends information about the order made by the buyer, with reference to the confirmation of payment of this order confirm_link.

In some embodiments, the validation of the entered data occurs on the customer’s device (102).

In some embodiments, the validation of the entered data occurs on the server (204), while the data about the payers entered on the device (102) is sent to the server (204), where they are validated.

In some embodiments, the sending of customer order information with reference to a payment confirmation occurs on the customer’s device (102).

In some embodiments, the sending of information about the customer’s order with reference to the payment confirmation takes place on the server.

In some embodiments, when sending information about a customer’s order with reference to a payment confirmation on the server (204), the following steps are performed:

- the server (204) based on the information about the goods in the order, generates a description of the customer’s order,

- the server (204) generates at least one unique link to confirm payment of the order by the payer confirm_link pointing to the server (204), while the link contains a code for simplified authorization of payers and links the authorization context auth_context_id, order ID of the orderNumber and the payer ,

- server (204) sends the generated order description and confirm_link to at least one payer using his phone number or e-mail.

In some implementations, generating a confirm_link includes the following steps:

- Generate on the server (204) a unique identifier pay_code (code for simplified authorization);

- Bind on the server (204) the pay_code identifier with the authorization context identifier auth_context_id, the order identifier OrderNumber.

- Form on the server (204) a link pointing to the server (204) in one of the parameters of which the pay_code value is transmitted.

An example of a link could be http://web-server.com/param1={pay_code) or http://web-server.com/param1/{pay_code}

Where instead of {pay_code} a specific value is substituted. As an indication of the server, the URI web-server.com is used, which indicates the actual address of the server (204).

Payers indicated by the buyer receive order information on the device (Fig. 2, 105N or 105M). If the information was sent to the payer's phone number, the message received contains brief information about the order and a link to a page with a full description of the order and options for refusing and confirming payment of the buyer's order. When clicking on the link, the payer displays the interface of the order information (Fig. 5). If the information was sent to the payer's e-mail, the message contains information about the order, options for rejection and confirmation of payment of the buyer's order.

In some embodiments, the order information interface comprises at least a description of the order and / or customer comments (501), order items (502).

In some implementations, if the information was sent to an electronic messenger account associated with the payer’s phone number, the message contains information about the order, options for refusing and confirming payment of the payer's order.

In the case of expressing consent to pay for this customer’s order, the payer (105N or 105M) is redirected by the server (204) to the order payment interface formed on the server (203). If the consent to payment is made by more than one payer, then all subsequent payers, except the very first, refuse to make the payment.

In some embodiments, for redirecting the payer by the server (204) to the order payment interface generated on the server (203), a redirect_link link is generated, pointing to the server (203) and containing the order number OrderNumber and optionally a token.

In some implementations, the redirect_link link format is predefined when configured. As an illustrative example, when setting up, the address of the payment processor, such as http://webshop.com/pay/order={OrderNumberasket&token={Token}, can be set. where {OrderNumber} is the value of the order number, and {Token} is the token.

In some implementations, consent to payment is expressed by clicking on the “Execute” / “Confirm” button (504).

In some implementations, when a payment is refused, the payer displays the payment rejection interface.

In some implementations, when processing a payment consent, the server (204) determines the value of the OrderNumber associated with this order and sends this data to the server (203). After that, the payer on the device (Fig. 2, 105N or 105M) displays the payment interface of this customer order for this payer.

In some implementations, when processing a payment consent, the server (204) determines the token, the value of the OrderNumber associated with this order, and sends this data to the server (203). After that, the payer on the device (Fig. 2, 105N or 105M) displays the payment interface of this customer order for this payer. After receiving the data, the server (203) checks the token associated with the given order number OrderNumber and the received token, as well as the availability of the stored order with this orderNumber. In case of their mismatch and / or absence of an order with such an OrderNumber number, the payment operation is canceled. After that, the server (203) receives from the database (206) the data associated with the OrderNumber order and makes the necessary settings for the payment of goods through the payment gateway.

In some implementations, the settings of the payment gateway mean the implementation of the sequence of actions (operations) necessary to effect payment, for example, registering an order with a payment gateway.

If necessary, the payer on the device (Fig 2, 105N or 105M) in the payment interface selects the payment medium. When the choice of means of payment is made, the payer enters the payment data and confirms the payment.

In some embodiments, the choice of means of payment includes the following options - plastic card, payment systems, payment via SMS, etc.

In some embodiments, the payment data includes a card number, CVC / CVC2 code, card expiration date, card holder.

After confirming the payment of the payer, the server (203) notifies the buyer of the payment of his order by the payer.

If it is not possible to complete the payment of the order by the payer, the server (203) notifies the buyer of an error in payment.

In some embodiments, the database (205) may be a relational database or key-value storage, or a hierarchical database.

In some embodiments, the database (205) is located in the server RAM (204).

In some embodiments, the customer device (102) is a personal computer.

In some embodiments, the customer device (102) is a smartphone or tablet.

In some embodiments, the customer’s device is an electronic terminal located in a store. The terminal is connected to the Internet and has the ability to access the server (203).

In some embodiments, communication between the server (203) and the server (204) is via the Internet.

In some embodiments, communication between the device (105N) and / or 105M and the server (204) or (203) is via the Internet.

In some implementations, the protocol http and / or https is used to communicate the server (203) and the server (204).

In some implementations, a binary protocol is used to communicate the server (203) and the server (204).

In some embodiments (Fig. 2), the server (203) is a web server on which an online store is located, in which the buyer selects the goods to order. The server (204) hosts software that allows payment for the goods of the buyer at the expense of third-party payers. Server software (204) uses a database (205) to store data.

In some implementations, the http / https protocol and the methods implemented in them, get, post, put, etc., can be used to exchange data between the server (203) and the buyer’s device (102).

In some implementations, the http / https protocol and the methods implemented in them - get, post, put, etc. can be used to exchange data between the server (203) or (204) and the payer device (105N or 105M).

Some nuances that are beyond the scope of this technical solution, but necessary for understanding the concept of order processing by an online store running on a web server (103) or (203) are described below (Fig. 7).

1. The buyer interacts with the store to create an order in the online store.

2. After delegating the right to pay the order to the payer and receiving confirmation from the payer, the store registers the order in the payment gateway. For registration, such parameters as the amount debited, the currency debited, the order number in the store system, as well as the customer return URL are used.

3. On the registration request, the payment gateway returns a unique order identifier in the payment system and the URL to which the payer must be redirected to receive the payment form.

4. The store sends the redirect client browser to the URL obtained in step 3.

5. The payer device opens the URL.

6. As the page at the specified URL, the payer’s device displays the payment form.

7. The payer fills out the form and sends the data to the payment gateway server.

8. The system checks the involvement of the card in 3DSecure (SecureCode).

9. The gateway sends the payer device a redirect to the issuer’s ACS page (this step is necessary to implement 3DS).

10. The payer device requests the user authorization form from ACS (each issuer does this differently).

11.ACS sends and displays this form on the payer’s device.

12. The payer fills out the form and sends it to ACS.

13. ACS processes the completed form and (regardless of the result) submits to the redirect browser the URL of the payment gateway page. Along with this URL, the encrypted parameters of the authorization result are transmitted.

14. The payer device requests the payment gateway page, passing the encrypted parameters of the authorization result.

15. The payment gateway makes payment (debiting).

16. After making the payment, the payment gateway transfers the return URL (indicated earlier when registering the order with the store) to the payer device.

17. The payer device requests a page with payment results from the store.

18. (optional) The store system requests a payment gateway about the payment status of the order (by internal number in the payment system).

19. (optional) The payment gateway returns the payment status.

20. The store system transmits a page with payment results to the client’s browser.

In this scheme, steps 18 and 19 are optional, the store may not use them in their work. If after 20 minutes allotted for payment, the client did not return from the payment gateway to the store payment results page (to the customer’s return URL), then the payment is considered unsuccessful. Changing the order payment status can be done at the request of the store manually by the Bank staff after checking the transaction status in banking systems. In this case, after confirming the change in the status of the order, the store may fulfill a second request for the status of payment for the order (steps 18-19). Upon completion of paragraph 20, the interaction between the store and the payment gateway in on-line mode ends. Further operations to complete the payment (in the case of two-stage payments), cancel the payment and refund are carried out off-line.

In some embodiments, for registering an order with a payment gateway, at least the following data is transmitted by the server (FIG. 2, 203 or FIG. 1, 103):

- merchantOrderNumber - order number in the store;

- amount - payment amount in minimum currency units;

- currency - payment currency code ISO 4217;

- returnUrl - address to which the payer should be redirected in case of successful payment;

- failUrl - address to which the payer should be redirected in case of unsuccessful payment.

EXAMPLES OF IMPLEMENTATION

The server (Fig. 2, 203) is a web server on which an online store is located. The web server software used is the MySQL database, the Apache 2 web server, and the Debian 7 operating system.

The server (Fig. 2, 204) is a web server on which a service is located that provides the ability to pay for goods at the expense of third-party payers. As the web server software, the MSSQL database (205), the IIS web server, and the Windows operating system are used.

The customer device (102) is a laptop with a Windows operating system.

The buyer through the Internet, through the browser (firefox, opera, ie, chrome or any other) device (102) browses the pages of the online store and adds the goods that he wants to buy to the basket of this online store. Having selected the necessary goods, the buyer begins the process of registration of goods. Starting the checkout process, the web server on which the store is located saves the generated order in its own MySQL database. The saved order is given the order number identifier OrderNumber, the order identifier order_id, which is set automatically when a new record is added to the database. After passing the stages of placing an order, the buyer on the device (102) displays the payment option selection interface containing the payment option at the expense of third-party payers in the form of a "pay for me" button. When forming this interface, the server (203) created an order nugget, saved it as a js object and linked the sending of this js object and the token associated with the order by clicking on the "pay for me" button to the server (204). When this button is clicked, data is sent to the server (204) and the process of authorization and customer identification by the server (204) starts. The server (204) displays the authorization and identification interface in the modal window of the online store located on the server (203), containing the fields name (Fig. 3, 301), customer phone number (302). After entering the data by pressing the button (303), they are sent to the server (204) and the customer is shown an interface containing an authorization code input field (Fig. 3B, 304). The server (204), having received the data, generates an authorization code (auth_code) and sends it to the buyer at the phone number indicated by him. The buyer, having received an authorization code, enters it (auth_code) on the device (102), after which the entered code is sent to the server (204). The server (204), having received the authorization code entered by the buyer, compares it with the one sent to the buyer. If both codes match, the buyer is authorized, otherwise authorization is denied. After successful authorization of the buyer, he is associated with the order identifier order_id. Next, the buyer on the device (102) in the same modal window displays the interface for entering new or selecting previously entered data about third parties - payers, who will be asked to pay for the order. This interface contains fields for entering the name and phone number or e-mail of the payer. The buyer enters the data and sends it to the server (204) by clicking on the "request payment" button (Fig. 4, 408). Upon successful validation of the entered data on the server (204), an authorization context is created, a unique authorization context identifier auth_context_id is generated, which is associated with the payers specified by the buyer and order ID order_id. Then, to the indicated phone numbers or e-mails of the payers, the server (204) sends information about the order made by the buyer, with a link to the confirmation of payment of the order confirm_link, unique for each payer. Payers indicated by the buyer receive order information on the device (Fig. 2, 105N or 105M). If the information was sent to the payer's phone number, the message received contains brief information about the order and a link to a page with a full description of the order and options for refusing and confirming payment of the buyer's order. When clicking on the link, the payer displays the interface of the order information (Fig. 5). If the information was sent to the payer's e-mail, the message contains information about the order, options for rejection and confirmation of payment of the payer's order. The payer from the device 105N presses the “confirm” button, the server (204) determines the value of the OrderNumber order number associated with this order and the token, then sends this data to the server (203) and redirects the payer to the order payment interface formed on the server (203). Server (203), before displaying the payment interface to the payer, verifies the sent token, and the token associated with this order extracts the order information from the database with OrderNumber number and makes the necessary settings to pay for the goods through the payment gateway. Next, the payer on the device (Fig. 2, 105N or 105M) in the payment interface selects the payment medium. When the choice of means of payment is made, the payer enters the payment data and confirms the payment.

A person skilled in the art can easily understand the various embodiments of the present technical solution from the above description and prior art, the disclosed technical solution. It is assumed that the description and examples are considered only as exemplary, with the essence and scope of this technical solution, indicated by the formula.

It should be borne in mind that the present technical solution is not limited to the exact designs that were described above and illustrated in the accompanying drawings, and that various modifications and changes can be made without departing from its scope.

Claims (14)

1. The method of online transfer of the right to pay for goods or services from the buyer's device to third-party payer devices contains the following steps: - receive on the server from the buyer's device a request for payment of the generated order at the expense of another payer; - form a customer’s order mold on the server, assign the order identifier to the order mold and save the order mold in the database; - authorize the buyer placing the order through the buyer's device; - receive on the server data of at least one payer from the buyer's device; - form on the server for at least one payer a unique link to pay for the order formed by the buyer, pointing to the server, and the link connects the authorization context, order ID, payer; - the server sends at least one payer order information, a unique link generated to pay for the order formed by the buyer; - when clicking on the generated unique link, the payer displays on the payer’s device an interface for paying for the order made by the buyer without the need for authorization and / or identification. 2. The method of claim 1, wherein the payer data includes at least a full name and a phone number. 3. The method of claim 1, wherein the payer data includes at least a full name and e-mail. 4. The method according to claim 1, wherein sending order information to payers is carried out via sms or mms. 5. The method according to claim 1, wherein sending information about the order to payers is carried out by means of an electronic messenger account associated with the payer's phone number. 6. The method according to claim 1, wherein sending order information to payers is done via e-mail. 7. The method of claim 1, wherein the order information includes order description text and / or customer comments, order items.

Images