KR102762501B1 - Method for providing easy payment relay service and system thereof - Google Patents

Abstract

The present invention relates to a method and system for providing a simple payment brokerage service, which adopts a token-mediated payment method having high security because it does not store physical card information when a user uses a simple payment service at an on/offline merchant, a multiple payment method that is not locked-in to a specific PG company or a specific VAN company, and an on/offline simple payment method that allows the use of simple payment with a low fee because it does not go through a PG company. In addition, the purpose is to integrate complex and non-unified simple payment services so that the user can proactively select multiple simple payment services according to an appropriate environment and conditions, or manage them as a single simple payment service.

Description

METHOD FOR PROVIDING EASY PAYMENT RELAY SERVICE AND SYSTEM THEREOF

The present invention relates to a method and system for providing a simple payment brokerage service, which adopts a token-mediated payment method having high security because it does not store physical card information when a user uses a simple payment service at an on/offline merchant, a multiple payment method that is not locked-in to a specific PG company or a specific VAN company, and an on/offline simple payment method that allows the use of simple payment with a low fee because it does not go through a PG company. In addition, the purpose is to integrate complex and non-unified simple payment services so that the user can proactively select multiple simple payment services according to an appropriate environment and conditions, or manage them as a single simple payment service.

Simple payment services such as Kakao Pay, SSG Pay, and Coupang Pay are electronic payment services that allow you to make payments easily and quickly anytime, anywhere, regardless of location or time, using the card information you initially registered.

If we take a closer look at this conventional simple payment service process, we can see that PG and VAN companies are involved in the middle of the simple payment process. Here, PG is an abbreviation for an electronic payment agency service (Payment Gateway) and is a representative merchant that is responsible for any damages that may occur to users due to online transactions. It acts as a conduit for customers to safely make payments using credit cards and various payment methods when sellers sell products and services online, and provides representative merchant services. In addition, VAN is an abbreviation for a Value Added Network (VAN) and is a company that processes approval and purchases on behalf of merchants and card companies for card payments. In this way, conventional PG and VAN companies exist as ancillary businesses that sellers must pass through depending on the type of service they provide.

However, even if it is an offline transaction where a service provided by a store is used and payment is made, if the payment terminal located at the store is not used, the simple payment service is made through a PG company, so the seller has to pay the high online fee contracted with the PG company rather than the low offline fee contracted with the card company, which causes a considerable financial burden on the seller, and in addition, the conventional PG company's simple payment method has adopted a billiard-type simple payment method that is inconvenient due to low security and accessibility, and when registering a card, the physical card information is stored, which may be exposed to illegal activities such as hacking or snooping, and other security issues arise. In addition, if a user registers a card with a specific PG company, the card information is locked in the specific PG company, so the user has to register the card again to use a different PG company, which is also a problem of inconvenience.

Meanwhile, simple payment services such as Kakao Pay and SSG Pay are also experiencing problems such as the inconvenience of having to register a card for other simple payment services even if you register a card for one simple payment service, and the increased number of choices for users due to the emergence of various simple payment services, which causes confusion in the purchasing decision process.

The technical problem to be solved by the present invention is to provide a method and system for providing a simple payment mediation service that adopts a method of mediating simple payment through a payment token without storing the physical card information, unlike the conventional PG company simple payment service that stores the physical card information and the bill key-type simple payment method during the simple payment service process.

Another technical problem to be solved by the present invention is to provide a method and system for providing a simple payment intermediary service in a multiple payment method that enables the seller to make a simple payment to a PG company or VAN company of the seller's choice using a payment token issued by a card company through the company, unlike a conventional simple payment service of a PG company that is locked-in to a specific PG company.

Another technical problem that the present invention seeks to solve is to provide a method and system for providing a simple payment intermediary service that adopts an on/offline integrated simple payment method in which simple payment is made directly through a VAN company without going through a PG company in the case of offline transactions, unlike conventional simple payment services that must necessarily go through a PG company, which is a representative merchant, even in offline transactions.

Another technical problem to be solved by the present invention is to provide a method and system for providing a simple payment intermediary service that can manage existing simple payment services as a single integrated management service, thereby enabling integrated management as a single simple payment service by registering a card once for the first time without having to register a card for each of a plurality of simple payment services.

Meanwhile, the technical problems of the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned can be clearly understood by those skilled in the art from the description below.

The present invention is to solve the problems described above, and a method for providing a simple payment intermediary service according to the present invention may include a step in which, when a simple payment server receives physical card information from a user and transmits the physical card information to the simple payment intermediary server, the simple payment intermediary server requests the card company server to verify the physical card information and requests the card company server to create a card identifier; a step in which, when the card company server completes the verification of the physical card information and creates the card identifier and transmits it to the simple payment intermediary server, the card identifier is transmitted to the simple payment server and the physical card information is deleted; and a step in which, when the simple payment server transmits the card identifier to the simple payment intermediary server, the simple payment intermediary server requests the card company server to verify the received card identifier and requests the creation of a token based on the card identifier.

In addition, the method for providing a simple payment intermediary service of the present invention may further include, after the step of transmitting the card identifier to the simple payment server and deleting the physical card information, a step of storing the payment information and a step of transmitting the payment information to the simple payment server when a payment request and payment information are received from an on/offline merchant.

