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

Abstract

The present invention is a token brokerage-type payment method that has high security by not storing physical card information when a user uses a simple payment service at an online or offline affiliated store, and a multiple payment method that is not locked in to a specific PG company or a specific VAN company. It relates to a method and system for providing simple payment brokerage services that adopts an online/offline simple payment method that allows simple payments to be used at low fees without going through a PG company. In addition, it integrates complex and unharmonized simple payment services to allow users to independently select multiple simple payment services according to appropriate environments and conditions or manage them as one simple payment service.

Description

Method of providing simple payment brokerage service and system therefor {METHOD FOR PROVIDING EASY PAYMENT RELAY SERVICE AND SYSTEM THEREOF}

The present invention is a token brokerage-type payment method that has high security by not storing physical card information when a user uses a simple payment service at an online or offline affiliated store, and a multiple payment method that is not locked in to a specific PG company or a specific VAN company. It relates to a method and system for providing simple payment brokerage services that adopts an online/offline simple payment method that allows simple payments to be used at low fees without going through a PG company. In addition, it integrates complex and unharmonized simple payment services to allow users to independently select multiple simple payment services according to appropriate environments and conditions or manage them as one simple payment service.

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

If we look closely at this conventional simple payment service process, PG and VAN companies are involved in the simple payment process. Here, PG is an abbreviation for electronic payment gateway service provider, and is responsible for the damage to users that may occur due to online transactions. When a seller sells products and services online, it acts as a conduit and provides representative merchant services so that customers can safely make payments using credit cards and various payment methods. In addition, VAN is an abbreviation for Value Added Network Operator, and is a company that processes approval and purchase on behalf of merchants and card companies in card payments. In this way, conventional PG companies and VAN companies exist as ancillary businesses that must be passed through depending on the type of service provided by the seller.

However, even if it is an offline transaction where payment is made using a service provided by an affiliated store, if the payment terminal provided at the affiliated store is not used, a simple payment service is provided through a PG company, so the seller receives the low price contracted with the card company. Since the seller had to pay the high online fee contracted with the PG company rather than the offline fee, a problem arises in which a considerable financial burden arises. Additionally, the conventional simple payment method of the PG company is a bill key-type simple payment that is inconvenient due to low security and accessibility. Another security problem is that the physical card information is stored when registering the card, which may expose it to illegal activities such as hacking or snooping, and that the user may not be able to send the card to a specific PG company. Once registered, the card information is locked in with the specific PG company, so there is also the inconvenience of having to register the card again in order to use another PG company.

Meanwhile, for simple payment services such as Kakao Pay and SSG Pay, even if a card is registered for one simple payment service, the user's choices are increasing due to the hassle of having to register the card for other simple payment services and the emergence of various simple payment services. Problems such as causing confusion in the purchasing decision process are occurring.

The technical problem that the present invention aims to solve is to mediate simple payments through payment tokens without storing physical card information, unlike the conventional PG company simple payment service that stores bill key-type simple payment method and physical card information during the simple payment service process. The purpose is to provide a simple payment brokerage service provision method and system that adopts the method.

Another technical problem that the present invention aims to solve is that, unlike the conventional PG company simple payment service that is locked in to a specific PG company, the seller can make a simple payment to the PG company or VAN company desired by the seller using a payment token issued by the card company through our company. The purpose is to provide a method and system for providing a simple payment brokerage service using a multiple payment method that allows the payment to be made.

Another technical problem that the present invention aims to solve is that, unlike the conventional simple payment service that necessarily goes through the PG company, which is the representative affiliate, even for offline transactions, simple payment is made directly through the VAN company without going through the PG company. The purpose is to provide a method and system for providing simple payment brokerage services that adopts an integrated online/offline simple payment method.

Another technical problem that the present invention aims to solve is to enable integrated management of existing simple payment services into one integrated management service, so that when you register a card for the first time, you can use one simple payment service without having to register a card for each of multiple simple payment services. The purpose is to provide a method and system for providing a simple payment brokerage service that can be integrated and managed like a payment service.

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

The present invention is intended to solve the above problems. The method of providing a simple payment brokerage service according to the present invention is when the simple payment server receives physical card information from the user and transmits the physical card information to the simple payment brokerage server. The simple payment brokerage server requests verification of the physical card information from the card company server and requests the card company server to generate a card identifier, and the card company server completes verification of the physical card information and generates the card identifier. If the card identifier is transmitted to the payment brokerage server, transmitting the card identifier to the simple payment server and deleting the physical card information; and if the simple payment server transmits the card identifier to the simple payment brokerage server, the simple payment brokerage The server may request verification of the received card identifier from the card company server and request generation of a token based on the card identifier.

