KR20140013810A

KR20140013810A - Mobile billing method

Info

Publication number: KR20140013810A
Application number: KR1020120082373A
Authority: KR
Inventors: 양 선 박
Original assignee: 양 선 박
Priority date: 2012-07-27
Filing date: 2012-07-27
Publication date: 2014-02-05

Abstract

Mobile payment method according to an aspect of the present invention that can process payment without the personal information of the buyer is carried out in the mobile payment system that can be connected to the buyer terminal and the seller server. The mobile payment method may further include: generating transaction code when receiving transaction information about a transaction of a product or service concluded between a seller and a buyer and a transaction code request for identification of the transaction from the seller server; Transmitting the generated transaction code to the seller server, and matching the generated transaction code with the transaction information and storing it in a database; Determining a validity of the received transaction code when receiving a payment request including the transaction code and payment information from the purchaser terminal; And processing the payment request according to the validity of the transaction code. Here, the transaction information may include seller information excluding buyer information and the traded product or service information.

Description

Mobile payment method {MOBILE BILLING METHOD}

The present invention relates to a mobile payment method, and more particularly to a mobile payment method using a mobile payment system for non-face-to-face transactions.

Non-face-to-face transactions refer to a type of transaction in which buyers and sellers do not identify a product through actual face-to-face transactions, which are beginning to increase due to the spread of computers and the development of wired / wireless networks.

In addition, with the recent rapid expansion of smartphone penetration, mobile e-commerce services have appeared in the form of applications on the basis of such an environment, and mobile payment services through smartphones have been in earnest.

The mobile payment service is a payment service that pays a transaction price for a transaction of a product or service made online and offline using a mobile terminal. The mobile payment service provides user accessibility and user convenience by allowing a user to easily purchase a product or a service through a mobile terminal without being restricted by time and place.

Korean Patent Laid-Open Publication No. 10-2004-00871204 (hereinafter, referred to as a prior art) provides a payment method for a non-face-to-face transaction using a mobile terminal. Prior art transmits transaction information, buyer's personal information and buyer's payment information to a payment agency server (hereinafter referred to as a mobile payment system) that provides a mobile payment service through a paid service providing server (hereinafter referred to as a seller server). This prior art has a problem that the seller can collect and exploit the buyer's personal information and buyer's payment information. In addition, since the seller server is weaker in security than the mobile payment system, there is another problem that the personal information and payment information of the buyer are more exposed to the outside by hackers.

On the other hand, the prior art transmits the authentication number to the buyer terminal using the mobile communication number of the buyer terminal received from the seller server to authenticate the buyer terminal. As such, the method of authenticating the purchaser terminal based on the mobile communication number has a problem that it is difficult to apply to international transactions because the mobile communication number system is different in each country.

The present invention is to solve the above problems, to provide a mobile payment method that can enhance the security in the payment process to the technical problem.

Another object of the present invention is to provide a mobile payment method that can process a payment without the purchaser's personal information.

In addition, another technical problem of the present invention is to provide a mobile payment method that can be paid even during international transactions.

The mobile payment method according to an aspect of the present invention for achieving the above object is performed in the mobile payment system that can be connected to the buyer terminal, the seller server. The mobile payment method may further include: generating transaction code when receiving transaction information about a transaction of a product or service concluded between a seller and a buyer and a transaction code request for identification of the transaction from the seller server; Transmitting the generated transaction code to the seller server, and matching the generated transaction code with the transaction information and storing it in a database; Determining a validity of the received transaction code when receiving a payment request including the transaction code and payment information from the purchaser terminal; And processing the payment request according to the validity of the transaction code. Here, the transaction information includes seller information excluding buyer information and the traded product or service information.

According to the present invention, since the mobile payment system receives the payment information of the buyer directly from the purchaser terminal, the payment information of the buyer is not exposed to the seller, thereby securing security.

In addition, according to the present invention, there is another effect that the buyer's personal information is not exposed to the outside because the buyer does not need to provide personal information.

