KR102093549B1 - Method of paying by user access and apparatus providing the method - Google Patents

Abstract

Payment method by a user connection according to an embodiment of the present invention, collecting user information for performing a payment; And generating a payment link for input of payment related information; And generating an identifier according to a predetermined rule based on the user information. And adding the identifier to the payment link to generate a payment link dedicated to the user; And transmitting the user-only payment link to the user; And receiving the payment-related information through the user-specific payment link; And performing a payment procedure by optical character recognition based on the payment related information, wherein the identifier and the user-specific payment link are generated only for the payment performed by the user.

Description

Payment method by user access and a device providing the method {METHOD OF PAYING BY USER ACCESS AND APPARATUS PROVIDING THE METHOD}

The present invention relates to a payment method by a user connection and an apparatus providing the method, and more specifically, by verifying whether a connection to a payment link is by a party right holder having access, non-face to face using optical character recognition The present invention relates to a payment method by user access and an apparatus for providing the method, which can guarantee the reliability and security of the payment procedure.

Recently, fintech technology has been highlighted due to changes in financial infrastructure due to the emergence of specialized Internet banks, attempts to diversify financial transactions, and globalization of commerce. These fintech technologies are expanding and applied to various business fields in which existing payment methods are used. Accordingly, various technologies are combined with the existing payment method.

Existing payment methods may be classified into a face-to-face payment method and a non-face-to-face payment method depending on whether the buyer and the seller face each other at the time of payment.

In the case of the face-to-face payment method, the purchaser and the seller perform the payment procedure in a face-to-face state. Therefore, since the purchaser and the seller can directly check the payment procedure, verification of whether the other party has a legitimate authority with respect to the payment procedure is unnecessary.

However, in the case of the non-face-to-face payment method, the payment procedure is performed without the buyer and seller facing each other. Specifically, when a purchase contract is concluded between a buyer and a seller, the seller transmits a link for input of payment information to the buyer, and the buyer can access the link and input payment information. In this process, a third party without legitimate authority in connection with payment, that is, a third party other than the buyer and the seller, may access the link. For example, there may be a case where a third party accesses a link transmitted by the seller to perform payment, or a third party accesses the seller's link instead to authorize payment.
[Related literature]
JP 2005-216226 A

The present invention provides a payment method and a method using a user connection that can guarantee the reliability and security of an in-person payment procedure by verifying whether or not the access to the payment link is by a party right holder having access. An object of the present invention is to provide a device.

In addition, the present invention prevents access to the server of a user other than the user by collecting the user's access environment, and prevents an unauthorized third party from accessing the URL provided to the user, thereby solving the problem of the existing URL. An object of the present invention is to provide a payment method by user access and an apparatus providing the method.

Furthermore, the present invention generates a URL so that the URL is not polluted or modified by attaching the identification information obfuscating the user information to the URL, and the user access by verifying whether the URL accessed by the user is polluted or modified. An object of the present invention is to provide a payment method and an apparatus providing the method.

The technical problems to be achieved in the present invention are not limited to the technical problems mentioned above, and other technical problems that are not mentioned are obvious to those skilled in the art to which the embodiments proposed by the following description belong. It can be understood.

Payment method by a user connection according to an embodiment of the present invention, collecting user information for performing a payment; And generating a payment link for input of payment related information; And generating an identifier according to a predetermined rule based on the user information. And adding the identifier to the payment link to generate a payment link dedicated to the user; And transmitting the user-only payment link to the user; And receiving the payment-related information through the user-specific payment link; And performing a payment procedure by optical character recognition based on the payment related information, wherein the identifier and the user-specific payment link are generated only for the payment performed by the user.

In a computer-readable recording medium recording a program for executing a payment method by a user connection according to another embodiment of the present invention, the payment method by the user connection comprises: collecting user information for performing payment; And generating a payment link for input of payment related information; And generating an identifier according to a predetermined rule based on the user information. And adding the identifier to the payment link to generate a payment link dedicated to the user; And transmitting the user-only payment link to the user; And receiving the payment-related information through the user-specific payment link; And performing a payment procedure by optical character recognition based on the payment related information, wherein the identifier and the user-only payment link are generated only for the payment performed by the user.