In addition, the method for providing a simple payment brokerage service of the present invention is to receive a payment request and payment information from an online/offline affiliated store after the step of transmitting the card identifier to the simple payment server and deleting the physical card information, the payment It may further include storing information and transmitting the payment information to the simple payment server.

In addition, in the method of providing a simple payment brokerage service of the present invention, the simple payment brokerage server requests verification of the received card identifier from the card company server,

After the step of requesting the generation of a token based on the card identifier, the card company server generates the token when verification of the card identifier requested for verification is completed and transmits the generated token to the simple payment brokerage server. In this case, the step of verifying the compatibility of the received token and delivering the token whose compatibility has been verified to the simple payment server may be further included.

In addition, the method of providing a simple payment brokerage service of the present invention includes verifying the compatibility of the received token and delivering the token for which the compatibility has been verified to the simple payment server, wherein the simple payment server receives the received payment information and When the token is transmitted to the simple payment brokerage server, the simple payment brokerage server may further include the step of transmitting the token to the card company server and requesting payment approval.

In addition, in the method of providing a simple payment brokerage service of the present invention, after the step of the simple payment brokerage server delivering the token to the card company server and requesting payment approval, the card company server verifies the token, approves the payment, and When the payment details are sent to the simple payment brokerage server after deducting the user's card limit, the simple payment brokerage server stores the payment details and generates a payment approval message, and the simple payment brokerage server records the payment details. It may further include transmitting the payment approval message to the online/offline affiliated store.

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

Meanwhile, the present invention is another method to solve the above problems. The method of providing a simple payment brokerage service involves receiving physical card information from the user terminal 10 and transmitting the physical card information to the simple payment brokerage server, The simple payment brokerage server requests the card company server to verify the physical card information and generate a card identifier; when the card company server completes the verification of the physical card information and generates the card identifier, A step of the simple payment brokerage server receiving the card identifier and deleting the physical card information. When the simple payment brokerage server receives the card identifier and deletes the physical card information, the simple payment brokerage server receives the card identifier. Based on the step of registering a card and when the simple payment brokerage server receives payment requests and payment information from online/offline affiliated stores and stores the payment information, the simple payment brokerage server provides simple payment to the user terminal 10. A step of requesting server selection may be included.

In addition, the method for providing a simple payment brokerage service of the present invention is when, after the step of the simple payment brokerage server requesting the user terminal 10 to select a simple payment server, the user terminal 10 selects the simple payment server, It may further include the step of the simple payment brokerage server transmitting the payment information to the simple payment server.

In addition, the method of providing a simple payment brokerage service of the present invention is, after the step of the simple payment brokerage server transmitting the payment information to the simple payment server, when the simple payment server requests the simple payment brokerage server to generate a token, When the simple payment brokerage server requests verification of the card identifier from the card company server and requests creation of the token based on the card identifier, and when the card company server completes verification of the card identifier for which verification has been requested, When the token is generated and the generated token is transmitted to the simple payment brokerage server, the step of verifying the compatibility of the received token and delivering the compatibility-verified token to the simple payment server may be further included. .

In addition, the method of providing a simple payment brokerage service of the present invention includes verifying the compatibility of the received token and delivering the token for which the compatibility has been verified to the simple payment server, wherein the simple payment server receives the received payment information and When the token is transmitted to the simple payment brokerage server, the simple payment brokerage server may further include the step of transmitting the token to the card company server and requesting payment approval.

In addition, in the method of providing a simple payment brokerage service of the present invention, after the step of the simple payment brokerage server delivering the token to the card company server and requesting payment approval, the card company server verifies the token, approves the payment, and When the payment details are sent to the simple payment brokerage server after deducting the user's card limit, the simple payment brokerage server stores the payment details and generates a payment approval message, and the simple payment brokerage server records the payment details. It may further include transmitting the payment approval message to the online/offline affiliated store.

According to the present invention as described above, the simple payment brokerage service adopts a brokerage token payment method that does not store physical card information, thereby preventing the user's card information from being leaked and illegal activities such as hacking in advance. It has the effect of improving security and increasing trust from users.

In addition, the simple payment brokerage service expands the simple payment service network by allowing simple payment to be made with just a payment token even if the payment is made through a random simple payment company without being locked in to a specific PG company, providing convenience to users and payment providers. It not only provides autonomy of choice, but also provides work convenience to managers who manage simple payment services.

In addition, the simple payment brokerage service adopts an offline simple payment method in which simple payments are made directly through a VAN company without going through a PG company, so that economic benefits can be obtained by eliminating the fees incurred while going through a PG company, and the overall simple payment process. It has the effect of simplifying.