In addition, the method for providing a simple payment intermediary service of the present invention is such that the simple payment intermediary server requests verification of the received card identifier from the card company server.

After the step of requesting the creation of a token based on the above card identifier, if the card company server completes the verification of the card identifier for which the verification request has been made and creates the token and transmits the created token to the easy payment intermediary server, the method may further include the step of verifying the compatibility of the received token and transmitting the token for which the compatibility has been verified to the easy payment server.

In addition, the method for providing a simple payment brokerage service of the present invention may further include a step of verifying the compatibility of the received token and transmitting the token, the compatibility of which has been verified, to the simple payment server, and, if the simple payment server transmits the received payment information and token to the simple payment brokerage server, the simple payment brokerage server transmits the token to the card company server and requests payment approval.

In addition, the method for providing a simple payment intermediary service of the present invention may further include a step in which, after the simple payment intermediary server transmits the token to the card company server and requests payment approval, if the card company server verifies the token to approve payment and deducts the user's card limit and then transmits payment details to the simple payment intermediary server, a step in which the simple payment intermediary server stores the payment details and generates a payment approval message, and a step in which the simple payment intermediary server transmits the payment details and the payment approval message to the on/offline merchant.

In addition, the method for providing a simple payment intermediary service of the present invention may be characterized in that the received token can be linked with any simple payment intermediary server - other PG companies, other VAN companies, etc. - to receive payment approval from the card company server.

Meanwhile, the present invention provides another method for solving the above problems, and the method for providing a simple payment intermediary service may include a step in which, when physical card information is input from a user terminal (10) and the physical card information is transmitted to a simple payment intermediary server, the simple payment intermediary server requests the card company server to verify the physical card information and to generate a card identifier, when the card company server completes the verification of the physical card information and generates the card identifier, the simple payment intermediary server receives the card identifier and deletes the physical card information, when the simple payment intermediary server receives the card identifier and deletes the physical card information, the simple payment intermediary server registers a card based on the card identifier, and when the simple payment intermediary server receives a payment request and payment information from an on/offline merchant and stores the payment information, the simple payment intermediary server may request the user terminal (10) to select a simple payment server.

In addition, the method for providing a simple payment brokerage service of the present invention may further include a step in which, after the step in which the simple payment brokerage server requests the user terminal (10) to select a simple payment server, if the user terminal (10) selects the simple payment server, the simple payment brokerage server transmits the payment information to the simple payment server.

In addition, the method for providing a simple payment brokerage service of the present invention may further include, after the step of the simple payment brokerage server transmitting the payment information to the simple payment server, a step of the simple payment brokerage server requesting the card company server to verify the card identifier and requesting the generation of the token based on the card identifier when the simple payment server requests the simple payment brokerage server to create a token after the step of the simple payment brokerage server transmitting the payment information to the simple payment server, and a step of generating the token and transmitting the generated token to the simple payment brokerage server when the card company server completes the verification of the card identifier for which verification has been requested.

In addition, the method for providing a simple payment brokerage service of the present invention may further include a step of verifying the compatibility of the received token and transmitting the token, the compatibility of which has been verified, to the simple payment server, and, if the simple payment server transmits the received payment information and token to the simple payment brokerage server, the simple payment brokerage server transmits the token to the card company server and requests payment approval.

In addition, the method for providing a simple payment intermediary service of the present invention may further include a step in which, after the simple payment intermediary server transmits the token to the card company server and requests payment approval, if the card company server verifies the token to approve payment and deducts the user's card limit and then transmits payment details to the simple payment intermediary server, a step in which the simple payment intermediary server stores the payment details and generates a payment approval message, and a step in which the simple payment intermediary server transmits the payment details and the payment approval message to the on/offline merchant.

According to the present invention as described above, the simple payment intermediary service adopts an intermediary token payment method that does not store physical card information, thereby preventing the user's card information from being leaked and preventing illegal acts such as hacking in advance, thereby enhancing security and improving trust from users.

In addition, the simple payment intermediary service is not locked in to a specific PG company and allows simple payments to be made with only a payment token even if the payment is made through any simple payment company. This not only expands the simple payment service network and provides convenience to users and autonomy in choosing a payment company, but also provides convenience to administrators who manage the simple payment service.

In addition, the simple payment intermediary service adopts an offline simple payment method in which simple payments are made directly through the VAN company without going through the PG company, thereby eliminating the fees incurred when going through the PG company, thereby achieving economic benefits and simplifying the simple payment process overall.

In addition, the simple payment intermediary service has the effect of simplifying users' simple payment service selection by allowing existing simple payment services to be managed as a single integrated management service, preventing users' purchase confusion, and encouraging users to appropriately manage or utilize the benefits and events provided by the simple payment service.

Meanwhile, the effects of the present invention are not limited to those mentioned above, and other technical effects not mentioned will be clearly understood by those skilled in the art from the description below.

