WO2022001176A1 - 支付令牌申请方法、设备、系统和服务器 - Google Patents

支付令牌申请方法、设备、系统和服务器 Download PDF

Info

Publication number
WO2022001176A1
WO2022001176A1 PCT/CN2021/080495 CN2021080495W WO2022001176A1 WO 2022001176 A1 WO2022001176 A1 WO 2022001176A1 CN 2021080495 W CN2021080495 W CN 2021080495W WO 2022001176 A1 WO2022001176 A1 WO 2022001176A1
Authority
WO
WIPO (PCT)
Prior art keywords
application module
payment
token
server
binding
Prior art date
Application number
PCT/CN2021/080495
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 WO2022001176A1 publication Critical patent/WO2022001176A1/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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3672—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes initialising or reloading thereof
    • 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
    • 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions

Definitions

  • the present application belongs to the technical field of payment security, and specifically relates to a payment token application method, device, system and server.
  • the purpose of this application is to provide a payment token application method, device, system and server for the deficiencies of the prior art.
  • An embodiment of the present application provides a payment token application method, which is applied to a second application module in a terminal device.
  • the method includes: after receiving an invocation instruction from the first application module, displaying a bound payment account for use in The user selects a payment account from the already bound payment accounts, wherein the calling instruction carries the merchant information of the first application module; and sends a binding token authorization request to the server for the first application module to request according to The requested binding token authorization code applies to the server for a payment token, wherein the binding token authorization request carries the merchant information of the first application module and the payment account selected by the user.
  • the binding token authorization request also carries transaction control parameters.
  • the transaction control parameter includes at least one of a validity period of the payment token, a single-day transaction limit of the payment token, and a single-day transaction number of the payment token.
  • it also includes: providing a setting interface for the user to set the transaction control parameters.
  • the method further includes: receiving a binding token authorization code from a server, and forwarding the received binding token authorization code to the first application module.
  • the prompt information of the payment account and/or the prompt information of the user's identity information is also sent to the first application module. application module.
  • An embodiment of the present application provides a payment token application method, which is applied to a first application module of a terminal device.
  • the payment token application method includes: invoking a second application module, and transmitting the first application module to the second application module.
  • Merchant information of the application module for the second application module to send a binding token authorization request to the server, and the binding token authorization request carries the merchant information of the first application module and the The payment account selected by the application module, wherein the first application module is software that invokes the second application module, and the payment account that the user can select in the second application module is that the user has bound in the second application module.
  • receiving a binding token authorization code the binding token authorization code is generated by the server according to the binding token authorization request; sending a payment token request to the server, the The payment token request carries the binding token authorization code; the payment token is received from the server.
  • the binding token authorization code is forwarded by the server to the first application module via the second application module; while receiving the binding token authorization code from the second application module, Further receiving the prompt information of the payment account and/or the prompt information of the user's identity information from the second application module; the method further comprises: displaying the prompt information of the payment account and/or the prompt of the user's identity information information, so that the user can confirm whether the prompt information is correct; if the user confirms that the prompt information is correct, the step of sending a payment token request to the server is performed.
  • it also includes the step of selecting a second application module, including: sending a query request to the server to query the applications supported by the server; displaying the queried application list, so that the user can select an application as the selected application. the second application module.
  • an encryption discriminant code and the merchant information of the first application module are also encrypted, and the encryption discriminant code is for the first application module to register in the server.
  • the ciphertext of its business information obtained at the time.
  • it also includes: receiving first encrypted data, a second secret key and clock information from a server, where the first encrypted data is a ciphertext obtained by encrypting the binding token authorization code with the first secret key; according to The received clock information synchronizes the clock, and uses the second secret key and the synchronized clock information to encrypt its own merchant information to obtain second encrypted data; when the second application module is called, the second encrypted data is also encrypted.
  • the second encrypted data and the first encrypted data are sent to the server.
  • An embodiment of the present application provides a payment token application method, which is applied to a server.
  • the method includes: receiving a binding token authorization request from a second application module, where the binding token authorization request carries the first application module's Merchant information and the payment account selected by the user in the bound payment account of the second application module; in the case that the binding token authorization request is verified, generate the binding token authorization code, and send the The binding token authorization code is sent to the first application module; a payment token request is received from the first application module, and the payment token request carries the binding token authorization code; If the token request verification is passed, a payment token is generated, and the payment token is sent to the first application module.
  • the binding token authorization request also carries the merchant information of the first application module; if the merchant information carried by the binding token authorization code is registered merchant information, the binding The specified token authorization request is verified.
  • it also includes: providing a registration service for the first application module; encrypting the merchant information of the first application module to obtain an encrypted discrimination code; sending the encrypted discrimination code to the first application module; Receive the encrypted discriminant code and merchant information from the first application module; decrypt the encrypted discriminant code, and compare the decrypted plaintext with the received merchant information, if the two are consistent, the binding order The license authorization request is verified.
  • the payment token request also carries merchant information of the first application module; the step of verifying the payment token request includes at least one of the following three verification methods: binding as described If the token authorization code exists, the verification is passed; if the merchant information is consistent with the merchant information in the application for the binding token authorization code, the verification is passed; if the binding token authorization code is within the validity period, the verification is passed. pass through.
  • first encrypted data, second secret key and clock information are also sent to the first application module, where the first encrypted data is the binding token.
  • the ciphertext obtained by encrypting the license authorization code with the first secret key;
  • the method also includes:
  • the method further includes: encrypting the merchant information of the first application module retained by itself by using its own second secret key and its own clock information , obtain the third ciphertext, determine whether the third ciphertext is consistent with the second ciphertext received from the first application module, and determine whether the received first encrypted data is decrypted by the first secret key. Whether the authorization code of the binding token is consistent with the authorization code of the binding token reserved by itself, if they are consistent, the verification of the payment token request is passed.
  • sending the payment token to the first application module includes: forwarding the binding token authorization code to the first application module via the second application module.
  • the embodiment of the present application provides a payment token application method, including: in a terminal device, a first application module calls a second application module, and transmits the merchant information of the first application module to the second application module; In the terminal device, after receiving the calling instruction of the first application module, the second application module displays it on the payment account bound by the second application module, so that the user can select a payment from the bound payment account.
  • binding token authorization request carries the merchant information of the first application module and the payment account selected by the user; at the server, at the binding token In the case that the verification of the fixed token authorization request is passed, a binding token authorization code is generated, and the binding token authorization code is sent to the first application module; in the terminal device, the first application module Send a payment token request to the server, where the payment token request carries the binding token authorization code; at the server, in the case that the payment token request is verified, a payment token is generated, and Sending the payment token to the first application module.
  • An embodiment of the present application provides a terminal device, the terminal device has a first memory and a first processor, the first memory stores a first instruction and/or a second instruction, and the first instruction is stored in the first When a processor is running, it is configured to execute the payment token application method of the aforementioned first application module, and the second instruction is executed on the first processor to execute the aforementioned payment token application method of the second application module.
  • An embodiment of the present application provides a server, the server includes a second memory and a second processor, the second memory stores a payment token management program, and the second processor runs the payment token management program to Execute the aforementioned payment token application method applied on the server.
  • Embodiments of the present application provide a payment token application system, including the aforementioned terminal device and the aforementioned server.
  • the beneficial effects of the present application are: the user only needs to bind a payment account (for example, a bank card) on the second application module, and when the user needs to bind the payment account on the first application module, The operation can be performed through the second application module that has already bound the payment account, and the first application module will not touch payment-sensitive information such as bank card numbers, which increases the security in the process of binding the payment account.
  • a payment account for example, a bank card
  • FIG. 1 is a flowchart of a payment token application method provided by an embodiment of the present application.
  • FIG. 2 is a flowchart of a payment token application method provided by another embodiment of the present application.
  • FIG. 3 is a flowchart of a payment token application method provided by another embodiment of the present application.
  • FIG. 4 is a flowchart of a payment token application method provided by another embodiment of the present application.
  • FIG. 5 is an interaction flowchart of a payment token application method provided by another embodiment of the present application.
  • FIG. 6 is a structural block diagram of a payment account management system provided by an embodiment of the present application.
  • the terminal device is, for example, a device such as a smart phone, a tablet computer, or a personal computer that is operated by a terminal user.
  • the second application module is for example Application modules for payment, such as mobile banking and shopping APP with payment function, can of course also be HTML5 pages of these application modules.
  • the first application module refers to the software that needs to be bound to a payment account (for example, a bank card needs to be bound).
  • the difference between the labels of the first application module and the second application module is only that during the application process, the second application module has bound the payment account, and the first application module needs to apply for a payment token through the assistance of the second application module.
  • the first application module and the second application module may be implemented entirely by software, entirely by hardware, or by a combination of software and hardware.
  • the server provides management services for payment tokens.
  • a payment token also known as a token or payment token, is a piece of code that replaces payment-sensitive information such as a bank card number.
  • the payment token application method provided by the embodiment of the present application is applied to the second application module of the terminal device.
  • the execution subject is the software that has been bound to the payment account, such as or Page; from the hardware point of view, the execution body can be the terminal device running these software or the server that provides HTML5 page service for the terminal device.
  • the method includes the following steps.
  • Step S101 After receiving the calling instruction of the first application module, the bound payment accounts are displayed for the user to select a payment account from the bound payment accounts, wherein the calling instruction carries the first application module 's business information.
  • the merchant information is, for example, a merchant number or a token requester number.
  • the merchant information is the unique identifier of the first application module on the server.
  • Step S102 Send a binding token authorization request to the server, so that the first application module can apply to the server for a payment token according to the requested binding token authorization code, wherein the binding token authorization request Carrying the merchant information of the first application module and the payment account selected by the user.
  • the second application module displays its already bound payment account, which may display part of the card number of the bound bank card, the single-day and single-day transaction limit of the bound bank card, and the number of transactions per day and other transaction controls. parameter.
  • the user selects a payment account on the second application module as the payment account to which the first application module applies for binding.
  • the binding token authorization code applied by the second application module is a string of codes.
  • the code of the binding token authorization code itself has no specific meaning.
  • the server may directly send the binding token authorization code to the first application module, or may first send it to the second application module, and then the second application module forwards the received binding token authorization code to the first application module. an application module. Subsequently, the first application module can apply to the server for a final payment token by virtue of the binding token authorization code.
  • the first application module obtains the binding token authorization code from the server through the second application module, and then obtains the payment token from the server by relying on the binding token authorization code. If a payment account needs to be bound to the first application module, the first application module will not contact the payment account to be bound during the whole process of card binding, which reduces the chance of exposure of the payment account and increases security.
  • some embodiments of the present application also provide some specific implementations and extension solutions of the payment token application method, which will be described below.
  • the binding token authorization request also carries transaction control parameters.
  • the transaction control parameter includes, for example, at least one of the validity period of the payment token, the transaction limit of the payment token in a single day, and the number of transactions in a single day of the payment token.
  • the transaction control parameters may be the transaction control parameters of the payment account selected in the second application module by default.
  • the second application module further provides a setting interface for the user to set the transaction control parameters.
  • the prompt information of the payment account and/or the prompt information of the user's identity information is also sent to the first application module. application module.
  • the first application module can display the prompt information of the payment account and/or the prompt information of the user's identity information for the user to confirm.
  • the payment token application method provided by the embodiment of the present application is applied to the first application module of the terminal device.
  • the execution subject is the software that needs to bind the payment account (herein referred to as the first application module), such as or Page; from the hardware point of view, the execution body can be the terminal device running these software or the server that provides HTML5 page service for the terminal device.
  • the method includes the following steps.
  • Step S201 Invoke the second application module, and pass the merchant information of the first application module to the second application module, so that the second application module sends a binding token authorization request to the server, the binding token
  • the authorization request carries the merchant information of the first application module and the payment account selected by the user in the second application module, wherein the first application module is software that calls the second application module, and the user
  • the payment account that can be selected by the second application module is the payment account that the user has bound in the second application module.
  • Step S202 Receive a binding token authorization code, where the binding token authorization code is generated by the server according to the binding token authorization request. It may be received from the server, or may be received through the second application module.
  • Step S203 sending a payment token request to the server, where the payment token request carries the binding token authorization code
  • Step S204 receiving a payment token from the server.
  • the first application module applies to the server for a binding token authorization code through the second application module, and then applies to the server for a payment token by virtue of the binding token authorization code.
  • the first application module does not contact sensitive information such as payment accounts in the whole process, which improves the safety.
  • some embodiments of the present application also provide some specific implementations and extension solutions of the payment token application method, which will be described below.
  • the binding token authorization code is forwarded by the server to the first application module via the second application module; while receiving the binding token authorization code from the second application module, Further receiving the prompt information of the payment account and/or the prompt information of the user's identity information from the second application module; the method further comprises: displaying the prompt information of the payment account and/or the prompt of the user's identity information information, so that the user can confirm whether the prompt information is correct; if the user confirms that the prompt information is correct, the step of sending a payment token request to the server is performed.
  • the prompt information of the payment account is, for example, the last 4-digit card number of the bank card, the type of the bank card, and the name of the bank.
  • the prompt information of the user's identity information is, for example, the identity card number of the user with the hidden part of the user, the mobile phone number registered by the user for the bank card, and the like. Provide users with more prompt information for users to confirm.
  • the user can confirm the payment account and personal information to be bound in the first application module.
  • it also includes the step of selecting a second application module, including: sending a query request to the server to query the applications supported by the server; displaying the queried application list, so that the user can select an application as the selected application. the second application module.
  • the user can choose which software to use as the relay to apply for the binding token authorization code for the first application module.
  • the first application module can also provide a display interface to display relevant information of the payment account that has been bound (for example, the card issuing bank, account type, the tail number of the corresponding payment account, the validity period of the payment token, the transaction limit Wait).
  • relevant information of the payment account that has been bound for example, the card issuing bank, account type, the tail number of the corresponding payment account, the validity period of the payment token, the transaction limit Wait.
  • the first application module (the card binding has been completed at this time) can also provide a function of unbinding. According to the unbinding operation of the user, the first application module only needs to send the information marking the state change to the server.
  • the first application module will also receive a corresponding notification from the server.
  • the first application module can obtain the latest state information of the payment token from the notification.
  • an encrypted discriminant code and the merchant information of the first application module are also sent to the server, and the encryption discriminant code is the first application module in the The ciphertext of its merchant information obtained by the server when it registers.
  • the first application module will obtain an encryption discriminating code when the server performs registration, and the encryption discriminating code is the encrypted cipher text of the merchant information of the first application module.
  • the first application module also sends the encrypted identification code and its own merchant information when sending the binding token authorization request.
  • the server can validate the bind token authorization request accordingly.
  • Doing so can prevent some phishing fraud APPs from counterfeiting the relevant merchant information of the first application module, causing the user to bind the bank card to the phishing APP, thereby avoiding the loss of the user's property.
  • it also includes: receiving first encrypted data, a second secret key and clock information from a server, where the first encrypted data is a ciphertext obtained by encrypting the binding token authorization code with the first secret key; according to The received clock information synchronizes the clock, and uses the second secret key and the synchronized clock information to encrypt its own merchant information to obtain second encrypted data; when the second application module is called, the second encrypted data is also encrypted.
  • the second encrypted data and the first encrypted data are sent to the server.
  • the addition of the clock information can realize that when the server does not respond for a certain period of time, the application for the payment token of the first application module can be rejected, so as to avoid the user from waiting for a long time.
  • an embodiment of the present application further provides a payment token application method, which is applied to a server.
  • the execution subject is the software run by the server, and from the hardware point of view, the execution subject is the server.
  • the method includes the following steps.
  • Step S301 Receive a binding token authorization request from the second application module, where the binding token authorization request carries the merchant information of the first application module and the user's information in the bound payment account of the second application module. The selected payment account.
  • Step S302 when the binding token authorization request is verified, generate a binding token authorization code, and send the binding token authorization code to the first application module.
  • Step S303 Receive a payment token request from the first application module, where the payment token request carries the binding token authorization code.
  • Step S304 in the case that the verification of the payment token request is passed, generate a payment token, and send the payment token to the first application module.
  • the server generates a binding token authorization code for the first application module based on the interaction with the second application module, and then the first application module applies to the server for a payment token by virtue of the binding token authorization code.
  • the first application module does not touch sensitive information such as payment accounts in the whole process to improve security.
  • some embodiments of the present application also provide some specific implementations and extension solutions of the payment token application method, which will be described below.
  • it also includes: providing a registration service for the first application module; encrypting the merchant information of the first application module to obtain an encrypted discrimination code; sending the encrypted discrimination code to the first application module; Receive the encrypted discriminant code and merchant information from the first application module; decrypt the encrypted discriminant code, and compare the decrypted plaintext with the received merchant information, if the two are consistent, the binding order The license authorization request is verified.
  • the server encrypts the merchant information of the first application module, and sends the ciphertext (ie, the encryption identification code) to the first application module.
  • the first application module needs to provide the correct encryption discrimination code and correct merchant information in order to obtain the binding token authorization code.
  • the payment token request also carries merchant information of the first application module; the step of verifying the payment token request includes at least one of the following three verification methods: binding as described If the token authorization code exists, the verification is passed; if the merchant information is consistent with the merchant information in the application for the binding token authorization code, the verification is passed; if the binding token authorization code is within the validity period, the verification is passed. pass through.
  • the server determines whether the binding token authorization code carried in the payment token request exists in the server, and if so, determine whether the merchant information carried in the payment token request is the same as the binding token authorization code The merchant information carried in the corresponding binding token authorization request is consistent. If so, it is determined whether the current time is within the validity period of the binding token authorization code. If so, the payment token request is verified.
  • the server only determines that the binding token authorization code and merchant information carried in the received payment token request are correct and have not expired, and the payment token request is verified.
  • first encrypted data, second secret key and clock information are also sent to the first application module, where the first encrypted data is the binding token.
  • the server when the server generates the binding token authorization code, it will also generate a first secret key and a second secret key, and use the first secret key to encrypt the binding token authorization code to obtain the first encrypted data, and the first secret key
  • An encrypted data, a second secret key and clock information are sent to the first application module (either directly to the first application module, or forwarded through the second application module).
  • the first application module performs clock synchronization according to the received clock information, and encrypts the merchant information with the second secret key and the synchronized clock information to form second encrypted data.
  • the first application module sends the second encrypted data and the received first encrypted data to the server.
  • the device provides the third encrypted data by encrypting the merchant information stored by itself by using the second secret key stored by itself and the clock information by itself, and judges whether the second encrypted data and the third encrypted data are consistent, and at the same time use the self-retained data
  • the first secret medicine decrypts the first encrypted data, compares the binding token authorization code obtained by decryption with the binding token authorization code saved by itself, and judges whether they are consistent. If the results of the two judgments are consistent , then the payment token request is legitimate.
  • the server refuses the payment token request when there is no response for a certain period of time, so as to avoid users from waiting for a long time.
  • the first application module calls the second application module, and sends the above information to the server.
  • the server After receiving the above information, the server does not receive the binding token authorization request from the second application module in time, so it can send rejection information to the first application module.
  • sending the payment token to the first application module includes: forwarding the binding token authorization code to the first application module via the second application module.
  • the user can make payment according to the payment token when using the first application module.
  • the payment request is sent to the server.
  • the server replaces the payment token in the payment request with a payment account (such as a bank card number), and then sends the payment request to the corresponding card issuer.
  • a payment account such as a bank card number
  • the card issuer For the payment transaction initiated by the payment token, the card issuer adds a marked payment identifier to the payment request after the card number is converted, and the card issuer accepts the card number transaction with the marked payment identifier but no verification elements.
  • an embodiment of the present application further provides a payment token application method.
  • the method shows the complete interaction process among the first application module, the second application module and the server running on the terminal device.
  • the payment token application method includes the following steps.
  • Step S401 On the terminal device, the first application module calls the second application module, and transmits the merchant information of the first application module to the second application module.
  • Step S402 in the terminal device, after the second application module receives the calling instruction of the first application module, it displays the bound payment account of the second application module for the user to use the bound payment account
  • One payment account is selected from among the above, and a binding token authorization request is sent to the server, wherein the binding token authorization request carries the merchant information of the first application module and the payment account selected by the user.
  • Step S403 the server generates a binding token authorization code when the verification of the binding token authorization request is passed, and sends the binding token authorization code to the first application module;
  • Step S404 On the terminal device, the first application module sends a payment token request to the server, where the payment token request carries the binding token authorization code.
  • Step S405 In the server, in the case that the verification of the payment token request is passed, a payment token is generated, and the payment token is sent to the first application module.
  • the first application module calls the second application module to select the bank card to be bound in the second application module.
  • the second application module sends a binding token authorization request to the server, the merchant information of the first application module, transaction control parameters and the merchant number of the first application module.
  • the server verifies the binding token authorization request and generates the binding token authorization code.
  • the server sends the binding token authorization code to the second application module.
  • the second application module sends the binding token authorization code and prompt information to the first application module.
  • the first application module displays prompt information for the user to confirm whether the prompt information is correct.
  • the first application module sends a payment token request to the server, carrying the merchant information and the binding token authorization code.
  • the server verifies the payment token request, and if the verification passes, a payment token is generated and sent to the first application module.
  • an embodiment of the present application further provides a terminal device 1 having a first memory 11 and a first processor 12, the first memory 11 stores the first instruction and/or the second instruction, the first When the first processor 12 runs, an instruction is used to execute the aforementioned payment token application method applied to the first application module, and the second instruction runs on the first processor 12 to execute the aforementioned payment token applied to the second application module How to apply.
  • the embodiment of the present application further provides a server 2, the server 2 includes a second memory 21 and a second processor 22, the second memory 21 stores a payment token management program, and the second processor 22 runs the payment token management program The program is used to execute the aforementioned payment token application method applied on the server.
  • the embodiments of the present application provide a payment token application system, including the above-mentioned terminal device and the above-mentioned server.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