In addition, the simple payment brokerage service simplifies the user's simple payment service options by enabling integrated management of existing simple payment services into one integrated management service, prevents user purchase confusion, and allows users to use the simple payment service provided by the simple payment service. It has the effect of encouraging people to appropriately manage or utilize benefits and events.

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.

1 is a flowchart 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 diagram schematically showing the process of providing a simple payment service to a user through the simple payment brokerage server 100 according to the present invention.
Figure 3 is a flowchart showing a method of providing a simple payment brokerage service according to the first embodiment.
Figure 4 is a flowchart showing a method of providing a simple payment brokerage service according to the second embodiment.
Figure 5 is a flowchart showing a method of providing a simple payment brokerage service according to a third embodiment.
Figure 6 is a flowchart showing a method of providing a simple payment brokerage service according to a fourth embodiment.
Figure 7 is a diagram specifically showing an example of utilizing a simple payment brokerage service in the payment process using an O2O (Offline to Online) service.
Figures 8 and 9 are diagrams specifically showing an example of using the token of a simple payment brokerage service so that different simple payment affiliate services can be linked.
Figure 10 is a diagram illustrating in detail an example of using the token of a simple payment brokerage service so that different simple payment brokerage services can be linked.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the attached drawings. The advantages and features of the present invention and methods for achieving them will become clear by referring to the embodiments described in detail below along with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below and may be implemented in various different forms, and the present embodiments are merely intended to ensure that the disclosure of the present invention is complete and to provide common knowledge in the technical field to which the present invention pertains. It is provided to fully inform those who have the scope of the invention, and the present invention is only defined 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 with meanings that can be commonly understood by those skilled in the art to which the present invention pertains. Additionally, terms defined in commonly used dictionaries are not interpreted ideally or excessively unless clearly specifically defined. The terms used in this specification are for describing embodiments and are not intended to limit the invention. As used herein, singular forms also include plural forms, unless specifically stated otherwise in the context.

Terms such as “first” and “second” are used to distinguish one component from another component, and the scope of rights should not be limited by these terms. For example, a first component may be named a second component, and similarly, the second component may also be named a first component.

As used herein, “comprises” and/or “comprising” refers to a referenced component, step, operation and/or element that includes one or more other components, steps, operations and/or elements. Does not exclude presence or addition.

Meanwhile, the present invention is not limited to the specific embodiments and application examples described above, and various modifications may be made by those skilled in the art without departing from the gist of the present invention as claimed in the claims. Of course, it is possible, but these modified implementations should not be understood separately from the technical idea or outlook of the present invention.

Before giving a full explanation of the present invention, 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 brokerage server 100 according to the present invention. Let us briefly look at terms frequently mentioned in the process of providing the simple payment brokerage service of the present invention.

First, the conventional online payment and offline mobile payment method (a) according to Figure 1 is a payment method in which payment is made online and payment is made offline, but payment is made through mobile payment. In this method, online payment is made. Since it is difficult to visit affiliated stores or individually specify a contract with one online affiliated store, a representative affiliated store, i.e., a PG company (Payment Gateway), is involved, which contracts with the card company server on behalf of the online affiliated store and handles payments. A VAN company, which establishes a communication network and handles card payment and purchase-related tasks, also becomes involved.

Conventional online payment and offline mobile payment methods (a) have adopted a bill key-type payment method in which payment is initiated through a PG bill key preset on the user terminal 10, and as the first step of the payment method, the user terminal 10 When a Bilky-type payment begins, the online merchant (sub-franchise) requests payment approval from the PG company (representative merchant). If the PG company approves the payment, the existing card payment process, which is the authentication stage, approval stage, and purchase stage, is carried out through the PG company, VAN company, and card company servers. During the card payment process, the authentication stage is a stage where the PG company checks whether the card making the payment is a valid card and whether the owner of the card is the person himself/herself through the card company number, expiration date, and CVC number. The approval stage is when the PG company receives information from the user or affiliated store. This is a step in which the received payment information is transmitted 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 user's card limit is deducted and the approved result is transmitted back to the VAN company. The stage up to delivering the approval result received by the VAN company back to the user or affiliated store can also be referred to as the approval stage. The purchase step is a step in which the affiliated store receives payment for selling the product. It includes a step where the affiliated store transmits a sales slip to the card company server through a VAN company, and the card company server that receives the sales slip deposits the payment amount to the affiliated store.

On the other hand, the payment method (b) through the simple payment brokerage server 100 adopts a token brokerage type payment method as can be seen in FIG. 1, and the online payment method is made through a PG company, but is different from the conventional online payment. It can be confirmed that offline mobile payments, which were also classified, allow payments to be made without going through a PG company, simplifying the payment process and reducing fees.