According to the embodiments of the present invention, it is possible to prevent a third party who is not a user who has a legitimate authority for the payment procedure from accessing the server, thereby ensuring the reliability and security of the non-face-to-face payment procedure.

In addition, according to embodiments of the present invention, by generating a URL that is not polluted or modified by a third party, and verifying whether a URL accessed by a user is polluted or modified, it is possible to solve the problem of the existing URL. have.

Furthermore, according to embodiments of the present invention, it is possible to prevent unnecessary storage space from being wasted by attaching the collected information to a URL without separately storing it.

1 is a view for explaining the type of payment method by user access according to an embodiment of the present invention.
2 is a block diagram showing the configuration of an apparatus for providing a payment method by a user connection according to an embodiment of the present invention.
FIG. 3 is a diagram illustrating a process of creating a payment link exclusively for a buyer in order to perform payment by a user connection according to an embodiment of the present invention.
4 is a diagram illustrating a process of reading an identifier to perform payment by a user connection according to an embodiment of the present invention.
5A to 5C are diagrams illustrating examples of transmitting a payment link to perform payment by user access according to an embodiment of the present invention.

Hereinafter, specific embodiments of the present invention will be described in detail with reference to the drawings. However, the technical spirit of the present invention is not limited by the embodiments described below, and other implementations that fall within the scope of the technical spirit of the present invention or other inventions that are backward due to the addition, modification, and deletion of other components. You can easily suggest examples.

The terminology used in the present invention has been selected, as far as possible, the general terminology widely used in connection with the present technology, but in special cases, the term is arbitrarily selected by the applicant, and in this case, its meaning is described in detail in the description of the applicable invention. Therefore, it is revealed in advance that the present invention should be grasped as the meaning of the term rather than the name of the simple term. In the descriptions below, the word 'comprising' does not exclude the presence of elements or steps other than those listed.

1 is a view for explaining the type of payment method by user access according to an embodiment of the present invention.

The payment method according to the user connection according to an embodiment of the present invention may allow the payment server to generate a payment link and transmit it as user-specific information, and allow the user to access the payment link and perform payment by optical character recognition. .

The payment link may be for input of payment information or payment card image. Here, the payment information may be information necessary for approval of payment. The payment information may include at least one of a card number, a card expiration date, a CVC number, and a cardholder's name.

Payment by Optical Character Recognition (OCR) scans or shoots the payment card to obtain the payment card image, performs optical text recognition on the payment card image, recognizes the payment information, and then pays the payment information. You can approve payment based on that.

The type of payment method by user access may be classified into a terminal type and a server type according to the type of data that the mobile terminal 100 transmits to the server 200. Here, the mobile terminal 100 is a payment-side device owned by a payer, and may transmit payment information to the server 200. Here, the payer may be a purchaser who purchases an item or service and pays for the cost through the payment procedure. In addition, the server 200 may be a payee-side device owned by the payee, or a value-added network (VAN) company device that processes payments and receives fees on behalf of the payee. Here, the payee may be a seller who sells goods or services and receives payment for the payment through the payment procedure.

In the case of a terminal type, data that the mobile terminal 100 transmits to the server 200 may be payment information. Specifically, the mobile terminal 100 may access the payment link transmitted by the server 200. In this case, the mobile terminal 100 acquires the payment card image by scanning or photographing the payment card C, performs optical character recognition on the payment card image, recognizes the payment information, and then displays the payment information to the server 200 ). The server 200 may approve payment based on payment information.

To this end, a payment application (a payment app) for performing OCR recognition may be installed and executed in the mobile terminal 100. When the mobile terminal 100 wants to perform payment by OCR recognition, the mobile terminal 100 may activate and execute the payment app.

In the case of a server type, data that the mobile terminal 100 transmits to the server 200 may be a payment card image. Specifically, the mobile terminal 100 may access the payment link transmitted by the server 200. In this case, the mobile terminal 100 may acquire a payment card image by scanning or photographing the payment card C, and transmit the payment card image to the server 200.

The server 200 may recognize payment information by performing optical character recognition (OCR) on the payment card image. To this end, a payment app for performing OCR recognition may be installed and executed on the server 200. When the server 200 wants to perform payment by OCR recognition, it may activate and execute the payment app. In this case, the server 200 may approve payment based on payment information.

Referring to FIG. 1, in the case of a terminal type, the mobile terminal 100 acquires a payment card image by scanning or photographing a payment card C, and extracts payment information 110 from the payment card image. Here, the payment information 110 is a card number and a card validity period. Therefore, the form of information that the mobile terminal 100 transmits to the server 200 becomes text data. In this case, the server 200 approves payment based on the received card number and the validity period of the card.

In FIG. 1, in the case of the server type, the mobile terminal 100 scans or photographs the payment card C to obtain the payment card image 120 and transmits the obtained payment card image 120 to the server 200. . Therefore, the form of information that the mobile terminal 100 transmits to the server 200 becomes image data. In this case, the server 200 extracts payment information from the payment card image 120 and approves payment based on the payment information.

Meanwhile, in FIG. 1, the mobile terminal 100 may be implemented in the form of a tablet PC, a laptop computer, a desk top PC, and the like. In addition, the server 200 may be implemented in the form of a mobile terminal, a tablet PC, a laptop computer, a desk top PC, and the like.

2 is a block diagram showing the configuration of an apparatus for providing a payment method by a user connection according to an embodiment of the present invention.

An apparatus for providing a payment method by user access according to an embodiment of the present invention may generate a payment link and transmit it as user-specific information, and allow a user to access the payment link and perform payment by optical character recognition. have.

A device that provides a payment method by user access may be implemented as the server 200. In this case, the server 200 may generate and transmit a user-only URL, and verify whether the access to the URL is a connection by a legitimate user. Specifically, when transmitting a web URL for the purpose of allowing the user to access the server, the server 200 may attach an identification code to identify the user information to the URL. For example, after obfuscating the information of the user's hardware or software, etc., which is expected to the connection URL to be transmitted to the user, and attaching it to the URL, and transmitting the information, the user compares the connection information and the URL when connecting to the server through this URL. It is possible to determine whether access is allowed by verifying whether or not access is made in an expected environment. Thereby, it is possible to prevent a third party from illegally acquiring the URL and accessing it.

To this end, the server 200 may include an information collection unit 210, a URL generation unit 220, a reading unit 230, and a control unit 240.

The information collecting unit 210 may collect information necessary to provide payment by user access. Specifically, the information collecting unit 210 may collect buyer-specific information, buyer information, access information, and the like.

The buyer-specific information may be information that a buyer can receive a payment link. The buyer-specific information may include at least one of a mobile terminal number possessed by the buyer, a buyer's email address, a buyer's email account, and a buyer SNS account.

Here, the buyer may be a payer who purchases an item or service and pays the cost for this through a payment card. In this case, the mobile terminal 100 may be a payer-side device owned by the payer. In addition, the payment card may include all types of cards that can be paid, such as credit cards, check cards, and prepaid cards.

The buyer information may be information about the buyer. For example, the buyer information may include the buyer's name or ID, address, and job.

The access information may be information related to access to the corresponding payment link when the visitor accesses the payment link. Specifically, the access information may include access URL, access IP address, access program information, access terminal information, and the like. For example, when a buyer accesses a payment link through the mobile terminal 100, the access information may be a serial number of the mobile terminal 100.

The URL generator 220 may generate a payment link.

Here, the payment link may record a location on a network where a buyer can input payment information and payment card images. According to an embodiment, the payment link may be a uniform resource locator (URL). The URL may be a set of rules that record the type and location of specific information resources that are distributed over the network. When accessing the payment link, it may move to a location on the network where payment information can be entered.