Figure 1 is a flow chart showing a conventional online payment method and an offline mobile payment method and an online payment method and an offline mobile payment method according to the present invention.
Figure 2 is a drawing schematically showing the process of providing a simple payment service to a user through a simple payment mediation server (100) according to the present invention.
Figure 3 is a diagram showing a flow chart of a method for providing a simple payment brokerage service according to the first embodiment.
Figure 4 is a flowchart showing a method for providing a simple payment brokerage service according to the second embodiment.
Figure 5 is a flowchart showing a method for providing a simple payment brokerage service according to the third embodiment.
Figure 6 is a flowchart showing a method for providing a simple payment brokerage service according to the fourth embodiment.
Figure 7 is a drawing specifically showing an example of using a simple payment intermediary service in a payment process using an O2O (Offline to Online) service.
Figures 8 and 9 are drawings specifically showing examples of utilizing tokens of a simple payment intermediary service to link different simple payment affiliate services.
Figure 10 is a diagram specifically showing an example of utilizing a token of a simple payment intermediary service to link different simple payment intermediary services.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. The advantages and features of the present invention and the methods for achieving them will become apparent with reference to the embodiments described in detail below together with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, but may be implemented in various different forms, and the present embodiments are provided only to make the disclosure of the present invention complete and to fully inform those skilled in the art of the scope of the invention, and the present invention is defined only by the scope of the claims. Like reference numerals refer to like elements throughout the specification.

Unless otherwise defined, all terms (including technical and scientific terms) used in this specification may be used in a meaning that can be commonly understood by a person of ordinary skill in the art to which the present invention belongs. In addition, terms defined in commonly used dictionaries shall not be ideally or excessively interpreted unless explicitly specifically defined. The terminology used in this specification is for the purpose of describing embodiments and is not intended to limit the present invention. In this specification, the singular also includes the plural unless specifically stated in the phrase.

Terms such as "first", "second", etc. are intended to distinguish one component from another, and the scope of the rights should not be limited by these terms. For example, the first component may be referred to as the second component, and similarly, the second component may also be referred to as the first component.

As used herein, the terms "comprises" and/or "comprising" do not exclude the presence or addition of one or more other components, steps, operations and/or elements.

Meanwhile, the present invention is not limited to the specific embodiments and application examples described above, and various modifications can be made by those skilled in the art without departing from the gist of the present invention claimed in the claims. Furthermore, such modifications should not be understood as being distinct from the technical idea or prospect of the present invention.

Before going into a detailed explanation of the present invention, let us first briefly compare the two payment methods to see what differences there are between the conventional online payment method and the payment method through the simple payment mediation server (100) according to the present invention, and briefly look at terms frequently mentioned in the process of providing the simple payment mediation service of the present invention.

First, the conventional online payment and offline mobile payment method (a) according to Fig. 1 is a payment method in which payment is made online and a payment method in which payment is made offline but via mobile payment. In this method, since it is difficult to visit an online merchant or to contract with each online merchant individually, a representative merchant, that is, a PG company (Payment Gateway), is involved, which contracts with the card company server on behalf of the online merchant and acts as an agent for payment and settlement, and a VAN company that builds a communication network between the card company server and the merchant and acts as an agent for card payment and acquisition-related work is also involved.

Conventional online payment and offline mobile payment methods (a) have adopted a bill-type payment method in which payment is initiated through a PG bill-key set in a user terminal (10). As the first step of the payment method, when a bill-type payment is initiated through a user terminal (10), an online merchant (sub-merchant) requests payment approval from a PG company (representative merchant). When the PG company approves the payment, the existing card payment process of authentication step-approval step-purchase step is carried out through the PG company, VAN company, and card company server. During the card payment process, the authentication step is the step where the card making the payment is valid and the owner of the card is confirmed through the card company number, expiration date, and CVC number. The approval step is the step where the PG company transmits the payment information received from the user or the merchant to the VAN company, and the VAN transmits the payment information to the card company server to deduct the user's card limit. Furthermore, the step where the user's card limit is deducted and the approval result is transmitted back to the VAN company, and the VAN transmits the approval result back to the user or the merchant can also be called the approval step. The purchase step is the step where the merchant receives the payment for the product sold, and includes the step where the merchant transmits a sales receipt to the card company server through the VAN company, and the card company server receiving the sales receipt deposits the payment to the merchant.

On the other hand, the payment method (b) via the simple payment intermediary server (100) adopts a token intermediary payment method as shown in Fig. 1, so that the online payment method proceeds with payment through a PG company, but the offline mobile payment, which was distinguished from the conventional online payment, proceeds with payment without going through a PG company, so that the payment procedure is simplified and the commission can also be reduced.

In this way, the reason why the payment method (b) through the simple payment intermediary server (100) can be made without going through a PG company is that it is a card registration method that does not store physical card information and a token generation method that is created based on a card identifier. A detailed explanation of this will be examined in detail when explaining the method for providing a simple payment intermediary service according to the first embodiment of the present invention.

Figure 2 is a drawing schematically showing the process of providing a simple payment service to a user through the simple payment mediation server (100) of the present invention.

[Easy Payment Brokerage Server (100)]

The simple payment mediation server (100) according to FIG. 2 is a server that integrates complicated and unified simple payment services (meaning simple payment services provided by existing simple payment affiliate servers (200)) when a user uses a simple payment service at an online/offline merchant, so that the user can proactively select multiple simple payment services according to an appropriate environment and conditions or manage them as a single simple payment service, and provides a token mediation payment method that does not store physical card information and thus has high security, a multiple payment method that is not locked-in to a specific PG company or a specific VAN company, and a service that allows the use of simple payment at a low fee by not going through a PG company in the case of offline transactions.