In this way, the reason why the payment method (b) through the simple payment brokerage server 100 may not go through the PG company is because of the card registration method that does not store physical card information and the token generation method that is generated based on the card identifier. This can be explained in more detail when explaining the method of providing a simple payment brokerage service according to the first embodiment of the present invention.

Figure 2 is a diagram schematically showing the process of providing a simple payment service to a user through the simple payment brokerage server 100 of the present invention.

[Easy payment brokerage server (100)]

The simple payment brokerage server 100 according to FIG. 2 provides a complex and unharmonized simple payment service (the simple payment service provided by the existing simple payment affiliate server 200) when a user uses the simple payment service at an online/offline affiliated store. A token that integrates multiple simple payment services to allow users to independently select multiple simple payment services according to the appropriate environment and conditions or manage them as one simple payment service, and has high security because it does not store physical card information This is a server that provides services to enable simple payments with low fees without going through a PG company in the case of brokerage-type payment methods, multiple payment methods that are not locked in to a specific PG company or a specific VAN company, and offline transactions.

This simple payment brokerage server 100 can be subdivided into a simple payment authentication server 110 and a simple payment approval server 120 in order to efficiently perform the above purposes.

[Easy payment authentication server (110)]

The simple payment authentication server 110 leads the user's identity verification process, generates a card identifier to encrypt the user's physical card, and requests card verification and registration to the card company server 300 through the generated card identifier. , upon receiving the first card ID from the card company, it generates a second card ID that can only be read within the simple payment brokerage server 100 and plays the role of enabling tokens to be created through this, and performs the simple payment authentication mentioned above. The role of the server 110 and related terms will be examined in more detail in the first embodiment, which will be described later.

[Easy payment approval server (120)]

If the simple payment authentication server 110 hosted card registration and token generation in the simple payment brokerage service providing method of the present invention, the simple payment approval server 120 is a card company server ( 300), and when the card company server 300 verifies the token and approves the payment, the payment details are stored on the server according to the approved payment result, and a payment approval message is generated to send to the user terminal 10 or a simple It performs the role of transmitting to the 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, which will be described later.

[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 services that are currently commercialized, for example, a server that provides simple payment services such as SSG Pay and Kakao Pay.

<Example 1>

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

The method of providing a simple payment service according to the first embodiment can be largely divided into a card registration process, a token creation process, and a payment process after token creation. Below, we will explain the card registration process in order.

[Card Registration]

In order to register a card, the simple payment affiliate server 200 first receives the user ID and physical card information from the user and transmits a request to register the physical card information to the simple payment authentication server 110 (S101). . Here, the user ID may mean a unique ID for identifying a user who has registered as a member of the simple payment affiliate server 200. In addition, it can be used not only to identify users in the simple payment affiliate server 200, but also as an integrated user ID that can identify users in the simple payment brokerage server 100. Alternatively, the user ID used in the simple payment affiliate server 200 and the ID used to identify the user in the simple payment brokerage server 100 may exist separately. However, at this time, the IDs between the two servers will be able to be mapped to each other.

Next, when the simple payment affiliate server 200 receives physical card information from the user and transmits a request to register physical card information to the simple payment authentication server 110 (S101), the simple payment authentication server 110 sends the physical card information to the simple payment authentication server 110. A card identifier that encrypts information is generated (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 leakage 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).

Afterwards, the card company server 300 verifies the card based on the received card identifier, and when card verification is completed, it registers the card and generates the first card ID (S104).

Here, the first card ID is an ID given 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. However, the card identifier is a physical ID for the purpose of registering the card. Card information is encrypted, and the difference is that the first card ID 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).

Afterwards, the simple payment authentication server 110 generates a second card ID that replaces 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 in step S102 and the first card ID in step S104, and the second card ID is matched with the first card ID received from the card company server 300 (S107). The second card ID registered in the simple payment authentication server 110 serves to allow the card to be registered without having to register the card in each of the multiple simple payment affiliate servers 200. When requesting a disposable card number, the second card ID can also be used as a disposable card number.

After the simple payment authentication server 110 generates 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) and registers the user card. The step is completed.

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

[Token Generation]

In order for the 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 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 the second card ID to the simple payment authentication server 110 and requests a payment token based on it, the simple payment authentication server 110 sends the received second card ID and user information to the simple payment authentication server 110. The user is verified by comparison (S110).

Here, the user information is user information necessary for identity verification and authentication, such as the name, age, and phone number previously entered by the user into the simple payment authentication server 110.