The URL generator 220 may generate an identifier that can verify the buyer.

In this case, the URL generator 220 may generate an identifier based on buyer-specific information, buyer information, or access information. Here, the identifier may be uniquely assigned to the transaction contract concluded by the buyer.

The URL generator 220 may generate an identifier according to various embodiments.

According to an embodiment, the URL generation unit 220 may generate an identifier by encrypting any one of buyer-specific information, buyer information, or access information.

Here, encryption uses an encryption key (a specific bit string) to transform the information into an encrypted text whose meaning is unknown. The encryption method can be roughly classified into a private key method and a public key method. Since the private key method uses the same key for encryption and decryption, it is necessary for the sender and the receiver to have the same key in secret during communication. On the other hand, the public key method uses different keys for encryption and decryption, and the encryption key is disclosed and the decryption key is kept secret. Encryption can be performed by various algorithms. The encryption algorithm can be classified into a symmetric algorithm and an asymmetric algorithm. The symmetric algorithm may include DES, 3-DES, AES, SEED, ARIA, MASK, etc., and the asymmetric algorithm may include RSA, DSA, etc.

According to another embodiment, the URL generator 220 may generate an identifier by obfuscating any one of buyer-specific information, buyer information, or access information.

Here, obfuscation may be a task that makes it difficult to read code written in a programming language. For example, it may be hiding ideas or algorithms used in a program. Obfuscation can be classified into source code obfuscation and binary obfuscation depending on the scope of application. Obfuscation can be done by: 1) writing code that does more or less complex than necessary, 2) mixing a number of irrelevant functions, and 3) third, encoding the data obscurely. .

The URL generator 220 may generate a buyer-only URL.

Specifically, the URL generator 220 may generate a URL dedicated to the buyer by adding an identifier to the payment link. For example, the URL generator 220 may add an identifier to the end of the address of the payment link, or add the identifier in a hidden form to the payment link when transmitting the payment link and transmit the ID.

The buyer-only URL may be a link created only for payment for a purchase contract signed by the buyer. In this case, the buyer is a party right holder who has access to the buyer-only URL, and a third party other than the buyer becomes an unauthorized person who does not have access to the buyer-only URL.

The reading unit 230 may read the identifier. In this case, the reading unit 230 may read whether the identifier separated from the payment link used by the accessor is the identifier given to the corresponding payment link.

Specifically, the reader 230 may receive the identifier generated by the URL generator 220 and set it as a first identifier.

The reader 230 may separate the identifier from the payment link used by the accessor and set it as the second identifier. To this end, the reader 230 may separate the identifier from the address end of the payment link or extract the identifier hidden in the payment link.

The reading unit 230 may compare whether the first identifier and the second identifier match. If the first identifier and the second identifier match, the reader 230 may determine that the identifier separated from the payment link used by the accessor is the identifier given to the payment link. On the other hand, if the first identifier and the second identifier do not match, the reader 230 may determine that the identifier separated from the payment link used by the accessor is not the identifier assigned to the payment link.

The control unit 240 may transmit a buyer-specific URL as buyer-specific information.

For example, the controller 240 may transmit a buyer-only URL to the mobile terminal number possessed by the buyer, the buyer's email address, the buyer's email account, and the buyer's SNS account.

The control unit 240 may allow or block access to a visitor-only URL. According to an embodiment, the control unit 240 may use an external access firewall.

The controller 240 may perform a payment procedure by optical character recognition.

According to an embodiment, the control unit 240 may transmit a payment receipt to the mobile terminal 100. Specifically, when payment is approved, the controller 240 may generate a payment receipt and transmit the payment receipt generated with buyer-specific information. Here, the payment receipt may include information about payment details including payment approval, payment card, payment amount, payment item, or payment service.

FIG. 3 is a diagram illustrating a process of creating a payment link exclusively for a buyer in order to perform payment by a user connection according to an embodiment of the present invention.