In order to efficiently perform the above purposes, the simple payment mediation server (100) can be subdivided into a simple payment authentication server (110) and a simple payment approval server (120).

[Easy Payment Authentication Server (110)]

The simple payment authentication server (110) initiates the user's identity verification procedure, generates a card identifier to encrypt the user's physical card, requests card verification and registration to the card company server (300) through the generated card identifier, and upon receiving a first card ID from the card company, generates a second card ID that can only be read within the simple payment intermediary server (100) and enables tokens to be generated through this. The roles and related terms of the above-mentioned simple payment authentication server (110) will be examined in more detail in the first embodiment described below.

[Easy Payment Approval Server (120)]

If the above-mentioned simple payment authentication server (110) took charge of card registration and token generation in the simple payment intermediary service providing method of the present invention, the simple payment approval server (120) transfers the token to the card company server (300) so that the simple payment using the token can be approved, and when the card company server (300) verifies the token and approves the payment, it stores the payment details on the server according to the approved payment result, and generates a payment approval message and transmits it to the user terminal (10) or the simple payment affiliate server (200). The role of the above-mentioned simple payment approval server (120) and related terms will be examined in more detail in the first embodiment described below.

[Easy Payment Affiliate Server (200)]

The simple payment affiliate server (200) frequently mentioned in the present invention refers to a service server that provides simple payment that is currently commercialized, for example, a server that provides simple payment services such as SSG Pay and Kakao Pay.

< 1 Example>

Figure 3 is a flowchart showing a method for providing a simple payment brokerage service according to the first embodiment.

The method for providing a simple payment service according to the first embodiment can be broadly divided into a card registration process, a token generation process, and a payment process after token generation. Below, the card registration process will be explained in order.

[Card registration]

In order to register a card, the process starts with the step of the easy payment affiliate server (200) receiving a user ID and physical card information from the user and transmitting a request for registration of the physical card information to the easy payment authentication server (110) (S101). Here, the user ID may refer to a unique ID for identifying a user who has registered as a member of the easy payment affiliate server (200). In addition, it may be utilized as an integrated user ID that can be used not only to identify the user in the easy payment affiliate server (200) but also to identify the user in the easy payment intermediary server (100). Alternatively, the user ID used in the easy payment affiliate server (200) and the ID used to identify the user in the easy payment intermediary server (100) may exist separately. However, in this case, the IDs between the two servers may be mapped to each other.

Next, when the simple payment affiliate server (200) receives physical card information from the user and sends a request for registration of the physical card information to the simple payment authentication server (110) (S101), the simple payment authentication server (110) generates a card identifier that encrypts the physical card information (S102). Here, the card identifier is a series of identification numbers that encrypt the physical card information and are used to prevent illegal activities such as leaks and hacking that may occur when the physical card information is stored and used as is.

After the simple payment authentication server (110) generates a card identifier that encrypts the physical card information, the simple payment approval server (110) transmits the generated card identifier to the card company server (300) to send a card verification and registration request (S103).

Thereafter, the card company server (300) verifies the card based on the received card identifier, and when card verification is complete, registers the card and generates a first card ID (S104).

Here, the first card ID is an ID assigned to the user card by the card company server (300), and is similar to the card identifier in that it is used to identify the card, but the card identifier is encrypted with actual card information for the purpose of registering the card, and the first card ID is different in that it is used not only to identify the card, but also to identify the card for overall card use and payment.

Next, the card company server (300) transmits the generated first card ID to the simple payment authentication server (110) (S105).

Thereafter, the simple payment authentication server (110) generates a second card ID that is substituted with the received first card ID and registers the generated second card ID on the server (S106).

Here, the second card ID is distinguished from the card identifier of step S102 and the first card ID of step S104, and the second card ID is matched (S107) with the first card ID received from the card company server (300). The second card ID registered in the simple payment authentication server (110) enables registration of the card without having to register the card in each of the multiple simple payment affiliate servers (200), and when the simple payment affiliate server (200) requests a disposable card number, the second card ID can also be utilized as a disposable card number.

After the simple payment authentication server (110) creates and registers the second card ID, the simple payment authentication server (110) transmits the registered second card ID to the simple payment affiliate server (200) (S108), thereby completing the step of registering the user card.

The card registration step is a mandatory step to use the simple payment service, and the card registration step can naturally be performed before payment is made, or the user can register the card in advance even when payment is not required.

[Token Creation]

In order for a user's card to be registered in the simple payment affiliate server (200) and the simple payment of the present invention to begin, a token generation step must be performed. The process of generating such a token begins with the step where the simple payment affiliate server (200) first transmits the user ID and the second card ID to the simple payment authentication server (110) and requests a payment token based on this (S109).

When the simple payment affiliate server (200) transmits a second card ID to the simple payment authentication server (110) and requests a payment token based on this, the simple payment authentication server (110) verifies the user by comparing the received second card ID with the user information (S110).

Here, user information is user information required for identity verification and authentication, such as name, age, and phone number that the user has entered into the simple payment authentication server (110).

Thereafter, the simple payment authentication server (110) transmits the first card ID previously received to the card company server (300) to request a payment token (S111).

Next, the card company server (300) verifies the received first card ID and generates a token when verification is completed (S112). In addition, the card company server (300) transmits the token to the simple payment authentication server (110) (S113), and the simple payment authentication server (110) transfers the token received from the card company server (300) to the simple payment affiliate server (200) (S114), thereby completing the token generation step.

