Implementation method of a three-party payment protocol based on secure deep link

Abstract

The application provides an implementation method of a three-party payment protocol based on a secure deep link, which is applied to a vendor side and comprises the following steps: receiving a payment order sent by a merchant side; judging whether the payment order comprises an application credential token; if not, generating an application credential token according to the payment order, returning the application credential token to the merchant side, and enabling the merchant side to send a payment order with the token; if the application credential token is included, verifying the token, and if the verification is passed, performing payment on the payment order, otherwise, rejecting the payment on the payment order. The application further provides an implementation device of the three-party payment protocol. The application further provides a corresponding device. The method of the application can help the vendor App to acquire information of an external merchant App without relying on a system interface.

Description

Technical Field

[0001] This invention belongs to the field of mobile security, specifically relating to a method for implementing a third-party payment protocol based on secure deep links. Background Technology

[0002] For various Android devices, current vendor apps primarily identify the identity of external apps (such as merchant apps) they interact with through interfaces provided by the underlying operating system. Therefore, upon receiving a payment order, obtaining information from the merchant app through this interface can verify the association between the merchant app and the payment order. However, due to the uncertainty of mobile operating system privacy policies, it cannot be guaranteed that such information will continue to be obtained by vendor apps. For example, similar request source information has been automatically blocked in iOS 13 and above.

[0003] Given the above situation, it is necessary to propose a new third-party payment protocol based on a secure deep link mechanism that ensures the legitimacy and uniqueness of the redirection target. This protocol can help the manufacturer's App obtain information from external merchant Apps to support their security testing without relying on system interfaces. Summary of the Invention

[0004] The purpose of this invention is to provide a method for implementing a third-party payment protocol based on secure deep linking, so as to help manufacturer apps obtain information from external merchant apps without relying on system interfaces.

[0005] To achieve the above objectives, this invention provides a method for implementing a third-party payment protocol based on secure deep linking, which is applied on the vendor side, including:

[0006] Receive payment orders sent by the merchant, wherein the payment orders are generated by the merchant in response to the order placement request of the transaction;

[0007] Determine whether the payment order includes application credential tokens;

[0008] If application credentials tokens are not included, then:

[0009] Based on the payment order, determine whether there is a secure deep link between the manufacturer and the merchant. If so, generate an application credential token based on the payment order and return the application credential token to the merchant, so that the merchant sends a payment order with the application credential token included.

[0010] If application credentials tokens are included, then:

[0011] Verify the application credential token;

[0012] If the verification passes, the payment order is processed; otherwise, the payment order is rejected.

[0013] Preferably, the application credential token has a predetermined number of uses, and verifying the application credential token specifically includes canceling the application credential token so that the application credential token becomes invalid after the predetermined number of uses has been successfully canceled.

[0014] Preferably, generating an application credential token based on a payment order specifically includes: generating an application credential token based on the merchant identity information in the payment order.

[0015] Preferably, the secure deep link is an App Link or a Universal Link; before receiving the payment order sent by the merchant, it also includes:

[0016] The manufacturer receives a secure deep link obtained from the merchant's registration.

[0017] The manufacturer generates a corresponding identifier for the merchant to complete the registration;

[0018] Send the merchant's identifier to the merchant side;

[0019] Furthermore, the payment order includes a merchant-side identifier;

[0020] Determining whether there is a secure deep link between the manufacturer and the merchant based on the payment order includes: determining whether there is a secure deep link between the manufacturer and the merchant based on the merchant's identifier.

[0021] Preferably, the manufacturer side includes the manufacturer's server and the manufacturer's application on the user device;

[0022] Determine whether there is a secure deep link between the manufacturer and the merchant based on the payment order, specifically including:

[0023] The vendor's server receives payment orders sent by the vendor's application;

[0024] The vendor's server uses the merchant's identifier to determine if there is a secure deep link on the merchant's side. If so, it sends the secure deep link on the merchant's side to the vendor's application.

[0025] Generate application credential tokens based on payment orders, specifically including:

[0026] The vendor's server generates application credential tokens based on the payment order;

[0027] The vendor's server sends application credentials tokens to the vendor's application.

[0028] Preferably, the application credential token is verified. If the verification passes, payment is made to the payment order; otherwise, payment is refused. Specifically, this includes:

[0029] The vendor's server receives the application credential token sent by the vendor's application.

[0030] The vendor's server verifies the application credential token;

[0031] If the verification passes, the vendor server processes the payment order and then returns the payment result to the vendor application, which in turn sends the payment result to the merchant. Otherwise, the vendor server terminates the process to refuse to process the payment order.

[0032] Preferably, if the verification passes, the vendor server processes the payment order and then returns the payment result to the vendor application, which in turn sends the payment result to the merchant side. Specifically, this includes:

[0033] The vendor's server returns a successful verification result to the vendor's application, which then displays a confirmation interface for the user to confirm the payment.

[0034] The vendor's server receives the payment result return request sent by the vendor's application in response to the payment confirmation operation;

[0035] The vendor's server returns the payment result to the vendor's application, which then sends the payment result to the merchant's side.

[0036] On the other hand, this invention provides a method for implementing a third-party payment protocol based on secure deep linking, which is applied to the merchant side, including:

[0037] A payment order is generated in response to the order request for the transaction, the payment order not including the application credential token;

[0038] Send a payment order to the vendor side, so that the vendor side can determine whether the payment order includes an application credential token, and generate an application credential token based on the payment order if the application credential token is not included;

[0039] Receive the application credential token returned from the vendor;

[0040] Send a payment order containing the application credential token to the manufacturer, so that the manufacturer can determine whether the payment order includes the application credential token and verify the application credential token if it does.