Collect buyer information (S301).

The information collection unit 210 of the server 200 may collect information necessary to provide payment by user access. Specifically, the information collecting unit 210 may collect buyer-specific information, buyer information, access information, and the like. Here, the access information may include information about the accessor's hardware and software.

An identifier capable of verifying the buyer is generated (S302).

In this case, the URL generator 220 of the server 200 may generate an identifier based on buyer-specific information, buyer information, or access information. Here, the identifier may be uniquely assigned to the transaction contract concluded by the buyer.

The URL generator 220 may generate an identifier according to various embodiments. According to an embodiment, the URL generation unit 220 may generate an identifier by encrypting any one of buyer-specific information, buyer information, or access information. According to another embodiment, the URL generator 220 may generate an identifier by obfuscating any one of buyer-specific information, buyer information, or access information.

A buyer-only URL is generated by adding the generated identifier (S303).

Specifically, the URL generation unit 220 of the server 200 may generate a payment link and generate a buyer-only URL by adding an identifier to the payment link. In this case, the URL generator 220 may generate a URL dedicated to the buyer by adding an identifier to the address end of the payment link or by adding the identifier in a hidden form to the payment link.

Here, the payment link may be a URL. In addition, the buyer-only URL may be a link created only for payment for a purchase contract concluded by the buyer. In this case, the buyer is a party right holder who has access to the buyer-only URL, and a third party other than the buyer becomes an unauthorized person who does not have access to the buyer-only URL.

A buyer-only URL is transmitted (S304).

The control unit 240 of the server 200 may transmit a buyer-specific URL as buyer-specific information. For example, the controller 240 may transmit a buyer-only URL to the mobile terminal number possessed by the buyer, the buyer's email address, the buyer's email account, and the buyer's SNS account.

Thereby, the buyer can receive a buyer-only URL and input payment information or a payment card image through the URL.

4 is a diagram illustrating a process of reading an identifier to perform payment by a user connection according to an embodiment of the present invention.

The access information of the visitor is collected (S401).

The information collecting unit 210 of the server 200 may collect access information of a visitor. Here, the access information of the accessor may be information related to access to the URL when the accessor accesses the buyer-only URL. Specifically, the access information of the accessor may include a URL accessed by the accessor, an access IP address, access program information, access terminal information, and the like. For example, when a visitor accesses a buyer-only URL through the mobile terminal 100, the access information of the visitor may be a serial number of the mobile terminal 100.

The identifier is separated from the URL used by the visitor to access (S402).

The reading unit 230 of the server 200 may separate the identifier from the URL used by the accessor to access. In this case, the reader 230 may separate the identifier from the address end of the URL or extract the identifier hidden in the URL.

The identifier is read (S403).

Specifically, the reading unit 230 of the server 200 may receive the identifier generated by the URL generating unit 220 and set it as the first identifier. Also, the reading unit 230 may set the identifier separated in step S402 as the second identifier. In this case, the reading unit 230 may compare whether the first identifier and the second identifier match.

It is determined whether it is a legitimate approach (S404).

The reader 230 of the server 200 may determine whether the access of the accessor is a legitimate access, when the accessor accesses a URL dedicated to the buyer.

Specifically, when the first identifier and the second identifier match, the reader 230 may determine that the second identifier is an identifier given to the buyer-only URL. In this case, access of the accessor is a legitimate access. On the other hand, if the first identifier and the second identifier do not match, the reader 230 may determine that the second identifier is not an identifier given to the buyer-only URL. In this case, the access of the accessor is an invalid access.

If it is determined that the access is legitimate in step S404 (S404-Yes), the control unit 240 of the server 200 allows access of the accessor through the mobile terminal 100 (S405). Thereafter, the controller 240 of the server 200 performs a payment procedure by optical character recognition (S407).

If it is determined in step S404 that it is not a legitimate access (S404-No), the controller 240 of the server 200 blocks access of the accessor through the mobile terminal 100 (S406). In this case, the control unit 240 of the server 200 ends the procedure for providing payment by user access.