一种支付令牌申请方法、设备、系统和服务器，包括：接收第一应用模块的调用指令后，展示已绑定的支付账户，以供用户从已绑定的支付账户中选择一个支付账户，其中，调用指令携带第一应用模块的商户信息（S101）；向服务器发送绑定令牌授权请求，以供第一应用模块根据请求到的绑定令牌授权码向服务器申请支付令牌，其中，绑定令牌授权请求携带第一应用模块的商户信息、以及用户所选取的支付账户（S102）。

Description

支付令牌申请方法、设备、系统和服务器 技术领域
本申请属于支付安全技术领域，具体涉及一种支付令牌申请方法、设备、系统和服务器。
背景技术
随着互联网的快速发展，人们的支付方式也发生了巨大的变革，消费者从原先使用银行卡在POS机上进行支付，逐渐演变为使用二维码、手机应用(APP)、物联网设备等多种途径进行支付。而支付敏感信息也从单纯的卡号等变得复杂多样，这些敏感信息无论从传递方式、存储位置、加密手段等，都比以前面临着更加严峻的安全风险，如果没有一个安全的支付保障措施，消费者的支付行为将面临不可预估的风险。与此同时，用户越来越频繁地使用手机进行购物和支付。目前，各大银行、第三方支付机构等均推出了自己的钱包应用(例如是
Figure PCTCN2021080495-appb-000001
)。用户使用这些钱包应用时，均需要在各个钱包应用中绑定银行卡进行支付。在一些场景中，用户也会在一些购物应用上绑定银行卡。在各个应用中绑定银行卡的过程，增加了银行卡信息泄露的风险。
发明内容
本申请的目的在于针对现有技术的不足之处，提供一种支付令牌申请方法、设备、系统和服务器。
为解决上述技术问题，本申请采用如下技术方案。
本申请的实施例提供一种支付令牌申请方法，应用于终端设备中的第 二应用模块，所述方法包括：接收第一应用模块的调用指令后，展示已绑定的支付账户，以供用户从已绑定的支付账户中选择一个支付账户，其中，所述调用指令携带所述第一应用模块的商户信息；向服务器发送绑定令牌授权请求，以供所述第一应用模块根据请求到的绑定令牌授权码向所述服务器申请支付令牌，其中，所述绑定令牌授权请求携带所述第一应用模块的商户信息、以及用户所选取的支付账户。
可选地，所述绑定令牌授权请求还携带交易控制参数。
可选地，所述交易控制参数包括：所述支付令牌的有效期、所述支付令牌的单日交易限额和所述支付令牌的单日交易次数中的至少一项。
可选地，还包括：提供设置界面，以供用户设置所述交易控制参数。
可选地，还包括：从服务器接收绑定令牌授权码，并将接收到的绑定令牌授权码转发至所述第一应用模块。
可选地，将接收到的绑定令牌授权码转发至所述第一应用模块的同时，还将所述支付账号的提示信息和/或用户的身份信息的提示信息发送给所述第一应用模块。
本申请的实施例提供一种支付令牌申请方法，应用于终端设备的第一应用模块，所述支付令牌申请方法包括：调用第二应用模块，并向所述第二应用模块传递第一应用模块的商户信息，以供所述第二应用模块向服务器发送绑定令牌授权请求，所述绑定令牌授权请求携带所述第一应用模块的商户信息、以及用户在所述第二应用模块选取的支付账户，其中，所述第一应用模块为调用所述第二应用模块的软件，用户在所述第二应用模块能够选取的支付账户为用户在所述第二应用模块已经绑定的支付账户；接收绑定令牌授权码，所述绑定令牌授权码为所述服务器根据所述绑定令牌 授权请求而生成的；向所述服务器发送支付令牌请求，所述支付令牌请求携带所述绑定令牌授权码；从所述服务器接收支付令牌。
可选地，所述绑定令牌授权码是所述服务器经所述第二应用模块转发至所述第一应用模块的；从所述第二应用模块接收绑定令牌授权码的同时，还从所述第二应用模块接收所述支付账户的提示信息和/或用户的身份信息的提示信息；所述方法还包括：展示所述支付账户的提示信息和/或用户的身份信息的提示信息，以供用户确认所述提示信息是否正确；在用户确认所述提示信息正确的情况下，执行所述向所述服务器发送支付令牌请求的步骤。
可选地，还包括选取第二应用模块的步骤，包括：向所述服务器发送查询请求，以查询所述服务器所支持的应用；展示查询到的应用列表，以供用户从中选取一个应用作为所述第二应用模块。
可选地，在调用所述第二应用模块的情况下，还将加密判别码和所述第一应用模块的商户信息，所述加密判别码为所述第一应用模块在所述服务器进行注册时获取的其商户信息的密文。
可选地，还包括：从服务器接收第一加密数据、第二秘钥和时钟信息，所述第一加密数据为所述绑定令牌授权码经第一秘钥加密得到的密文；根据接收到的时钟信息同步时钟，采用所述第二秘钥以及同步后的时钟信息对自身的商户信息加密得到第二加密数据；在调用所述第二应用模块的情况下，还将所述第二加密数据以及所述第一加密数据发送至所述服务器。
本申请的实施例提供一种支付令牌申请方法，应用于服务器，所述方法包括：从第二应用模块接收绑定令牌授权请求，所述绑定令牌授权请求 携带第一应用模块的商户信息、以及用户在所述第二应用模块的已绑定支付账户中所选取的支付账户；在所述绑定令牌授权请求验证通过的情况下，生成绑定令牌授权码，并将所述绑定令牌授权码发送至所述第一应用模块；从所述第一应用模块接收支付令牌请求，所述支付令牌请求携带所述绑定令牌授权码；在所述支付令牌请求验证通过的情况下，生成支付令牌，并将所述支付令牌发送至所述第一应用模块。
可选地，所述绑定令牌授权请求还携带所述第一应用模块的商户信息；在所述绑定令牌授权码携带的商户信息为已注册的商户信息的情况下，所述绑定令牌授权请求验证通过。
可选地，还包括：对所述第一应用模块提供注册服务；对所述第一应用模块的商户信息进行加密得到加密判别码；将所述加密判别码发送至所述第一应用模块；从所述第一应用模块接收加密判别码和商户信息；对所述加密判别码进行解密，并将解密得到的明文与接收到的商户信息进行比对，如二者一致则所述绑定令牌授权请求验证通过。
可选地，所述支付令牌请求还携带所述第一应用模块的商户信息；对所述支付令牌请求进行验证的步骤包括以下三种验证方式中的至少一种：如所述绑定令牌授权码存在，则验证通过；如所述商户信息与所述绑定令牌授权码申请时的商户信息一致，则验证通过；如所述绑定令牌授权码在有效期内，则验证通过。
可选地，生成所述绑定令牌授权码的同时，还向所述第一应用模块发送第一加密数据、第二秘钥和时钟信息，所述第一加密数据为所述绑定令牌授权码经第一秘钥加密得到的密文；
所述方法还包括：
从所述第一应用模块接收第二加密数据以及第一加密数据；所述方法还包括：采用自身的第二秘钥和自身的时钟信息对自身保留的所述第一应用模块的商户信息加密，得到第三密文，判断所述第三密文与从所述第一应用模块接收的第二密文是否一致，并且判断接收到的第一加密数据经所述第一秘钥解密后得到的绑定令牌授权码与自身保留的绑定令牌授权码是否一致，如均一致则所述支付令牌请求验证通过。
可选地，将所述支付令牌发送至所述第一应用模块，包括：经所述第二应用模块转发而将所述绑定令牌授权码发送至所述第一应用模块。
本申请的实施例提供一种支付令牌申请方法，包括：在终端设备，第一应用模块调用第二应用模块，并向所述第二应用模块传递所述第一应用模块的商户信息；在所述终端设备，所述第二应用模块接收第一应用模块的调用指令后，展示在所述第二应用模块已绑定的支付账户，以供用户从已绑定的支付账户中选择一个支付账户，向服务器发送绑定令牌授权请求，其中，所述绑定令牌授权请求携带所述第一应用模块的商户信息、以及用户所选取的支付账户；在所述服务器，在所述绑定令牌授权请求验证通过的情况下，生成绑定令牌授权码，并将所述绑定令牌授权码发送至所述第一应用模块；在所述终端设备，所述第一应用模块向所述服务器发送支付令牌请求，所述支付令牌请求携带所述绑定令牌授权码；在所述服务器，在所述支付令牌请求验证通过的情况下，生成支付令牌，并将所述支付令牌发送至所述第一应用模块。
本申请的实施例提供一种终端设备，所述终端设备具有第一存储器和第一处理器，所述第一存储器存储第一指令和/或第二指令，所述第一指令在所述第一处理器运行时用于执行前述第一应用模块的支付令牌申请方 法，所述第二指令在所述第一处理器运行以执行前述第二应用模块的支付令牌申请方法。
本申请的实施例提供一种服务器，所述服务器包括第二存储器和第二处理器，所述第二存储器存储支付令牌管理程序，所述第二处理器运行所述支付令牌管理程序以执行前述应用在服务器的支付令牌申请方法。
本申请的实施例提供一种支付令牌申请系统，包括前述的终端设备以及前述述的服务器。
与现有技术相比，本申请的有益效果为：用户只需要在第二应用模块上绑定支付账户(例如是绑定银行卡)，当其需要在第一应用模块绑定支付账户时，可以通过这个已经绑定支付账户的第二应用模块进行操作，第一应用模块不会接触到诸如银行卡号这样的支付敏感信息，增加了支付账户绑定过程中的安全性。
附图说明
图1是本申请的实施例提供的支付令牌申请方法的流程图。
图2是本申请的又一实施例提供的支付令牌申请方法的流程图。
图3是本申请的又一实施例提供的支付令牌申请方法的流程图。
图4是本申请的又一实施例提供的支付令牌申请方法的流程图。
图5是本申请的又一实施例提供的支付令牌申请方法的交互流程图。
图6是本申请的实施例提供的支付账户管理系统的结构框图。
具体实施方式
在本申请中，应理解，诸如“包括”或“具有”等术语旨在指示本说 明书中所公开的特征、数字、步骤、行为、部件、部分或其组合的存在，并且不旨在排除一个或多个其他特征、数字、步骤、行为、部件、部分或其组合存在的可能性。
另外还需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。
本申请的实施例中，终端设备例如是智能手机、平板电脑、或者个人电脑这样的供终端用户操作的设备。第二应用模块例如是
Figure PCTCN2021080495-appb-000002
手机银行、具有支付功能的购物APP这样的进行支付的应用模块，当然也可以是这些应用模块的HTML5页面。第一应用模块指的是需要绑定支付账户(例如是需要绑定银行卡)的软件，同样例如是
Figure PCTCN2021080495-appb-000003
具有支付功能的购物APP，或者它们的HTML5页面。第一应用模块和第二应用模块标号的区别仅在于在应用过程中，第二应用模块已经绑定了支付账户，第一应用模块需要通过第二应用模块的协助申请支付令牌。第一应用模块可和第二应用模块可以完全由软件实现、完全由硬件实现、或者软硬结合的方式实现。服务器提供支付令牌的管理服务。支付令牌(payment token)也称令牌或支付令牌，它是用一段代码代替诸如银行卡号这样的支付敏感信息。
下面结合附图所示的实施例对本申请作进一步说明。
参考图1，本申请实施例所提供的支付令牌申请方法，应用于终端设备的第二应用模块。从软件角度看，执行主体是已经绑定支付账户的软件，例如是
Figure PCTCN2021080495-appb-000004
或者
Figure PCTCN2021080495-appb-000005
页面；从硬件角度看，执行主体可以是运行这些软件的终端设备或者为终端设备提供HTML5页面服务 的服务器。该方法包括以下步骤。
步骤S101、接收第一应用模块的调用指令后，展示已绑定的支付账户，以供用户从已绑定的支付账户中选择一个支付账户，其中，所述调用指令携带所述第一应用模块的商户信息。
商户信息例如是商户号或者令牌请求者编号。商户信息是第一应用模块在服务器的唯一标识。
步骤S102、向服务器发送绑定令牌授权请求，以供所述第一应用模块根据请求到的绑定令牌授权码向所述服务器申请支付令牌，其中，所述绑定令牌授权请求携带所述第一应用模块的商户信息、以及用户所选取的支付账户。
例如第二应用模块展示其已经绑定的支付账户，可以是展示已经绑定的银行卡的部分卡号、已经绑定的银行卡的单日单日交易限额、单日单日交易次数等交易控制参数。用户在第二应用模块上选择一个支付账户作为第一应用模块申请绑定的支付账户。
第二应用模块所申请的绑定令牌授权码是一串编码，作为第一应用模块于服务器之间通信的一个凭证，绑定令牌授权码的编码本身并无特定含义。
服务器可以将绑定令牌授权码直接发送至第一应用模块，也可以是首先发送至第二应用模块，随后所述第二应用模块将接收到的绑定令牌授权码转发至所述第一应用模块。随后，第一应用模块可以凭借这个绑定令牌授权码向服务器申请最终的支付令牌。
用户只需要在第二应用模块上绑定支付账户，第一应用模块通过第二应用模块从服务器获得绑定令牌授权码，然后依靠绑定令牌授权码从服务 器获得支付令牌。如需在第一应用模块上绑定支付账户，第一应用模块在绑卡的全程中都不会接触所要绑定的支付账户，减少了支付账户暴露的机会，增加安全性。
基于图1的支付令牌申请方法，本申请的一些实施例还提供了该支付令牌申请方法的一些具体实施方案，以及扩展方案，下面进行说明。
可选地，所述绑定令牌授权请求还携带交易控制参数。所述交易控制参数例如包括：所述支付令牌的有效期、所述支付令牌的单日交易限额和所述支付令牌的单日交易次数中的至少一项。
交易控制参数可以是默认采用第二应用模块中所选支付账户的交易控制参数。也可以是在所述终端设备，所述第二应用模块还提供设置界面，以供用户设置所述交易控制参数。
可选地，将接收到的绑定令牌授权码转发至所述第一应用模块的同时，还将所述支付账号的提示信息和/或用户的身份信息的提示信息发送给所述第一应用模块。
如此，在所述终端设备，所述第一应用模块能够展示所述支付账号的提示信息和/或用户的身份信息的提示信息，以供用户进行确认。
基于相同的发明构思，参考图2，本申请实施例所提供的支付令牌申请方法，应用于终端设备的第一应用模块。从软件角度看，执行主体是需要绑定支付账户的软件(本文称为第一应用模块)，例如是
Figure PCTCN2021080495-appb-000006
Figure PCTCN2021080495-appb-000007
或者
Figure PCTCN2021080495-appb-000008
页面；从硬件角度看，执行主体可以是运行这些软件的终端设备或者为终端设备提供HTML5页面服务的服务器。该方法包括以下步骤。
步骤S201、调用第二应用模块，并向所述第二应用模块传递第一应用模块的商户信息，以供所述第二应用模块向服务器发送绑定令牌授权请求，所述绑定令牌授权请求携带所述第一应用模块的商户信息、以及用户在所述第二应用模块选取的支付账户，其中，所述第一应用模块为调用所述第二应用模块的软件，用户在所述第二应用模块能够选取的支付账户为用户在所述第二应用模块已经绑定的支付账户。
步骤S202、接收绑定令牌授权码，所述绑定令牌授权码为所述服务器根据所述绑定令牌授权请求而生成的。可以是从服务器接收，也可是经第二应用模块中转而接收。
步骤S203、向所述服务器发送支付令牌请求，所述支付令牌请求携带所述绑定令牌授权码；
步骤S204、从所述服务器接收支付令牌。
第一应用模块通过第二应用模块向服务器申请绑定令牌授权码，然后凭借绑定令牌授权码向服务器申请支付令牌，第一应用模块全程不接触诸如支付账户的敏感信息，提高了安全性。
基于图2的支付令牌申请方法，本申请的一些实施例还提供了该支付令牌申请方法的一些具体实施方案，以及扩展方案，下面进行说明。
可选地，所述绑定令牌授权码是所述服务器经所述第二应用模块转发至所述第一应用模块的；从所述第二应用模块接收绑定令牌授权码的同时，还从所述第二应用模块接收所述支付账户的提示信息和/或用户的身份信息的提示信息；所述方法还包括：展示所述支付账户的提示信息和/或用户的身份信息的提示信息，以供用户确认所述提示信息是否正确；在用户确认所述提示信息正确的情况下，执行所述向所述服务器发送支付令 牌请求的步骤。
支付账号的提示信息例如是银行卡后4位卡号、银行卡类型、银行名称等。用户的身份信息的提示信息例如是用户的隐去部分位后的身份证号、用户为该银行卡注册的手机号等。为用户提供更多的提示信息，供用户确认。
如此，用户可以在第一应用模块对即将绑定的支付账户以及个人信息进行确认。
可选地，还包括选取第二应用模块的步骤，包括：向所述服务器发送查询请求，以查询所述服务器所支持的应用；展示查询到的应用列表，以供用户从中选取一个应用作为所述第二应用模块。
也就是用户可以选择具体通过那个软件作为中转为第一应用模块申请绑定令牌授权码。
除此之外，第一应用模块还可以提供展示界面，展示已经绑定的支付账户的相关信息(例如是发卡银行、账户类型、对应的支付账户的尾号、支付令牌的有效期、交易限额等)。
第一应用模块(此时已经完成绑卡)还可以提供解除绑定的功能。根据用户的解绑操作，第一应用模块向服务器发送标记状态变更的信息即可。
如第二应用模块对第一应用模块所绑定的支付账户进行了操作，第一应用模块也会从服务器接收到相应的通知。第一应用模块可以从该通知中获知支付令牌的最新状态信息。
可选地，在调用所述第二应用模块的情况下，还将加密判别码和所述第一应用模块的商户信息发送至服务器，所述加密判别码为所述第一应用 模块在所述服务器进行注册时获取的其商户信息的密文。
第一应用模块在服务器进行注册时会获得加密判别码，加密判别码是第一应用模块的商户信息经加密后的密文。第一应用模块在发送绑定令牌授权请求的同时还发送加密判别码以及自身的商户信息。服务器可据此对绑定令牌授权请求进行验证。
这样做可以防止某些钓鱼类欺诈APP假冒第一应用模块的相关商户信息，导致用户将银行卡绑定至钓鱼APP中，避免用户财产损失。
可选地，还包括：从服务器接收第一加密数据、第二秘钥和时钟信息，所述第一加密数据为所述绑定令牌授权码经第一秘钥加密得到的密文；根据接收到的时钟信息同步时钟，采用所述第二秘钥以及同步后的时钟信息对自身的商户信息加密得到第二加密数据；在调用所述第二应用模块的情况下，还将所述第二加密数据以及所述第一加密数据发送至所述服务器。
时钟信息的加入，可以实现服务器一定时期无响应时，拒绝第一应用模块的支付令牌的申请，避免用户长时间等待。
基于相同的发明构思，参考图3，本申请的实施例还提供一种支付令牌申请方法，应用于服务器。从软件角度来讲，执行主体为服务器所运行的软件，从硬件角度来讲，执行主体是服务器。该方法包括以下步骤。
步骤S301、从第二应用模块接收绑定令牌授权请求，所述绑定令牌授权请求携带第一应用模块的商户信息、以及用户在所述第二应用模块的已绑定支付账户中所选取的支付账户。
步骤S302、在所述绑定令牌授权请求验证通过的情况下，生成绑定 令牌授权码，并将所述绑定令牌授权码发送至所述第一应用模块。
步骤S303、从所述第一应用模块接收支付令牌请求，所述支付令牌请求携带所述绑定令牌授权码。
步骤S304、在所述支付令牌请求验证通过的情况下，生成支付令牌，并将所述支付令牌发送至所述第一应用模块。
服务器基于与第二应用模块的交互为第一应用模块生成绑定令牌授权码，随后第一应用模块凭借绑定令牌授权码向服务器申请支付令牌。第一应用模块全程不接触支付账户等敏感信息，提高安全性。
基于图3的支付令牌申请方法，本申请的一些实施例还提供了该支付令牌申请方法的一些具体实施方案，以及扩展方案，下面进行说明。
可选地，所述支付令牌请求还携带所述第一应用模块的商户信息；在所述绑定令牌授权码携带的商户信息为已注册的商户信息的情况下，所述绑定令牌授权请求验证通过。
可选地，还包括：对所述第一应用模块提供注册服务；对所述第一应用模块的商户信息进行加密得到加密判别码；将所述加密判别码发送至所述第一应用模块；从所述第一应用模块接收加密判别码和商户信息；对所述加密判别码进行解密，并将解密得到的明文与接收到的商户信息进行比对，如二者一致则所述绑定令牌授权请求验证通过。
也就是第一应用模块在服务器进行注册时，服务器将第一应用模块的商户信息进行加密，并将密文(即上述加密判别码)发送至第一应用模块。第一应用模块需要提供正确的加密判别码和正确的商户信息，才能获得绑定令牌授权码。
这样做可以防止某些钓鱼类欺诈APP假冒商户应用的相关商户信息， 导致用户将银行卡绑定至钓鱼应用中，避免用户财产损失。
对支付令牌请求进行验证的一种方式如下。可选地，所述支付令牌请求还携带所述第一应用模块的商户信息；对所述支付令牌请求进行验证的步骤包括以下三种验证方式中的至少一种：如所述绑定令牌授权码存在，则验证通过；如所述商户信息与所述绑定令牌授权码申请时的商户信息一致，则验证通过；如所述绑定令牌授权码在有效期内，则验证通过。
例如：判断所述支付令牌请求中携带的绑定令牌授权码是否在所述服务器存在，如是，则判断所述支付令牌请求中携带的商户信息是否与所述绑定令牌授权码所对应的绑定令牌授权请求中携带的商户信息一致，如是，则判断当前时间是否在所述绑定令牌授权码的有效期内，如是，则所述支付令牌请求验证通过。
也就是服务器只有判断接收到的支付令牌请求中携带的绑定令牌授权码和商户信息都是正确的并且未超过有效期，支付令牌请求即验证通过。
可选地，生成所述绑定令牌授权码的同时，还向所述第一应用模块发送第一加密数据、第二秘钥和时钟信息，所述第一加密数据为所述绑定令牌授权码经第一秘钥加密得到的密文；所述方法还包括：从所述第一应用模块接收第二加密数据以及第一加密数据；所述方法还包括：采用自身的第二秘钥和自身的时钟信息对自身保留的所述第一应用模块的商户信息加密，得到第三密文，判断所述第三密文与从所述第一应用模块接收的第二密文是否一致，并且判断接收到的第一加密数据经所述第一秘钥解密后得到的绑定令牌授权码与自身保留的绑定令牌授权码是否一致，如均一致，则所述支付令牌请求验证通过。
详细的过程如下：
首先，服务器在生成绑定令牌授权码时，还会生成第一秘钥、第二秘钥，并采用第一秘钥对绑定令牌授权码加密，得到第一加密数据，并将第一加密数据、第二秘钥和时钟信息发送给第一应用模块(可以是直接发送至第一应用模块，也可以是经第二应用模块转发)。
随后，第一应用模块根据接收到的时钟信息进行时钟同步，用第二秘钥和同步后的时钟信息对商户信息加密，形成第二加密数据。第一应用模块向服务器发送第二加密数据、其接受到的第一加密数据。
最后，标记附图提供设备使用自身保存的第二秘钥、自身的时钟信息对自身保存的商户信息加密得到第三加密数据，判断第二加密数据和第三加密数据是否一致，同时用自身保留的第一秘药对第一加密数据进行解密，将解密得到的绑定令牌授权码与自身保存的绑定令牌授权码进行比对，判断是否一致，如果两次判断的结果都是一致的，那么支付令牌请求合法。
由于是在信息的加入，可以实现服务器在一定时期无响应时，拒绝支付令牌请求，避免用户长时间等待。
例如第一应用模块调用第二应用模块，并向服务器发送上述信息。服务器接收到上述信息后并没有及时从第二应用模块接收到绑定令牌授权请求，如此便可以向第一应用模块发送拒绝信息。
可选地，将所述支付令牌发送至所述第一应用模块，包括：经所述第二应用模块转发而将所述绑定令牌授权码发送至所述第一应用模块。
服务器完成支付令牌的分发后，用户在使用第一应用模块时，即可根据该支付令牌进行支付。支付请求会发送至服务器。服务器将支付请求中 的支付令牌替换成支付账户(例如银行卡号)，随后再讲支付请求发送至对应的发卡机构。
发卡机构对于支付令牌发起的支付交易，服务器在转换卡号后的支付请求中增加标记支付标识，发卡机构承兑带标记支付标识但无验证要素的卡号交易。
基于相同的发明构思，参考图4并结合图5，本申请的实施例还提供一种支付令牌申请方法。该方法展示了终端设备上运行的第一应用模块、第二应用模块以及服务器三者之间完整的交互过程。所述支付令牌申请方法包括以下步骤。
步骤S401、在终端设备，第一应用模块调用第二应用模块，并向所述第二应用模块传递所述第一应用模块的商户信息。
步骤S402、在所述终端设备，所述第二应用模块接收第一应用模块的调用指令后，展示在所述第二应用模块已绑定的支付账户，以供用户从已绑定的支付账户中选择一个支付账户，向服务器发送绑定令牌授权请求，其中，所述绑定令牌授权请求携带所述第一应用模块的商户信息、以及用户所选取的支付账户。
步骤S403、在所述服务器，在所述绑定令牌授权请求验证通过的情况下，生成绑定令牌授权码，并将所述绑定令牌授权码发送至所述第一应用模块；
步骤S404、在所述终端设备，所述第一应用模块向所述服务器发送支付令牌请求，所述支付令牌请求携带所述绑定令牌授权码。
步骤S405、在所述服务器，在所述支付令牌请求验证通过的情况 下，生成支付令牌，并将所述支付令牌发送至所述第一应用模块。
各个步骤的实现细节以及变式均可参考前述的实施例，对此不作赘述。
参考图5，在一个具体的例子中，第一步，第一应用模块调用第二应用模块，以在第二应用模块选择需要绑定的银行卡。第二步，第二应用模块向服务器发送绑定令牌授权请求，第一应用模块的商户信息、交易控制参数以及第一应用模块的商户号。第三步，服务器验证绑定令牌授权请求，生成绑定令牌授权码。第四步，服务器将绑定令牌授权码发送至第二应用模块。第五步，第二应用模块将绑定令牌授权码和提示信息发送给第一应用模块。第六步，第一应用模块展示提示信息，供用户确认提示信息是否正确。第七步，第一应用模块向服务器发送支付令牌请求，携带商户信息和绑定令牌授权码。第八步，服务器验证支付令牌请求，验证通过则生成支付令牌并发送至第一应用模块。
参考图6，基于相同的发明构思，本申请的实施例还提供一种终端设备1具有第一存储器11和第一处理器12，第一存储器11存储第一指令和/或第二指令，第一指令在第一处理器12运行时用于执行前述应用于第一应用模块的支付令牌申请方法，第二指令在第一处理器12运行而执行前述应用于第二应用模块的支付令牌申请方法。
相应地，本申请的实施例还提供一种服务器2，服务器2包括第二存储器21和第二处理器22，第二存储器21存储支付令牌管理程序，第二处理器22运行支付令牌管理程序以执行前述应用在服务器的支付令牌申请方法。
相应地，本申请的实施例提供一种支付令牌申请系统，包括上述的终 端设备和上述的服务器。
本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。
本申请的保护范围不限于上述的实施例，显然，本领域的技术人员可以对本申请进行各种改动和变形而不脱离本申请的范围和精神。倘若这些改动和变形属于本申请权利要求及其等同技术的范围，则本申请的意图也包含这些改动和变形在内。

Claims (21)

  1. 一种支付令牌申请方法，其特征在于，应用于终端设备中的第二应用模块，所述方法包括：
    接收第一应用模块的调用指令后，展示已绑定的支付账户，以供用户从已绑定的支付账户中选择一个支付账户，其中，所述调用指令携带所述第一应用模块的商户信息；
    向服务器发送绑定令牌授权请求，以供所述第一应用模块根据请求到的绑定令牌授权码向所述服务器申请支付令牌，其中，所述绑定令牌授权请求携带所述第一应用模块的商户信息、以及用户所选取的支付账户。
  2. 根据权利要求1所述的方法，其特征在于，所述绑定令牌授权请求还携带交易控制参数。
  3. 根据权利要求2所述的方法，其特征在于，所述交易控制参数包括：所述支付令牌的有效期、所述支付令牌的单日交易限额和所述支付令牌的单日交易次数中的至少一项。
  4. 根据权利要求2所述的方法，其特征在于，还包括：提供设置界面，以供用户设置所述交易控制参数。
  5. 根据权利要求1所述的方法，其特征在于，还包括：从所述服务器接收绑定令牌授权码，并将接收到的绑定令牌授权码转发至所述第一应用模块。
  6. 根据权利要求5所述的方法，其特征在于，将接收到的绑定令牌授权码转发至所述第一应用模块的同时，还将所述支付账号的提示信息和/或用户的身份信息的提示信息发送给所述第一应用模块。
  7. 一种支付令牌申请方法，其特征在于，应用于终端设备的第一应用 模块，所述支付令牌申请方法包括：
    调用第二应用模块，并向所述第二应用模块传递所述第一应用模块的商户信息，以供所述第二应用模块向服务器发送绑定令牌授权请求，所述绑定令牌授权请求携带所述第一应用模块的商户信息、以及用户在所述第二应用模块选取的支付账户，其中，所述第一应用模块为调用所述第二应用模块的软件，用户在所述第二应用模块能够选取的支付账户为用户在所述第二应用模块已经绑定的支付账户；
    接收绑定令牌授权码，所述绑定令牌授权码为所述服务器根据所述绑定令牌授权请求而生成的；
    向所述服务器发送支付令牌请求，所述支付令牌请求携带所述绑定令牌授权码；
    从所述服务器接收支付令牌。
  8. 根据权利要求7所述的方法，其特征在于，所述绑定令牌授权码是所述服务器经所述第二应用模块转发至所述第一应用模块的；
    从所述第二应用模块接收绑定令牌授权码的同时，还从所述第二应用模块接收所述支付账户的提示信息和/或用户的身份信息的提示信息；
    所述方法还包括：展示所述支付账户的提示信息和/或用户的身份信息的提示信息，以供用户确认所述提示信息是否正确；
    在用户确认所述提示信息正确的情况下，执行所述向所述服务器发送支付令牌请求的步骤。
  9. 根据权利要求7所述的方法，其特征在于，还包括选取第二应用模块的步骤，包括：
    向所述服务器发送查询请求，以查询所述服务器所支持的应用模块；
    展示查询到的应用模块列表，以供用户从中选取一个应用模块作为所述第二应用模块。
  10. 根据权利要求7所述的方法，其特征在于，在调用所述第二应用模块的情况下，还将加密判别码和所述第一应用模块的商户信息发送至服务器，所述加密判别码为所述第一应用模块在所述服务器进行注册时获取的其商户信息的密文。
  11. 根据权利要求7所述的方法，其特征在于，还包括：从所述服务器接收第一加密数据、第二秘钥和时钟信息，所述第一加密数据为所述绑定令牌授权码经第一秘钥加密得到的密文；
    根据接收到的时钟信息同步时钟，采用所述第二秘钥以及同步后的时钟信息对自身的商户信息加密得到第二加密数据；
    在调用所述第二应用模块的情况下，还将所述第二加密数据以及所述第一加密数据发送至所述服务器。
  12. 一种支付令牌申请方法，其特征在于，应用于服务器，所述方法包括：
    从第二应用模块接收绑定令牌授权请求，所述绑定令牌授权请求携带第一应用模块的商户信息、以及用户在所述第二应用模块的已绑定支付账户中所选取的支付账户；
    在所述绑定令牌授权请求验证通过的情况下，生成绑定令牌授权码，并将所述绑定令牌授权码发送至所述第一应用模块；
    从所述第一应用模块接收支付令牌请求，所述支付令牌请求携带所述绑定令牌授权码；
    在所述支付令牌请求验证通过的情况下，生成支付令牌，并将所述支付令牌发送至所述第一应用模块。
  13. 根据权利要求12所述的方法，其特征在于，所述绑定令牌授权请求还携带所述第一应用模块的商户信息；
    在所述绑定令牌授权码携带的商户信息为已注册的商户信息的情况下，所述绑定令牌授权请求验证通过。
  14. 根据权利要求12所述的方法，其特征在于，还包括：
    对所述第一应用模块提供注册服务；
    对所述第一应用模块的商户信息进行加密得到加密判别码；
    将所述加密判别码发送至所述第一应用模块；
    从所述第一应用模块接收加密判别码和商户信息；
    对所述加密判别码进行解密，并将解密得到的明文与接收到的商户信息进行比对，如二者一致则所述绑定令牌授权请求验证通过。
  15. 根据权利要求12所述的方法，其特征在于，所述支付令牌请求还携带所述第一应用模块的商户信息；对所述支付令牌请求进行验证的步骤包括以下三种验证方式中的至少一种：
    如所述绑定令牌授权码存在，则验证通过；
    如所述商户信息与所述绑定令牌授权码申请时的商户信息一致，则验证通过；
    如所述绑定令牌授权码在有效期内，则验证通过。
  16. 根据权利要求12所述的方法，其特征在于，生成所述绑定令牌授权码的同时，还向所述第一应用模块发送第一加密数据、第二秘钥和时钟信息，所述第一加密数据为所述绑定令牌授权码经第一秘钥加密得到的密 文；
    所述方法还包括：
    从所述第一应用模块接收第二加密数据以及第一加密数据；
    采用自身的第二秘钥和自身的时钟信息对自身保留的所述第一应用模块的商户信息加密，得到第三密文，判断所述第三密文与从所述第一应用模块接收的第二密文是否一致，并且判断接收到的第一加密数据经所述第一秘钥解密后得到的绑定令牌授权码与自身保留的绑定令牌授权码是否一致，如均一致则所述支付令牌请求验证通过。
  17. 根据权利要求12所述的方法，其特征在于，将所述支付令牌发送至所述第一应用模块，包括：经所述第二应用模块转发而将所述绑定令牌授权码发送至所述第一应用模块。
  18. 一种支付令牌申请方法，其特征在于，包括：
    在终端设备，第一应用模块调用第二应用模块，并向所述第二应用模块传递所述第一应用模块的商户信息；
    在所述终端设备，所述第二应用模块接收第一应用模块的调用指令后，展示在所述第二应用模块已绑定的支付账户，以供用户从已绑定的支付账户中选择一个支付账户，向服务器发送绑定令牌授权请求，其中，所述绑定令牌授权请求携带所述第一应用模块的商户信息、以及用户所选取的支付账户；
    在所述服务器，在所述绑定令牌授权请求验证通过的情况下，生成绑定令牌授权码，并将所述绑定令牌授权码发送至所述第一应用模块；
    在所述终端设备，所述第一应用模块向所述服务器发送支付令牌请 求，所述支付令牌请求携带所述绑定令牌授权码；
    在所述服务器，在所述支付令牌请求验证通过的情况下，生成支付令牌，并将所述支付令牌发送至所述第一应用模块。
  19. 一种终端设备，其特征在于，所述终端设备具有第一存储器和第一处理器，所述第一存储器存储第一指令和/或第二指令，所述第一指令在所述第一处理器运行时用于执行权利要求7-11任意一项所述的支付令牌申请方法，所述第二指令在所述第一处理器运行以执行权利要求1-6任意一项所述的支付令牌申请方法。
  20. 一种服务器，其特征在于，所述服务器包括第二存储器和第二处理器，所述第二存储器存储支付令牌管理程序，所述第二处理器运行所述支付令牌管理程序以执行根据权利要求12-17任意一项所述的支付令牌申请方法。
  21. 一种支付令牌申请系统，其特征在于，根据权利要求19所述的终端设备以及根据权利要求20所述的服务器。
PCT/CN2021/080495 2020-06-28 2021-03-12 支付令牌申请方法、设备、系统和服务器 WO2022001176A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010594938.6A CN111861457B (zh) 2020-06-28 2020-06-28 支付令牌申请方法、设备、系统和服务器
CN202010594938.6 2020-06-28

Publications (1)

Publication Number Publication Date
WO2022001176A1 true WO2022001176A1 (zh) 2022-01-06

Family

ID=72988113

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/080495 WO2022001176A1 (zh) 2020-06-28 2021-03-12 支付令牌申请方法、设备、系统和服务器

Country Status (3)

Country Link
CN (1) CN111861457B (zh)
TW (1) TWI775288B (zh)
WO (1) WO2022001176A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111861457B (zh) * 2020-06-28 2023-02-21 中国银联股份有限公司 支付令牌申请方法、设备、系统和服务器
CN112488681A (zh) * 2020-12-11 2021-03-12 广东广宇科技发展有限公司 基于区块链的授权码支付方法、系统、终端及存储介质
CN113159761A (zh) * 2021-01-06 2021-07-23 中国银联股份有限公司 基于设备连接的支付授权转移系统及支付授权转移方法
CN114244627B (zh) * 2022-01-04 2023-12-26 上海华申智能卡应用系统有限公司 一种授权方法及系统

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104899741A (zh) * 2014-03-05 2015-09-09 中国银联股份有限公司 一种基于ic银行卡的在线支付方法以及在线支付系统
CN105897668A (zh) * 2015-10-22 2016-08-24 乐视致新电子科技（天津）有限公司 一种第三方账号授权方法、设备、服务器及其系统
US20180247306A1 (en) * 2017-02-24 2018-08-30 Passport Technology Inc. Systems and methods for rule-based payment card management using tokens
CN109218298A (zh) * 2018-09-04 2019-01-15 中钞信用卡产业发展有限公司杭州区块链技术研究院 一种应用数据访问方法及系统
CN110574060A (zh) * 2017-03-23 2019-12-13 万事达卡国际公司 用于令牌的供应和管理的数字钱包
CN111861457A (zh) * 2020-06-28 2020-10-30 中国银联股份有限公司 支付令牌申请方法、设备、系统和服务器

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2466810A (en) * 2009-01-08 2010-07-14 Visa Europe Ltd Processing payment authorisation requests
EP3078156A4 (en) * 2013-10-11 2017-07-12 Visa International Service Association Network token system
CN105812341B (zh) * 2014-12-31 2019-03-29 阿里巴巴集团控股有限公司 一种标识用户身份的方法及装置
KR20170118431A (ko) * 2016-04-15 2017-10-25 삼성전자주식회사 전자 장치 및 이를 이용한 결제 방법
CN107403312B (zh) * 2016-05-18 2024-03-26 北京三星通信技术研究有限公司 快捷支付方法和装置
CN106652227B (zh) * 2016-10-14 2020-03-27 中国银联股份有限公司 一种智能汽车支付系统以及支付方法
SG10201803139UA (en) * 2018-04-13 2019-11-28 Mastercard International Inc Method and system for facilitating designated payment transaction

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104899741A (zh) * 2014-03-05 2015-09-09 中国银联股份有限公司 一种基于ic银行卡的在线支付方法以及在线支付系统
CN105897668A (zh) * 2015-10-22 2016-08-24 乐视致新电子科技（天津）有限公司 一种第三方账号授权方法、设备、服务器及其系统
US20180247306A1 (en) * 2017-02-24 2018-08-30 Passport Technology Inc. Systems and methods for rule-based payment card management using tokens
CN110574060A (zh) * 2017-03-23 2019-12-13 万事达卡国际公司 用于令牌的供应和管理的数字钱包
CN109218298A (zh) * 2018-09-04 2019-01-15 中钞信用卡产业发展有限公司杭州区块链技术研究院 一种应用数据访问方法及系统
CN111861457A (zh) * 2020-06-28 2020-10-30 中国银联股份有限公司 支付令牌申请方法、设备、系统和服务器