Afterwards, the simple payment authentication server 110 transmits the previously received first card ID to the card company server 300 and requests 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 a token to the simple payment authentication server 110 (S113), and the simple payment authentication server 110 sends the token received from the card company server 300 to the simple payment affiliate server 200. Upon delivery (S114), the token creation step is completed.

[Token simple payment]

When a token is generated through the above process, a simple payment is made through the generated token. In the token simple payment process, first, the simple payment affiliate server 200 makes a payment to the simple payment approval server 120 with payment information and a token. It starts with the step of requesting approval (S115).

Afterwards, 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 delivers the received token and payment approval request to the card company server 300, the card company server 300 verifies the received token and approves the payment when verification is completed (S117). Additionally, the card company server 300 verifies the received token and, when verification is completed, 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, generates a payment approval message (S119), and transmits the payment details and payment approval message to the simple payment affiliate server 200 (S120).

We looked at the method of providing simple payment brokerage services according to the first embodiment above.

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

<Second Embodiment>

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

The method of providing a simple payment brokerage service according to the second embodiment of the present invention is different from the first embodiment of the present invention in that it provides a simple payment brokerage service by using only the first card ID rather than using the second card ID. There is. Except for the steps corresponding to these differences, the steps are the same as those of the first embodiment of the present invention, so to prevent redundant description, only the steps corresponding to the differences will be described.

In the method of providing a simple payment brokerage 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).

Afterwards, 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 not only the first card ID role described in the first embodiment, but also the second card ID role. 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 the first card ID, and the simple payment authentication server 110 It can reduce role burden.

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 generation (S109a).

Next, the simple payment authentication server 110 verifies the user based on the received first card ID and user information (S110a). The step (S110a) differs 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.

Since the subsequent steps are the same as the first embodiment of the present invention, they will be omitted.

<Third Embodiment>

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

The method of providing a simple payment brokerage service according to the third embodiment of the present invention is the same as the card registration step of the method of providing a simple payment brokerage service according to the second embodiment of the present invention, but in the token generation step, from the card company server 300 It is different from the second embodiment of the present invention in that the generated payment token is replaced with a payment code and used. Except for the steps corresponding to these differences, the steps are the same as those of the second embodiment of the present invention, so to prevent redundant description, only the steps corresponding to the differences will be described.

In the method of providing a simple payment brokerage service according to the third embodiment of the present invention, after transmitting the token generated by the card company server 300 to the simple payment authentication server 110 (S113), the simple payment authentication server 110 The received payment token is replaced with a payment code (S301). Here, the payment code may mean a code that is replaced with the same payment token generated from the card company server 300, and preferably may be a barcode, or may mean a QR code. For reference, when the payment code is prepared in the form of a barcode, the barcode can constitute data based on 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).

Afterwards, the simple payment affiliate server 200 can provide the received payment code to the user, and if the user wants to proceed with the simple payment, he or she can present the provided payment code to the offline affiliated store or offline affiliated store. When the affiliated store recognizes the payment code through a separate device (e.g., barcode scanner), the simple payment affiliate server 200 transmits the payment information and payment code to the simple payment approval server 120 and approves the payment based on this. Request (S303). For reference, the steps described above describe the CPM (Customer Present Mode: see Figure 7), that is, the process of simple payment being made by the user presenting the payment code to the affiliated store. Conversely, the simple payment affiliate server 200 makes the payment. Simple payment using MPM (Merchant Present Mode: see Figure 7), which provides the code to an online/offline merchant rather than providing the code to the user, and the merchant presents the payment code to the user so that the user recognizes the payment code through the terminal. It can also be done in this way.

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, and is replaced with the same payment code as the payment code, but includes payment information (e.g., price of the product, date of purchase/sale, etc.). It may be another form of payment token.

Since step S304 is the same as the second embodiment of the present invention, it will be omitted.

<Fourth Embodiment>

The method of providing a simple payment service according to the fourth embodiment shown in Figure 6 involves a card registration process and a token generation process in the same way as the method of providing a simple payment service according to the first to third embodiments, but there is a difference in the card registration process. There is a difference from the simple payment service provision method according to the first to third embodiments in that there is a user's selection process for the simple payment affiliate server 200 between the card registration process and the token creation process.

The card registration process of the simple payment service provision method according to the fourth embodiment begins with the step where the simple payment authentication server 110 requests the user terminal 10 to input physical card information (S401). Before step S401, the user terminal 10 requests the simple payment affiliate server 200 to register a physical card, and the simple payment affiliate server 200 transmits the physical card registration request to the simple payment authentication server 110. There may be more steps.

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