In addition, according to the present invention, since a transaction code for identifying a transaction between the purchaser terminal and the seller server is generated and provided irrespective of the mobile communication number of the purchaser terminal, it can be used in an international transaction, thereby securing universality. have.

1 is a view schematically showing a mobile trading system according to an embodiment of the present invention.
FIG. 2 is a diagram for describing a mobile payment system of FIG. 1.
3 is a flowchart illustrating a mobile payment method according to an embodiment of the present invention.
4 is a diagram illustrating an example of performing a mobile payment through an application for payment in a purchaser terminal.
5 is a flowchart illustrating an embodiment of a transaction code generation method performed in a mobile payment system.
6 is a flowchart illustrating an embodiment of a mobile payment method using a transaction code performed in a mobile payment system.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. In order to clearly explain the present invention, parts not related to the description in the drawings are omitted, and the same reference numerals are used for the same parts throughout the specification.

Meanwhile, the meaning of the terms described in the present invention should be understood as follows.

The terms "first "," second ", and the like are intended to distinguish one element from another, and the scope of the right should not be limited by these terms. For example, the first component may be referred to as a second component, and similarly, the second component may also be referred to as a first component.

It should be understood that the singular " include "or" have "are to be construed as including a stated feature, number, step, operation, component, It is to be understood that the combination is intended to specify that it does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or combinations thereof.

1 is a view schematically showing a mobile trading system according to an embodiment of the present invention.

Referring to FIG. 1, the mobile transaction system 100 includes a buyer terminal 110, a seller server 120, a mobile payment system 130, and a card company server 140.

First, the purchaser terminal 110 transmits a purchase request for one or more products or services that a buyer wants to purchase to the seller server 120 to enter into a transaction with the seller server 120. In addition, the purchaser terminal 110 transmits the payment information to the mobile payment system 130 to pay the transaction amount for the transaction.

To this end, the purchaser terminal 110 pays for the first purchaser terminal 111 for the purchase of a product or service sold by the seller server 120, and the product or service purchased through the first purchaser terminal 111. It may include a second buyer terminal 112 for.

In this case, the first purchaser terminal 111 may be connected to the seller server 120 by wire or wirelessly to transmit a purchase request for one or more products or services to be purchased to the seller server 120. The second purchaser terminal 112 is a portable means for wireless communication, which is connected to the mobile payment system 130 based on wireless communication such as a cellular network or a wireless LAN. The payment information may be transmitted to the mobile payment system 130.

The purchaser terminal 110 according to an exemplary embodiment of the present invention shown in FIG. 1 has a first buyer terminal 111 for purchasing a product or a service and a second buyer terminal for payment for a purchased product or a service. Although 112 is separated, in another embodiment, the second purchaser terminal 112 may perform both a purchase and a payment. In one embodiment, the payment information may include the credit card information of the purchaser. . Credit card information is information about a conventional plastic credit card, the buyer enters the 16-digit card unique number, the card expiration date, the three-digit CVC (CVV) number and the card password to the second buyer terminal 112 Can be obtained.

In another embodiment, the payment information may include the mobile card information of the buyer. The mobile card information is information about a mobile card stored in a universal subscriber identity module (USIM) or a secure element (SE) installed in the second purchaser terminal 112 and is linked with an application for mobile card payment. Such mobile card information includes one or more mobile credit card information and a password for security (PIN). Here, the password PIN may include a user password GPIN and a payment password LPIN to increase the security of the mobile payment.

Next, the seller server 120 transmits the transaction information about the transaction between the seller and the buyer and the transaction code request for the transaction to the mobile payment system 130 according to the purchase request of the first buyer terminal 111. .

At this time, the transaction information is characterized in that it does not include the buyer information, such as the buyer's name, social security number, telephone number, mobile communication number, address. That is, the transaction information includes seller information excluding buyer information and product or service information concluded between the seller server 120 and the first buyer terminal 111. Here, the seller information includes at least one of the trade name, address, contact information, and business number of the seller, and the product or service information includes the product name or service name, the manufacturer, the date of manufacture, the unit price of the product or service, the transaction quantity, and the transaction. Include at least one of the amounts.

As described above, since the seller server 120 does not provide the buyer information to the mobile payment system 130, the seller server 120 does not need to request the buyer information from the first buyer terminal 111 or register the buyer information in advance. The mobile transaction system 100 including the seller server 120 can prevent the leakage of buyer information to the outside, which is effective for protecting personal information.

On the other hand, the seller server 120 receives the transaction code from the mobile payment system 130, and transmits the received transaction code to the first buyer terminal (111).

Next, the mobile payment system 130 generates a transaction code according to the transaction code request of the seller server 120 and transmits the transaction code to the seller server 120. In addition, the mobile payment system 130 processes a transaction amount payment for a transaction concluded between the first buyer terminal 111 and the seller server 120 according to the payment request of the second buyer terminal 112.

Hereinafter, the mobile payment system 130 according to an embodiment of the present invention will be described in more detail with reference to FIG. 2.

FIG. 2 is a diagram for describing a mobile payment system of FIG. 1.

Referring to FIG. 2, the mobile payment system 130 includes a communication unit 210, a transaction code generation unit 220, a database 230, a transaction code verification unit 240, and a payment processing unit 250.

First, when the communication unit 210 receives a transaction code request from the seller server 120 or a payment request from the second buyer terminal 112, the communication unit 210 connects to the seller server 120 or the second buyer terminal 112 to establish a session. Connect The communication unit 210 communicates with the seller server 120 or the second purchaser terminal 112 through the connected session.

The communication unit 210 maintains the session connection until the seller server 120 or the second buyer terminal 112 terminates the connection or the mobile payment is completed.

Next, when the transaction code generation unit 220 receives the transaction information and transaction code request for the product or service transaction concluded between the seller and the buyer from the seller server 120 through the communication unit 210, identifying the transaction Generate a transaction code for

The transaction code generation unit 220 generates a unique transaction code using at least one of numbers, letters, and symbols. To this end, the transaction code generation unit 220 may randomly generate a transaction code by a combination of at least one of numbers, letters, and symbols, and check whether the generated transaction code already exists as a valid transaction code. If it already exists, the transaction code generation unit 220 may regenerate the transaction code.

In one embodiment, the transaction code generation unit 220 may generate a unique transaction code by adding a serial number to the combination of numbers, letters, and symbols.

In one embodiment, the transaction code generation unit 220 may set the valid time of the transaction code when generating the transaction code. In this case, the transaction code is valid within the set valid time, and may be lost when the valid time elapses. The valid time of the transaction code may be arbitrarily set by the mobile payment system 130 or may be set to a value previously registered by the seller in the mobile payment system 130.

In one embodiment, the transaction code generation unit 220 may generate a transaction code including a status code. The status code indicates the status of a transaction code and may be represented by using at least one code string among a plurality of code strings.

For example, a transaction code may be generated as six code strings, and the first code string among the six code strings may represent a status code. At this time, the status code may have one of '0' and '1'. The status code value '0' may indicate a valid state. In addition, the status code value '1' may indicate an invalid state in which the validity of the transaction code has elapsed or the validity is lost by receiving the transaction code from the second purchaser terminal 112 and confirming its validity.

For another example, the status code may be further subdivided than the above-described example to have one of '0', '1', '2', '3' and '4'. At this time, the status code value '0' indicates the valid state, the status code value '1' indicates the valid time of the transaction code has elapsed, and the status code value '2' indicates the transaction code from the second buyer terminal 112. It may indicate that the state has been received and validated. In addition, the status code value '3' may indicate a state in which payment has been successfully processed, and the status code value '4' may indicate a state in which the payment has failed.

Although the mobile payment system 130 according to the above-described embodiment is described as including the status code in the transaction code, in another embodiment, the status code may be set and managed separately from the transaction code.

Next, the database 230 stores and manages the transaction code generated by the transaction code generator 220 by matching the transaction information. In this case, the transaction information is received from the seller server 120 through the communication unit 210, and includes seller information and product or service information. In addition, the database 230 may further store the valid time of the transaction code.

Meanwhile, the mobile payment system 130 may further include a transaction code manager (not shown) to manage the transaction code stored in the database 240. The transaction code management unit (not shown) may change or delete the transaction code according to the transaction code state. For example, the transaction code management unit (not shown) may change the status code value included in the transaction code when the valid time of the transaction code elapses. For another example, the transaction code management unit (not shown) may delete the transaction code when the payment is completed.

Next, when the transaction code verification unit 240 receives the payment request including the transaction code and payment information from the second buyer terminal 112 through the communication unit 210, it determines the validity of the received transaction code. To this end, the transaction code verification unit 240 checks whether the transaction code received from the second buyer terminal 112 is recorded in the database 230.

The transaction code verification unit 240 may determine that the transaction code is valid when the transaction code received from the second buyer terminal 112 is recorded in the database 230.

In one embodiment, the transaction code verification unit 240 may determine that the transaction code is valid if the time when the transaction code is received from the second buyer terminal 112 is within the valid time range.

Next, the payment processing unit 250 processes the payment request of the second buyer terminal 112 according to the validity of the transaction code received from the second buyer terminal 112.

If it is determined that the transaction code is valid by the transaction code verification unit 240, the payment processor 250 requests a payment approval from the card company server 140. In this case, the payment approval request includes payment information and transaction information received from the second buyer terminal 112, where the transaction information is matched with a transaction code received from the second buyer terminal 112 in the database 230. Corresponds to the transaction information.

When the payment processing unit 250 receives the payment processing result from the card company server 140, the payment processing unit 250 transmits the payment processing result to the second buyer terminal 112 and the seller server 120 through the communication unit 210.

On the contrary, if it is determined by the transaction code verification unit 240 that the transaction code is not valid, the payment processor 250 requests the second purchaser terminal 112 to re-enter the transaction code or transmits a transaction code error message.

In one embodiment, the payment processing unit 250 may change the state of the corresponding transaction code or delete the corresponding transaction code according to the payment processing result received from the card company server 140. For example, when the payment processing unit 250 receives the payment processing result from the card company server 140, the payment processing unit 250 may change the state of the corresponding transaction code to the payment completion state.

Referring back to FIG. 1, the card company server 140 receives a payment approval request from the mobile payment system 130 and processes a payment according to the received payment approval request. When the payment is processed, the card company server 140 transmits the payment processing result to the mobile payment system 130.

Mobile transaction system 100 according to an embodiment of the present invention shown in Figure 1 is shown that the mobile payment system 130 and the card company server 140 is directly connected, in another embodiment a van (VAN) The company server (not shown) may relay between the mobile payment system 130 and the card company server 140. In this case, the bansa server (not shown) may be connected to the mobile payment system 130 and the plurality of card company servers 140 to transmit a payment approval request received from the mobile payment system 130 to the corresponding card company server 140. In addition, the bansa server (not shown) may receive the payment processing result for the payment approval request from the card company server 140 and transmit it to the mobile payment system 130.

In addition, the mobile transaction system 100 according to an embodiment of the present invention shown in Figure 1 is shown that the seller server 120 and the mobile payment system 130 is implemented by a separate operator, another implementation In an example, the seller server 120 may perform a function of the mobile payment system 130.

3 is a flowchart illustrating a mobile payment method according to an embodiment of the present invention.

Referring to FIG. 3, first, the first buyer terminal 111 transmits a purchase request for one or more products or services to the seller server 120 (S301). The first buyer terminal 111 may select one or more products or services from among the products or services sold by the seller server 120, and request the seller server 120 to purchase the selected products or services.

Next, the seller server 120 concludes a transaction according to the purchase request of the first buyer terminal 111, and transmits the transaction information and transaction code request for the transaction to the mobile payment system 130 (S302).

In this case, the transaction information includes seller information excluding buyer information and product or service information concluded between the seller and the buyer. Here, the seller information includes at least one of the trade name, address, contact information, and business number of the seller, and the product or service information includes the product name or service name, the manufacturer, the date of manufacture, the unit price of the product or service, the transaction quantity, and the transaction. Include at least one of the amounts.

Next, the mobile payment system 130 generates a transaction code (S303). The mobile payment system 130 generates a transaction code for identifying a transaction concluded between the seller and the buyer according to the transaction code request of the seller server 120. At this time, the transaction code is composed of at least one combination of numbers, letters, and symbols, and may be randomly generated.

In one embodiment, the transaction code may be generated by adding a serial number to the combination of numbers, letters, and symbols.

In one embodiment, the mobile payment system 130 may set the valid time of the transaction code when generating the transaction code. At this time, the transaction code may be valid only within a set validity time. The valid time of the transaction code may be arbitrarily set by the mobile payment system 130 or may be set to a value previously registered by the seller in the mobile payment system 130.

In one embodiment, the mobile payment system 130 may generate a transaction code including a status code. The status code indicates the status of a transaction code and may be represented by using at least one code string among a plurality of code strings. For example, the transaction code may indicate the state of the transaction code using the first code string of the plurality of code strings. At this time, the state of the transaction code may include a valid state and an invalid state.

Next, the mobile payment system 130 stores the generated transaction code in the database and transmits it to the seller server 120 (S304 and S305). The mobile payment system 130 matches the generated transaction code with the transaction information received from the seller server 120 and stores and manages it in the database. In this case, the transaction information includes seller information and product or service information.

On the other hand, the mobile payment system 130 may further include a valid time of the transaction code in the database. The mobile payment system 130 may change or delete the corresponding transaction code when the valid time of the transaction code elapses.

For example, it is assumed that the mobile payment system 130 generates the transaction code '012345' according to the transaction code request of the seller server 120 and sets the transaction code valid time to 1 minute.

According to an embodiment, if the first code string of the transaction code indicates a status code, the mobile payment system 130 may change the transaction code from '012345' to '112345' when one minute has elapsed. At this time, the status code value '1' may represent a state in which the valid time of the transaction code has elapsed.

According to another embodiment, if the transaction code does not include a status code, the mobile payment system 130 may delete the transaction code '012345' when one minute has elapsed.

Next, the seller server 120 transmits the transaction code received from the mobile payment system 130 to the first buyer terminal 111 (S306). The first buyer terminal 111 may display a transaction code transmitted from the seller server 120. Next, the second buyer terminal 112 may transmit a payment request including the transaction code and payment information to the mobile payment system ( 130) (S307).

In one embodiment, the second purchaser terminal 112 may download and install the first application for payment from the mobile payment system 130. The second purchaser terminal 112 may input a transaction code and payment information through the first application, and transmit a payment request including the input transaction code and payment information to the mobile payment system 130.

On the other hand, the second buyer terminal 112 may input the buyer's credit card information or mobile card information as payment information. Here, the credit card information is information about a conventional plastic credit card, and may include a 16-digit card unique number, a card expiration date, a 3-digit CVC (CVV) number, and a card password.

In addition, the mobile card information is information about a mobile card stored in a universal subscriber identity module (USIM) or a secure element (SEIM) installed in the second buyer terminal 112, and may be linked with a first application for payment. The mobile card may include one or more mobile credit card information and a password for security (PIN). Here, the password PIN may include a user password GPIN and a payment password LPIN to increase the security of the mobile payment.

Hereinafter, a specific example of performing a mobile payment using the transaction code and mobile card information in the second buyer terminal 112 will be described later.

4 is a diagram illustrating an example in which mobile payment is performed through an application for payment in a purchaser terminal.

Referring to FIG. 4, when the second buyer terminal 112 drives the first application for payment, first, the second buyer terminal 112 displays a transaction code as shown in FIG. 4A. In, and select the payment button.

When the payment button is selected, the second buyer terminal 112 displays the transaction information for the transaction corresponding to the transaction code, as shown in FIG. 4B. In more detail, the second buyer terminal 112 may transmit a transaction code and transaction information confirmation request to the mobile payment system 130 through the second application. In addition, the second purchaser terminal 112 may receive and display transaction information according to the transaction information confirmation request from the mobile payment system 130.