Also Published As

Publication number Publication date
TW202201310A (zh) 2022-01-01
CN111861457A (zh) 2020-10-30
CN111861457B (zh) 2023-02-21
TWI775288B (zh) 2022-08-21

Similar Documents

Publication Publication Date Title
CN112602300B (zh) 用于非接触式卡的密码认证的系统和方法
CN108476227B (zh) 用于设备推送供应的系统和方法
AU2016244274B2 (en) Credential provision and proof system
WO2022001176A1 (zh) 支付令牌申请方法、设备、系统和服务器
KR101621254B1 (ko) 오티피 기반의 가상 번호 결제 방법, 컴퓨터 판독가능한 기록매체 및 시스템
EP1710980B1 (en) Authentication services using mobile device
US20110103586A1 (en) System, Method and Device To Authenticate Relationships By Electronic Means
CN113168635A (zh) 用于非接触式卡的密码认证的系统和方法
JP7483688B2 (ja) 非接触カードの暗号化認証のためのシステムおよび方法
US20230396441A1 (en) Systems and methods for cryptographic authentication of contactless cards
JP2017537421A (ja) 支払いトークンのセキュリティを確保する方法
CN112602104A (zh) 用于非接触卡的密码认证的系统和方法
CN112352410B (zh) 使用智能卡作为安全令牌的方法和装置，可读存储介质
CN113168631A (zh) 用于非接触卡的密码认证的系统和方法
CN112655010A (zh) 用于非接触式卡的密码认证的系统和方法
KR101754486B1 (ko) 계좌정보를 이용한 모바일 결제 서비스 제공 방법
CN113169873A (zh) 用于非接触卡的密码认证的系统和方法
EP4053720A1 (en) Secure online authentication method using mobile id document
CN118076964A (zh) 高效且受保护的数据传输系统和方法

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: 21833526

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: 21833526

Country of ref document: EP

Kind code of ref document: A1