Afterwards, the simple payment authentication server 110 transmits the generated card identifier verification request to the card company server 400 (S405), and the card company server 300 verifies the received card identifier and generates the first card ID when verification is completed. Do it (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 begins payment, the simple payment affiliate server 200 transmits payment information and a payment request to the simple payment brokerage server 100 (S409). Next, the simple payment approval server 120 stores payment information (S410).

After the simple payment approval server 120 stores the payment information, the simple payment approval server 100 transmits a request to select the simple payment server 100 from the user terminal 10 (S411). The simple payment brokerage server 100 according to the fourth embodiment integrates and manages or brokers commonly used simple payment affiliate servers 200, and the simple payment brokerage server 100 allows a user to use a plurality of simple payment affiliate servers 200. One feature may be that it provides a choice so that one can be selected. Through this, users can appropriately use point accumulation benefits, discount benefits, etc. implemented by the simple payment affiliate server 200.

When the user terminal 10 receives a request to select the simple payment affiliate server 200 from the simple payment approval server 110, the user selects the simple payment affiliate server 200 through the user terminal 10 and confirms the selection. It is transmitted to the simple payment brokerage server 100, more precisely, the 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 brokerage server 100, the token creation process begins.

Since the token generation process and the payment process after token generation in the method of providing simple payment brokerage services according to the fourth embodiment are the same as the method of providing simple payment brokerage services according to the second embodiment, detailed descriptions will be omitted.

We looked at the method of providing simple payment brokerage services according to the fourth embodiment above.

Next, we will explain various usage examples of the simple payment service provision method.

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

Figure 7 is a diagram showing an example of the use of a method for providing a simple payment brokerage service according to the first embodiment, and is specifically a diagram showing a method for providing a simple payment service in the O2O (Offline to Online) method.

Before looking at the method of providing an O2O simple payment service according to Figure 7, the first thing to note is that the user who wants to make a simple payment has already performed the card registration process and token creation process and has been granted a token in advance. and that offline affiliated stores use online simple payment services.

Users who use the 020-type simple payment service will first be granted a token through the token generation method according to the first embodiment, and the user can use simple payment methods (card/account/prepaid), MPM (Merchant Present Mode), and CPM. Payment is made by selecting one of the representative O2O payment methods such as (Customer Present Mode).

The simple payment method is to select the payment method desired by the user among the simple payment services provided by the simple payment affiliate server (200). The payment method is a credit card or check card registered on the simple payment affiliate server (200). , using an account payment to be transferred from the user's bank account as a payment method, and using the recharge amount or prepaid amount (prepayment) that the user has already charged to the simple payment affiliate server (200) or the affiliated store server as a payment method. It is done by.

Meanwhile, MPM (Merchant Present Mode) allows the merchant to present a QR code or barcode containing payment information to the user so that the user can recognize the QR code or barcode through a user terminal 10 such as a smart phone to proceed with payment. It is a payment method.

CPM (Customer Present Mode), in contrast to MPM (Merchant Present Mode), allows the user to present to the affiliated store a QR code or barcode containing personal identification information that can be used to confirm payment, and the affiliated store can use the QR code or barcode reader to It is a payment method that recognizes a barcode to proceed with payment. For reference, MPM and CPM payments will follow the payment method made on the user terminal.

As mentioned earlier, the user can proceed with the payment on his own initiative by selecting one of these three payment methods. If the user selects one of the three payment methods and proceeds with the payment, the user must first proceed with the payment through the simple payment brokerage server. The token received from (100) is once again transmitted to the simple payment brokerage server (100) (Figure 7-①) to notify that the payment has been made, and the token received by the simple payment brokerage server (100) is sent to the card company server (300). It is sent to request token verification and payment approval (Figure 7-②). Next, the card company server 300 verifies the received token, and when verification is completed, the card company server 300 approves the payment and the payment is processed normally (Figure 7-③).

The O2O (Offline to Online) payment method using tokens in this way can be seen as a combination of the existing convenient O2O payment method with a token payment method with high security and versatility.

Meanwhile, Figure 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, even if a user registers a card on only one simple payment affiliate server 200, the user can make a simple payment using a token without having to register the card on another simple payment affiliate server 200. In other words, assuming that the user has registered as a member of a plurality of simple payment affiliate servers (200) and registered a card only on the first simple payment affiliate server (201), the plurality of simple payment affiliate servers (200) User information is stored through the user's membership registration, and card information (e.g., first card ID or/and second card ID) is generated in the first simple payment affiliate server 201 during the process of registering the user's card. , Card information is mapped to user information to form a 'simple payment linkage network (a network between multiple simple payment affiliate servers 200 where user information is stored)', and through this simple payment linkage network, different simple payment affiliates This means that simple payment linkage between servers 200 can be achieved.

For example, if a user who normally uses SSG Pay visits a bakery to purchase bread, and the bakery offers a 15% discount when paying for bread with Kakao Pay, In order to receive discount benefits, users will have to sign up for Kakao Pay on the spot and register their card with Kakao Pay. However, by using the token of the present invention, users do not have to do inconvenient activities such as signing up for Kakao Pay or registering a card. You can simply pay for bread by generating a token through SSG Pay, which you normally use, and sending the generated token to Kakao Pay.

Returning to Figure 8, looking in detail at the process of linking the simple payment affiliate server 200 using a token, first, user information is stored in the first and second simple payment affiliate servers 200, and the first simple payment affiliate server 200 is stored in the first simple payment affiliate server 200. As the card is registered in 201, the card information is mapped to the user information, thereby forming a simple payment linked network (FIG. 8-①).

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

When the second simple payment affiliate server 202 receives a token from the first simple payment affiliate server 201 (Figure 8-②), the second simple payment affiliate server 202 processes the simple payment so that the simple payment can proceed. A token is transmitted to the mediation server 100 (Figure 8-③).

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

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

Referring to FIG. 9, after the simple payment linkage network is formed, that is, after the user information and card information are mapped to the simple payment affiliate servers 200, the 'token for linkage' is stored in the first card in which the card is registered. Simple payment linkage may be achieved by transmitting the card to the unregistered second simple payment affiliate server 202 through the simple payment brokerage server 100 rather than the simple payment affiliate server 201. In other words, in Figure 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 sends a 'token for linking' to the second simple payment affiliate server. Simple payment linkage is carried out by sending it to the server 202, but in Figure 9, the 'token for linkage' is managed by the simple payment brokerage server 100, and when simple payment linkage begins, the simple payment affiliate whose card is not registered Even if the server 200 is a simple payment affiliate server 200 where user information and card information are mapped, a 'token for linking' is transmitted (Figure 9-②) to enable simple payment linking. As shown in Figure 9, if the 'token for linking' is managed by the simple payment brokerage server 100, even if mapping of user information and card information between the simple payment affiliate servers 200 is done, the 'token for linking' is managed by the simple payment affiliate server 200. This can be used as a way to prevent tokens from linking together due to policy and agreement issues. In addition, since the simple payment mediation server 100 is involved in token creation, the method of managing the 'token for linking' by the simple payment mediation server 100 may have relatively higher security and compatibility compared to other methods.

On the other hand, Figure 10 is a diagram showing that different simple payment intermediary servers can be interconnected and utilized by exchanging tokens with each other. In other words, when a user attempts to proceed with a transaction through the cross-border payment brokerage server 400 in which the card has not been registered, the token from the simple payment brokerage server 100 is transferred to the cross-border payment brokerage server 400 even if the card is not re-registered. ), payment can be processed. As an easy example, an affiliated store signs a contract with a simple payment brokerage service provider such as a PG company or VAN company that performs and brokers payment-related tasks on its behalf. The affiliated store contracts with one of several simple payment brokerage service providers. When you select and enter into a contract, and each affiliated store has a different simple payment brokerage service company, the user who wants to purchase a product has the problem of having to register a card for each simple payment brokerage service, and the payment process provided by the simple payment brokerage service is different from the simple payment brokerage service. Since it may be different for each user, problems may occur that may cause confusion for users. Accordingly, the present invention can be implemented so that users can make payments through the cross-party payment brokerage server 100 using the simple payment token provided by the present invention.