5A to 5C are diagrams illustrating examples of transmitting a payment link to perform payment by user access according to an embodiment of the present invention.

5A is a case where a payment link is transmitted through a text message. The server 200 may transmit a payment link through a text message. To this end, the server 200 may transmit a text message including a payment link to the mobile terminal number possessed by the buyer.

The text message app installed and executed in the mobile terminal 100 may receive a text message from the server 200. In this case, the text message app may operate in conjunction with the mobile terminal number. For example, the text message app may receive a text message transmitted to the mobile terminal number.

When receiving the text message, the mobile terminal 100 may activate the inactive text message app and display a text message including a payment link on the screen.

Referring to FIG. 5A, a text message 510 received as the mobile terminal number of the mobile terminal 100 is displayed on the screen of the mobile terminal 100. The text message 510 displays payment link 520 and information about the sender. Here, the sender is a calling number of the seller or server 200 that has sent the text message 510, which is 02-3210-0000.

When the text message 510 is received, payment is performed through optical character recognition by accessing the payment link 520 through the mobile terminal 100. Specifically, in the case of a terminal type, a payment card is photographed or scanned through the mobile terminal 100, and payment information is extracted by optical character recognition from the payment card image. The mobile terminal 100 transmits the extracted payment information to the server 200, and the server 200 approves payment based on the payment information. In the case of a server type, a payment card is photographed or scanned through the mobile terminal 100, and the mobile terminal 100 transmits the acquired payment card image to the server 200. The server 200 extracts payment information by optical character recognition from the payment card image, and authorizes payment based on the payment information.

5B is a case where a payment link is transmitted through SNS. The server 200 may transmit a payment link through SNS. To this end, the server 200 may transmit a conversation including a payment link to the buyer's SNS account.

The SNS app installed and running on the mobile terminal 100 may receive a conversation. In this case, the SNS app may operate in conjunction with the buyer's SNS account. For example, the SNS app may receive a conversation sent to the buyer's SNS account.

When receiving the conversation, the mobile terminal 100 may activate the inactive SNS app and display a conversation including a payment link on the screen. For example, when receiving a conversation through a chat SNS, the mobile terminal 100 may display a conversation window including a payment link on the screen.

Referring to FIG. 5B, on the screen of the mobile terminal 100, a conversation window including a conversation 530 received by the account of the corresponding SNS is displayed. In the conversation 530, payment link 540 and information about the sender are displayed. Here, the sender becomes Paycoq as the SNS account of the seller or server 200 that has sent the conversation 530.

When the conversation 530 is received, payment is performed through optical character recognition by accessing the payment link 540 through the mobile terminal 100. Since the detailed payment process has already been described in FIG. 5A, a description thereof will be omitted.

5C is a case where a payment link is transmitted via email. The server 200 may transmit a payment link through email. To this end, the server 200 may send an email including a payment link to the buyer's email address.

An email app installed and running on the mobile terminal 100 may receive an email at an email address assigned to the buyer's account. In this case, the email app may operate in conjunction with the email address registered by the buyer. For example, the email app can receive emails sent to the buyer's email address.

When receiving the email, the mobile terminal 100 may activate the inactive email app and display an email including a payment link on the screen.

Referring to FIG. 5C, an email window including an email 550 received as an email address of the corresponding email app is displayed on the screen of the mobile terminal 100. In the email window, information about the email 550 including the payment link 560 and the sender is displayed. Here, the sender becomes a paycock as an email account of the seller or server 200 that has sent the email 550.

When the email 550 is received, payment is performed by optical character recognition by accessing the payment link 560 through the mobile terminal 100. Since the detailed payment process has already been described in FIG. 5A, a description thereof will be omitted.

Previously, in FIGS. 3 to 5C, a payment method by user access according to various embodiments of the present disclosure has been described. However, the payment method may be implemented as a computer-readable recording medium recording a program for executing the payment method according to an embodiment.