[0041] The receiving manufacturer returns the payment result after the verification is successful and the payment order is paid.

[0042] Preferably, after receiving the application credential token returned from the manufacturer and before sending a payment order with the application credential token included, the method further includes: locally storing the application credential token and adding the application credential token to the payment order;

[0043] Furthermore, after storing the application credential token locally, it also includes:

[0044] Generate a payment order in response to an order request from another transaction;

[0045] The application credential token, read from the merchant side, is added to the payment order;

[0046] Repeat the steps of sending a payment order containing the application credential token to the manufacturer and receiving the payment result.

[0047] Preferably, the merchant side includes a merchant server and a merchant application on the user device;

[0048] A payment order is generated in response to the order request for the transaction, specifically including:

[0049] The merchant application sends a transaction order request to the merchant server, which then generates a payment order in response to the transaction order request.

[0050] The merchant application receives payment orders returned by the merchant server;

[0051] Furthermore, the payment result returned by the receiving manufacturer upon successful verification includes:

[0052] The merchant application receives the payment result returned by the manufacturer.

[0053] The merchant application returns the payment result to the merchant server.

[0054] Preferably, the secure deep link is an App Link or a Universal Link;

[0055] Before generating a payment order in response to a transaction's order request, the process also includes:

[0056] Register to obtain a secure deep link from the merchant side;

[0057] Send a secure deep link from the merchant side to the manufacturer side, so that the manufacturer side generates an identifier for the merchant side to complete the registration.

[0058] Receive the merchant's identifier sent by the manufacturer;

[0059] Furthermore, the payment order includes a merchant-side identifier.

[0060] Preferably, the manufacturer side includes the manufacturer's server and the manufacturer's application on the user device;

[0061] Before generating the application credential token based on the payment order, the process also includes: the vendor server receiving the payment order sent by the vendor application, checking whether there is a secure deep link on the merchant side based on the merchant-side identifier, and if so, sending the secure deep link on the merchant side to the vendor application.

[0062] The application credential token is generated by the vendor's server based on the merchant's identity information in the payment order.

[0063] On the other hand, the present invention provides an implementation apparatus for a third-party payment protocol based on secure deep linking, comprising:

[0064] On the merchant side, the setup is as follows: generate a payment order in response to a transaction order request, wherein the payment order does not include an application credential token; send the payment order; receive the application credential token; send a payment order incorporating the application credential token; and receive the payment result returned by the vendor after verification and payment of the payment order.

[0065] On the manufacturer's side, it is configured to: receive payment orders sent by the merchant; and determine whether the payment order includes application credentials tokens.

[0066] If the application credential token is not included, then: determine whether there is a secure deep link between the vendor and the merchant based on the payment order; generate an application credential token based on the payment order; and return the application credential token to the merchant.

[0067] If an application credential token is included, then: verify the application credential token; process the payment order; otherwise, refuse to process the payment order.

[0068] Preferably, after receiving the application credential token returned from the manufacturer's side and before sending a payment order with the application credential token included, the merchant's side is further configured to: store the application credential token locally and add the application credential token to the payment order;

[0069] After storing the application credential token locally, the merchant side is further configured to: generate a payment order in response to an order request for another transaction; add the application credential token read from the merchant side to the payment order; and repeatedly send the payment order with the application credential token added to it to the vendor side and receive the payment result.

[0070] Preferably, the merchant side includes a merchant server and a merchant application on the user device;

[0071] The process of generating a payment order in response to a transaction order request includes: the merchant application sending a transaction order request to the merchant server, causing the merchant server to generate a payment order in response to the transaction order request; and the merchant application receiving the payment order returned by the merchant server.

[0072] Furthermore, the payment result returned by the receiving vendor upon successful verification includes: the merchant application receiving the payment result returned by the vendor; and the merchant application returning the payment result to the merchant server.

[0073] Preferably, the secure deep link is an App Link or a Universal Link; before generating a payment order in response to a transaction's order request, the merchant side is further configured as follows:

[0074] Register to obtain a secure deep link from the merchant side;

[0075] Send a secure deep link from the merchant side to the manufacturer side, so that the manufacturer side generates an identifier for the merchant side to complete the registration.

[0076] Receive the merchant's identifier sent by the manufacturer;

[0077] Furthermore, the payment order includes a merchant-side identifier;

[0078] Determining whether there is a secure deep link between the manufacturer and the merchant based on the payment order includes: determining whether there is a secure deep link between the manufacturer and the merchant based on the merchant's identifier.

[0079] Preferably, the manufacturer side includes the manufacturer's server and the manufacturer's application on the user device;

[0080] Determining whether there is a secure deep link on the merchant side based on the payment order involves: the merchant server receiving the payment order sent by the merchant application; the merchant server searching for and determining whether there is a secure deep link on the merchant side based on the merchant-side identifier; if so, sending the secure deep link on the merchant side to the merchant application.

[0081] The process of generating an application credential token based on a payment order includes: the vendor server generating an application credential token based on the payment order; and the vendor server sending the application credential token to the vendor application.

[0082] Preferably, the application credential token is verified before payment is made for the payment order; otherwise, payment is refused. Specifically, this includes:

[0083] The vendor application sends the application credential token to the vendor server, enabling the vendor server to verify the application credential token;

[0084] If the verification passes, the vendor server processes the payment order and then returns the payment result to the vendor application, which in turn sends the payment result to the merchant. Otherwise, the vendor server terminates the process to refuse to process the payment order.

[0085] On the other hand, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described above.

