CN111861457B - Payment token application method, device, system and server - Google Patents
Payment token application method, device, system and server Download PDFInfo
- Publication number
- CN111861457B CN111861457B CN202010594938.6A CN202010594938A CN111861457B CN 111861457 B CN111861457 B CN 111861457B CN 202010594938 A CN202010594938 A CN 202010594938A CN 111861457 B CN111861457 B CN 111861457B
- Authority
- CN
- China
- Prior art keywords
- application module
- payment
- token
- binding
- server
- Prior art date
- Legal status (The legal status 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 status listed.)
- Active
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
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
The application provides a payment token application method, device, system and server. The method comprises the following steps: after receiving a calling instruction of a first application module, displaying the bound payment accounts so that a user can select one payment account from the bound payment accounts, wherein the calling instruction carries merchant information of the first application module; sending a binding token authorization request to a server, so that the first application module applies for a payment token from the server according to the binding token authorization code, wherein the binding token authorization request carries merchant information of the first application module and a payment account selected by a user. By adopting the method, the safety in the process of binding the payment account can be increased.
Description
Technical Field
The application belongs to the technical field of payment security, and particularly relates to a payment token application method, device, system and server.
Background
With the rapid development of the internet, people's payment mode has also undergone a huge revolution, and consumers gradually evolve to pay by using multiple ways such as two-dimensional codes, mobile phone Applications (APPs), internet of things devices and the like from the original use of bank cards on POS machines. The payment sensitive information is also changed from a simple card number and the like into complex and various information, the sensitive information faces more severe safety risks than the prior sensitive information in a transmission mode, a storage position, an encryption means and the like, and if no safe payment guarantee measure exists, the payment behavior of a consumer faces unpredictable risks. At the same time, users are shopping and paying more and more frequently using mobile phones. Currently, each big bank, third party payment authority, etc. has introduced its own wallet application (for example, cloud flash protection). When the users use the wallet applications, bank cards are bound in each wallet application to pay. In some scenarios, the user may also bind a bank card on some shopping applications. The process of binding the bank card in each application increases the risk of information leakage of the bank card.
Disclosure of Invention
The application aims to provide a payment token application method, equipment, a system and a server aiming at the defects in the prior art.
In order to solve the technical problem, the following technical scheme is adopted in the application.
The embodiment of the application provides a payment token application method, which is applied to a second application module in terminal equipment, and the method comprises the following steps: after receiving a calling instruction of a first application module, displaying the bound payment accounts so that a user can select one payment account from the bound payment accounts, wherein the calling instruction carries merchant information of the first application module; sending a binding token authorization request to a server, so that the first application module applies for a payment token from the server according to the binding token authorization code, wherein the binding token authorization request carries merchant information of the first application module and a payment account selected by a user.
Optionally, the binding token authorization request further carries transaction control parameters.
Optionally, the transaction control parameters include: at least one of an expiration date of the payment token, a single-day transaction limit of the payment token, and a number of single-day transactions of the payment token.
Optionally, the method further comprises: and providing a setting interface for a user to set the transaction control parameters.
Optionally, the method further comprises: receiving a binding token authorization code from a server and forwarding the received binding token authorization code to the first application module.
Optionally, while forwarding the received binding token authorization code to the first application module, sending prompt information of the payment account and/or prompt information of the identity information of the user to the first application module.
The embodiment of the application provides a payment token application method, which is applied to a first application module of a terminal device and comprises the following steps: calling a second application module, and transmitting merchant information of a first application module to the second application module, so that the second application module sends a binding token authorization request to a server, wherein the binding token authorization request carries the merchant information of the first application module and a payment account selected by a user in the second application module, the first application module is software for calling the second application module, and the payment account which can be selected by the user in the second application module is a payment account already bound by the user in the second application module; receiving a binding token authorization code, the binding token authorization code being generated by the server in accordance with the binding token authorization request; sending a payment token request to the server, wherein the payment token request carries the binding token authorization code; a payment token is received from the server.
Optionally, the binding token authorization code is forwarded by the server to the first application module via the second application module; receiving prompt information of the payment account and/or prompt information of identity information of the user from the second application module while receiving the binding token authorization code from the second application module; the method further comprises the following steps: displaying prompt information of the payment account and/or prompt information of identity information of the user so that the user can confirm whether the prompt information is correct or not; and under the condition that the user confirms that the prompt message is correct, executing the step of sending a payment token request to the server.
Optionally, the method further includes a step of selecting a second application module, including: sending a query request to the server to query applications supported by the server; and displaying the inquired application list so that the user can select one application from the application list as the second application module.
Optionally, in a case of calling the second application module, an encrypted discrimination code and the merchant information of the first application module are further used, where the encrypted discrimination code is a ciphertext of the merchant information of the first application module obtained when the first application module is registered in the server.
Optionally, the method further comprises: receiving first encrypted data, a second secret key and clock information from a server, wherein the first encrypted data is a ciphertext obtained by encrypting the binding token authorization code through the first secret key; synchronizing a clock according to the received clock information, and encrypting the merchant information of the merchant by adopting the second secret key and the synchronized clock information to obtain second encrypted data; and under the condition of calling the second application module, the second encrypted data and the first encrypted data are also sent to the server.
The embodiment of the application provides a payment token application method, which is applied to a server and comprises the following steps: receiving a binding token authorization request from a second application module, wherein the binding token authorization request carries merchant information of a first application module and a payment account selected by a user from bound payment accounts of the second application module; generating a binding token authorization code under the condition that the binding token authorization request passes verification, and sending the binding token authorization code to the first application module; receiving a payment token request from the first application module, the payment token request carrying the binding token authorization code; and generating a payment token and sending the payment token to the first application module under the condition that the payment token request passes verification.
Optionally, the binding token authorization request further carries merchant information of the first application module; and under the condition that the merchant information carried by the binding token authorization code is the registered merchant information, the binding token authorization request passes verification.
Optionally, the method further comprises: providing a registration service to the first application module; encrypting the merchant information of the first application module to obtain an encryption distinguishing code; sending the encrypted discrimination code to the first application module; receiving an encrypted discrimination code and merchant information from the first application module; and decrypting the encrypted discrimination code, comparing the plaintext obtained by decryption with the received merchant information, and if the plaintext obtained by decryption is consistent with the merchant information, verifying the binding token authorization request.
Optionally, the payment token request further carries merchant information of the first application module; the step of verifying the payment token request comprises at least one of the following three verification methods: if the binding token authorization code exists, the authentication is passed; if the merchant information is consistent with the merchant information when the binding token authorization code is applied, the authentication is passed; and if the binding token authorization code is in the valid period, the authentication is passed.
Optionally, while generating the binding token authorization code, sending first encrypted data, a second secret key, and clock information to the first application module, where the first encrypted data is a ciphertext obtained by encrypting the binding token authorization code with a first secret key;
the method further comprises the following steps:
receiving second encrypted data and first encrypted data from the first application module; the method further comprises the following steps: and encrypting the merchant information of the first application module reserved by the first application module by using a second secret key of the first application module and clock information of the first application module to obtain a third ciphertext, judging whether the third ciphertext is consistent with the second ciphertext received from the first application module, judging whether a binding token authorization code obtained after the received first encrypted data is decrypted by the first secret key is consistent with a binding token authorization code reserved by the first application module, and if so, passing the verification of the payment token request.
Optionally, sending the payment token to the first application module comprises: sending the binding token authorization code to the first application module for forwarding by the second application module.
An embodiment of the application provides a payment token application method, which includes: at a terminal device, a first application module calls a second application module and transmits merchant information of the first application module to the second application module; after receiving a calling instruction of a first application module, a second application module of the terminal device displays a payment account bound in the second application module so that a user can select one payment account from the bound payment accounts and sends a binding token authorization request to a server, wherein the binding token authorization request carries merchant information of the first application module and the payment account selected by the user; in the server, generating a binding token authorization code and sending the binding token authorization code to the first application module under the condition that the binding token authorization request passes verification; at the terminal equipment, the first application module sends a payment token request to the server, wherein the payment token request carries the binding token authorization code; and generating a payment token and sending the payment token to the first application module by the server under the condition that the payment token request passes the verification.
The embodiment of the application provides a terminal device, which is provided with a first memory and a first processor, wherein the first memory stores a first instruction and/or a second instruction, the first instruction is used for executing a payment token application method of the first application module when the first processor is operated, and the second instruction is operated on the first processor to execute the payment token application method of the second application module.
Embodiments of the present application provide a server, which includes a second memory and a second processor, where 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 to the server.
An embodiment of the present application provides a payment token application system, which includes the foregoing terminal device and the foregoing server.
Compared with the prior art, the beneficial effect of this application is: the user only needs to bind the payment account (such as binding a bank card) on the second application module, when the user needs to bind the payment account on the first application module, the user can operate through the second application module already bound with the payment account, the first application module does not contact payment sensitive information such as a bank card number, and the security in the process of binding the payment account is improved.
Drawings
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 yet another embodiment of the present application.
Fig. 3 is a flowchart of a payment token application method provided by yet another embodiment of the present application.
Fig. 4 is a flowchart of a payment token application method provided by yet another embodiment of the present application.
Fig. 5 is an interaction flow diagram of a payment token application method provided by yet another embodiment of the present application.
Fig. 6 is a block diagram of a payment account management system according to an embodiment of the present application.
Detailed Description
In this application, it is to be understood that terms such as "including" or "having" are intended to indicate the presence of the disclosed features, numbers, steps, acts, components, parts, or combinations thereof, and are not intended to preclude the presence or addition of one or more other features, numbers, steps, acts, components, parts, or combinations thereof.
It should also be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict. The present application will be described in detail below with reference to the embodiments with reference to the attached drawings.
In the embodiment of the present application, the terminal device is, for example, a device operated by an end user, such as a smart phone, a tablet computer, or a personal computer. The second application module is, for example, an application module for payment such as cloud flash payment, mobile banking, and shopping APP with payment function, and may also be an HTML5 page of the application modules. The first application module refers to software needing to bind a payment account (for example, needing to bind a bank card), and is also for example, cloud flash payment applications, shopping APP with a payment function, or HTML5 pages of the applications. The first application module and the second application module are different in reference number only in that the second application module already binds to the payment account in the application process, and the first application module needs to apply for the payment token with the assistance of the second application module. The first application module and the second application module can be implemented completely by software, completely by hardware, or by a combination of software and hardware. The server provides a management service for the payment token. Payment tokens (payment tokens), also known as tokens or payment tokens, are payment sensitive information such as bank card numbers that are replaced with a code.
The application is further described with reference to examples of embodiments shown in the drawings.
Referring to fig. 1, the payment token application method provided in the embodiment of the present application is applied to a second application module of a terminal device. From the software perspective, the execution subject is software bound with the payment account, for example, the software is a set of applications flashed in cloud or set of HTML5 pages flashed in cloud; from a hardware perspective, the executing agent may be a terminal device running these software or a server providing HTML5 page service for the terminal device. The method comprises the following steps.
Step S101, after receiving a calling instruction of a first application module, displaying the bound payment accounts so that a user can select one payment account from the bound payment accounts, wherein the calling instruction carries merchant information of the first application module.
The merchant information is, for example, a merchant number or a token requestor number. The merchant information is a unique identifier of the first application module at the server.
Step S102, sending a binding token authorization request to a server, so that the first application module applies for a payment token from the server according to a binding token authorization code obtained by the request, wherein the binding token authorization request carries merchant information of the first application module and a payment account selected by a user.
For example, the second application module displays the bound payment account, and may display transaction control parameters such as a partial card number of the bound bank card, a single-day transaction limit of the bound bank card, and a single-day transaction number of the bound bank card. And the user selects one payment account on the second application module as the payment account which is applied for binding by the first application module.
The binding token authorization code applied by the second application module is a series of codes and is used as a certificate for communication between the first application module and the server, and the code of the binding token authorization code has no specific meaning.
The server may directly send the binding token authorization code to the first application module, or may first send the binding token authorization code to the second application module, and then the second application module forwards the received binding token authorization code to the first application module. The first application module may then apply for a final payment token from the server by means of this binding token authorization code.
The user only needs to bind the payment account on the second application module, and 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 means of the binding token authorization code. If the payment account needs to be bound on the first application module, the first application module does not contact the payment account to be bound in the whole card binding process, the exposure opportunity of the payment account is reduced, and the safety is improved.
Based on the payment token application method of fig. 1, some embodiments of the present application also provide some specific embodiments of the payment token application method, and an extension scheme, which are described below.
Optionally, the binding token authorization request further carries transaction control parameters. The transaction control parameters include, for example: at least one of an expiration date of the payment token, a single-day transaction limit of the payment token, and a number of single-day transactions of the payment token.
The transaction control parameters may be transaction control parameters that default to the selected payment account in the second application module. The second application module may further provide a setting interface for the user to set the transaction control parameter at the terminal device.
Optionally, while forwarding the received binding token authorization code to the first application module, sending prompt information of the payment account and/or prompt information of the identity information of the user to the first application module.
Therefore, in the terminal device, the first application module can display prompt information of the payment account and/or prompt information of identity information of the user for the user to confirm.
Based on the same inventive concept, referring to fig. 2, the payment token application method provided in the embodiment of the present application is applied to a first application module of a terminal device. From the software perspective, the execution subject is software (referred to as a first application module) needing to bind the payment account, for example, cloud flash protection applications or cloud flash protection HTML5 pages; from a hardware perspective, the executing agent may be a terminal device running these software or a server providing HTML5 page service for the terminal device. The method comprises the following steps.
Step S201, invoking a second application module, and transmitting merchant information of a first application module to the second application module, so that the second application module sends a binding token authorization request to a server, where the binding token authorization request carries the merchant information of the first application module and a payment account selected by a user in the second application module, where the first application module is software invoking the second application module, and the payment account that the user can select in the second application module is a payment account already bound by the user in the second application module.
Step S202, receiving a binding token authorization code, wherein the binding token authorization code is generated by the server according to the binding token authorization request. The receiving may be from the server or may be received via a second application module.
Step S203, sending a payment token request to the server, wherein the payment token request carries the binding token authorization code;
step S204, receiving a payment token from the server.
The first application module applies for the binding token authorization code to the server through the second application module, then applies for the payment token to the server through the binding token authorization code, and the first application module does not contact sensitive information such as a payment account in the whole process, so that the safety is improved.
Based on the payment token application method of fig. 2, some embodiments of the present application also provide some specific embodiments of the payment token application method, and an extension scheme, which are described below.
Optionally, the binding token authorization code is forwarded by the server to the first application module via the second application module; receiving prompt information of the payment account and/or prompt information of identity information of the user from the second application module while receiving the binding token authorization code from the second application module; the method further comprises the following steps: displaying prompt information of the payment account and/or prompt information of identity information of the user so that the user can confirm whether the prompt information is correct or not; and under the condition that the user confirms that the prompt message is correct, executing the step of sending a payment token request to the server.
The prompt information of the payment account is, for example, a 4-digit card number after the bank card, a bank card type, a bank name and the like. The prompt information of the identity information of the user is, for example, an identification number of the user after hiding a part of the position, a mobile phone number registered for the bank card by the user, and the like. More prompt messages are provided for the user to confirm.
In this way, the user can confirm the payment account to be bound and the personal information at the first application module.
Optionally, the method further includes a step of selecting a second application module, including: sending a query request to the server to query applications supported by the server; and displaying the inquired application list so that the user can select one application from the application list as the second application module.
That is, the user may select the software to be converted into the first application module to apply for the binding token authorization code.
In addition, the first application module may provide a presentation interface for presenting information related to the bound payment account (e.g., card issuing bank, account type, tail number of the corresponding payment account, validity period of the payment token, transaction limit, etc.).
The first application module (now binding card has been completed) may also provide the function of unbinding. According to the unbinding operation of the user, the first application module only needs to send information of the change of the marking state to the server.
If the second application module operates the payment account bound to the first application module, the first application module also receives a corresponding notification from the server. The first application module may learn the latest state information of the payment token from the notification.
Optionally, in a case of calling the second application module, an encrypted discrimination code and the merchant information of the first application module are further sent to a server, where the encrypted discrimination code is a ciphertext of the merchant information of the first application module obtained when the first application module registers in the server.
The first application module obtains an encryption judgment code when the server registers, and the encryption judgment code is a ciphertext of the encrypted merchant information of the first application module. The first application module sends a binding token authorization request and also sends an encryption distinguishing code and merchant information of the first application module. The server can verify the binding token authorization request accordingly.
By the method, the situation that some phishing type fraud APPs forge relevant merchant information of the first application module to cause the user to bind the bank card to the phishing APP can be prevented, and property loss of the user is avoided.
Optionally, the method further comprises: receiving first encrypted data, a second secret key and clock information from a server, wherein the first encrypted data is a ciphertext obtained by encrypting the binding token authorization code through the first secret key; synchronizing a clock according to the received clock information, and encrypting the merchant information of the merchant by adopting the second secret key and the synchronized clock information to obtain second encrypted data; and under the condition of calling the second application module, the second encrypted data and the first encrypted data are also sent to the server.
The clock information is added, so that the application of the payment token of the first application module is refused when the server does not respond for a certain period, and the long-time waiting of a user is avoided.
Based on the same inventive concept, referring to fig. 3, an embodiment of the present application further provides a payment token application method applied to a server. From the software perspective, the execution subject is software executed by the server, and from the hardware perspective, the execution subject is the server. The method comprises the following steps.
Step S301, receiving a binding token authorization request from a second application module, where the binding token authorization request carries merchant information of the first application module and a payment account selected by a user from the bound payment accounts of the second application module.
Step S302, generating a binding token authorization code under the condition that the binding token authorization request passes verification, and sending the binding token authorization code to the first application module.
Step S303, receiving a payment token request from the first application module, where the payment token request carries the binding token authorization code.
Step S304, generating a payment token under the condition that the payment token request passes verification, and sending the payment token to the first application module.
The server generates a binding token authorization code for the first application module based on interaction with the second application module, and the first application module subsequently applies for a payment token from the server by means of the binding token authorization code. The first application module does not contact sensitive information such as a payment account in the whole process, and the safety is improved.
Based on the payment token application method of fig. 3, some embodiments of the present application also provide some specific embodiments of the payment token application method, and an extension scheme, which are described below.
Optionally, the payment token request further carries merchant information of the first application module; and under the condition that the merchant information carried by the binding token authorization code is the registered merchant information, the binding token authorization request passes verification.
Optionally, the method further comprises: providing a registration service to 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; receiving an encrypted discrimination code and merchant information from the first application module; and decrypting the encrypted discrimination code, comparing the plaintext obtained by decryption with the received merchant information, and if the plaintext obtained by decryption is consistent with the received merchant information, verifying the authorization request of the binding token.
That is, when the first application module registers in the server, the server encrypts the merchant information of the first application module and sends the ciphertext (i.e., the encrypted discrimination code) to the first application module. The first application module needs to provide the correct encrypted discrimination code and the correct merchant information to obtain the binding token authorization code.
By the method, the situation that some phishing fraud APP imitates the relevant merchant information of the merchant application to cause the user to bind the bank card into the phishing application can be prevented, and property loss of the user is avoided.
One way to validate a payment token request is as follows. Optionally, the payment token request further carries merchant information of the first application module; the step of verifying the payment token request comprises at least one of the following three verification methods: if the binding token authorization code exists, the verification is passed; if the merchant information is consistent with the merchant information when the binding token authorization code is applied, the merchant information passes the verification; and if the binding token authorization code is in the valid period, the authentication is passed.
For example: and judging whether a binding token authorization code carried in the payment token request exists in the server, if so, judging whether merchant information carried in the payment token request is consistent with merchant information carried in the binding token authorization request corresponding to the binding token authorization code, if so, judging whether the current time is within the validity period of the binding token authorization code, and if so, verifying the payment token request.
That is, the server only judges that the binding token authorization code and the merchant information carried in the received payment token request are correct and do not exceed the validity period, and the payment token request is verified.
Optionally, while generating the binding token authorization code, sending first encrypted data, a second secret key, and clock information to the first application module, where the first encrypted data is a ciphertext obtained by encrypting the binding token authorization code with a first secret key; the method further comprises the following steps: receiving second encrypted data and first encrypted data from the first application module; the method further comprises the following steps: and encrypting the merchant information of the first application module reserved by the merchant by using a second secret key of the merchant and clock information of the merchant to obtain a third ciphertext, judging whether the third ciphertext is consistent with the second ciphertext received from the first application module, judging whether a binding token authorization code obtained after the received first encrypted data is decrypted by the first secret key is consistent with a binding token authorization code reserved by the merchant, and if so, judging that the payment token request passes the verification.
The detailed process is as follows:
first, when the server generates the binding token authorization code, the server also generates a first key and a second key, encrypts the binding token authorization code by using the first key to obtain first encrypted data, and sends the first encrypted data, the second key and the clock information to the first application module (either directly to the first application module or forwarded by the second application module).
And then, the first application module carries out clock synchronization according to the received clock information, and encrypts the merchant information by using a second secret key and the synchronized clock information to form second encrypted data. And the first application module sends the second encrypted data and the received first encrypted data to the server.
And finally, the marked figure provides that the equipment encrypts merchant information stored by the equipment by using a second secret key stored by the equipment and clock information of the equipment to obtain third encrypted data, judges whether the second encrypted data is consistent with the third encrypted data, decrypts the first encrypted data by using a first secret drug reserved by the equipment, compares a binding token authorization code obtained by decryption with a binding token authorization code stored by the equipment to judge whether the binding token authorization code is consistent, and if the results of two judgments are consistent, the payment token request is legal.
Because the information is added, the server can refuse the request of the payment token when the server does not respond for a certain period, and the long-time waiting of the user is avoided.
For example, the first application module calls the second application module and sends the information to the server. The server does not receive the binding token authorization request from the second application module in time after receiving the information, so that rejection information can be sent to the first application module.
Optionally, sending the payment token to the first application module comprises: the binding token authorization code is sent to the first application module forwarded via the second application module.
After the server finishes the distribution of the payment token, the user can pay 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 (e.g., a bank card number) and then forwards the payment request to the corresponding issuer.
For the payment transaction initiated by the payment token, the server adds a marked payment identifier in the payment request after the card number is converted, and the card issuing organization accepts the card number transaction with the marked payment identifier but without verification elements.
Based on the same inventive concept, referring to fig. 4 in combination with fig. 5, an embodiment of the present application further provides a payment token application method. The method shows a complete interaction process among the first application module, the second application module and the server which run on the terminal equipment. The payment token application method comprises the following steps.
Step S401, in the terminal device, the first application module calls a second application module and transmits the merchant information of the first application module to the second application module.
Step S402, after receiving a call instruction of a first application module, a second application module displays the payment accounts bound in the second application module, so that a user can select one payment account from the bound payment accounts, and sends a binding token authorization request to a server, wherein the binding token authorization request carries merchant information of the first application module and the payment account selected by the user.
Step S403, in the server, generating a binding token authorization code under the condition that the binding token authorization request passes verification, and sending the binding token authorization code to the first application module;
step S404, in the terminal device, the first application module sends a payment token request to the server, and the payment token request carries the binding token authorization code.
Step S405, generating a payment token and sending the payment token to the first application module by the server under the condition that the payment token request passes verification.
The implementation details and variations of each step can refer to the foregoing embodiments, which are not described in detail.
Referring to fig. 5, in a specific example, in a first step, the first application module calls the second application module to select a bank card to be bound at the second application module. And secondly, the second application module sends a binding token authorization request, the merchant information of the first application module, the transaction control parameters and the merchant number of the first application module to the server. And thirdly, the server verifies the binding token authorization request and generates a binding token authorization code. And fourthly, the server sends the binding token authorization code to the second application module. And fifthly, the second application module sends the binding token authorization code and the prompt message to the first application module. And sixthly, the first application module displays the prompt message for the user to confirm whether the prompt message is correct or not. And seventhly, the first application module sends a payment token request to the server, wherein the payment token request carries the merchant information and the binding token authorization code. And eighthly, the server verifies the payment token request, and if the payment token request passes the verification, a payment token is generated and sent to the first application module.
Referring to fig. 6, based on the same inventive concept, the embodiment of the present application further provides a terminal device 1 having a first memory 11 and a first processor 12, where the first memory 11 stores a first instruction and/or a second instruction, the first instruction is used to execute the aforementioned payment token application method applied to the first application module when the first processor 12 is operated, and the second instruction is used to execute the aforementioned payment token application method applied to the second application module when the first processor 12 is operated.
Accordingly, 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 to execute the aforementioned payment token application method applied to the server.
Accordingly, an embodiment of the present application provides a payment token application system, including the above terminal device and the above server.
The embodiments in the present application are described in a progressive manner, and the same and similar parts among the embodiments can be referred to each other, and each embodiment focuses on differences from other embodiments.
The protective scope of the present application is not limited to the above-described embodiments, and it is apparent that various modifications and variations can be made to the present application by those skilled in the art without departing from the scope and spirit of the present application. It is intended that the present application also include such modifications and variations as come within the scope of the appended claims and their equivalents.
Claims (21)
1. A payment token application method applied to a second application module in a terminal device, the method comprising:
after receiving a calling instruction of a first application module, displaying the bound payment accounts so that a user can select one payment account from the bound payment accounts, wherein the calling instruction carries merchant information of the first application module;
sending a binding token authorization request to a server, so that the first application module applies for a payment token from the server according to a binding token authorization code obtained by the binding token authorization request, wherein the binding token authorization request carries merchant information of the first application module and a payment account selected by a user, and the server generates the payment token and sends the payment token to the first application module under the condition that the payment token request passes verification.
2. The method of claim 1, wherein the binding token authorization request further carries transaction control parameters.
3. The method of claim 2, wherein the transaction control parameters comprise: at least one of an expiration date of the payment token, a single-day transaction limit of the payment token, and a number of single-day transactions of the payment token.
4. The method of claim 2, further comprising: and providing a setting interface for a user to set the transaction control parameters.
5. The method of claim 1, further comprising: receiving a binding token authorization code from the server and forwarding the received binding token authorization code to the first application module.
6. The method of claim 5, wherein the received binding token authorization code is forwarded to the first application module while prompting information for the payment account and/or user identity information is sent to the first application module.
7. A payment token application method applied to a first application module of a terminal device, the payment token application method comprising:
calling a second application module, and transmitting 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 a server, wherein the binding token authorization request carries the merchant information of the first application module and a payment account selected by a user in the second application module, the first application module is software for calling the second application module, and the payment account which can be selected by the user in the second application module is a payment account already bound by the user in the second application module;
receiving a binding token authorization code, the binding token authorization code being generated by the server in accordance with the binding token authorization request;
sending a payment token request to the server, wherein the payment token request carries the binding token authorization code;
a payment token is received from the server.
8. The method of claim 7, wherein the binding token authorization code is forwarded by the server to the first application module via the second application module;
receiving prompt information of the payment account and/or prompt information of identity information of a user from the second application module while receiving a binding token authorization code from the second application module;
the method further comprises the following steps: displaying prompt information of the payment account and/or prompt information of identity information of the user so that the user can confirm whether the prompt information is correct or not;
and under the condition that the user confirms that the prompt message is correct, executing the step of sending a payment token request to the server.
9. The method of claim 7, further comprising the step of selecting a second application module comprising:
sending a query request to the server to query the application modules supported by the server;
and displaying the inquired application module list so that the user can select one application module from the application module list as the second application module.
10. The method according to claim 7, wherein in a case where the second application module is invoked, an encrypted discrimination code and the merchant information of the first application module are also sent to a server, and the encrypted discrimination code is a ciphertext of the merchant information of the first application module obtained when the server registers.
11. The method of claim 7, further comprising: receiving first encrypted data, a second secret key and clock information from the server, wherein the first encrypted data is a ciphertext obtained by encrypting the binding token authorization code through the first secret key;
synchronizing a clock according to the received clock information, and encrypting the merchant information of the merchant by adopting the second secret key and the synchronized clock information to obtain second encrypted data;
and under the condition of calling the second application module, the second encrypted data and the first encrypted data are also sent to the server.
12. A payment token application method, applied to a server, the method comprising:
receiving a binding token authorization request from a second application module, wherein the binding token authorization request carries merchant information of a first application module and a payment account selected by a user from bound payment accounts of the second application module;
generating a binding token authorization code under the condition that the binding token authorization request passes verification, and sending the binding token authorization code to the first application module;
receiving a payment token request from the first application module, the payment token request carrying the binding token authorization code;
and generating a payment token and sending the payment token to the first application module under the condition that the payment token request passes verification.
13. The method of claim 12, wherein the binding token authorization request further carries merchant information for the first application module;
and under the condition that the merchant information carried by the binding token authorization code is the registered merchant information, the binding token authorization request passes verification.
14. The method of claim 12, further comprising:
providing a registration service to the first application module;
encrypting the merchant information of the first application module to obtain an encryption distinguishing code;
sending the encrypted discrimination code to the first application module;
receiving an encrypted discrimination code and merchant information from the first application module;
and decrypting the encrypted discrimination code, comparing the plaintext obtained by decryption with the received merchant information, and if the plaintext obtained by decryption is consistent with the received merchant information, verifying the authorization request of the binding token.
15. The method of claim 12, wherein the payment token request further carries merchant information for the first application module; the step of verifying the payment token request comprises at least one of the following three verification methods:
if the binding token authorization code exists, the authentication is passed;
if the merchant information is consistent with the merchant information when the binding token authorization code is applied, the authentication is passed;
and if the binding token authorization code is within the valid period, the verification is passed.
16. The method according to claim 12, wherein the first application module is further configured to send first encrypted data, a second secret key, and clock information to the first application module while generating the binding token authorization code, where the first encrypted data is a ciphertext obtained by encrypting the binding token authorization code with the first secret key;
the method further comprises the following steps:
receiving second encrypted data and first encrypted data from the first application module;
and encrypting the merchant information of the first application module reserved by the first application module by using a second secret key of the first application module and clock information of the first application module to obtain a third ciphertext, judging whether the third ciphertext is consistent with the second ciphertext received from the first application module, judging whether a binding token authorization code obtained after the received first encrypted data is decrypted by the first secret key is consistent with a binding token authorization code reserved by the first application module, and if so, passing the verification of the payment token request.
17. The method of claim 12, wherein sending the payment token to the first application module comprises: sending the binding token authorization code to the first application module for forwarding by the second application module.
18. A payment token application method, comprising:
at a terminal device, a first application module calls a second application module and transmits merchant information of the first application module to the second application module;
after receiving a calling instruction of a first application module, a second application module of the terminal device displays a payment account bound to the second application module so that a user can select one payment account from the bound payment accounts, and sends a binding token authorization request to a server, wherein the binding token authorization request carries merchant information of the first application module and the payment account selected by the user;
in the server, generating a binding token authorization code and sending the binding token authorization code to the first application module under the condition that the binding token authorization request passes verification;
at the terminal equipment, the first application module sends a payment token request to the server, wherein the payment token request carries the binding token authorization code;
and generating a payment token and sending the payment token to the first application module by the server under the condition that the payment token request passes verification.
19. A terminal device having a first memory and a first processor, the first memory storing first instructions for performing the payment token application method of any one of claims 7 to 11 when the first processor is run and/or second instructions for performing the payment token application method of any one of claims 1 to 6 when the first processor is run.
20. A server, characterized in that the server comprises a second memory storing a payment token management program and a second processor running the payment token management program to perform the payment token application method according to any one of claims 12-17.
21. A payment token application system, characterized by a terminal device according to claim 19 and a server according to claim 20.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010594938.6A CN111861457B (en) | 2020-06-28 | 2020-06-28 | Payment token application method, device, system and server |
| TW110102421A TWI775288B (en) | 2020-06-28 | 2021-01-22 | Payment token application method, equipment, system and server |
| PCT/CN2021/080495 WO2022001176A1 (en) | 2020-06-28 | 2021-03-12 | Method for applying for payment token, apparatus, system, and server |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010594938.6A CN111861457B (en) | 2020-06-28 | 2020-06-28 | Payment token application method, device, system and server |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111861457A CN111861457A (en) | 2020-10-30 |
| CN111861457B true CN111861457B (en) | 2023-02-21 |
Family
ID=72988113
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010594938.6A Active CN111861457B (en) | 2020-06-28 | 2020-06-28 | Payment token application method, device, system and server |
Country Status (3)
| Country | Link |
|---|---|
| CN (1) | CN111861457B (en) |
| TW (1) | TWI775288B (en) |
| WO (1) | WO2022001176A1 (en) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111861457B (en) * | 2020-06-28 | 2023-02-21 | 中国银联股份有限公司 | Payment token application method, device, system and server |
| CN112488681A (en) * | 2020-12-11 | 2021-03-12 | 广东广宇科技发展有限公司 | Block chain-based authorization code payment method, system, terminal and storage medium |
| CN113159761A (en) * | 2021-01-06 | 2021-07-23 | 中国银联股份有限公司 | Payment authorization transfer system and payment authorization transfer method based on equipment connection |
| CN114244627B (en) * | 2022-01-04 | 2023-12-26 | 上海华申智能卡应用系统有限公司 | Authorization method and system |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105897668A (en) * | 2015-10-22 | 2016-08-24 | 乐视致新电子科技（天津）有限公司 | Third party account authorization method, device, server and system |
| CN107301542A (en) * | 2016-04-15 | 2017-10-27 | 三星电子株式会社 | Electronic installation and the method for payment using the electronic installation |
| CN109218298A (en) * | 2018-09-04 | 2019-01-15 | 中钞信用卡产业发展有限公司杭州区块链技术研究院 | A kind of application data access method and system |
| CN110574060A (en) * | 2017-03-23 | 2019-12-13 | 万事达卡国际公司 | Digital wallet for provisioning and management of tokens |
Family Cites Families (9)
| 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 |
| CN104899741B (en) * | 2014-03-05 | 2018-11-27 | 中国银联股份有限公司 | A kind of on-line payment method and on-line payment system based on IC bank card |
| CN105812341B (en) * | 2014-12-31 | 2019-03-29 | 阿里巴巴集团控股有限公司 | A kind of method and device of identity user identity |
| CN107403312B (en) * | 2016-05-18 | 2024-03-26 | 北京三星通信技术研究有限公司 | Quick payment method and device |
| CN106652227B (en) * | 2016-10-14 | 2020-03-27 | 中国银联股份有限公司 | Intelligent automobile payment system and payment method |
| US20180247306A1 (en) * | 2017-02-24 | 2018-08-30 | Passport Technology Inc. | Systems and methods for rule-based payment card management using tokens |
| SG10201803139UA (en) * | 2018-04-13 | 2019-11-28 | Mastercard International Inc | Method and system for facilitating designated payment transaction |
| CN111861457B (en) * | 2020-06-28 | 2023-02-21 | 中国银联股份有限公司 | Payment token application method, device, system and server |
-
2020
- 2020-06-28 CN CN202010594938.6A patent/CN111861457B/en active Active
-
2021
- 2021-01-22 TW TW110102421A patent/TWI775288B/en active
- 2021-03-12 WO PCT/CN2021/080495 patent/WO2022001176A1/en active Application Filing
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105897668A (en) * | 2015-10-22 | 2016-08-24 | 乐视致新电子科技（天津）有限公司 | Third party account authorization method, device, server and system |
| CN107301542A (en) * | 2016-04-15 | 2017-10-27 | 三星电子株式会社 | Electronic installation and the method for payment using the electronic installation |
| CN110574060A (en) * | 2017-03-23 | 2019-12-13 | 万事达卡国际公司 | Digital wallet for provisioning and management of tokens |
| CN109218298A (en) * | 2018-09-04 | 2019-01-15 | 中钞信用卡产业发展有限公司杭州区块链技术研究院 | A kind of application data access method and system |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2022001176A1 (en) | 2022-01-06 |
| TW202201310A (en) | 2022-01-01 |
| CN111861457A (en) | 2020-10-30 |
| TWI775288B (en) | 2022-08-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112602300B (en) | System and method for password authentication of contactless cards | |
| CN111861457B (en) | Payment token application method, device, system and server | |
| KR101621254B1 (en) | Payment method, computer readable recording medium and system using virtual number based on otp | |
| CA2972895C (en) | Security for mobile payment applications | |
| CN102801710B (en) | A kind of network trading method and system | |
| EP2526514B1 (en) | Method, device and system for securing payment data for transmission over open communication networks | |
| CN106716916B (en) | Authentication system and method | |
| CN113168635A (en) | System and method for password authentication of contactless cards | |
| JP7483688B2 (en) | System and method for cryptographic authentication of contactless cards - Patents.com | |
| CN112789643A (en) | System and method for password authentication of contactless cards | |
| JP2017537421A (en) | How to secure payment tokens | |
| CN105046488A (en) | Method, apparatus, and system for generating transaction-signing one-time password | |
| CN112602104A (en) | System and method for password authentication of contactless cards | |
| CN102790767B (en) | Information safety control method, information safety display equipment and electronic trading system | |
| JP2013514556A (en) | Method and system for securely processing transactions | |
| CN104038924A (en) | Method and system for achieving resource exchange information processing | |
| UA113415C2 (en) | METHOD, SERVER AND PERSONAL AUTHENTICATION SYSTEM | |
| CN113168631A (en) | System and method for password authentication of contactless cards | |
| EP3718283A1 (en) | Systems and methods for protecting against relay attacks | |
| CN112655010A (en) | System and method for password authentication of contactless cards | |
| KR20230005815A (en) | Tap to pay your credit bill | |
| KR20150106198A (en) | Method, server and device for certification | |
| KR101754486B1 (en) | Method for Providing Mobile Payment Service by Using Account Information | |
| KR101604622B1 (en) | Method for Processing Mobile Payment by Using Encryption Matrix Authentication | |
| CN113169873A (en) | System and method for password authentication of contactless cards |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40034019 Country of ref document: HK |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |