TWI775820B - Mobile payment subauthorization method and payment system realized by the method - Google Patents

Abstract

The invention relates to a mobile payment authorization method and a system thereof. The method includes the following steps: binding a payment account to the main user terminal; logging in to the server by the main user terminal and the slave user terminal respectively, the main user terminal sending a sub-authorization request to the server; and the server verifying the sub-authorization request , after passing the verification, issue the Token and the transaction key to the slave user terminal; and the slave user terminal realizes payment according to the Token and the transaction key. According to the present invention, trust-based mobile payment transfer authorization between family members and friends can be realized, and Token and transaction key can be used to ensure the security of the transaction. At the same time, the user does not need to enter a password when making payment, which is fast and convenient, and has a good user experience. . On the other hand, the client mobile phone can conduct payment transactions without being connected to the Internet.

Description

Mobile payment subauthorization method and payment system realized by the method

The invention relates to computer communication technology, in particular to a mobile payment sub-authorization method based on a payment token (Token), a payment system, a mobile terminal and a server realized by using the mobile payment sub-authorization method.

Existing mainstream payment methods all require a password to verify the user's identity to realize payment. This has the following disadvantages,

First, the user needs to enter a password to pay, the payment process is troublesome, and the user experience is poor.

Second, mobile payment needs to bind your own bank card, and cannot realize shared bank card payment between families or friends.

Third, the user account password may be stolen, bringing security risks.

In view of the above problems, the purpose of the present invention is to propose a trust-based mobile payment transfer authorization method between family members or friends under the premise of ensuring payment security, and use the method Implemented mobile payment sub-authorization system.

The mobile payment authorization method of the present invention is realized by the master user terminal, the slave user terminal, the server and the merchant terminal, and the method includes the following steps: a binding step, the master user terminal is bound to a payment account; a sub-authorization request Proposing steps, the main user terminal and the slave user terminal log in to the server respectively, and the main user terminal sends a sub-authorization request to the server; in the sub-authorization request verification step, the server verifies the sub-authorization request, and after passing the verification, issues a sub-authorization request. The Token is given to the slave user terminal; and the sub-authorization payment step is performed, and the slave user terminal realizes payment according to the Token and the transaction key.

Preferably, in the sub-authorization request, the main user terminal presets one or more of the authorization limit amount, the authorization limit time, the authorization limit location, the authorization limit merchant, and whether transaction confirmation is required.

Preferably, the sub-authorization request verification step includes the following sub-steps: the server checks the sub-authorization request; Tokens and transaction keys are stored in the secure element or in the cloud.

Preferably, the sub-authorization payment step includes the following sub-steps Step: When making a payment transaction from the user terminal, use the cloud or local security element to generate a Token instead of PAN, use the Token to use a transaction key for each transaction, and convert the transaction elements (including Token, transaction amount, merchant number, Terminal number and other information) are encrypted to form transaction ciphertext, and consumer transactions are carried out at the transaction terminal; the merchant terminal sends the transaction information including the current consumption location, merchant number, transaction amount, transaction Token, and transaction ciphertext to the server; the server Verify the transaction Token, decrypt the transaction ciphertext information, and verify the legitimacy of the transaction identity; in the case of successful verification, the server returns the verification success to the merchant terminal and completes the payment.

Preferably, in the sub-step of the server verifying the transaction Token, the server verifies the transaction Token and determines whether one or more of the transaction amount, transaction time, transaction location, and transaction merchant are included in the sub-authorization request as needed. preset.

Preferably, in the sub-step of the server verifying the transaction Token, it further includes: the server sends the transaction information to the main user terminal for transaction confirmation, and when the main user terminal confirms that the transaction can be executed, the server returns to the merchant terminal. Verification succeeded.

The mobile payment sub-authorization system of the present invention is characterized in that the system is provided with: a main user terminal for binding with the payment account and for submitting a sub-authorization request to the following server; From the user terminal, it is used to receive the Token and transaction key sent by the following server, store it in the security unit or in the cloud, and use the Token in combination with the transaction key to conduct transactions; the server, used for Check the sub-authorization request from the master user terminal and generate a Token and a transaction key under the condition of passing the check and issue it to the slave user terminal, which is used to verify the slave user terminal when making transaction payment. The transaction Token and the transaction cipher text sent by the user terminal, and the transaction is completed when the verification is passed; and the merchant terminal, when the user terminal consumes at the merchant terminal, it is used to include the transaction from the user terminal in the future. The transaction information of Token, merchant number, transaction amount, and transaction ciphertext is submitted to the server.

Preferably, the master user terminal sets one or more of the authorization limit amount, the authorization limit time, the authorization limit location, and the authorization limit merchant in the sub-authorization request.

Preferably, the merchant terminal is provided with: an LBS module for acquiring the transaction location where the transaction is generated; and a communication module for uploading the transaction location and transaction information generated by the transaction to the server.

Preferably, the server is provided with: a Token authorization module for generating a Token and a transaction key, and issuing the Token and the transaction key to the slave user terminal; and a position calculation module for calculating The distance between the transaction location and the authorization-restricted location is compared to whether the conditions for the authorization-restricted location set in the sub-authorization request are met.

Preferably, the Token authorization module is further used for this Token sets a certain life cycle.

Preferably, the main user terminal sets in the sub-authorization request whether transaction confirmation is required, and in the case that the transaction confirmation is required, the server forwards the relevant transaction information to the main user terminal and the main The user terminal makes the confirmation, and the transaction is only allowed after confirmation through the main user terminal.

The mobile terminal of the present invention is characterized in that the mobile terminal is used to receive the Token and the transaction key sent by the server, store the Token and the transaction key in the security unit or in the cloud, and use the Token to combine the transaction key to trade.

The server of the present invention is used to realize the authorization of sub-payment from the main user terminal to the user terminal, and is characterized in that it is used to check the sub-authorization request from the main user terminal and generate Token and transaction under the condition of passing the check. The key is issued to the slave user terminal, and is used to verify the transaction Token and transaction ciphertext sent from the slave user terminal when the transaction payment is performed, and the transaction payment is completed when the verification is passed.

Preferably, the server of the present invention is provided with: a Token authorization module for generating a Token and a transaction key, and issuing the Token and the transaction key to a slave user terminal; and a position calculation module for calculating the transaction The distance between the location and the authorized-restricted location is compared to whether it complies with the conditions for the authorized restricted location set in the sub-authorization request.

According to the present invention, it is possible to use from the master user terminal to the slave The user terminal can perform mobile payment sub-authorization, thereby realizing trust-based mobile payment sub-authorization between family members and friends. Among them, the Token and the transaction key can be used to realize the transaction, thereby ensuring the security of the transaction. Moreover, the user does not need to enter a password when making payment, which is fast and convenient, and provides a good user experience. On the other hand, since multiple tokens and multiple transaction keys can be received and stored in advance from the user terminal, payment transactions can be performed from the user terminal without being connected to the Internet.

100: main user terminal

200: from the user terminal

300: Server

310:Token authorization module

320: Position calculation module

400: Merchant Terminal

410: Communication module

420: LBS module

FIG. 1 is a flow chart showing the mobile payment sub-authorization method of the present invention.

FIG. 2 is a flowchart showing an embodiment of the mobile payment subauthorization method of the present invention.

FIG. 3 is a block diagram showing the configuration of an embodiment of the mobile payment deauthorization system of the present invention.

Introduced below are some of the various embodiments of the present invention and are intended to provide a basic understanding of the present invention. It is not intended to identify key or critical elements of the invention or to delineate the scope of what is claimed.

First, some terms that appear in the present invention will be explained.

Card simulation technology is a technology that simulates the NFC terminal as a card as a whole and accepts access from the card reader.

Token technology means that after the Token SP generates the Token according to the PAN (main account) provided by the Token Requestor, the Token is used as the substitute value of the PAN to circulate in all aspects of the payment, so that in the payment process, the unique PAN is only in the Token SP, the transfer Since the three parties are connected by dedicated lines and trust each other, and when the Token is detected as a risk or expires, a new Token will be generated to replace it, which greatly reduces the possibility of PAN leakage during the payment process and greatly improves PAN security.

LBS location service, also known as Location Based Service (LBS), obtains the location information (latitude and longitude coordinates) of mobile terminal users through the network of telecom mobile operators (eg GSM network, CDMA network).

PAN refers to the main account number of the bank card issued by the bank, which is generally composed of the identity of the card issuer, the identity of the personal account and the check digit.

HCE (host-based card emulation) refers to host-based card emulation, which implements card emulation on mobile terminals equipped with NFC functions.

First, the mobile payment subauthorization method of the present invention will be described.

FIG. 1 is a flow chart showing the mobile payment sub-authorization method of the present invention.

As shown in FIG. 1 , the mobile payment authorization method of the present invention is implemented by a master user terminal, a slave user terminal, a server and a merchant terminal, and the method includes the following steps: Binding step S100: binding the master user terminal Payment account; sub-authorization request submission step S200: master user terminal, slave user The terminals log in to the server respectively, and the main user terminal sends a sub-authorization request to the server. In the sub-authorization request, the main user terminal can set the authorization limit amount, authorization limit time, authorization limit location, and authorization limit merchant according to the needs. and so on, it is also possible to set whether transaction confirmation is required as needed; sub-authorization request verification step S300: the server verifies the sub-authorization request, and after passing the verification, issues a Token and a transaction key to the slave user terminal at one time; Authorizing payment step S400: using the Token and the transaction key from the user terminal to realize payment, wherein the user terminal stores the Token and transaction key in its secure element (SE) or in the cloud, and performs payment from the user terminal. During the payment transaction, the cloud or local security element (SE) generates a Token, and the Token is used to conduct consumption transactions on the transaction terminal that supports the cloud flash payment on the merchant side. The merchant terminal will include the current consumption location, merchant number, transaction amount, and transaction Token, Relevant consumption information, including transaction cipher text, is sent to the server, and the server verifies the transaction Token and transaction cipher text, and completes the payment if the verification is successful.

Next, specific application embodiments of the mobile payment sub-authorization method of the present invention will be described.

FIG. 2 is a flowchart showing an embodiment of the mobile payment subauthorization method of the present invention.

The mobile payment sub-authorization method of this embodiment is implemented by the master user terminal 100 , the slave user terminal 200 , the server 300 and the merchant terminal 400 .

As shown in Figure 2, a mobile payment subauthorization method according to an embodiment of the present invention includes the following specific steps:

主使用者終端100通過例如移動支付應用等綁定支付帳戶(例如，銀行卡、支付卡、消費卡等)。

The main user terminal 100 binds a payment account (eg, bank card, payment card, consumption card, etc.) through, for example, a mobile payment application.

主使用者終端100、從使用者終端200分別登錄到伺服器300。

The master user terminal 100 and the slave user terminal 200 log in to the server 300, respectively.

主使用者終端100向伺服器300發出轉授權請求，以允許從使用者終端200通過能夠使用主使用者終端100的支付功能，其中，在轉授權請求中，主使用者終端100可以根據需要來設定授權限定金額、授權限定時間、授權限定地點、授權限定商戶等，也可以根據需要來設定是否需要交易確認。

The master user terminal 100 sends a sub-authorization request to the server 300 to allow the slave user terminal 200 to use the payment function of the master user terminal 100. Set the authorization limit amount, authorization limit time, authorization limit location, authorization limit merchant, etc. You can also set whether transaction confirmation is required according to your needs.

伺服器300對於轉授權請求的相關資訊進行核對，在通過核對後，一次性頒發Token和交易金鑰給從使用者終端200(該臨時Token對應於主使用者終端100所綁定的支付帳號)，從使用者終端200將Token和交易金鑰儲存在其安全元件(SE)裡或者儲存在雲端，此時從使用者終端200具有支付功能。根據主使用者終端100的設定，具有Token的從使用者終端100的支付交易具有授權限定金額、授權限定時間、授權限定地點、授權限定商戶等的各類限制範圍，如果超越限制範圍，從使用者終端200將失去支付功能。

The server 300 verifies the relevant information of the sub-authorization request, and after the verification, issues a Token and a transaction key to the secondary user terminal 200 at one time (the temporary Token corresponds to the payment account bound to the primary user terminal 100) , the slave user terminal 200 stores the Token and the transaction key in its secure element (SE) or in the cloud. At this time, the slave user terminal 200 has a payment function. According to the settings of the master user terminal 100, the payment transaction of the slave user terminal 100 with Token has various restrictions such as authorized limited amount, authorized limited time, authorized limited location, authorized limited merchants, etc. The user terminal 200 will lose the payment function.

從使用者終端200進行支付交易時，雲端或者本地安全元件(SE)產生一個Token，透過HCE(host- based cardemulation)或者SE(Secure Element)，在商戶側支援雲閃付的交易終端400進行消費交易。另外，通常雲端會提前產生一個以上Token，以便使用者在設備未聯網時仍可使用HCE支付。

When a payment transaction is performed from the user terminal 200, the cloud or local secure element (SE) generates a Token, and through HCE (host-based cardemulation) or SE (Secure Element), the transaction terminal 400 that supports cloud flash payment on the merchant side conducts consumption trade. In addition, usually the cloud will generate more than one Token in advance, so that users can still use HCE to pay when the device is not connected to the Internet.

商戶終端400將包括目前消費位置、商戶號、交易金額以及交易Token、交易密文等在內的相關消費資訊傳送至伺服器300。

The merchant terminal 400 transmits relevant consumption information including the current consumption location, merchant number, transaction amount, transaction Token, transaction ciphertext, etc. to the server 300 .

伺服器300驗證交易Token和交易密文，並根據需要來判斷交易金額、交易時間、交易地點、交易商戶是否符合授權限定金額、授權限定時間、授權限定地點、授權限定商戶等。

The server 300 verifies the transaction Token and the transaction ciphertext, and determines the transaction amount, transaction time, transaction location, and whether the transaction merchant meets the authorized limit amount, authorization limit time, authorization limit location, authorized limit merchant, etc. as required.

根據需要可選地進行交易確認，伺服器300發送交易資訊給主使用者終端100進行交易確認。

Optionally perform transaction confirmation as required, and the server 300 sends transaction information to the main user terminal 100 for transaction confirmation.

驗證成功的情況(可選地包含交易確認成功的情況)下，伺服器300向商戶終端400返回驗證成功並完成支付。

In the case of successful verification (optionally including the case of successful transaction confirmation), the server 300 returns the verification success to the merchant terminal 400 and completes the payment.

In the present invention, in order to solve the problem of card number information leakage, Token replaces the card number with a virtual number string of 13 to 19 bits. The server 300 issues a Token and a transaction key to the slave user terminal 200. Through the transaction key, a transaction ciphertext is calculated for each card swiping transaction, which is used to confirm the legitimacy of the transaction identity. Through the combination of Token and transaction key, transaction security is realized.

FIG. 3 is a block diagram showing the configuration of an embodiment of the mobile payment deauthorization system of the present invention.

As shown in FIG. 3 , the mobile payment sub-authorization system of the present invention includes a master user terminal 100 , a slave user terminal 200 , a server 300 and a merchant terminal 400 .

The main user terminal 100 refers to the mobile payment device of the main user, for example, it can be a smart phone, a tablet computer or a wearable device, etc. It can include a payment APP and bind a payment account (for example, a bank card, a payment card, etc.), User login and subsequent payment transfer authorization can be realized by using the payment APP. The main user terminal 100 is used for binding a payment account and for submitting a sub-authorization request to the server 300 . The main user terminal 100 can set one or more of the authorization limit amount, the authorization limit time, the authorization limit location, the authorization limit merchant, etc. in the sub-authorization request according to the needs, and also can set whether the transaction confirmation is required according to the needs. .

The slave user terminal 200 refers to the user's mobile device, which is installed with a payment APP, such as a smart phone, a tablet computer or a wearable device, etc., to receive the Token certificate sent from the server 300 (or stored in the cloud), Complete the payment. Receive the Token and the transaction key sent by the server 300 from the user terminal 200, store the Token and the transaction key in the security unit or in the cloud, and use the Token and the transaction key to conduct transactions.

The server 300 is used to check the sub-authorization request from the master user terminal 100 and generate a Token and a transaction key under the condition of passing the check and issue it to the slave user terminal 200, which is used to verify the slave user terminal 200 when making transaction payment. The transaction Token and the transaction ciphertext sent from the user terminal 200 and the transaction payment is completed when the verification is passed.

The server 300 includes: a token authorization module 310 and a position calculation module 320, wherein the position calculation module 320 is an optional module.

The Token authorization module 310 is used to generate a Token and a transaction key, bind the Token to the card number corresponding to the master transaction terminal, and authorize the Token to the slave user terminal 200 . Further, the token authorization module 310 can also set a certain life cycle for the token.

The location calculation module 320 is used for calculating the distance between the transaction location and the authorization-restricted location, and compares whether the conditions for the authorization-restricted location set in the sub-authorization request are met.

The merchant terminal 400 may be, for example, a terminal device such as a merchant's POS machine. The merchant terminal 400 includes a communication module 410 and an LBS function module 420, wherein the LBS function module 420 is an optional module. The communication module 410 is used for uploading the transaction location (optional) and transaction information generated by the transaction to the server 300 . The LBS module 420 is used to detect where the transaction takes place.

According to the present invention, mobile payment transfer authorization can be performed from the master user terminal to the slave user terminal, thereby realizing trust-based mobile payment transfer authorization among family members and friends. Among them, the Token and the transaction key can be used to realize the transaction, thereby ensuring the security of the transaction. Moreover, the user does not need to enter a password when making payment, which is fast and convenient, and provides a good user experience. On the other hand, since multiple tokens and transaction keys can be received and stored in advance from the user terminal, payment transactions can be performed from the user terminal without being connected to the Internet.

The above examples mainly illustrate the mobile payment transfer authorization method of the present invention, the payment system realized by using the mobile payment transfer authorization method, and the mobile payment transfer authorization method. Mobile terminal and server. Although only a few of these specific embodiments of the present invention have been described, it will be understood by those of ordinary skill in the art that the present invention may be embodied in many other forms without departing from the spirit and scope thereof. Accordingly, the examples and embodiments shown are to be regarded as illustrative and not restrictive, and the present invention may encompass a variety of Modification and replacement.

Claims (12)