[0086] On the other hand, a computing device includes a memory and a processor, the memory storing executable code, which, when executed by the processor, performs the method described above.

[0087] Compared to existing third-party payment protocols, the secure deep-link-based third-party payment protocol implementation method of this invention ensures the merchant's legitimacy by securely transmitting application credential tokens via a secure deep link on the merchant side. Without relying on system interfaces, it still helps manufacturers identify the identity of external merchant apps. New interactive processes can be implemented through client SDKs provided by platforms such as Android, thus reducing the cost of merchant integration and modification. Furthermore, by storing the application credential token locally, the token acquisition process only needs to occur once, resulting in minimal overall system performance overhead. Additionally, the application credential token is stored using a keystore or keychain by default, and is not stored in plaintext, thus ensuring high security. Attached Figure Description

[0088] Figure 1 This is a schematic diagram of the data flow in the implementation method of a secure deep link-based third-party payment protocol according to the first embodiment of the present invention.

[0089] Figure 2 This is a flowchart of a method for implementing a secure deep link-based third-party payment protocol according to a second embodiment of the present invention.

[0090] Figure 3 This is a flowchart of a method for implementing a secure deep link-based third-party payment protocol according to a third embodiment of the present invention. Detailed Implementation

[0091] The present invention will be further described below with reference to specific embodiments. It should be understood that the following embodiments are for illustrative purposes only and are not intended to limit the scope of the invention.

[0092] First Implementation Method: Implementation of a Third-Party Payment Protocol Based on Secure Deep Linking

[0093] like Figure 1As shown, the implementation method of the third-party payment protocol based on secure deep link according to the first embodiment of the present invention involves a merchant side and a manufacturer side. The merchant side includes a merchant application (i.e., a merchant app) and a merchant server on a user device, and the manufacturer side includes a manufacturer application (i.e., a manufacturer app) and a manufacturer server on a user device. The merchant application and the manufacturer application are usually located on the same user device, which can typically be an Android or iOS device.

[0094] like Figure 1 As shown, the implementation method of the third-party payment protocol based on secure deep linking mainly includes the following steps:

[0095] 100: The merchant side registers a secure deep link and then registers this secure deep link with the manufacturer's server on the manufacturer side.

[0096] Secure deep links are used to ensure the legitimacy and uniqueness of the redirected target. When the user device is an Android device, the secure deep link is an App Link; when the user device is an iOS device, the secure deep link is a Universal Link. In this embodiment, the secure deep link used is specifically an App Link.

[0097] Step 100 specifically includes:

[0098] 101: The merchant server installs the merchant application on the user's device to register and obtain a secure deep link (such as a URL) on the merchant side, and sends the secure deep link on the merchant side to the manufacturer's server on the manufacturer side.

[0099] 102: The vendor's server generates a merchant-side identifier to complete the registration and sends the merchant-side identifier to the merchant's server.

[0100] Therefore, after a legitimate merchant registers a secure deep link for waking up itself on the user's device, it registers this secure deep link with the vendor's server. This ensures that the vendor server's App Link registration list includes the secure deep links for waking up each legitimate merchant, along with each merchant's identifier. Subsequently, the vendor server can use these merchant-side secure deep links in the list to transmit sensitive data, such as tokens, ensuring that sensitive data can only be securely transmitted to legitimate merchants.

[0101] 110: The merchant generates a payment order in response to the order request for the transaction. The payment order does not include application credential tokens, and specifically includes:

[0102] 111: The merchant application sends an order request to the merchant server;

[0103] 112: The merchant server responds to the order request for the transaction and generates a payment order that includes the merchant's identifier;

[0104] 113: The merchant application receives the payment order returned by the merchant server; at this time, the payment order does not include the application credential token.

[0105] 114: Merchant application sends payment orders.

[0106] 120: The vendor application continuously receives payment orders sent by the merchant application.

[0107] 130: The vendor application determines whether the payment order includes an application credential token; if it does not include an application credential token, it indicates that this is the first payment and proceeds to step 140; otherwise, proceeds to step 150.

[0108] Step 140 corresponds to the case without application credentials tokens, i.e., the first half of the process for the first payment, which includes:

[0109] 141: The vendor side determines whether it has a secure deep link to the merchant side based on the payment order. If so, it obtains the secure deep link to the merchant side. Subsequently, it generates an application credential token based on the payment order.

[0110] Specifically, the system determines whether the manufacturer has a secure deep link to the merchant based on the payment order. If so, it retrieves the secure deep link to the merchant, including:

[0111] The vendor application sends the payment order to the vendor server. The payment order includes a merchant-side identifier. Based on the merchant-side identifier, the vendor server searches to determine if there is a secure deep link on the merchant side. If so, the secure deep link on the merchant side is retrieved from the vendor server.

[0112] The process of generating an application credential token based on a payment order includes: the vendor's server generating the application credential token based on the payment order; and then the vendor's application receiving the application credential token sent by the vendor's server.

[0113] The generation of application credential tokens specifically includes: generating application credential tokens based on merchant identity information in the payment order. Merchant identity information includes the user's device type and the merchant's own mobile application type, i.e., the device + mobile application dimension. The vendor's server obtains the merchant identity information based on the order information in the payment order, and then uses this information to generate a random number through a random mechanism, which serves as the application credential token.

[0114] 142: The vendor application returns the application credentials token to the merchant application on the merchant side, which can be done through a secure deep link or other means;

[0115] Here, the secure deep link mechanism ensures the legitimacy and uniqueness of the redirected target. For unauthorized merchant applications, although their generated payment orders may contain false merchant identity information to trick the manufacturer into generating application credential tokens, these unauthorized applications cannot receive the application credential tokens through a secure deep link.