If the buyer checks the transaction information and then selects the OK button, the second buyer terminal 112 receives a user password GPIN from the buyer, as shown in FIG. 4C. The user password (GPIN) is for user authentication and may be set by the user when issuing a mobile card. In this case, the second purchaser terminal 112 may access the mobile credit card after the user password (GPIN) authentication.

If the user password (GPIN) authentication is successful, the second purchaser terminal 112 allows the purchaser to select one of a plurality of mobile credit cards stored in the mobile card, as shown in FIG. 4D. In one embodiment, the second buyer terminal 112 may preset a mobile credit card with a high frequency of use in order to increase the convenience of the buyer's selection.

When one mobile credit card is selected for payment, the second purchaser terminal 112 receives a payment password LPIN for the mobile credit card selected from the buyer, as shown in FIG. 4E. The payment password (LPIN) is for credit card authentication and, unlike the user password (GPIN), is set for each mobile credit card issued to the mobile card.

When the confirmation button is selected by the purchaser, the second purchaser terminal 112 transmits a payment request including a transaction code, mobile credit card information, and a payment password (LPIN) to the mobile payment system 130.

When the payment is successfully made in the mobile payment system 130, the second buyer terminal 112 receives the payment processing result from the mobile payment system 130, and as shown in FIG. 4F, the received payment processing result is received. Display.

Referring back to FIG. 3, the mobile payment system 130 determines the validity of the transaction code received from the second buyer terminal 112 (S308). To this end, the mobile payment system 130 checks whether the transaction code received from the second buyer terminal 112 is recorded in the database 230.

If the transaction code received from the second buyer terminal 112 is recorded in the database 230, the mobile payment system 130 may determine that the transaction code is valid.

In one embodiment, the mobile payment system 130 may determine that the transaction code is valid if the time when the transaction code is received from the second buyer terminal 112 is within the valid time range.

Next, the mobile payment system 130 processes the payment request according to the validity of the transaction code received from the second buyer terminal 112. If it is determined that the transaction code is valid, the mobile payment system 130 transmits a payment approval request to the card company server 140 (S309). At this time, the mobile payment system 130 transmits the transaction information and payment information received from the second buyer terminal 112 to the card company server 140 while requesting payment approval.

Next, the card company server 140 processes the payment based on the transaction information and payment information received from the mobile payment system 130, and transmits the payment processing result to the mobile payment system 130 (S310 and S311).

Next, the mobile payment system 130 transmits the payment processing result received from the card company server 140 to the seller server 120 and the second buyer terminal 112 (S312 and S313).