[Easy token payment]

When a token is created through the above process, simple payment is performed through the created token, and the token simple payment process begins at the step where the simple payment affiliate server (200) requests payment approval from the simple payment approval server (120) using payment information and a token (S115).

Thereafter, the simple payment approval server (120) transmits the received token and payment approval request to the card company server (300) (S116).

After the simple payment approval server (120) transmits the received token and payment approval request to the card company server (300), the card company server (300) verifies the received token and, when verification is complete, approves the payment (S117). In addition, the card company server (300) verifies the received token and, when verification is complete, transmits the payment result or payment details to the simple payment approval server (120) (S118).

Thereafter, the simple payment approval server (120) stores the payment details and generates a payment approval message (S119), and transmits the payment details and payment approval message to the simple payment affiliate server (200) (S120).

We have examined the method for providing a simple payment brokerage service according to the first embodiment.

Next, a method for providing a simple payment service according to the second embodiment will be described.

<Second embodiment>

FIG. 4 is a drawing specifically showing a method for providing a simple payment brokerage service according to a second embodiment of the present invention.

The method for providing a simple payment mediation service according to the second embodiment of the present invention differs from the first embodiment of the present invention in that it provides a simple payment mediation service by utilizing only the first card ID, without utilizing the second card ID. Except for the steps corresponding to this difference, the steps are identical to those of the first embodiment of the present invention, so only the steps corresponding to the difference will be described to avoid redundant description.

In the method for providing a simple payment intermediary service according to the second embodiment of the present invention, when the card company server (300) completes card verification, it transmits the first card ID to the simple payment authentication server (110) (S105).

Thereafter, the simple payment authentication server (110) registers the first card ID received from the card company server (300) (S106a). The first card ID here is a card ID that can perform the role of the first card ID described in the first embodiment as well as the role of the second card ID. Due to this role of the first card ID, the second embodiment of the present invention simplifies the procedure by omitting the process of separately generating the second card ID and matching it with the first card ID, and reduces the burden of the role of the simple payment authentication server (110).

Next, when the simple payment authentication server (110) registers the first card ID received from the card company server (300), the simple payment authentication server (110) transmits the registered first card ID to the simple payment affiliate server (200) (S108a).

Thereafter, the simple payment affiliate server (200) transmits the received first card ID and user ID to the simple payment authentication server (110) to request token creation (S109a).

Next, the simple payment authentication server (110) verifies the user based on the received first card ID and user information (S110a). The above step (S110a) is different from the first embodiment of the present invention in that the simple payment authentication server (110) verifies the user through the first card ID rather than the second card ID.

The subsequent steps are identical to the first embodiment of the present invention and are therefore omitted.

<Third embodiment>

FIG. 5 is a drawing specifically showing a method for providing a simple payment brokerage service according to a third embodiment of the present invention.

The method for providing a simple payment brokerage service according to the third embodiment of the present invention is identical to the card registration step of the method for providing a simple payment brokerage service according to the second embodiment of the present invention, but is different from the second embodiment of the present invention in that, in the token generation step, a payment token generated from the card company server (300) is substituted for a payment code and utilized. Except for the steps corresponding to this difference, the steps are identical to the steps of the second embodiment of the present invention, so only the steps corresponding to the difference will be described to avoid redundant description.

In the method for providing a simple payment mediation service according to the third embodiment of the present invention, after a token generated by a card company server (300) is transmitted to a simple payment authentication server (110) (S113), the simple payment authentication server (110) replaces the received payment token with a payment code (S301). Here, the payment code may mean a code that is replaced in the same way as the payment token generated by the card company server (300), and may preferably mean a barcode or a QR code. For reference, if the payment code is provided in the form of a barcode, the barcode may consist of data according to a combination of 21 characters or numbers.

Meanwhile, after the simple payment authentication server (110) replaces the payment token with a payment code (S301), the simple payment authentication server (110) transmits the replaced payment code to the simple payment affiliate server (200) (S302).

Thereafter, the simple payment affiliate server (200) can provide the received payment code to the user, and if the user wants to proceed with simple payment, he/she can present the provided payment code to an offline merchant or offline merchant. If the merchant recognizes the payment code through a separate device (e.g., a barcode scanner), the simple payment affiliate server (200) transmits the payment information and the payment code to the simple payment approval server (120) and requests payment approval based on this (S303). For reference, the steps described above describe the process of simple payment in which the user presents the payment code to the merchant, that is, CPM (Customer Present Mode: see FIG. 7). On the contrary, the simple payment method can also be performed in MPM (Merchant Present Mode: see FIG. 7), in which the simple payment affiliate server (200) does not provide the payment code to the user, but provides it to an online/offline merchant, and the merchant presents the payment code to the user so that the user recognizes the payment code through a terminal.

Next, the simple payment approval server (120) replaces the received payment code with a payment token (S304). Here, the payment token may be a payment token generated from the card company server (300) in step S112 described above, or may be another form of payment token that is replaced in the same way as the payment code but includes payment information (e.g., price of the product, purchase/sale date, etc.).

Since the steps after S304 are the same as the second embodiment of the present invention, they are omitted.

<Example 4>