[0116] 143: The merchant application stores the application credential token locally; thus, the merchant side stores the application credential token.

[0117] The merchant application uses a keystore system to store the application credentials token locally, without storing them in plaintext, thus ensuring high security.

[0118] In this embodiment, when the user device is an Android device, a keystore is used as the key store system to locally store application credential tokens. When the user device is an iOS device, a keychain is used as the key store system to locally store application credential tokens.

[0119] 144: The merchant application adds the application credential token to the payment order and sends the payment order with the application credential token added to it for the vendor application to receive.

[0120] At this point, since the receiving of the vendor application in step 120 is ongoing, after receiving the payment order sent by the merchant application, the process returns to step 120 to execute steps 130 and 150.

[0121] Step 150: The merchant verifies the application credential token. If the verification passes, the payment order is processed; otherwise, the payment order is rejected.

[0122] Step 150 corresponds to the latter half of the initial payment process, which specifically includes:

[0123] 151: The vendor application sends the application credential token to the vendor server, which then verifies the application credential token. If the verification passes, the vendor server sends the verification result back to the vendor application; otherwise, the process ends to refuse payment for the payment order.

[0124] In other embodiments, the application credential token may have a specified number of uses, and the verification of the application credential token by the vendor server in step 151 can be achieved through cancellation, so that the application credential token becomes invalid after the cancellation of the specified number of uses is passed.

[0125] This verified the merchant's identity information.

[0126] 152: After receiving the verification result returned by the vendor's server, the vendor application displays a user confirmation interface for the user to confirm the payment operation; subsequently, in response to the payment confirmation operation, it sends a payment result return request to the vendor's server.

[0127] 153: The vendor's server processes the payment order and returns the payment result to the vendor's application;

[0128] 154: The vendor application returns the payment result to the merchant application;

[0129] 155: The merchant application returns the payment result to the merchant server. The transaction is now complete.

[0130] Thus, the entire process of the first payment is completed through steps 100-154 described above.

[0131] As mentioned above, since the merchant application already stores the application credential token, it can directly read the local application credential token and initiate a request. The vendor application can then directly verify the merchant's identity information by validating the application credential token. The following details the subsequent payment process when an application credential token is present.

[0132] 160 (corresponding to 110): Return to step 110, where the merchant application generates a payment order in response to the transaction's order request.

[0133] Since the merchant application stores application credentials tokens, the payment order is generated by the merchant side in response to the order request of the transaction. Specifically, the payment order is generated by the merchant side in response to the order request of the transaction, and the application credentials token read from the merchant side is added after generation, so that the payment order sent by the merchant side includes the application credentials token.

[0134] In other words, step 160 includes:

[0135] 161: The merchant application sends an order request to the merchant server;

[0136] 162: The merchant server responds to the order request for the transaction and generates a payment order, which includes the merchant's identifier;

[0137] 163: The merchant application receives the payment order returned by the merchant server; at this time, the payment order does not include the application credential token.

[0138] 164: Read the local application credential token in the merchant application;

[0139] 165: The merchant application sends a payment order that includes the application's credential token.

[0140] 170 (corresponding to 120): The vendor application determines whether the payment order includes an application credential token; since it includes an application credential token, step 180 (corresponding to step 150) is executed at this time;

[0141] Step 180 specifically includes:

[0142] 181 (corresponding to step 151): The vendor application sends the application credential token to the vendor server, so that the vendor server verifies the application credential token; if the verification passes, the vendor server sends the verification result to the vendor application; otherwise, the process ends to terminate the transaction.

[0143] 182 (corresponding to step 152): After receiving the verification result returned by the vendor server, the vendor application displays a user confirmation interface for the user to perform a payment confirmation operation; subsequently, in response to the payment confirmation operation, it sends a payment result return request to the vendor server.

[0144] 183 (corresponding to step 153): The vendor server returns the payment result to the vendor application;

[0145] 184 (corresponding to step 154): The vendor application returns the payment result to the merchant application;

[0146] 185 (corresponding to step 155): The merchant application returns the payment result to the merchant server to complete the transaction.

[0147] In summary, this invention transmits application credential tokens through secure deep links, ensuring that the application credential tokens generated by the vendor are delivered to the legitimate and unique merchant side. Therefore, the vendor side can verify the true identity of the merchant side based on the application credential tokens without relying on the capabilities provided by the system interface.

[0148] Second embodiment: Implementation method of a third-party payment protocol based on secure deep linking

[0149] like Figure 2 The diagram illustrates an implementation method for a secure deep-link-based third-party payment protocol according to a second embodiment of the present invention. This method also involves a merchant side and a vendor side. The merchant side includes a merchant application and a merchant server, while the vendor side includes a vendor application and a vendor server. According to the second embodiment of the present invention, the implementation method for the secure deep-link-based third-party payment protocol is applied to the vendor side and includes:

[0150] 200: A secure deep link pre-registered by the merchant and received from the manufacturer, specifically including:

[0151] 201: The merchant application is installed on the user's device by the merchant server so that the merchant side can register on the user's device and obtain a secure deep link on the merchant side;

[0152] Secure deep links are used to ensure the legitimacy and uniqueness of the redirected target. In this embodiment, when the user device is an Android device, the secure deep link is an App Link; when the user device is an iOS device, the secure deep link is a Universal Link.

[0153] 202: The vendor's server receives a secure deep connection from the merchant's server.

[0154] 203: The vendor's server generates the corresponding merchant's identifier to complete the registration;

[0155] 204: The vendor's server sends the merchant's identifier to the merchant's server.