The embodiments have been mainly described above, but this is merely an example and does not limit the present invention, and those skilled in the art to which the present invention pertains are not exemplified above, without departing from the essential characteristics of the present embodiment. It will be appreciated that various modifications and applications are possible. For example, each component specifically shown in the embodiment may be modified. And differences related to these modifications and applications should be construed as being included in the scope of the invention defined in the appended claims.

100: mobile terminal 110: payment information
120: payment card video 200: server
210: information collection unit 220: URL generation unit
230: reading unit 240: control unit
510: text message 520, 540, 560: payment link
530: Conversation 550: Email

Claims (10)

In the payment method by user access for non-face-to-face payment,
The server, collecting user information to perform the payment;
Generating, by the server, a payment link for input of payment related information;
Generating, by the server, an identifier according to a predetermined rule based on the user information;
Generating, by the server, a payment link dedicated to a user by adding the identifier to the payment link;
Sending, by the server, a payment link dedicated to the user to the user;
Receiving, by the server, the payment related information through the payment link dedicated to the user; And
The server, based on the payment-related information, comprising the steps of performing a payment process by optical character recognition,
The identifier and the payment link dedicated to the user are generated only for the payment performed by the user,
The identifier is for verifying whether the user accessing the payment link dedicated to the user is a party right holder having access authority, and any one of hardware and software used by the user to access the payment link dedicated to the user It is generated by performing any one of obfuscation and encryption for user information that is about, and is used to determine whether the user is allowed to access by verifying whether or not the user has accessed in the expected environment.
Set the identifier generated by the server as a first identifier to add to the payment link,
Separate the second identifier from the payment link dedicated to the user to which the payment related information is input,
It is determined whether the second identifier is an identifier given to the user-specific payment link according to whether the first identifier matches the second identifier,
Payment method by user access, comparing whether the first identifier and the second identifier match, allowing access of the accessor if they match and blocking access of the accessor if not. delete delete delete delete The method of claim 1
The payment link,
Payment method by user access, which is a Uniform Resource Locator (URL). According to claim 1,
When the payment related information is a payment card image, a user access to perform the optical text recognition on the payment card image to extract first payment related information, and perform the payment procedure based on the first payment related information Payment method. The method of claim 7,
The first payment related information,
Payment method by user access including at least one of a payment card number and an expiration date. According to claim 1,
When the payment-related information is text data for a payment card, a payment method by a user connection that performs the payment procedure based on the payment-related information. In the computer-readable recording medium recording a program for executing a payment method by a user connection for non-face-to-face payment,
The payment method by the user access for the non-face-to-face payment,
The server, collecting user information to perform the payment;
Generating, by the server, a payment link for input of payment related information;
Generating, by the server, an identifier according to a predetermined rule based on the user information;
Generating, by the server, a payment link dedicated to a user by adding the identifier to the payment link;
Sending, by the server, a payment link dedicated to the user to the user;
Receiving, by the server, the payment related information through the payment link dedicated to the user; And
The server, based on the payment-related information, comprising the steps of performing a payment process by optical character recognition,
The identifier and the user-specific payment link are created only for the payment performed by the user,
The identifier is for verifying whether the user accessing the payment link dedicated to the user is a party right holder having access authority, and any one of hardware and software used by the user to access the payment link dedicated to the user It is generated by performing any one of obfuscation and encryption for user information that is about, and is used to determine whether the user is allowed to access by verifying whether or not the user has accessed in the expected environment.
Set the identifier generated by the server as a first identifier to add to the payment link,
Separate the second identifier from the payment link dedicated to the user to which the payment related information is input,
It is determined whether the second identifier is an identifier given to the user-specific payment link according to whether the first identifier matches the second identifier,
Comparing whether the first identifier and the second identifier match, allowing access of the accessor if they match, and blocking access of the accessor if not.
A computer-readable recording medium recording a program for executing a payment method by user access.

Images