In the mobile payment method according to the exemplary embodiment illustrated in FIG. 3, the first purchaser terminal 111 and the second purchaser terminal 112 are separated from each other to perform different operations, but in another embodiment, the second purchaser terminal ( 112 may perform all operations performed by the first purchaser terminal 111. In this case, the second purchaser terminal 112 may download and install a second application for purchase from the seller server 120 in advance. The second purchaser terminal 112 may select one or more products or services through the second application, and request the seller server 120 to purchase the selected products or services. In one embodiment, when the transaction code received from the seller server 120 is touched or clicked, the second buyer terminal 112 may run the second application. In this case, the second purchaser terminal 112 may provide user convenience by automatically inputting the transaction code into the first application for payment. Hereinafter, a method of generating a transaction code in the mobile payment system 130 and mobile An embodiment of a method of performing payment will be described with a specific example. For convenience of explanation, it is assumed that the transaction code includes a status code indicating the status of the transaction code, and the first code string indicates the status code.

At this time, the state of the transaction code includes a valid state and an invalid state, and furthermore, the invalid state is a state in which the valid time has elapsed, a state in which the transaction code is received from the purchaser terminal 110 and the validity thereof is confirmed, and the payment is successfully Processed status, and payment failed.

5 is a flowchart illustrating an embodiment of a transaction code generation method performed in a mobile payment system.

Referring to FIG. 5, when the mobile payment system 130 receives a transaction information and a transaction code request for a transaction concluded between a seller and a buyer from a seller server 120, the mobile payment system 130 generates a transaction code for the transaction at the same time. The valid time is set (S501 and S502).

The mobile payment system 130 sets a status code as a valid state value when generating a transaction code. For example, the mobile payment system 130 may generate a transaction code '012345' according to the transaction code request of the seller server 120 and set the valid time of the transaction code to 1 minute. At this time, the status code value '0' indicates a valid state.

The mobile payment system 130 checks whether the generated transaction code is valid in the database (S503).

If there is a transaction code that is identical to the generated transaction code among the transaction codes stored in the database and the state is valid, the mobile payment system 130 regenerates the transaction code.

On the contrary, if not present, the mobile payment system 130 matches the generated transaction code with the transaction information, stores it in the database, and transmits it to the seller server 120 (S504 and S505).

6 is a flowchart illustrating a specific example of a mobile payment method using a transaction code performed in a mobile payment system.

Referring to FIG. 6, when the valid time of a transaction code stored in the database has elapsed, the mobile payment system 130 changes the status code of the corresponding transaction code from an effective state value to an invalid state value (S601 and S602).

For example, when the valid time of the transaction code '012345' stored in the database has elapsed, the mobile payment system 130 may change the transaction code to '112345'. At this time, the status code value '1' may indicate an invalid state, in particular, a state in which the valid time has elapsed.

Next, when the mobile payment system 130 receives the transaction code and payment information from the purchaser terminal 110, it determines the validity of the received transaction code (S603 and S604). The mobile payment system 130 checks whether the transaction code received from the purchaser terminal 110 exists in the database.

If the transaction code received from the purchaser terminal 110 exists in the database 230, the mobile payment system 130 may determine that the transaction code is valid.

For example, when the mobile payment system 130 receives the transaction code '012345' from the buyer terminal 110, the mobile payment system 130 may check whether the transaction code '012345' is recorded in the database. At this time, if the transaction code '012345' is recorded in the database, the mobile payment system 130 will determine that the transaction code '012345' is valid. On the other hand, if the transaction code '012345' recorded in the database is already changed to '112345' after the valid time has elapsed, the mobile payment system 130 will determine that the transaction code '012345' is not valid.

Next, if it is determined that the transaction code received from the purchaser terminal 110 is not valid, the mobile payment system 130 transmits a transaction code error message to the purchaser terminal 110 (S604 and S605).

On the other hand, if it is determined that the transaction code received from the purchaser terminal 110 is valid, the mobile payment system 130 changes the status code of the corresponding transaction code into an invalid state value and transmits a payment approval request to the card company server 140. (S606 and S607).

The mobile payment system 130 changes the status code of the corresponding transaction code from the valid state value to the invalid state value.

For example, if a transaction code identical to the transaction code '012345' stored in the database is received from the purchaser terminal 110 and its validity is confirmed, the mobile payment system 130 may change the transaction code to '212345'. . In this case, the status code value '2' may indicate an invalid state, in particular, a state in which a transaction code is received from the purchaser terminal 110 and its validity is confirmed. Accordingly, the mobile payment system 130 may perform the payment only once even if the same transaction code is repeatedly received from the purchaser terminal 110 within a predetermined time. The predetermined time may correspond to a time from when the transaction code is received until the settlement of the corresponding transaction code is completed.

Next, when the mobile payment system 130 receives the payment processing result from the card company server 140, the mobile payment system 130 changes the state of the corresponding transaction code to the payment completion state, and changes the payment processing result to the seller server 120 and the buyer terminal 110. (S608, S609, and S610).

For example, when the payment processing result for the transaction code '012345' is received from the card company server 140, the mobile payment system 130 may change the transaction code to '312345' or '412345' according to the payment processing result. . At this time, the status code value '3' may indicate a state in which payment has been successfully processed, and the status code value '4' may indicate a state in which the payment has failed. Accordingly, the mobile payment system 130 may manage the processing result for each transaction.

Although FIG. 6 illustrates that S601 and S602 are performed before receiving a transaction code from the purchaser terminal 110, the mobile payment system 130 according to another embodiment deals with S601 and S602 from the purchaser terminal 110. You can also do it after receiving the code. In more detail, when the mobile payment system 130 receives the transaction code from the purchaser terminal 110, the mobile payment system 130 may determine the validity of the received transaction code. In this case, the mobile payment system 130 may determine that the transaction code is valid if the transaction code received from the purchaser terminal 110 is recorded in the database and the received time is within the valid time range. On the other hand, the mobile payment system 130 may determine that the transaction code is invalid when the transaction code received from the purchaser terminal 110 is not recorded in the database or the received time exceeds the valid time. In particular, when the transaction code received from the purchaser terminal 110 exceeds the valid time, the mobile payment system 130 changes the status code of the corresponding transaction code recorded in the database from the valid state value to the invalid state value. Can be.

The functions performed by the mobile payment system described above may be implemented in the form of program instructions that can be executed by various computer means, and recorded in a computer-readable recording medium. At this time, the computer-readable recording medium may include program commands, data files, data structures, and the like, alone or in combination. On the other hand, the program instructions recorded on the recording medium may be those specially designed and configured for the present invention or may be available to those skilled in the art of computer software.

Those skilled in the art to which the present invention pertains will understand that the above-described present invention can be implemented in other specific forms without changing the technical spirit or essential features.

It is therefore to be understood that the above-described embodiments are illustrative in all aspects and not restrictive. The scope of the present invention is defined by the appended claims rather than the detailed description and all changes or modifications derived from the meaning and scope of the claims and their equivalents are to be construed as being included within the scope of the present invention do.

100: mobile transaction system 110: buyer terminal
120: seller server 130: mobile payment system
140: card company server 210: communication unit
220: transaction code generation unit 230: database
240: transaction code verification unit 250: payment processing unit

Claims

In the mobile payment method performed in the mobile payment system that can be connected to the buyer terminal and the seller server,
Generating a transaction code when receiving transaction information for a transaction of a product or service concluded between a seller and a buyer and a transaction code request for identification of the transaction from the seller server;
Transmitting the generated transaction code to the seller server, and matching the generated transaction code with the transaction information and storing it in a database;
Determining a validity of the received transaction code when receiving a payment request including the transaction code and payment information from the purchaser terminal; And
Processing the payment request according to the validity of the transaction code;
The transaction information is a mobile payment method including the seller information and the traded product or service information, except the buyer information.

The method of claim 1,
In the determining,
And if the transaction code received from the purchaser terminal is recorded in the database, determine the transaction code as valid.

The method of claim 1,
In the generating step, setting the valid time of the transaction code when generating the transaction code,
In the determining step, if the transaction code received from the purchaser terminal is within the valid time range, the mobile payment method characterized in that it is determined to be valid.

The method of claim 1,
The transaction code includes a status code indicating the state of the transaction code,
In the generating step, when generating the transaction code, the mobile payment method characterized in that for setting the status code to a valid state value.

5. The method of claim 4,
And when the valid time of the transaction code elapses, changing the status code from the valid state value to an invalid state value.

5. The method of claim 4,
In the determining,
And if it is determined that the received transaction code is valid, changing the status code from the valid status value to an invalid status value.

The method of claim 1, wherein processing the payment request
If it is determined that the transaction code is valid, requesting payment approval from a van company server or a card company server based on the payment information and the transaction information matched with the transaction code; And
And receiving the payment processing result from the bansa server or the card company server and transmitting the result to the seller terminal and the purchaser terminal.

The method of claim 1, wherein processing the payment request
And if it is determined that the transaction code is not valid, transmitting a transaction code error message to the purchaser terminal.

The method of claim 1,
Retrieving the transaction code from the database upon receiving the transaction code and transaction information confirmation request from the buyer terminal; And
The mobile payment method of claim 1, further comprising transmitting transaction information matched with the transaction code to the purchaser terminal.

The method of claim 1,
The transaction code is a mobile payment method, characterized in that consisting of at least one combination of numbers, letters, and symbols.