[0156] This step 200 only needs to be executed once, and does not need to be executed again in each subsequent transaction.

[0157] 210: Continuously receive payment orders sent by the merchant, wherein the payment orders are generated by the merchant in response to the order placement request of the transaction;

[0158] As described above, the merchant server has a merchant-side identifier and a corresponding secure deep link to the merchant side; therefore, the payment order includes the merchant-side identifier.

[0159] The merchant generates a payment order in response to the order request for the transaction, specifically including:

[0160] 211: The merchant application sends an order request to the merchant server, which then generates a payment order in response to the transaction's order request.

[0161] 212: The merchant application receives the payment order returned by the merchant server.

[0162] 220: Determine whether the payment order includes an application credential token;

[0163] 230: If the application credentials token is not included, proceed to step 240; otherwise, if the application credentials token is included, proceed to step 250.

[0164] Step 240 specifically includes:

[0165] 241: Determine whether the manufacturer has a secure deep link to the merchant based on the payment order. If so, obtain the secure deep link to the merchant.

[0166] Determining whether there is a secure deep link on the manufacturer's side based on the merchant's identifier specifically includes: determining whether there is a secure deep link on the manufacturer's side based on the merchant's identifier.

[0167] That is, step 241 specifically includes: the vendor server receives the payment order sent by the vendor application, the vendor server searches for and determines whether there is a secure deep link on the merchant side based on the merchant-side identifier, and if so, sends the secure deep link on the merchant side to the vendor application in order to obtain the secure deep link on the merchant side.

[0168] 242: Generate application credential tokens based on payment orders;

[0169] The process of generating an application credential token based on a payment order includes: the vendor server generating an application credential token based on the payment order; and then the vendor server receiving and sending the application credential token to the vendor application.

[0170] Specifically, generating application credential tokens includes generating application credential tokens based on the merchant identity information in the payment order.

[0171] 243: Return the application credential token to the merchant side via a secure deep link, enabling the merchant side to send a payment order that includes the application credential token;

[0172] Specifically, returning the application credential token to the merchant side via a secure deep link, enabling the merchant side to send a payment order with the application credential token included, includes: returning the application credential token to the merchant side via a secure deep link, enabling the merchant side to locally store the application credential token, add the application credential token to the payment order, and send the payment order with the application credential token included.

[0173] This results in application credentials being stored on the merchant's side.

[0174] At this point, since the manufacturer side continues to receive payment orders sent by the merchant side, the process returns to step 210 of receiving payment orders, that is, repeating the steps of receiving payment orders, determining whether the payment order includes application credential tokens, and executing step 250 based on the determination result.

[0175] 250: Verify the application credential token. If the verification passes, proceed with the payment order; otherwise, refuse to proceed with the payment order.

[0176] The application credential token may have a specified number of uses. Accordingly, verifying the application credential token specifically includes canceling the application credential token so that the application credential token becomes invalid after the cancellation of the specified number of uses is passed.

[0177] Step 250 specifically includes:

[0178] 251: The vendor's server receives the application credential token sent by the vendor's application;

[0179] 252: The vendor's server verifies the application credential token;

[0180] This allows for the verification of the merchant's identity. Even if an unauthorized merchant can illegally obtain the identity identifier of a legitimate merchant and impersonate it, it still cannot obtain the application credential token through a secure deep link, because a secure deep link only points to the legitimate merchant.

[0181] 253: If the verification passes, the vendor server will process the payment order and then return the payment result to the vendor application, which will then send the payment result to the merchant. Otherwise, the vendor server will terminate the process to refuse to process the payment order.

[0182] Specifically, the payment result is sent from the manufacturer's application to the merchant's side, which includes the merchant's application returning the payment result to the merchant's server.

[0183] If the verification passes, the vendor server processes the payment order and then returns the payment result to the vendor application, which in turn sends the payment result to the merchant. Specifically, this includes:

[0184] The vendor's server returns a successful verification result to the vendor's application, which then displays a confirmation interface for the user to confirm the payment.

[0185] The vendor's server receives the payment result return request sent by the vendor's application in response to the payment confirmation operation;

[0186] The vendor's server returns the payment result to the vendor's application, which then sends the payment result to the merchant's side.

[0187] After a transaction is completed or terminated, since the vendor side continues to receive payment orders sent by the merchant side, the process returns to step 210, which involves repeatedly receiving payment orders, determining whether the payment order includes an application credential token, verifying the application credential token if it is included, and returning the payment result to the merchant side when the verification passes.

[0188] Specifically, when the merchant stores the application credential token, the payment order is generated in response to the order placement request of the transaction. This includes: the payment order is generated in response to the order placement request of the transaction and the application credential token read from the merchant is added after generation, so that the payment order sent by the merchant includes the application credential token.

[0189] Third embodiment: Implementation method of a third-party payment protocol based on secure deep linking

[0190] like Figure 3The diagram illustrates a method for implementing a secure deep-link-based third-party payment protocol according to a third embodiment of the present invention. This method also involves a merchant side and a vendor side. The merchant side includes a merchant application and a merchant server, while the vendor side includes a vendor application and a vendor server. According to a second embodiment of the present invention, the method for implementing the secure deep-link-based third-party payment protocol is applied to the merchant side and includes:

[0191] 300: Secure deep links are pre-registered with the vendor.

[0192] Secure deep links are used to ensure the legitimacy and uniqueness of the redirected target. In this embodiment, when the user device is an Android device, the secure deep link is an App Link; when the user device is an iOS device, the secure deep link is a Universal Link.

[0193] Step 300 specifically includes:

[0194] 301: The merchant application is installed on the user's device by the merchant server to register a secure deep link on the merchant side on the user's device;

[0195] 302: The merchant server sends a secure deep link from the merchant side to the manufacturer side, enabling the manufacturer side to generate a merchant-side identifier to complete the registration.

[0196] 302: The merchant server receives the merchant-side identifier sent by the manufacturer.

[0197] 310: A payment order is generated in response to an order request for a transaction, wherein the payment order does not include an application credential token;

[0198] The payment order includes a merchant-side identifier.

[0199] A payment order is generated in response to the order request for the transaction, specifically including:

[0200] 311: The merchant application sends a transaction order request to the merchant server, which then generates a payment order in response to the transaction order request.

[0201] 312: The merchant application receives the payment order returned by the merchant server.

[0202] 320: Send a payment order to the vendor side, enabling the vendor side to determine whether the payment order includes an application credential token and, if it does not include an application credential token, obtain a secure deep link from the merchant side and generate an application credential token based on the payment order;

[0203] The application credential token is generated by the vendor's server on the vendor side based on the merchant's identity information in the payment order.

[0204] 330: Receive application credential tokens returned from the vendor side via a secure deep link on the merchant side;

[0205] Specifically, the secure deep link on the merchant side is obtained by the manufacturer's server receiving the payment order (which includes the merchant's identifier) ​​sent by the manufacturer's application, checking whether there is a secure deep link on the merchant side based on the merchant's identifier, and if so, sending the secure deep link on the merchant side to the manufacturer's application.

[0206] 340: Send a payment order containing the application credential token to the manufacturer, so that the manufacturer determines whether the payment order includes the application credential token and verifies the application credential token if it does.

[0207] The process may further include: storing the application credential token locally and adding the application credential token to the payment order after receiving the application credential token returned from the vendor.

[0208] This allows the merchant to store application credentials tokens locally.

[0209] 350: The receiving manufacturer returns the payment result after verification and payment of the payment order. The transaction is now complete.

[0210] The payment result is provided by the vendor application. After receiving the verification result returned by the vendor server, the application displays a user confirmation interface for the user to confirm the payment. In response to the payment confirmation operation, the application sends a payment result return request to the vendor server and finally receives the result from the vendor server.

[0211] The payment result returned by the receiving vendor upon successful verification includes:

[0212] 351: The merchant application receives the payment result returned by the manufacturer.

[0213] 352: The merchant application returns the payment result to the merchant server.

[0214] Since the merchant stores the application credential token locally, after storing the application credential token locally, the following is also included:

[0215] 361: Generates a payment order in response to an order request from another transaction;

[0216] 362: Add the application credential token read at the merchant's side to the payment order;

[0217] 363: Repeat the steps of sending the payment order containing the application credential token to the manufacturer and receiving the payment result (corresponding to steps 340-350).

[0218] Third embodiment: Implementation device for a secure deep link-based third-party payment protocol

[0219] Based on the above-described method for implementing a secure deep-link-based third-party payment protocol, an apparatus for implementing such a protocol is provided. According to a third embodiment of the present invention, the apparatus for implementing a secure deep-link-based third-party payment protocol includes:

[0220] On the merchant side, the setup is as follows: generate a payment order in response to a transaction's order request, wherein the payment order does not include an application credential token; send the payment order; receive the application credential token via a secure deep link on the merchant side; send a payment order incorporating the application credential token; and receive the payment result returned by the vendor side after verification and payment of the payment order.

[0221] On the manufacturer's side, it is configured to: receive payment orders sent by the merchant; and determine whether the payment order includes application credentials tokens.

[0222] If the application credential token is not included, then: determine whether there is a secure deep link on the merchant side based on the payment order; if so, obtain the secure deep link on the merchant side; generate an application credential token based on the payment order; and return the application credential token to the merchant side via the secure deep link.

[0223] If an application credential token is included, then: verify the application credential token; if the verification passes, process the payment order; otherwise, refuse to process the payment order.

[0224] The merchant side includes a merchant server and a merchant application on the user device, while the manufacturer side includes a manufacturer server and a manufacturer application on the user device.

[0225] After receiving the application credential token returned from the vendor side, and before sending a payment order that includes the application credential token, the merchant side is further configured to: store the application credential token locally and add the application credential token to the payment order.

[0226] After storing the application credential token locally, the merchant side is further configured to: generate a payment order in response to an order request for another transaction; add the application credential token read from the merchant side to the payment order; and repeatedly send the payment order with the application credential token added to it to the vendor side and receive the payment result.

[0227] The secure deep link is either an App Link or a Universal Link. Before generating a payment order in response to a transaction's order request, the merchant side is further configured to: install a merchant application on the user's device using a merchant server to register and obtain a secure deep link on the user's device; send the secure deep link on the merchant side to the manufacturer side, causing the manufacturer side to generate a merchant-side identifier to complete the registration; and receive the merchant-side identifier sent by the manufacturer side. Furthermore, the payment order includes the merchant-side identifier. Additionally, determining whether the manufacturer side has a secure deep link based on the payment order specifically includes: determining whether the manufacturer side has a secure deep link based on the merchant-side identifier.

[0228] Specifically, the system determines whether the vendor has a secure deep link to the merchant based on the payment order. If so, it retrieves the secure deep link from the merchant's side. This process includes: the vendor's server receiving the payment order from the vendor application; the vendor's server searching for a secure deep link based on the merchant's identifier; and if found, sending the secure deep link to the vendor application. The system also generates an application credential token based on the payment order. This process includes: the vendor's server generating the application credential token based on the payment order; and the vendor's server sending the application credential token to the vendor application.