Looking at the process in which the simple payment brokerage server (100) and the other simple payment brokerage server (400) are linked and the payment progresses, first, the user uses the simple payment affiliate server (200), the simple payment brokerage server (100), and the card company server. It will start with registering the user card through (300) and generating a token (Figure 10-①), and the subsequent payment process using the token will also be processed through the simple payment brokerage server where the user registered the card. If you signed a contract with (100), the simple payment process described so far will be the same.

On the other hand, even if the affiliated store with which the user wants to make a transaction has concluded a contract with the cross-party payment brokerage server 400 rather than the simple payment brokerage server 100, the user can use the simple payment affiliate server 200 to process the simple payment brokerage. If the token from the server 100 is transmitted to the cross-border payment brokerage server 400, the cross-border payment brokerage server 400 can be used like the simple payment brokerage server 100 previously used by the user.

We have looked at all examples of how to provide simple payment brokerage services.

Meanwhile, the present invention is not limited to the specific embodiments and application examples described above, and various modifications may be made by those skilled in the art without departing from the gist of the present invention as claimed in the claims. Of course, it is possible, but these modified implementations should not be understood separately from the technical idea or outlook of the present invention.

User terminal (10)
Simple payment brokerage server (100)
Simple payment authentication server (110)
Simple payment approval server (120)
Simple payment affiliate server (200)
1st simple payment affiliate server (201)
2nd simple payment affiliate server (202)
Card company server (300)
Other simple payment brokerage servers (400)