A mobile payment authorization method is implemented by a master user terminal, a slave user terminal, a server and a merchant terminal. The method includes the following steps: a binding step, the master user terminal is bound to a payment account; a sub-authorization request is submitted. , the main user terminal and the slave user terminal log in to the server respectively, and the main user terminal sends a sub-authorization request to the server; in the sub-authorization request verification step, the server verifies the sub-authorization request, and after passing the verification, issues multiple Token and a plurality of transaction keys are given to the slave user terminal; and the sub-authorization payment step, the slave user terminal uses the Token and the transaction key to realize payment, wherein, for each transaction, the Token is used instead of the PAN, and the slave user terminal uses the Token and the transaction key to realize payment. The terminal uses a transaction key to calculate a transaction ciphertext for confirming the legitimacy of the transaction identity, and uses the Token to perform consumption transactions at the merchant terminal that supports the cloud flash payment transaction terminal. In the verification step of the sub-authorization request, the server The sub-authorization request from the master user terminal is checked, and when the check is passed, multiple Tokens and multiple transaction keys are generated at one time and issued to the slave user terminal, and wherein the server generates Tokens and transactions. key, issue the Token and transaction key to the slave user terminal, and calculate the transaction location and authorization The distance between restricted locations is compared to whether they meet the conditions set in the sub-authorization request for authorized restricted locations. The mobile payment authorization method according to claim 1, wherein, in the sub-authorization request, the main user terminal presets one of the authorization limit amount, authorization limit time, authorization limit location, authorization limit merchant, and whether transaction confirmation is required. item or multiple items. The mobile payment authorization method according to claim 2, wherein the sub-authorization request verification step includes the following sub-steps: the server checks the sub-authorization request; after passing the verification, a Token and multiple transaction keys are issued at one time To the slave user terminal; and from the user terminal to store the Token and the transaction key in the secure element or in the cloud. The mobile payment authorization method according to claim 3, wherein the sub-authorization payment step includes the following sub-steps: when the user terminal performs the payment transaction at the transaction terminal, the Token on the cloud or the local security element is used instead of the PAN, and each The transaction uses a transaction key, encrypts the Token, transaction amount, merchant number, and terminal number as transaction elements to form a transaction ciphertext, and sends the merchant terminal for consumption transaction; the merchant terminal will include the current consumption location, merchant number, transaction amount to and transaction Token and transaction ciphertext transaction information are sent to the server; the server verifies the transaction Token, decrypts the transaction ciphertext information, and verifies and confirms the legitimacy of the transaction identity; and if the verification is successful, the server returns the verification to the merchant terminal Successful and completed payment. The mobile payment authorization method according to claim 4, wherein, in the sub-step of the server verifying the transaction Token, the server verifies the transaction Token and determines one of the transaction amount, transaction time, transaction location, and transaction merchant as needed Whether or not multiple items are preset in the sub-authorization request. The mobile payment authorization method according to claim 5, wherein, in the sub-step of the server verifying the transaction Token, it further comprises: the server sending transaction information to the main user terminal for transaction confirmation, and confirming the transaction at the main user terminal In the case of execution, the server returns the verification success to the merchant terminal. A mobile payment sub-authorization system, the system is provided with: a main user terminal for binding with a payment account and for submitting a sub-authorization request to the following server; a slave user terminal for receiving the following server The sent Token and transaction key are stored in the secure unit or in the cloud, and the Token and transaction key are used to conduct transactions; The server is used to check the sub-authorization request from the master user terminal and generate multiple Tokens and multiple transaction keys under the condition of passing the check and issue them to the slave user terminal, when making transaction payment It is used to verify the transaction Token and the transaction ciphertext sent from the user terminal and complete the transaction if the verification is passed; and the merchant terminal, when the slave user terminal consumes at the merchant terminal, is used for future use from the user terminal. The user terminal submits transaction information including transaction Token, merchant number, transaction amount, and transaction ciphertext to the server. It is characterized in that, for each transaction, the Token is used instead of the PAN, and a transaction key is used from the user terminal to calculate a The transaction ciphertext is used to confirm the legitimacy of the transaction identity, and the Token is used to conduct consumption transactions at the transaction terminal of the merchant terminal that supports the cloud flash payment. The Token and the transaction key are issued to the slave user terminal; and the location calculation module is used to calculate the distance between the transaction location and the authorized restricted location, and compare whether it conforms to the relevant authorized restricted location set in the sub-authorization request. conditions of. The mobile payment sub-authorization system according to claim 7, wherein the main user terminal sets one or more of the authorization limit amount, authorization limit time, authorization limit location, authorization limit merchant, etc. in the sub-authorization request. The mobile payment subauthorization system according to claim 8, wherein the merchant terminal is provided with: an LBS module for acquiring the transaction location where the transaction is generated; and a communication module for uploading the transaction location and transaction information generated by the transaction to the server. The mobile payment sub-authorization system according to claim 9, wherein the Token authorization module is further configured to set a certain life cycle for the Token. The mobile payment sub-authorization system according to claim 9, wherein the main user terminal sets in the sub-authorization request whether transaction confirmation is required, and in the case that the transaction confirmation is required, the server sends the relevant transaction information Forwarded to and confirmed by the main user terminal, the transaction is only allowed after confirmation by the main user terminal. A server is used to realize the authorization of sub-payment from the main user terminal to the user terminal. A Token and multiple transaction keys are issued to the slave user terminal, which is used to verify the transaction Token and transaction ciphertext sent from the slave user terminal when making transaction payment, and complete the transaction payment when the verification is passed. Among them, the server has: a Token authorization module, which is used to generate a Token and a transaction key, and issue the Token and transaction key to the slave user terminal; and a location calculation module, which is used to calculate the transaction location and authorization restrictions. The distance between the locations is compared to whether they meet the conditions set in the sub-authorization request regarding the authorized location.

Images