[0229] The process of generating a payment order in response to a transaction order request includes: the merchant application sending a transaction order request to the merchant server, causing the merchant server to generate a payment order in response; and the merchant application receiving the payment order returned by the merchant server. Furthermore, the process of receiving the payment result returned by the vendor upon successful verification includes: the merchant application receiving the payment result returned by the vendor; and the merchant application returning the payment result to the merchant server.

[0230] The process of verifying the application credential token and making payment for the payment order, or rejecting payment for the payment order, specifically includes: the vendor application sending the application credential token to the vendor server, which then verifies the application credential token; if the verification passes, the vendor server makes payment for the payment order and then returns the payment result to the vendor application, which then sends the payment result to the merchant; otherwise, the vendor server terminates the process to reject payment for the payment order.

[0231] A fourth embodiment of the present invention provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed in a computer, the computer, acting as a manufacturer, performs the steps of the method described in the second embodiment of the present invention. Since the steps performed are the same as those performed by the manufacturer in the second embodiment described above, they will not be repeated here.

[0232] A fifth embodiment of the present invention provides a computing device including a memory and a processor. The memory stores executable code. When the processor executes the executable code, it performs the steps of the method described in the second embodiment of the present invention on the manufacturer's side. Since the steps performed are the same as those performed on the manufacturer's side as described above, they will not be repeated here.

[0233] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of the invention. Various variations can be made to the above embodiments of the present invention. All simple and equivalent changes and modifications made in accordance with the claims and description of this application fall within the protection scope of the claims of this patent. All aspects not described in detail in this invention are conventional technical content.

Claims

1. An implementation method for a third-party payment protocol based on secure deep linking, applied on the vendor side, comprising: Receive payment orders sent by the merchant, wherein the payment orders are generated by the merchant in response to the order placement request of the transaction; Determine whether the payment order includes application credential tokens; If application credentials tokens are not included, then: Based on the payment order, determine whether there is a secure deep link between the manufacturer and the merchant. If so, generate an application credential token based on the payment order and return the application credential token to the merchant, so that the merchant sends a payment order with the application credential token included. If application credentials tokens are included, then: Verify the application credential token; If the verification passes, the payment order is processed; otherwise, the payment order is rejected.

2. The method for implementing a third-party payment protocol based on secure deep linking according to claim 1, wherein the application credential token has a predetermined number of uses, and verifying the application credential token specifically includes canceling the application credential token so that the application credential token becomes invalid after the predetermined number of uses has been successfully canceled.

3. The implementation method of the third-party payment protocol based on secure deep linking according to claim 1, generating application credential tokens based on payment orders, specifically includes: Generate application credential tokens based on the merchant identity information in the payment order.

4. The method for implementing a third-party payment protocol based on secure deep linking according to claim 1, wherein the secure deep linking is an App Link or a Universal Link; and further comprising, before receiving the payment order sent by the merchant: The manufacturer receives a secure deep link obtained from the merchant's registration. The manufacturer generates a corresponding identifier for the merchant to complete the registration; Send the merchant's identifier to the merchant side; Furthermore, the payment order includes a merchant-side identifier; Determining whether there is a secure deep link between the manufacturer and the merchant based on the payment order includes: determining whether there is a secure deep link between the manufacturer and the merchant based on the merchant's identifier.

5. The method for implementing a third-party payment protocol based on secure deep linking according to claim 4, wherein the vendor side includes the vendor server and the vendor application on the user device; Determine whether there is a secure deep link between the manufacturer and the merchant based on the payment order, specifically including: The vendor's server receives payment orders sent by the vendor's application; The vendor's server uses the merchant's identifier to determine if there is a secure deep link on the merchant's side. If so, it sends the secure deep link on the merchant's side to the vendor's application. Generate application credential tokens based on payment orders, specifically including: The vendor's server generates application credential tokens based on the payment order; The vendor's server sends application credentials tokens to the vendor's application.

6. The method for implementing a third-party payment protocol based on secure deep linking according to claim 5, wherein the application credential token is verified, and if the verification passes, payment is made for the payment order; Otherwise, the payment order will be refused, specifically including: The vendor's server receives the application credential token sent by the vendor's application. The vendor's server verifies the application credential token; If the verification passes, the vendor server processes the payment order and then returns the payment result to the vendor application, which in turn sends the payment result to the merchant. Otherwise, the vendor server terminates the process to refuse to process the payment order.

7. The implementation method of the third-party payment protocol based on secure deep linking according to claim 6, wherein if the verification passes, the vendor server makes payment for the payment order, and then returns the payment result to the vendor application, which in turn sends the payment result to the merchant side, specifically including: The vendor's server returns a successful verification result to the vendor's application, which then displays a confirmation interface for the user to confirm the payment. The vendor's server receives the payment result return request sent by the vendor's application in response to the payment confirmation operation; The vendor's server returns the payment result to the vendor's application, which then sends the payment result to the merchant's side.

8. An implementation method for a third-party payment protocol based on secure deep linking, applied to the merchant side, including: A payment order is generated in response to the order request for the transaction, the payment order not including the application credential token; Send a payment order to the vendor side, so that the vendor side can determine whether the payment order includes an application credential token, and generate an application credential token based on the payment order if the application credential token is not included; Receive the application credential token returned from the vendor; Send a payment order containing the application credential token to the manufacturer, so that the manufacturer can determine whether the payment order includes the application credential token, and verify the application credential token if it does. The receiving manufacturer returns the payment result after the verification is successful and the payment order is paid.