Claims (11)

In a method of providing a simple payment brokerage service server that integrates and manages or mediates existing simple payment servers so that the user can use the simple payment service under the user's control,
When the simple payment server receives physical card information from the user and transmits the physical card information to the simple payment brokerage server, the simple payment brokerage server requests verification of the physical card information from the card company server and sends the card information to the card company server. requesting creation of an identifier;
When the card company server completes verification of the physical card information, generates the card identifier, and transmits it to the simple payment brokerage server, transmitting the card identifier to the simple payment server and deleting the physical card information; and
When the simple payment server transmits the card identifier to the simple payment brokerage server, the simple payment brokerage server requests verification of the received card identifier from the card company server and provides a token based on the card identifier. A step of requesting creation;
Including,
How to provide simple payment brokerage service.
According to claim 1,
After sending the card identifier to the simple payment server and deleting the physical card information,
When receiving a payment request and payment information from an online/offline affiliated store, storing the payment information; and
Passing the payment information to the simple payment server
Containing more,
How to provide simple payment brokerage service.
According to claim 2,
After the simple payment brokerage server requests verification of the received card identifier from the card company server and requests creation of a token based on the card identifier,
When the card company server generates the token when verification of the card identifier requested for verification is completed and transmits the generated token to the simple payment brokerage server, the compatibility of the received token is verified and the compatibility is verified. delivering a token to the simple payment server;
Containing more,
How to provide simple payment brokerage service.
According to clause 3,
After verifying the compatibility of the received token and delivering the compatibility-verified token to the simple payment server,
When 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;
Containing more,
How to provide simple payment brokerage service.
According to paragraph 4,
After the simple payment brokerage server delivers 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 transmits the payment details to the simple payment brokerage server, the simple payment brokerage server stores the payment details and sends a payment approval message. generating a; and
The simple payment brokerage server transmitting the payment details and the payment approval message to the online/offline affiliated store;
Containing more,
How to provide simple payment brokerage service.
According to clause 5,
The delivered token is characterized in that it can be linked with any simple payment brokerage server - other PG companies, other VAN companies, etc. - to receive payment approval from the card company server.
How to provide simple payment brokerage service.
In a method of providing a simple payment brokerage service server that integrates and manages or mediates existing simple payment servers so that the user can use the simple payment service under the user's control,
When physical card information is input from the user terminal 10 and the physical card information is transmitted to the simple payment brokerage server, the simple payment brokerage server requests verification of the physical card information from the card company server and requests creation of a card identifier. steps;
When the card company server completes verification of the physical card information and generates the card identifier, the simple payment brokerage server receives the card identifier and deletes the physical card information;
When the simple payment brokerage server receives the card identifier and deletes the physical card information, the simple payment brokerage server registers a card based on the card identifier; and
When the simple payment brokerage server receives a payment request and payment information from an online/offline affiliated store and stores the payment information, the simple payment brokerage server requests the user terminal 10 to select a simple payment server;
Including,
How to provide simple payment brokerage service.
According to clause 7,
After the step of the simple payment brokerage server requesting the user terminal 10 to select a simple payment server,
When the user terminal 10 selects the simple payment server, the simple payment brokerage server transmits the payment information to the simple payment server;
Containing more,
How to provide simple payment brokerage service.
According to clause 8,
After the simple payment brokerage server transmits the payment information to the simple payment server,
When the simple payment server requests the simple payment intermediary server to generate a token, the simple payment intermediary server requests verification of the card identifier from the card company server and requests generation of the token based on the card identifier. ; and
When the card company server completes the verification of the card identifier requested for verification, generates the token and transmits the generated token to the simple payment brokerage server, the compatibility of the received token is verified, and the compatibility is verified. delivering a token to the simple payment server;
How to provide simple payment brokerage service.
According to clause 9,
After verifying the compatibility of the received token and delivering the compatibility-verified token to the simple payment server,
When 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;
Containing more,
How to provide simple payment brokerage service.
According to clause 10,
After the simple payment brokerage server delivers 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 transmits the payment details to the simple payment brokerage server, the simple payment brokerage server stores the payment details and sends a payment approval message. generating a; and
The simple payment brokerage server transmitting the payment details and the payment approval message to the online/offline affiliated store;
Containing more,
How to provide simple payment brokerage service.