The method for providing a simple payment service according to the fourth embodiment shown in Fig. 6 is similar to the method for providing a simple payment service according to the first to third embodiments in that the card registration process and the token generation process are performed, but there is a difference in the card registration process, and there is a process for selecting a user's simple payment affiliate server (200) between the card registration process and the token generation process, which is different from the method for providing a simple payment service according to the first to third embodiments.

The card registration process of the method for providing a simple payment service according to the fourth embodiment starts with the step of the simple payment authentication server (110) requesting the user terminal (10) to enter physical card information (S401). Before the step S401, there may be an additional step of the user terminal (10) requesting the simple payment affiliate server (200) to register a physical card, and the simple payment affiliate server (200) transmitting the request for physical card registration to the simple payment authentication server (110).

The user terminal (10) inputs physical card information and transmits the physical card information to the simple payment affiliate server (200) (S402). The simple payment affiliate server (200) transmits the received physical card information to the simple payment authentication server (110) (S403). The simple payment authentication server (110) generates a card identifier that encrypts the transmitted physical card information (S404).

Thereafter, the simple payment authentication server (110) transmits a verification request for the generated card identifier to the card company server (400) (S405), and the card company server (300) verifies the received card identifier and, when verification is completed, generates a first card ID (S406).

Next, the card company server (300) transmits the first card ID to the simple payment authentication server (110) (S407), and the simple payment authentication server (110) registers the card based on the received first card ID (S408).

Meanwhile, when card registration is completed and the user initiates payment, the simple payment affiliate server (200) transmits payment information and a payment request to the simple payment intermediary server (100) (S409). Then, the simple payment approval server (120) stores the payment information (S410).

After the simple payment approval server (120) stores the payment information, the simple payment approval server (100) transmits a request for selecting the simple payment server (100) from the user terminal (10) (S411). The simple payment mediation server (100) according to the fourth embodiment comprehensively manages or mediates commercially available simple payment affiliate servers (200), so the simple payment mediation server (100) can have one feature that provides the user with a choice to select one of a plurality of simple payment affiliate servers (200). Through this, the user can appropriately use point accumulation benefits, discount benefits, etc. implemented independently by the simple payment affiliate server (200).

When a user terminal (10) receives a request to select a simple payment affiliate server (200) from a simple payment approval server (110), the user selects a simple payment affiliate server (200) through the user terminal (10) and transmits the fact of selection to a simple payment mediation server (100), more precisely, to a simple payment approval server (120) (S412).

Thereafter, the simple payment approval server (120) transmits payment information to the simple payment affiliate server (200) selected by the user.

When the simple payment affiliate server (200) selected by the user receives payment information from the simple payment intermediary server (100), the token generation process begins.

The token generation process and the payment process after token generation of the method for providing a simple payment brokerage service according to the fourth embodiment are identical to those of the method for providing a simple payment brokerage service according to the second embodiment, so a detailed description will be omitted.

We have examined the method for providing a simple payment brokerage service according to the fourth embodiment.

Next, we will explain various examples of how to use the simple payment service.

[Example of using simple payment service provision method: O2O (Offline to Online)]

FIG. 7 is a drawing showing an example of using a method for providing a simple payment intermediary service according to the first embodiment, and is specifically a drawing showing a method for providing a simple payment service in the O2O (Offline to Online) manner.

Before examining the method of providing a simple payment service in the O2O manner according to Fig. 7, the first thing to note is that it is assumed that the user who wants to make a simple payment has already completed the card registration process and token generation process and has been issued a token in advance, and that the online simple payment service is used at an offline merchant.

Users using the 020 method of simple payment service will first be issued a token through the token generation method according to the first embodiment, and then proceed with payment by selecting one of the representative payment methods of the O2O method, such as simple payment method (card/account/prepaid), MPM (Merchant Present Mode), and CPM (Customer Present Mode).

The simple payment method is a payment method that the user selects from the simple payment services provided by the simple payment affiliate server (200). The payment method may be a credit card or check card registered with the simple payment affiliate server (200), an account payment that allows the money to be transferred from the user's bank account, or a payment amount that the user has previously charged to the simple payment affiliate server (200) or the merchant server or an amount paid in advance (prepaid).

Meanwhile, MPM (Merchant Present Mode) is a payment method in which a merchant presents a QR code or barcode containing payment information to a user, and the user recognizes the QR code or barcode through a user terminal (10) such as a smart phone to proceed with payment.

CPM (Customer Present Mode) is a payment method in which, unlike MPM (Merchant Present Mode), the user presents a QR code or barcode containing personal identification information that can be used to confirm payment to the merchant, and the merchant recognizes the QR code or barcode using a QR code reader or barcode reader to process the payment. As a reference, MPM and CPM payments will follow the payment method that is made on the user's terminal.

As mentioned above, the user can select one of these three payment methods and proceed with payment on his/her own initiative. If the user selects one of the three payment methods and proceeds with payment, the token that the user previously received from the simple payment intermediary server (100) is retransmitted to the simple payment intermediary server (100) (Figure 7-①), thereby notifying that the payment has been made. The simple payment intermediary server (100) transmits the received token to the card company server (300) to request token verification and payment approval (Figure 7-②). Then, the card company server (300) verifies the received token, and when verification is completed, the card company server (300) approves the payment, thereby processing the payment normally (Figure 7-③).