9. The method for implementing a third-party payment protocol based on secure deep linking according to claim 8, further comprising, after receiving the application credential token returned from the vendor side and before sending a payment order incorporating the application credential token: The application credential token is stored locally and added to the payment order. Furthermore, after storing the application credential token locally, it also includes: Generate a payment order in response to an order request from another transaction; The application credential token, read from the merchant side, is added to the payment order; Repeat the steps of sending a payment order containing the application credential token to the manufacturer and receiving the payment result.

10. The method for implementing a third-party payment protocol based on secure deep linking according to claim 8, wherein the merchant side includes a merchant server and a merchant application on the user device; A payment order is generated in response to the order request for the transaction, specifically including: The merchant application sends a transaction order request to the merchant server, which then generates a payment order in response to the transaction order request. The merchant application receives payment orders returned by the merchant server; Furthermore, the payment result returned by the receiving manufacturer upon successful verification includes: The merchant application receives the payment result returned by the manufacturer. The merchant application returns the payment result to the merchant server.

11. The method for implementing a third-party payment protocol based on secure deep linking according to claim 8, wherein the secure deep linking is an App Link or a Universal Link; Before generating a payment order in response to a transaction's order request, the process also includes: Register to obtain a secure deep link from the merchant side; Send a secure deep link from the merchant side to the manufacturer side, so that the manufacturer side generates an identifier for the merchant side to complete the registration. Receive the merchant's identifier sent by the manufacturer; Furthermore, the payment order includes a merchant-side identifier.

12. The method for implementing a third-party payment protocol based on secure deep linking according to claim 11, wherein the vendor side includes the vendor server and the vendor application on the user device; Before generating the application credential token based on the payment order, the following is also included: The vendor server receives payment orders sent by the vendor application, checks the merchant-side identifier to determine if there is a secure deep link on the merchant side, and if so, sends the secure deep link on the merchant side to the vendor application. The application credential token is generated by the vendor's server based on the merchant's identity information in the payment order.

13. An implementation apparatus for a secure deep-link-based third-party payment protocol, comprising: On the merchant side, it is configured to generate a payment order in response to a transaction's order request, wherein the payment order does not include application credential tokens; Send payment order; Receive application credential token; Send a payment order containing the application credentials token; receive the payment result returned by the vendor after verification and payment of the payment order; On the manufacturer's side, it is configured to: receive payment orders sent by the merchant; and determine whether the payment order includes application credentials tokens. If the application credential token is not included, then: determine whether there is a secure deep link between the vendor and the merchant based on the payment order; if so, generate an application credential token based on the payment order. Return the application credentials token to the merchant; If an application credential token is included, then: verify the application credential token; The payment order is processed; otherwise, the payment order is rejected.

14. The implementation apparatus for a third-party payment protocol based on secure deep linking according to claim 13, wherein after receiving the application credential token returned from the vendor side and before sending a payment order with the application credential token added, the merchant side is further configured to: locally store the application credential token and add the application credential token to the payment order; After storing the application credential token locally, the merchant side is further configured to: generate a payment order in response to an order request for another transaction; add the application credential token read from the merchant side to the payment order; and repeatedly send the payment order with the application credential token added to it to the vendor side and receive the payment result.

15. The implementation apparatus for a third-party payment protocol based on secure deep linking according to claim 13, wherein the merchant side includes a merchant server and a merchant application on the user device; The process of generating a payment order in response to a transaction order request includes: the merchant application sending a transaction order request to the merchant server, causing the merchant server to generate a payment order in response to the transaction order request; and the merchant application receiving the payment order returned by the merchant server. Furthermore, the payment result returned by the receiving vendor upon successful verification includes: the merchant application receiving the payment result returned by the vendor; and the merchant application returning the payment result to the merchant server.

16. The implementation apparatus for a third-party payment protocol based on secure deep linking according to claim 13, wherein the secure deep linking is an App Link or a Universal Link; before generating a payment order in response to a transaction order request, the merchant side is further configured to: Register to obtain a secure deep link from the merchant side; Send a secure deep link from the merchant side to the manufacturer side, so that the manufacturer side generates an identifier for the merchant side to complete the registration. Receive the merchant's identifier sent by the manufacturer; Furthermore, the payment order includes a merchant-side identifier; Determining whether there is a secure deep link between the manufacturer and the merchant based on the payment order includes: determining whether there is a secure deep link between the manufacturer and the merchant based on the merchant's identifier.

17. The implementation apparatus for a third-party payment protocol based on secure deep linking according to claim 16, wherein the vendor side includes a vendor server and a vendor application on the user device; Determining whether there is a secure deep link on the merchant side based on the payment order involves: the merchant server receiving the payment order sent by the merchant application; the merchant server searching for and determining whether there is a secure deep link on the merchant side based on the merchant-side identifier, and if so, sending the secure deep link on the merchant side to the merchant application. The process of generating an application credential token based on a payment order includes: the vendor server generating an application credential token based on the payment order; and the vendor server sending the application credential token to the vendor application.

18. The implementation apparatus for the third-party payment protocol based on secure deep linking according to claim 17, wherein the application credential token is verified, payment is made to the payment order, otherwise payment is refused, specifically including: The vendor application sends the application credential token to the vendor server, enabling the vendor server to verify the application credential token; If the verification passes, the vendor server processes the payment order and then returns the payment result to the vendor application, which in turn sends the payment result to the merchant. Otherwise, the vendor server terminates the process to refuse to process the payment order.

19. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method as described in any one of claims 1-12.

20. A computing device comprising a memory and a processor, the memory storing executable code, wherein when the processor executes the executable code, it performs the method as described in any one of claims 1-12.

Images