WO2018166359A1 - 移动支付转授权方法、及利用该方法实现的支付*** - Google Patents

移动支付转授权方法、及利用该方法实现的支付*** Download PDF

Info

Publication number
WO2018166359A1
WO2018166359A1 PCT/CN2018/077845 CN2018077845W WO2018166359A1 WO 2018166359 A1 WO2018166359 A1 WO 2018166359A1 CN 2018077845 W CN2018077845 W CN 2018077845W WO 2018166359 A1 WO2018166359 A1 WO 2018166359A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
user terminal
token
server
payment
Prior art date
Application number
PCT/CN2018/077845
Other languages
English (en)
French (fr)
Inventor
孙权
Original Assignee
***股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ***股份有限公司 filed Critical ***股份有限公司
Publication of WO2018166359A1 publication Critical patent/WO2018166359A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management

Definitions

  • the present invention relates to computer communication technologies, and in particular, to a mobile payment transfer authorization method based on a payment token (Token), a payment system implemented by the mobile payment transfer authorization method, a mobile terminal, and a server.
  • Token payment token
  • the user needs to input a password to pay, the payment process is troublesome, and the user experience is poor.
  • the user account password may be stolen, posing a security risk.
  • an object of the present invention is to provide a trust-based mobile payment transfer authorization method between family members or friends and a mobile payment transfer authorization system realized by the method under the premise of ensuring payment security. .
  • the mobile payment authorization method of the present invention is implemented by a primary user terminal, a user terminal, a server, and a merchant terminal, and the method includes the following steps:
  • Binding step the primary user terminal is bound to the payment account
  • the authorization request requesting step, the main user terminal and the user terminal respectively log in to the server, and the main user terminal sends a transfer authorization request to the server;
  • the server verifies the transfer authorization request, and after verification, issues a token to the slave user terminal;
  • payment is implemented from the user terminal based on the Token and the transaction key.
  • the primary user terminal presets one or more of an authorization limited amount, an authorization limited time, an authorized limited place, an authorized limited merchant, and whether a transaction confirmation is required.
  • the transfer authorization request verification step comprises the following sub-steps:
  • the Token and transaction keys are saved from the user terminal in a secure element or saved in the cloud.
  • the merchant terminal sends the transaction information including the current consumption location, the merchant number, the transaction amount, and the transaction token and the transaction ciphertext to the server;
  • the server verifies the transaction token, decrypts the transaction ciphertext information, and verifies the validity of the transaction identity; in the case of successful verification, the server returns the verification success to the merchant terminal and completes the payment.
  • the server verifies the transaction token and determines, according to the need, whether one or more of the transaction amount, the transaction time, the transaction location, and the transaction merchant are pre-set in the transfer authorization request. set.
  • the method further comprises: the server sending the transaction information to the main user terminal for confirming the transaction, and in the case that the main user terminal confirms that the transaction is executable, the server returns the verification success to the merchant terminal.
  • a primary user terminal for binding with a payment account and for submitting a delegation authorization request to a server described below;
  • a server configured to check the transfer authorization request from the primary user terminal and generate a Token and a transaction key in the case of verification and deliver the token and the transaction key to the slave user terminal, and use it to verify the transaction when performing transaction payment Describe the transaction token and transaction ciphertext sent from the user terminal and complete the transaction if the verification passes;
  • the merchant terminal is configured to submit transaction information from the user terminal including the transaction token, the merchant number, the transaction amount, and the transaction ciphertext to the server when the slave user terminal consumes at the merchant terminal.
  • the primary user terminal sets one or more of an authorized limited amount, an authorized limited time, an authorized limited place, an authorized limited merchant, and the like in the transfer authorization request.
  • the merchant terminal has:
  • LBS module for obtaining the trading location where the transaction is generated
  • a communication module configured to upload a transaction place and transaction information generated by the transaction to the server.
  • the server is provided with: a Token authorization module, configured to generate a Token and a transaction key, and send the Token and the transaction key to the slave user terminal; and a location calculation module, configured to calculate a transaction location and an authorization limit The distance between the locations, whether the comparison meets the conditions for the authorized location defined in the transfer authorization request.
  • a Token authorization module configured to generate a Token and a transaction key, and send the Token and the transaction key to the slave user terminal
  • a location calculation module configured to calculate a transaction location and an authorization limit The distance between the locations, whether the comparison meets the conditions for the authorized location defined in the transfer authorization request.
  • the primary user terminal sets whether a transaction confirmation is required in the transfer authorization request, and if the transaction confirmation is required, the server forwards the information about the transaction to the primary user terminal and confirms by the primary user terminal.
  • the transaction is allowed only after confirmation by the primary user terminal.
  • the Token and the transaction key are sent to the slave user terminal for verifying the transaction token and the transaction ciphertext sent from the slave user terminal when the transaction payment is made and completing the transaction payment if the verification is passed.
  • the server of the present invention is provided with:
  • a Token authorization module configured to generate a Token and a transaction key, and send the Token and the transaction key to the slave user terminal;
  • a location calculation module configured to calculate a distance between the transaction location and the authorized restriction location, and whether the comparison meets the condition for the authorized authorized location set in the transfer authorization request.
  • the present invention it is possible to perform mobile payment transfer authorization from the primary user terminal to the secondary user terminal, thereby enabling trust-based mobile payment transfer authorization between family members and friends.
  • the Token and the transaction key can be used to implement the transaction, thereby ensuring the security of the transaction.
  • the user does not need to input a password when paying, which is quick and convenient, and the user experience is good.
  • the payment transaction can be performed from the user terminal without networking.
  • FIG. 1 is a flow chart showing a mobile payment transfer authorization method of the present invention.
  • Card emulation technology is a technology that simulates an NFC terminal as a card as a whole and is accessed by a card reader.
  • Token technology means that the Token SP generates a Token according to the PAN (primary account) provided by the Token Requestor, and then transfers the Token as a substitute value of the PAN to each part of the payment, so that in the payment process, the unique PAN is only in the Token SP, and the transfer is performed.
  • the LBS location service is also called a Location Based Service (LBS), which acquires location information (latitude and longitude coordinates) of a mobile terminal user through a telecommunication mobile operator's network (eg, GSM network, CDMA network).
  • LBS Location Based Service
  • PAN refers to the bank card master account issued by the bank, which is generally composed of the card issuer identity, personal account identifier and check digit.
  • HCE host-based card emulation
  • host-based card emulation refers to host-based card emulation, which implements card emulation on a mobile terminal equipped with an NFC function.
  • FIG. 1 is a flow chart showing a mobile payment transfer authorization method of the present invention.
  • the mobile payment authorization method of the present invention is implemented by a primary user terminal, a secondary user terminal, a server, and a merchant terminal, and the method includes the following steps:
  • Binding step S100 the primary user terminal is bound to the payment account
  • the transfer authorization request is submitted to step S200: the primary user terminal and the secondary user terminal respectively log in to the server, and the primary user terminal sends a transfer authorization request to the server, wherein in the transfer authorization request, the primary user terminal can set the authorized limit amount and the authorization limit according to the need. Time, authorized limited location, authorized qualified merchants, etc., can also set whether to require transaction confirmation according to needs;
  • Transfer authorization request verification step S300 the server verifies the transfer authorization request, and after verification, issues the token and the transaction key to the slave user terminal at one time;
  • Transfer Authorization Payment Step S400 Implementing payment from the user terminal using the Token and the transaction key, wherein the Token and the transaction key are saved from the user terminal in their secure element (SE) or saved in the cloud, and the payment is made from the user terminal
  • the cloud or local security element (SE) generates a Token, which uses the Token to support the cloud flash payment transaction terminal on the merchant side for the consumer transaction.
  • the merchant terminal will include the current consumption location, the merchant number, the transaction amount, and the transaction token, transaction.
  • the relevant consumer information, such as ciphertext is transmitted to the server, and the server verifies the transaction token and the transaction ciphertext, and completes the payment if the verification is successful.
  • FIG. 2 is a flow chart showing an embodiment of a mobile payment transfer authorization method of the present invention.
  • the mobile payment transfer authorization method of this embodiment is implemented by the primary user terminal 100, the user terminal 200, the server 300, and the merchant terminal 400.
  • the mobile payment transfer authorization method includes the following specific steps:
  • the main user terminal 100 binds a payment account (for example, a bank card, a payment card, a consumer card, etc.) by, for example, a mobile payment application.
  • a payment account for example, a bank card, a payment card, a consumer card, etc.
  • the main user terminal 100 issues a transfer authorization request to the server 300 to allow the payment function from the user terminal 200 to be able to use the main user terminal 100, wherein in the transfer authorization request, the main user terminal 100 can set the authorization limit amount as needed.
  • the cloud or the local security element When the payment transaction is performed from the user terminal 200, the cloud or the local security element (SE) generates a Token, and the transaction terminal 400 supporting the cloud flash payment on the merchant side is consumed by the HCE (host-based cardemulation) or SE (Secure Element). transaction.
  • HCE host-based cardemulation
  • SE Secure Element
  • the cloud will generate more than one Token in advance so that users can still use HCE payment when the device is not connected to the Internet.
  • the merchant terminal 400 transmits the relevant consumption information including the current consumption location, the merchant number, the transaction amount, and the transaction token, the transaction ciphertext, and the like to the server 300.
  • the transaction confirmation is performed as needed, and the server 300 transmits the transaction information to the primary user terminal 100 for transaction confirmation.
  • the server 300 returns the verification success to the merchant terminal 400 and completes the payment.
  • Fig. 3 is a block diagram showing the construction of an embodiment of the mobile payment transfer authorization system of the present invention.
  • the mobile payment transfer authorization system of the present invention includes a primary user terminal 100, a secondary user terminal 200, a server 300, and a merchant terminal 400.
  • the primary user terminal 100 refers to a mobile payment device of the primary user, and may be, for example, a smart phone, a tablet computer, or a wearable device, etc., and may include a payment APP, a binding payment account (eg, a bank card, a payment card, etc.), which may be utilized.
  • the payment APP implements user login and subsequent payment-to-authorization.
  • the primary user terminal 100 is configured to bind a payment account for submitting a transfer authorization request to the server 300.
  • the primary user terminal 100 may set one or more of the authorized limited amount, the authorized limited time, the authorized limited location, the authorized limited merchant, and the like in the transfer authorization request, and may also set whether the transaction confirmation is required according to the need.
  • the slave user terminal 200 refers to a mobile device of the user, which is installed with a payment APP, such as a smartphone, a tablet or a wearable device, and the like, accepts a Token certificate transmitted from the server 300 (or is stored in the cloud), and completes the payment.
  • a payment APP such as a smartphone, a tablet or a wearable device, and the like
  • accepts a Token certificate transmitted from the server 300 or is stored in the cloud
  • the Token and the transaction key transmitted from the server 300 are accepted from the user terminal 200, the Token and the transaction key are stored in the security unit or stored in the cloud, and the transaction is performed using the Token and the transaction key.
  • the server 300 is provided with a Token authorization module 310 and a location calculation module 320, wherein the location calculation module 320 is an optional module.
  • the Token authorization module 310 is configured to generate a Token and a transaction key, and bind the Token to the card number corresponding to the main transaction terminal, and authorize the Token to the secondary 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 configured to calculate a distance between the transaction location and the authorized restriction location, and whether the comparison meets the conditions of the authorization-defined location set in the transfer authorization request.
  • the merchant terminal 400 may be, for example, a terminal device of a merchant's POS machine or the like, and 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 configured to upload 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 occurred.
  • the present invention it is possible to perform mobile payment transfer authorization from the primary user terminal to the secondary user terminal, thereby enabling trust-based mobile payment transfer authorization between family members and friends.
  • the transaction can be realized by using the token and the transaction key, thereby ensuring the security of the transaction.
  • the user does not need to input a password when paying, which is quick and convenient, and the user experience is good.
  • the payment transaction can be performed from the user terminal without networking.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Computer Security & Cryptography (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Credit Cards Or The Like (AREA)
  • Cash Registers Or Receiving Machines (AREA)
  • Inspection Of Paper Currency And Valuable Securities (AREA)

Abstract

本发明涉及一种移动支付授权方法及其***。该方法包括下述步骤：主用户终端绑定支付账户；主用户终端、从用户终端分别登陆服务器，主用户终端向服务器发出转授权请求；服务器对于转授权请求进行核实，在通过核实后，颁发Token和交易密钥给从用户终端；以及从用户终端根据所述Token和交易密钥实现支付。根据本发明，能够实现家庭成员以及朋友之间基于信任的移动支付转授权，能够利用Token和交易密钥保证交易的安全性，同时，用户在支付时，无需输入密码，快捷方便，用户体验良好。另一方面，用户端手机无需联网即可进行支付交易。

Description

移动支付转授权方法、及利用该方法实现的支付*** 技术领域
本发明涉及计算机通信技术，具体地涉及基于支付标记(Token)实现的移动支付转授权方法、利用该移动支付转授权方法实现的支付***、移动终端以及服务器。
背景技术
现有的主流的支付方式都需要密码来验证用户身份实现支付。这具有以下缺点，
第一、用户需要输入密码才能支付，支付过程麻烦，用户体验较差。
第二、移动支付需要绑定自己的银行卡，无法实现家庭或者朋友之间的共享银行卡支付。
第三、用户账户密码可能被窃取，带来安全隐患。
发明内容
鉴于上述问题，本发明的目的在于，旨在提出了一种在保证支付安全的前提下能够实现家庭成员或者朋友之间基于信任的移动支付转授权方法以及利用该方法实现的移动支付转授权***。
本发明的移动支付授权方法，由主用户终端、从用户终端、服务器以及商户终端实现，该方法包括下述步骤：
绑定步骤，主用户终端绑定支付账户；
转授权请求提出步骤，主用户终端、从用户终端分别登陆服务器，主用户终端向服务器发出转授权请求；
转授权请求核实步骤，服务器对于转授权请求进行核实，在通过核实后，颁发Token给从用户终端；以及
转授权支付步骤，从用户终端根据所述Token和交易密钥实现支付。
优选地，在所述转授权请求中，主用户终端预先设定授权限定金额、授权限定时间、授权限定地点、授权限定商户以及是否需要交易确认中的一项或者多项。
优选地，所述转授权请求核实步骤包括下述子步骤：
服务器对于转授权请求进行核对；
在通过核对后，一次性颁发Token和交易密钥给从用户终端；
从用户终端将Token和交易密钥保存在安全元件里或者保存在在云端。
优选地，所述转授权支付步骤包括下述子步骤：
从用户终端进行支付交易时，使用在云端或者本地安全元件生成一个Token代替PAN，利用该Token，每次交易使用一个交易密钥，将交易要素(包括Token、交易金额、商户号、终端号等信息)进行加密形成交易密文，在交易终端进行消费交易；；
商户终端将包括当前消费位置、商户号、交易金额以及交易Token、交易密文的交易信息发送到服务器；
服务器验证交易Token，对交易密文信息进行解密，验证确认交易身份合法性；在验证成功的情况，服务器向商户终端返回验证成功并完成支付。
优选地，在服务器验证交易Token的子步骤中，服务器验证交易Token并根据需要判断交易金额、交易时间、交易地点、交易商户中的一项或多项是否在所述转授权请求中的预先设定。
优选地，在服务器验证交易Token的子步骤中，进一步包括：服务器发送交易信息给主用户终端进行交易确认，在主用户终端确认交易可执行的情况下服务器向商户终端返回验证成功。
本发明的移动支付转授权***，其特征在于，具备：
主用户终端，用于与支付账户进行绑定并且用于向下述的服务器提交转授权请求；
从用户终端，用于接受下述服务器发送来的Token和交易密钥，将其储存在安全单元中或者储存在云端，并且利用该Token结合交易密钥进行交易；
服务器，用于对来自主用户终端的所述转授权请求进行核对并且在通过核对的情况下生成Token和交易密钥并下发给所述从用户终端，在进行交易支付时用于验证从所述从用户终端发送来的交易Token和交易密文并且在验证通过情况下完成交易；以及
商户终端，在所述从用户终端在商户终端进行消费时，用于将来自从所述用户终 端包含交易Token、商户号、交易金额、交易密文的交易信息提交到服务器。
优选地，所述主用户终端在转授权请求中设定授权限定金额、授权限定时间、授权限定地点、授权限定商户等中的一项或多项。
优选地，所述商户终端具备：
LBS模块，用于获取产生交易的交易地点；以及
通讯模块，用于将交易产生的交易地点和交易信息上传到所述服务器。
优选地，所述服务器具备：Token授权模块，用于生成Token和交易密钥，将该Token和交易密钥下发给所述从用户终端；以及位置计算模块，用于计算交易地点与授权限制地点之间的距离，比对是否符合在所述转授权请求中设定的有关授权限定地点的条件。
优选地，所述Token授权模块进一步用于对该Token设定一定的生命周期。
优选地，所述主用户终端在转授权请求中设置是否需要交易确认，在设置为需要交易确认的情况下，所述服务器将有关的交易的信息转发到主用户终端并由主用户终端进行确认，仅在通过主用户终端确认后才允许交易。
本发明的移动终端，其特征在于，
所述移动终端用于接受服务器发送来的Token和交易密钥，将Token和交易密钥储存在安全单元中或者储存在云端，并且利用该Token结合交易密钥进行交易。
本发明的服务器用于实现主用户终端向用户终端进行转支付授权，其特征在于，
用于对来自主用户终端的转授权请求进行核对并且在通过核对的情况下生成
Token和交易密钥并下发给从用户终端，在进行交易支付时用于验证从所述从用户终端发送来的交易Token和交易密文并且在验证通过情况下完成交易支付。
优选地，本发明的服务器具备：
Token授权模块，用于生成Token和交易密钥，将该Token和交易密钥下发给从用户终端；以及
位置计算模块，用于计算交易地点与授权限制地点之间的距离，比对是否符合在所述转授权请求中设定的有关授权限定地点的条件。
根据本发明，能够从主用户终端向从用户终端进行移动支付转授权，由此能够实现家庭成员以及朋友之间基于信任的移动支付转授权。其中，能够利用 Token和交易密钥来实现交易，由此能够保证交易的安全性。而且，用户在支付时，无需输入密码，快捷方便，用户体验良好。另一方面，由于在从用户终端可以预先接收和存储多个Token和多个交易密钥，因此，从用户终端无需联网即可进行支付交易。
附图说明
图1是表示本发明的移动支付转授权方法的流程图。
图2是表示本发明的移动支付转授权方法的一实施方式的流程图。
图3是表示本发明的移动支付转授权***的一实施方式的构造框图。
具体实施方式
下面介绍的是本发明的多个实施例中的一些，旨在提供对本发明的基本了解。并不旨在确认本发明的关键或决定性的要素或限定所要保护的范围。
首先，对于本发明中会出现的一些名词进行说明。
卡模拟技术是将NFC终端整体上模拟成为一张卡片并接受读卡器访问的一种技术。
Token技术是指Token SP根据Token Requestor提供的PAN(主帐号)生成Token后，将Token作为PAN的替代值流转在支付的各个环节，使得在支付流程中，独一无二的PAN只在Token SP、转接方、发卡方间传递，由于三者专线连接且彼此互信，且当Token被检测到风险或到期时，将再次生成新Token替代，从而大幅降低支付过程中PAN泄漏的可能性，极大地提高了PAN的安全性。
LBS定位服务又叫做移动位置服务(Location Based Service，LBS)，它是通过电信移动运营商的网络(如GSM网、CDMA网)获取移动终端用户的位置信息(经纬度坐标)。
PAN是指银行发行的银行卡主账号，一般是由发卡机构标识、个人账户标识和校验位组成。
HCE(host-based card emulation)是指基于主机的卡模拟，是在配备NFC功能的移动终端上实现卡模拟。
首先，对于本发明的移动支付转授权方法进行说明。
图1是表示本发明的移动支付转授权方法的流程图。
如图1所示，本发明的移动支付授权方法由主用户终端、从用户终端、服 务器以及商户终端实现，该方法包括下述步骤：
绑定步骤S100：主用户终端绑定支付账户；
转授权请求提出步骤S200：主用户终端、从用户终端分别登陆服务器，主用户终端向服务器发出转授权请求，其中，在转授权请求中，主用户终端可以根据需要设定授权限定金额、授权限定时间、授权限定地点、授权限定商户等，也可以根据需要设置是否需要交易确认；
转授权请求核实步骤S300:服务器对于转授权请求进行核实，在通过核实后，一次性颁发Token和交易密钥给从用户终端；以及
转授权支付步骤S400：从用户终端利用该Token和交易密钥实现支付，其中，从用户终端将Token和交易密钥保存在其安全元件(SE)里或者保存在在云端，从用户终端进行支付交易时，云端或者本地安全元件(SE)生成一个Token，利用该Token在商户侧支持云闪付的交易终端进行消费交易，商户终端将包括当前消费位置、商户号、交易金额以及交易Token、交易密文等在内的相关消费信息传送至服务器，服务器验证交易Token和交易密文，在验证成功的情况下完成支付。
接着，对于本发明的移动支付转授权方法的具体应用的实施方式进行说明。
图2是表示本发明的移动支付转授权方法的一实施方式的流程图。
该实施方式的移动支付转授权方法由主用户终端100、从用户终端200、服务器300以及商户终端400实现。
如图2所示，本发明的一实施方式的移动支付转授权方法包括下述具体步骤：
①主用户终端100通过例如移动支付应用等绑定支付账户(例如，银行卡、支付卡、消费卡等)。
②主用户终端100、从用户终端200分别登陆到服务器300。
③主用户终端100向服务器300发出转授权请求，以允许从用户终端200通过能够使用主用户终端100的支付功能，其中，在转授权请求中，主用户终端100可以根据需要设定授权限定金额、授权限定时间、授权限定地点、授权限定商户等，也可以根据需要设置是否需要交易确认。
④服务器300对于转授权请求的相关信息进行核对，在通过核对后，一 次性颁发Token和交易密钥给从用户终端200(该临时Token对应于主用户终端100所绑定的支付帐号)，从用户终端200将Token和交易密钥保存在其安全元件(SE)里或者保存在在云端，此时从用户终端200具有支付功能。根据主用户终端100的设置，具有Token的从用户终端100的支付交易具有授权限定金额、授权限定时间、授权限定地点、授权限定商户等的各类限制范围，如果超越限制范围，从用户终端200将失去支付功能。
⑤从用户终端200进行支付交易时，云端或者本地安全元件(SE)生成一个Token，通过HCE(host-based cardemulation)或者SE(Secure Element)，在商户侧支持云闪付的交易终端400进行消费交易。另外，通常云端会提前生成一个以上Token，以便用户在设备未联网时仍可使用HCE支付。
⑥商户终端400将包括当前消费位置、商户号、交易金额以及交易Token、交易密文等在内的相关消费信息传送至服务器300。
⑦服务器300验证交易Token和交易密文，并根据需要判断交易金额、交易时间、交易地点、交易商户是否符合授权限定金额、授权限定时间、授权限定地点、授权限定商户等。
⑧根据需要可选地进行交易确认，服务器300发送交易信息给主用户终端100进行交易确认。
⑨验证成功的情况(可选地包含交易确认成功的情况)下，服务器300向商户终端400返回验证成功并完成支付。
在本发明中，Token为解决***信息泄露问题，以由13至19位的虚拟数字串，替代***。服务器300颁发Token和交易密钥给从用户终端200，通过交易密钥，针对每次刷卡交易，计算出一个交易密文，用于交易身份合法性确认。通过Token、交易密钥相结合，实现交易安全保障。
图3是表示本发明的移动支付转授权***的一实施方式的构造框图。
如图3所示，本发明的移动支付转授权***包括主用户终端100、从用户终端200、服务器300以及商户终端400。
主用户终端100是指主用户的移动支付设备，例如可以是智能手机、平板电脑或可穿戴设备等，它可以包含支付APP，绑定支付账户(例如，银行卡、支付卡等)，可以利用支付APP实现用户登录以及之后的支付转授权。主用户终端 100用于绑定支付账户，用于向服务器300提交转授权请求。其中，主用户终端100可以根据需要在转授权请求中设定授权限定金额、授权限定时间、授权限定地点、授权限定商户等中的一项或多项，也可以根据需要设置是否需要交易确认。
从用户终端200是指从用户的移动设备，它安装有支付APP，例如可以是智能手机、平板电脑或可穿戴设备等，接受来自服务器300传送的Token证书(或者存储于云端)，完成支付。从用户终端200接受服务器300发送来的Token和交易密钥，将Token和交易密钥储存在安全单元中或者储存在云端，并且利用该Token和交易密钥进行交易。
服务器300用于对来自主用户终端100的转授权请求进行核对并且在通过核对的情况下生成Token和交易密钥并下发给从用户终端200，在进行交易支付时用于验证从从用户终端200发送来的交易Token和交易密文并且在验证通过情况下完成交易支付。
服务器300具备：Token授权模块310以及位置计算模块320，其中，位置计算模块320是可选模块。
Token授权模块310用于生成Token和交易密钥，并绑定此Token与主交易终端所对应的***，将该Token授权与给从用户终端200。进一步地，Token授权模块310还能够对该Token设定一定的生命周期。
位置计算模块320用于计算交易地点与授权限制地点之间的距离，比对是否符合在所述转授权请求中设定的有关授权限定地点的条件。
商户终端400例如可以是商户的POS机等的终端设备，商户终端400具备：通信模块410和LBS功能模块420，其中，LBS功能模块420是可选模块。通讯模块410用于将交易产生的交易地点(可选)和交易信息上传到服务器300。LBS模块420用于探测交易发生的地点。
根据本发明，能够从主用户终端向从用户终端进行移动支付转授权，由此能够实现家庭成员以及朋友之间基于信任的移动支付转授权。其中，能够利用Token和交易密钥来实现交易，由此能够保证交易的安全性。而且，用户在支付时，无需输入密码，快捷方便，用户体验良好。另一方面，由于在从用户终端可以预先接收和存储多个Token和交易密钥，因此，从用户终端无需联网即可进行支付交易。
以上例子主要说明了本发明的移动支付转授权方法、利用该移动支付转授权方法实现的支付***、移动终端以及服务器。尽管只对其中一些本发明的具体实施方式进行了描述，但是本领域普通技术人员应当了解，本发明可以在不偏离其主旨与范围内以许多其他的形式实施。因此，所展示的例子与实施方式被视为示意性的而非限制性的，在不脱离如所附各权利要求所定义的本发明精神及范围的情况下，本发明可能涵盖各种的修改与替换。

Claims (15)

  1. 一种移动支付授权方法，由主用户终端、从用户终端、服务器以及商户终端实现，该方法包括下述步骤：
    绑定步骤，主用户终端绑定支付账户；
    转授权请求提出步骤，主用户终端、从用户终端分别登陆服务器，主用户终端向服务器发出转授权请求；
    转授权请求核实步骤，服务器对于转授权请求进行核实，在通过核实后，颁发Token和交易密钥给从用户终端；以及
    转授权支付步骤，从用户终端使用所述Token以及交易密钥实现支付。
  2. 如权利要求1所述的移动支付授权方法，其特征在于，
    在所述转授权请求中，主用户终端预先设定授权限定金额、授权限定时间、授权限定地点、授权限定商户以及是否需要交易确认中的一项或者多项。
  3. 如权利要求2所述的移动支付授权方法，其特征在于，
    所述转授权请求核实步骤包括下述子步骤：
    服务器对于转授权请求进行核对；
    在通过核对后，一次性颁发Token和多个交易密钥给从用户终端；
    从用户终端将Token和交易密钥保存在安全元件里或者保存在在云端。
  4. 如权利要求3所述的移动支付授权方法，其特征在于，
    所述转授权支付步骤包括下述子步骤：
    从用户终端在交易终端进行支付交易时，使用在云端或者本地安全元件的Token代替PAN，每次交易使用一个交易密钥，将作为交易要素的Token、交易金额、商户号、终端号进行加密形成交易密文，发送商户终端进行消费交易；
    商户终端将包括当前消费位置、商户号、交易金额以及交易Token、交易密文的交易信息发送到服务器；
    服务器验证交易Token，对交易密文信息进行解密，验证确认交易身份合法性；在验证成功的情况，服务器向商户终端返回验证成功并完成支付。
  5. 如权利要求4所述的移动支付授权方法，其特征在于，
    在服务器验证交易Token的子步骤中，服务器验证交易Token并根据需要判断交易金额、交易时间、交易地点、交易商户中的一项或多项是否在所述转授权请求中的预先设定。
  6. 如权利要求5所述的移动支付授权方法，其特征在于，
    在服务器验证交易Token的子步骤中，进一步包括：服务器发送交易信息给主用户终端进行交易确认，在主用户终端确认交易可执行的情况下服务器向商户终端返回验证成功。
  7. 一种移动支付转授权***，其特征在于，具备：
    主用户终端，用于与支付账户进行绑定并且用于向下述的服务器提交转授权请求；
    从用户终端，用于接受下述服务器发送来的Token和交易密钥储存在安全单元中或者储存在云端，并且利用该Token和交易密钥进行交易；
    服务器，用于对来自主用户终端的所述转授权请求进行核对并且在通过核对的情况下生成Token和交易密钥并下发给所述从用户终端，在进行交易支付时用于验证从所述从用户终端发送来的交易Token和交易密文并且在验证通过情况下完成交易；以及
    商户终端，在所述从用户终端在商户终端进行消费时，用于将来自从所述用户终端包含交易Token、商户号、交易金额、交易密文的交易信息提交到服务器。
  8. 如权利要求7所述的移动支付转授权***，其特征在于，
    所述主用户终端在转授权请求中设定授权限定金额、授权限定时间、授权限定地点、授权限定商户等中的一项或多项。
  9. 如权利要求8所述的移动支付转授权***，其特征在于，
    所述商户终端具备：
    LBS模块，用于获取产生交易的交易地点；以及
    通讯模块，用于将交易产生的交易地点和交易信息上传到所述服务器。
  10. 如权利要求9所述的移动支付转授权***，其特征在于，
    所述服务器具备：
    Token授权模块，用于生成Token和交易密钥，将该Token和交易密钥下发给所 述从用户终端；以及
    位置计算模块，用于计算交易地点与授权限制地点之间的距离，比对是否符合在所述转授权请求中设定的有关授权限定地点的条件。
  11. 如权利要求9所述的移动支付转授权***，其特征在于，
    所述Token授权模块进一步用于对该Token设定一定的生命周期。
  12. 如权利要求9所述的移动支付转授权***，其特征在于，
    所述主用户终端在转授权请求中设置是否需要交易确认，在设置为需要交易确认的情况下，所述服务器将有关的交易的信息转发到主用户终端并由主用户终端进行确认，仅在通过主用户终端确认后才允许交易。
  13. 一种移动终端，其特征在于，
    所述移动终端用于接受服务器发送来的Token和交易密钥储存在安全单元中或者储存在云端，并且利用该Token和交易密钥进行交易。
  14. 一种服务器，用于实现主用户终端向用户终端进行转支付授权，其特征在于，用于对来自主用户终端的转授权请求进行核对并且在通过核对的情况下生成Token和交易密钥并下发给从用户终端，在进行交易支付时用于验证从所述从用户终端发送来的交易Token和交易密文并且在验证通过情况下完成交易支付。
  15. 如权利要求14所述的服务器，其特征在于，具备：
    Token授权模块，用于生成Token和交易密钥，将该Token和交易密钥下发给从用户终端；以及
    位置计算模块，用于计算交易地点与授权限制地点之间的距离，比对是否符合在所述转授权请求中设定的有关授权限定地点的条件。
PCT/CN2018/077845 2017-03-17 2018-03-02 移动支付转授权方法、及利用该方法实现的支付*** WO2018166359A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710160386.6 2017-03-17
CN201710160386.6A CN107256484B (zh) 2017-03-17 2017-03-17 移动支付转授权方法、及利用该方法实现的支付***

Publications (1)

Publication Number Publication Date
WO2018166359A1 true WO2018166359A1 (zh) 2018-09-20

Family

ID=60027216

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/077845 WO2018166359A1 (zh) 2017-03-17 2018-03-02 移动支付转授权方法、及利用该方法实现的支付***

Country Status (3)

Country Link
CN (1) CN107256484B (zh)
TW (1) TWI775820B (zh)
WO (1) WO2018166359A1 (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107256484B (zh) * 2017-03-17 2021-01-15 ***股份有限公司 移动支付转授权方法、及利用该方法实现的支付***
CN108960818A (zh) * 2018-05-04 2018-12-07 ***股份有限公司 一种虚拟卡生成方法、用户终端以及令牌服务器
CN110009348B (zh) * 2019-03-25 2022-03-11 杭州秘猿科技有限公司 一种区块链的代理签名方法、***及电子设备
CN110267264B (zh) * 2019-05-20 2022-10-25 广西蛋壳机器人科技有限公司 一种未联网智能终端与用户移动终端绑定的***
CN111192052B (zh) * 2020-01-03 2023-05-09 广东岭南通股份有限公司 一种支付方法、支付服务器及支付终端
CN113743927B (zh) * 2020-05-27 2024-06-07 ***股份有限公司 基于用户支付标签的数据处理方法及***、用户支付标签
CN112435031A (zh) * 2020-08-06 2021-03-02 ***股份有限公司 基于用户绑定关系的数据处理方法及其***
CN112633888A (zh) * 2020-09-22 2021-04-09 ***股份有限公司 基于Token的数据处理方法及其***、移动终端
CN113159761A (zh) * 2021-01-06 2021-07-23 ***股份有限公司 基于设备连接的支付授权转移***及支付授权转移方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105450691A (zh) * 2014-08-21 2016-03-30 阿里巴巴集团控股有限公司 业务处理方法、装置及服务器
CN105593883A (zh) * 2013-08-30 2016-05-18 金雅拓股份有限公司 验证交易的方法
CN106464492A (zh) * 2013-10-11 2017-02-22 维萨国际服务协会 网络令牌***
CN107256484A (zh) * 2017-03-17 2017-10-17 ***股份有限公司 移动支付转授权方法、及利用该方法实现的支付***

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103065240B (zh) * 2013-01-11 2018-04-27 中兴通讯股份有限公司 一种移动支付处理方法和***
CN103051459B (zh) * 2013-01-17 2016-04-06 北京印天网真科技有限公司 安全卡的交易密钥的管理方法和装置
US20160063487A1 (en) * 2014-08-29 2016-03-03 Capital One Services, Llc System and method for double blind authentication
CN105528695B (zh) * 2014-09-28 2019-12-24 ***股份有限公司 一种基于标记的移动支付方法及移动支付***
CN106127467A (zh) * 2016-06-20 2016-11-16 上海易码信息科技有限公司 集金融卡支付与结算于一体的移动支付方法
CN106251140A (zh) * 2016-08-02 2016-12-21 ***股份有限公司 支付方法、支付应用***以及支付***

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105593883A (zh) * 2013-08-30 2016-05-18 金雅拓股份有限公司 验证交易的方法
CN106464492A (zh) * 2013-10-11 2017-02-22 维萨国际服务协会 网络令牌***
CN105450691A (zh) * 2014-08-21 2016-03-30 阿里巴巴集团控股有限公司 业务处理方法、装置及服务器
CN107256484A (zh) * 2017-03-17 2017-10-17 ***股份有限公司 移动支付转授权方法、及利用该方法实现的支付***

Also Published As

Publication number Publication date
TW201835824A (zh) 2018-10-01
CN107256484A (zh) 2017-10-17
CN107256484B (zh) 2021-01-15
TWI775820B (zh) 2022-09-01

Similar Documents

Publication Publication Date Title
WO2018166359A1 (zh) 移动支付转授权方法、及利用该方法实现的支付***
RU2663476C2 (ru) Защищенная обработка удаленных платежных транзакций, включающая в себя аутентификацию потребителей
US20170364895A1 (en) Person-To-Person Electronic Payment Processing
US20200302439A1 (en) Terminal configuration server for the remote configuration of terminals
US10325260B2 (en) System, method and computer program product for secure peer-to-peer transactions
KR20140023052A (ko) 결제 중개 시스템 및 방법
KR101472751B1 (ko) 제휴사 앱을 이용한 결제 제공 방법 및 시스템
CN101425901A (zh) 一种在处理终端中用于对用户身份验证的控制方法及装置
CN107395600A (zh) 业务数据验证方法、服务平台及移动终端
KR20140089730A (ko) 제휴사 앱을 이용한 결제수단 등록 방법 및 시스템
KR101505847B1 (ko) 결제 처리를 위한 제휴사 앱 인증 방법
KR101772358B1 (ko) 결제수단 등록을 위한 타사 앱 자동 식별 방법
WO2015162276A2 (en) Secure token implementation
KR101744706B1 (ko) 공인인증서 관리회사 기반의 간편 결제 시스템 및 이를 이용한 간편 결제 방법
KR20190083284A (ko) 음파장치와 암호화폐를 이용한 앱 연동 기반 비동기식 역방향 결제 방법
KR20190083286A (ko) 음파장치와 암호화폐를 이용한 앱 연동 기반 비동기식 역방향 결제 방법
KR20140089732A (ko) 결제수단 등록을 위한 제휴사 앱 자동 식별 방법
TWM575158U (zh) Financial system
KR20190083098A (ko) 무선장치와 암호화폐를 이용한 비동기식 역방향 결제 방법
KR20190083179A (ko) 음파장치와 암호화폐를 이용한 비동기식 역방향 결제 방법
KR20190081013A (ko) 음파장치와 암호화폐를 이용한 앱 연동 기반 비동기식 역방향 결제 방법
KR20190083175A (ko) 무선장치와 암호화폐를 이용한 비동기식 역방향 결제 방법
KR20190081012A (ko) 음파장치와 암호화폐를 이용한 앱 연동 기반 비동기식 역방향 결제 방법
KR20190083283A (ko) 음파장치와 암호화폐를 이용한 앱 연동 기반 비동기식 역방향 결제 방법
KR20190083285A (ko) 음파장치와 암호화폐를 이용한 앱 연동 기반 비동기식 역방향 결제 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18766958

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18766958

Country of ref document: EP

Kind code of ref document: A1