This O2O (Offline to Online) payment method utilizing tokens can be seen as a combination of the existing convenient O2O payment method and the highly secure and versatile token payment method.

Meanwhile, Fig. 8 is a diagram showing that tokens can be used in conjunction with each other between different simple payment affiliate servers (200).

Referring to FIG. 8, a user can perform a simple payment using a token without having to register the card in other simple payment affiliate servers (200) by registering the card in only one simple payment affiliate server (200). In other words, assuming that a user has registered as a member in multiple simple payment affiliate servers (200) and has registered the card in only the first simple payment affiliate server (201), user information is stored in the multiple simple payment affiliate servers (200) through the user's membership registration, and card information (e.g., first card ID and/or second card ID) is generated in the process of registering the user's card in the first simple payment affiliate server (201), and the card information is mapped to the user information to form a 'simple payment linkage network (a network between multiple simple payment affiliate servers (200) where user information is stored)', and simple payment linkage can be performed between different simple payment affiliate servers (200) through this simple payment linkage network.

To give an example of this simple payment linkage in everyday life, if a user who normally uses SSG Pay visits a bakery to buy bread and the bakery offers a 15% discount when paying for the bread with Kakao Pay, the user would have to sign up for Kakao Pay on the spot and register a card with Kakao Pay to receive the discount. However, by utilizing the token of the present invention, the user can simply generate a token through SSG Pay, which he normally uses, and send the generated token to Kakao Pay without having to go through the hassle of signing up for Kakao Pay or registering a card.

Returning to Figure 8, if we examine in detail the process of linking a simple payment affiliate server (200) using a token, it may first include a step in which user information is stored in the first or second simple payment affiliate server (200), a card is registered in the first simple payment affiliate server (201), and card information is mapped to the user information to form a simple payment linkage network (Figure 8-①).

Thereafter, the first easy payment affiliate server (201) transmits a token to the second easy payment affiliate server (202) where the user card is not registered in order to link with the second easy payment affiliate server (201) (Figure 8-②).

When the second easy payment affiliate server (202) receives a token from the first easy payment affiliate server (201) (Figure 8-②), the second easy payment affiliate server (202) transmits the token to the easy payment intermediary server (100) so that easy payment can proceed (Figure 8-③).

When the simple payment intermediary server (100) receives a token from the second simple payment affiliate server (202) (Figure 8-③), the simple payment intermediary server (100) transmits a token verification request and a payment approval request to the card company server (300) (Figure 8-④).

When a token verification request and a payment approval request are received from a simple payment intermediary server (100) (Figure 8-④), the card company server (300) verifies the token and, when verification is complete, approves the payment and processes the payment normally (Figure 8-⑤).

Referring to Fig. 9, after a simple payment linkage network is formed, that is, after user information and card information are mapped to simple payment affiliate servers (200), simple payment linkage may be achieved by transmitting a ‘token for linkage’ to a second simple payment affiliate server (202) where the card is not registered through a simple payment intermediary server (100) rather than the first simple payment affiliate server (201) where the card is registered. In other words, in FIG. 8, when user information and card information are mapped to the simple payment affiliate servers (200), the first simple payment affiliate server (201) where the card is registered transmits a ‘token for linking’ to the second simple payment affiliate server (202) to proceed with the simple payment linking, but in FIG. 9, the ‘token for linking’ is managed by the simple payment intermediary server (100), and when the simple payment linking starts, even if the card is not registered to the simple payment affiliate server (200) where the user information and card information are mapped, the ‘token for linking’ is transmitted (FIG. 9-②) to enable the simple payment linking. As shown in Fig. 9, if the 'token for linkage' is managed by the simple payment intermediary server (100), even if mapping of user information and card information between the simple payment affiliate servers (200) is done, token linkage between each other may not be done due to policy and agreement issues on each simple payment affiliate server, so this can be used as a method to prevent this. In addition, since the simple payment intermediary server (100) is involved in token creation, the simple payment intermediary server (100) managing the 'token for linkage' can be relatively more secure and compatible than other methods.

On the other hand, Fig. 10 is a diagram showing that different simple payment intermediary servers can be utilized in conjunction with each other by exchanging tokens. In other words, when a user attempts to conduct a transaction through a simple payment intermediary server (400) where the card has not been registered, the payment can be processed by sending a token from the simple payment intermediary server (100) to the simple payment intermediary server (400) without re-registering the card. As a simple example, a merchant enters into a contract with a simple payment intermediary service provider such as a PG company or VAN company that performs and mediates payment-related work on behalf of the merchant, and the merchant selects and enters into a contract with one of several simple payment intermediary service providers. If each merchant has a different simple payment intermediary service provider, there may be a problem that a user who wants to purchase a product must register a card for each simple payment intermediary service, and the payment process provided by each simple payment intermediary service may be different for each simple payment intermediary service, which may cause confusion for the user. Accordingly, the present invention can be implemented so that a user can make a payment through a simple payment intermediary server (100) using a simple payment token provided by the present invention.

If we examine in detail the process of payment being processed by linking the simple payment intermediary server (100) and the other simple payment intermediary server (400), it will first start with the user registering his/her card and generating a token through the simple payment affiliate server (200), the simple payment intermediary server (100), and the card company server (300) (Figure 10-①), and the payment procedure using the token thereafter will be the same as the simple payment process explained so far if the merchant with whom the user wishes to transact has entered into a contract with the simple payment intermediary server (100) where the user registered his/her card.

On the other hand, even if the merchant with which the user wishes to transact has entered into a contract with another easy payment intermediary server (400) rather than the above-mentioned easy payment intermediary server (100), if the user transmits a token from the easy payment intermediary server (100) to the other easy payment intermediary server (400) through the easy payment affiliate server (200), the other easy payment intermediary server (400) can also be utilized in the same way as the easy payment intermediary server (100) that the user previously used.

We have examined all examples of methods for providing simple payment intermediary services.

Meanwhile, the present invention is not limited to the specific embodiments and application examples described above, and various modifications can be made by those skilled in the art without departing from the gist of the present invention claimed in the claims. Furthermore, such modifications should not be understood as being distinct from the technical idea or prospect of the present invention.

User terminal (10)
Easy Payment Brokerage Server (100)
Easy Payment Authentication Server (110)
Easy Payment Approval Server (120)
Easy Payment Affiliate Server (200)
1st Easy Payment Affiliate Server (201)
Second Easy Payment Affiliate Server (202)
Card company server (300)
Other simple payment intermediary servers (400)

Claims (11)

In a method for providing a simple payment brokerage service in which a simple payment brokerage server integrates and manages or brokers existing simple payment servers so that users can use the simple payment service under user initiative,
When a simple payment server receives physical card information from a user and transmits said physical card information to a simple payment intermediary server, a step in which the simple payment intermediary server requests verification of said physical card information from a card company server and requests creation of a card identifier from the card company server;
When the card company server completes verification of the physical card information and generates the card identifier and transmits it to the simple payment intermediary server, a step of transmitting the card identifier to the simple payment server;
Step of receiving a payment request and payment information from an online/offline merchant, storing the payment information;
A step of transmitting the above payment information to the simple payment server;
When the simple payment server transmits the card identifier to the simple payment intermediary server, the simple payment intermediary server requests the card company server to verify the received card identifier and requests the creation of a token based on the card identifier;
A step of generating the token after the card company server completes verification of the card identifier for which the verification request has been received and transmitting the generated token to the simple payment intermediary server, verifying the compatibility of the received token and transmitting the token for which the compatibility has been verified to the simple payment server;
Including,
The above token is characterized by being capable of linking between different simple payment servers that store the same user information.
Method for providing simple payment intermediary service.
delete delete In paragraph 1,
After verifying the compatibility of the received token and transmitting the token verified for compatibility to the simple payment server,
When the simple payment server transmits the payment information and token to the simple payment intermediary server, the simple payment intermediary server transmits the token to the card company server and requests payment approval;
Including more,
Method for providing simple payment intermediary service.
In paragraph 4,
After the step where the above simple payment intermediary server transmits the token to the card company server and requests payment approval,
When the card company server verifies the token, approves the payment, deducts the user's card limit, and sends the payment details to the simple payment intermediary server, the simple payment intermediary server stores the payment details and generates a payment approval message; and
A step in which the above simple payment intermediary server transmits the payment details and the payment approval message to the above online/offline merchant;
Including more,
Method for providing simple payment intermediary service.
delete In a method for providing a simple payment brokerage service in which a simple payment brokerage server integrates and manages or brokers existing simple payment servers so that users can use the simple payment service under user initiative,
When a simple payment server that has received physical card information sends said physical card information to a simple payment intermediary server, a step in which said simple payment intermediary server requests verification of said physical card information to the card company server and requests creation of a card identifier;
When the card company server completes verification of the physical card information and generates the card identifier, the step of the simple payment intermediary server receiving the card identifier;
A step in which the above simple payment intermediary server registers a card based on the above card identifier;
When the above-mentioned simple payment intermediary server receives a payment request and payment information from an on/offline merchant and stores the payment information, a step in which the above-mentioned simple payment intermediary server requests the user terminal (10) to select a simple payment server;
When the user terminal (10) selects the simple payment server, the simple payment intermediary server transmits the payment information to the simple payment server;
When the simple payment server requests the simple payment intermediary server to create a token, the simple payment intermediary server requests the card company server to verify the card identifier and requests the token to be created based on the card identifier; and
When the card company server completes verification of the card identifier for which verification has been requested, the step of generating the token and transmitting the generated token to the simple payment intermediary server, verifying the compatibility of the received token and transmitting the token for which compatibility has been verified to the simple payment server;
Including,
The above token is characterized by being capable of linking between different simple payment servers that store the same user information.
Method for providing simple payment intermediary service.
delete delete In Article 7,
After verifying the compatibility of the received token and transmitting the token verified for compatibility to the simple payment server,
When the simple payment server transmits the payment information and token to the simple payment intermediary server, the simple payment intermediary server transmits the token to the card company server and requests payment approval;
Including more,
Method for providing simple payment intermediary service.
In Article 10,
After the step where the above simple payment intermediary server transmits the token to the card company server and requests payment approval,
When the card company server verifies the token, approves the payment, deducts the user's card limit, and sends the payment details to the simple payment intermediary server, the simple payment intermediary server stores the payment details and generates a payment approval message; and
A step in which the above simple payment intermediary server transmits the payment details and the payment approval message to the above online/offline merchant;
Including more,
Method for providing simple payment intermediary service.