Third-party payment

Abstract

Disclosed in embodiments of the present application are a third-party payment method and system. In the method, a payment request generated by a third-party server contains user information parameters and is associated with current ordering user identity information; upon receiving the payment request, a payment platform writes payment user identity information into the user information parameters, so that the third-party server can verify the consistency of the payment user identity information and the ordering user identity information on the basis of the user information parameters; and the payment platform performs a payment operation only when the third-party server verifies that the payment user identity information is consistent with the ordering user identity information. On the basis of the mechanism, during third-party payment, potential attack risks can be automatically detected, potential external phishing attacks can be defended against, user fund loss can be avoided, and a personal data protection capability can be provided. The system of the embodiments of the present application also has the described beneficial effects.

Description

Third-party payment Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a third-party payment method and system. Background Art

[0002] Nowadays, more and more mobile applications are beginning to connect to the third-party payment services of large mobile applications; however, due to the design of the protocol, the current mobile third-party payment services cannot ensure the consistency of the identities of users placing orders on the third-party service end and users paying on the payment platform, so there is a security risk.

[0003] Summary of the Invention

[0004] One or more embodiments of this specification provide a third-party payment method and system that can effectively verify the identities of users placing orders on a third-party server and users paying on a payment platform, ensuring the consistency of their identities and thus protecting the security of the third-party payment process.

[0005] According to a first aspect, a third-party payment method is provided, which is applicable to a third-party server. The method includes: in response to a user's order operation for a target order, generating a payment request and first signature information, and sending the payment request and the first signature information to a payment platform; the payment request carries a user information parameter associated with the identity information of the ordering user; in response to the payment platform verifying the first signature information, obtaining the payment credential returned by the payment platform and the payment user identity information transmitted by the payment platform through the user information parameter; verifying the user information based on the user information parameter; after verifying the user information, canceling the payment credential to the payment platform, so that the payment platform completes the payment operation for the target order.

[0006] As an optional implementation of the method described in the first aspect, the payment request also carries a bounce address; the payment platform returns the user information parameters and the payment credentials to the third-party server based on the trusted channel provided by the bounce address.

[0007] Specifically, the third-party service end includes a merchant APP and a merchant server; in response to the user's order operation for the target order, a payment request and a first signature information are generated, and the payment request and the first signature information are sent to the payment platform, specifically including: in response to the user's order operation for the target order, the merchant APP sends an order request to the merchant server; the merchant server generates the payment request in response to the order request, and signs the payment request with the merchant's private key to obtain the first signature information; the merchant server returns the payment request and the first signature information to the merchant APP; after the merchant APP adds the bounce address to the payment request, it sends the payment request to the payment platform, so that the payment platform can perform a bounce based on the bounce address, and return the payment credentials and the identity information collection parameters to the merchant APP.

[0008] As an optional implementation manner of the method described in the first aspect, verifying user information based on the user information parameters specifically includes: obtaining the payment user identity information carried in the user information parameters; locally querying the ordering user identity information associated with the user information parameters; performing consistency verification on the payment user identity information and the ordering user identity information, if the verification result is consistent, determining that the user information verification has passed; if the verification result is inconsistent, determining that the user information verification has failed.

[0009] As an optional implementation of the method described in the first aspect, after the user information is verified, the payment credential is cancelled to the payment platform, specifically including: in response to the verification of the user information, the merchant server generates a cancellation request, and signs the cancellation request with the merchant private key to obtain second signature information; the cancellation request, the second signature information and the payment credential are sent to the payment platform, so that the payment platform executes the payment operation for the target order after verifying the second signature information and the payment credential.

[0010] As an optional implementation manner of the method described in the first aspect, it also includes: updating the order status of the target order in response to the payment operation completion information fed back by the payment platform.

[0011] According to a second aspect, a third-party payment method is provided, which is applicable to a payment platform, and the method includes: responding to a payment request from a third-party server, requesting the user to authorize the payment operation; in response to the user authorization, verifying the first signature information sent synchronously with the payment request; after verifying the first signature information, generating a payment credential, and writing the locally stored ordering user identity information into the user information parameter in the payment request; sending the payment credential and the user information parameter to the third-party server; responding to a verification request from the third-party server, verifying the payment credential sent synchronously with the verification request, and after verification, executing the payment operation for the target order.

[0012] As an optional implementation of the method described in the second aspect, the payment request also carries a bounce address; the payment platform returns the user information parameters and the payment credentials to the third-party server based on the trusted channel provided by the bounce address.

[0013] Specifically, the payment platform includes a platform APP and a platform server, and the specific steps performed by the platform APP and the platform server include: in response to the payment request, the platform APP requests the user to authorize this payment operation; in response to the user authorization, the platform APP obtains the bounce address carried in the payment request, and sends the payment request, the first signature information transmitted synchronously with the payment request, and the user's authorization information to the platform server; after the platform server verifies the first signature information, it generates the payment credential and writes the locally stored ordering user identity information into the user information parameter in the payment request; the platform server returns the user information parameter and the payment credential to the platform APP; the platform APP returns the user information parameter and the payment credential to the third-party server based on the trusted channel provided by the bounce address.

[0014] As an optional implementation manner of the method described in the second aspect, in response to the verification request of the third-party server, the payment credential sent synchronously with the verification request is verified, and after the verification is passed, the payment operation for the target order is executed, specifically including: in response to the verification request of the third-party server, the second signature information transmitted synchronously with the verification request is verified; after the second signature information is verified, the payment credential is verified; after the payment credential is verified, the payment operation for the target order is executed.

[0015] As an optional implementation of the method described in the second aspect, the method also includes: after completing the payment operation for the target order, feeding back payment operation completion information to the third-party server, so that the third-party server updates the order status of the target order based on the payment operation completion information.

[0016] According to a third aspect, a third-party payment system is provided, comprising a third-party server and a payment platform; the third-party server is used to execute the third-party payment method applicable to the third-party server, and the payment platform is used to execute the third-party payment method applicable to the payment platform, so as to enable the user to perform payment operations on the target order on the third-party server.

[0017] The third-party payment method described in one or more embodiments of this specification has the beneficial effect of including a user information parameter in the payment request from the third-party server and associating it with the ordering user's identity information. Upon receiving the payment request, the payment platform writes the paying user's identity information into the user information parameter, enabling the third-party server to verify the consistency of the paying user's identity information with the ordering user's identity information based on the user information parameter. The payment platform will only proceed with the payment operation after the third-party server verifies that the paying user's identity information is consistent with the ordering user's identity information.

[0018] Based on this mechanism, potential attack risks can be automatically discovered during the third-party payment process, potential external phishing attacks can be resisted, and victims' financial losses can be prevented, providing the ability to protect end users.

[0019] The third-party payment system described in the embodiments of this specification also has the above-mentioned beneficial effects. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0021] FIG1 shows a flow chart of a third-party payment protocol provided by a mobile application in the prior art.

[0022] FIG2 is a schematic structural diagram illustrating a third-party payment system according to some embodiments of the present application.

[0023] FIG3 is a flow chart illustrating a third-party payment method in an implementation scenario according to some embodiments of the present application.

[0024] FIG4 is a flow chart showing a third-party payment method applicable to a third-party server according to some embodiments of the present application.

[0025] FIG5 is a flow chart showing a third-party payment method applicable to a payment platform according to some embodiments of the present application.

[0026] FIG6 is a schematic structural diagram showing a terminal device according to some embodiments of the present application. DETAILED DESCRIPTION

[0027] Nowadays, more and more mobile applications (hereinafter referred to as merchants) are integrating with third-party payment services of large mobile applications (hereinafter referred to as platforms). However, due to protocol design, current mobile third-party payment services cannot guarantee the identity consistency between the ordering user in the merchant app and the paying user in the platform app, thus posing potential security risks. Specifically, an attacker can send an unrelated payment request to a user and trick them into paying (for example, by scanning a maliciously constructed QR code), ultimately completing a phishing attack and causing the user to pay for the attacker's payment.

[0028] Please refer to FIG1 , which shows a schematic diagram of a process of a third-party payment protocol provided by a platform in the prior art. The process includes the following steps:

[0029] (101) In response to the user's order operation, the merchant APP sends an order request to the merchant server.

[0030] (102) The merchant server generates a payment request and signs the payment request with the merchant's private key.

[0031] (103) The merchant server returns the payment request to the merchant APP.

[0032] (104) The merchant APP sends the payment request to the platform APP.

[0033] (105) The platform APP requests authorization from the user to pay for the order, and after obtaining the user's authorization, sends the user authorization information, payment request and signature information to the platform server.

[0034] (106) The platform server verifies the merchant’s signature information.

[0035] (107) After the platform server verifies the merchant’s signature information, it transfers the payment to the merchant’s account.

[0036] (108) The platform server returns the payment notification information to the platform APP and carries its signature information.

[0037] (109) The platform server returns the payment notification information to the merchant server along with its signature information.

[0038] (110) After the merchant server verifies the signature information of the platform server, it trusts the payment notification information, and then changes the order status (to paid), and stores the order number generated by the platform in the payment notification information.

[0039] (111) The platform APP returns payment notification information to the merchant APP.

[0040] (112) Users check the order status through the merchant APP.

[0041] (113) The merchant server returns the status information of the order.

[0042] As can be seen from step (109) of the above process, in the current third-party payment protocol process, the merchant service end (including the merchant server and merchant APP) relies on the payment notification information returned by the payment platform end (including the platform server and platform APP) to confirm the payment result. In this process, the user's client session is decoupled, and there is no guarantee that the user who places the order and the user who pays are the same person. An attacker can forge a payment request in step (104) and send it to the platform, inducing the user to authorize the payment request, causing the platform server to transfer the payment to the attacker's account, resulting in financial losses for the user.

[0043] In view of this, one or more embodiments of this specification propose a third-party payment method and system to resist potential external phishing attacks during the third-party payment process and prevent users from suffering financial losses due to external attacks.

[0044] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments obtained by those skilled in the art based on the embodiments in this specification without creative work should fall within the scope of protection of this specification.

[0045] It should be noted that in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than those described in this specification. In addition, a single step described in this specification may be broken down into multiple steps for description in other embodiments, and multiple steps described in this specification may be combined into a single step for description in other embodiments.

[0046] Those skilled in the art will appreciate that the terms used in the embodiments of the present invention are for the purpose of describing specific embodiments only and are not intended to limit the present invention. The singular forms "a," "an," "the," and "the" used in the embodiments of the present invention and the appended claims are intended to include the plural forms, unless the context clearly indicates otherwise.

[0047] One or more embodiments of the present invention provide a third-party payment method. Please refer to Figure 2, which exemplifies a third-party payment system that can be used to implement the third-party payment method. It should be noted that the third-party payment method described in one or more embodiments of the present application can be implemented using the third-party payment system shown in Figure 2, but is not limited to the third-party payment system.

[0048] As shown in FIG2 , the third-party payment system includes a terminal device 20, a merchant server 21, and a platform server 22. The terminal device 20 is connected to the merchant server 21 and the platform server 22 via a communication link 23. The communication link 23 can be a wired network or a wireless network. For example, the terminal device 20 can establish communication connections with the merchant server 21 and the platform server 22 respectively using a communication method such as WIFI, Bluetooth, or infrared. Alternatively, the terminal device 20 can also establish communication connections with the merchant server 21 and the platform server 22 respectively via a mobile network, wherein the network standard of the mobile network can be any one of 2G (GSM), 2.5G (GPRS), 3G (WCDMA, TD-SCDMA, CDMA2000, UTMS), 4G (LTE), 4G+ (LTE+), WiMax, etc.

[0049] The communication link 23 can be implemented through a communication interface set on the terminal device 20, the merchant server 21 and the platform server 22. The communication interface can use a transceiver module such as, but not limited to, a network interface card or a transceiver to achieve communication between the terminal device 20 and the merchant server 21 and the platform server 22.

[0050] The terminal device 20 can be implemented using a smart device such as, but not limited to, a smartphone, a laptop, an iPad, etc. The terminal device is installed with a merchant APP provided by a third-party server, and the merchant APP is connected to the platform APP provided by the payment platform to implement a third-party payment function.

[0051] Please refer to Figure 6, which shows a schematic diagram of the structure of the terminal device 20 described above. The terminal device includes a bus 601, a processor 602, a memory 603, and a communication interface 604. Memory 603 stores a computer program. When the computer program runs on processor 602, it causes processor 602 to execute the specific steps required by terminal device 20 in the third-party payment method. It should be understood that this application does not limit the number of processors and memories in terminal device 20.

[0052] Bus 601 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, for example. Bus 601 may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, FIG6 shows only one line, but this does not imply a single bus or a single type of bus. Bus 601 may include a path for transmitting information between various components of a terminal device (e.g., processor 602, memory 603, and communication interface 604).

[0053] The processor 602 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0054] The memory 603 may include a volatile memory, such as a random access memory (RAM). The memory 603 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

[0055] The communication interface 604 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the terminal device and other devices or communication networks, such as communication between the terminal device and the merchant server 21 and the platform server 22 .

[0056] Merchant server 21 is the server for the merchant app and can be any device, equipment, platform, or device cluster with computing and processing capabilities. In this embodiment, the implementation of merchant server 21 is not limited. For example, merchant server 21 can be a single server or a server cluster consisting of multiple servers. Merchant server 21 can also be a cloud server, also known as a cloud computing server or cloud host, which is a host product in a cloud computing service system.

[0057] Platform server 22 is the server for the platform app. Similarly, platform server 22 can be any device, equipment, platform, or device cluster with computing and processing capabilities. In this embodiment, the implementation of platform server 22 is not limited. For example, platform server 22 can be a single server or a server cluster consisting of multiple servers. Platform server 22 can also be a cloud server, also known as a cloud computing server or cloud host, which is a host product in a cloud computing service system.

[0058] Please refer to Figure 3, which shows a flow chart of the third-party payment system when implementing the third-party payment method described in this embodiment. In this third-party payment method, the platform App and the platform server 22 constitute the payment platform, and the merchant App and the merchant server 21 constitute the third-party service end. The process of the third-party payment method includes the following steps:

[0059] (301) In response to the user's order placement operation for the target order, the merchant APP sends an order request to the merchant server 21.

[0060] (302) The merchant server 21 generates a payment request in response to the order request and signs the payment request with the merchant's private key to obtain first signature information. The payment request carries a user information parameter state associated with the ordering user's identity information.

[0061] (303) The merchant server 21 returns the payment request and the first signature information to the merchant APP.

[0062] (304) The merchant APP sends the payment request and the first signature information to the platform APP.

[0063] (305) In response to the payment request, the platform APP obtains authorization information for paying the target order from the user. After obtaining authorization, the platform APP sends the authorization information, the payment request and the first signature information to the platform server 22.

[0064] (306) The platform server 22 verifies the first signature information.

[0065] (307) After the platform server 22 verifies the first signature information, it generates a payment credential token, writes the locally stored payment user identity information into the user information parameter state carried in the payment request, and then returns the payment credential token and user information parameter state to the platform APP.

[0066] (308) The platform APP returns the payment credential token and user information parameter state to the merchant APP.

[0067] (309) The merchant APP returns the payment credential token and user information parameter state to the merchant server 21.

[0068] (310) The merchant server 21 obtains the payment user identity information recorded in the user information parameter state, and performs consistency verification between the payment user identity information and the ordering user identity information associated with the user information parameter state.

[0069] (311) After verifying that the payment user identity information is consistent with the ordering user identity information, the merchant server 21 signs the payment credential token using the merchant private key to obtain the second signature information. It then sends a verification request to the platform server 22 and simultaneously transmits the payment credential token and the second signature information.

[0070] (312) After verifying the second signature information, the platform server 22 trusts the cancellation request.

[0071] (313) After the platform server 22 verifies the payment credential token, it executes the transfer operation.

[0072] (314) The platform server 22 returns the payment result to the merchant server 21.

[0073] (315) The merchant server 21 returns the payment result to the merchant APP.

[0074] As can be seen from the above process, the third-party payment method described in this embodiment includes a user information parameter, "state," in the payment request generated by the third-party server, and associates it with the current ordering user's identity information. Subsequently, platform server 22 writes the paying user's identity information into the user information parameter, "state," and returns it to merchant server 21. By comparing the paying user's identity information with the ordering user's identity information, the identity consistency between the user placing the order on the merchant app and the user paying on the platform app is ensured. Even if an attacker forges an order and tricks the user into paying, the merchant server can automatically detect the potential attack risk by detecting the "state" parameter.

[0075] After the user authorizes the payment operation, the payment platform does not transfer the funds directly, but instead issues a temporary payment credential token. Subsequently, the third-party server needs to proactively verify the token with the payment platform to complete the payment. This gives the third-party server the right to choose the timing of payment completion, allowing the third-party server to complete the transaction after verifying the state.

[0076] Corresponding to the above-mentioned third-party payment system, in some embodiments, a third-party payment method is provided. Please refer to Figure 4, which shows a flow chart of the third-party payment method, which is applicable to a third-party server and includes steps S400 to S406.

[0077] S400: In response to the user's order placement operation for the target order, a payment request and first signature information are generated, and the payment request and the first signature information are sent to the payment platform.

[0078] The payment request carries a user information parameter called "state" that is associated with the ordering user's identity information. This parameter is a fillable parameter that will be filled in later by the payment platform.

[0079] Specifically, the third-party server includes the merchant APP and the merchant server 21. The specific process of the third-party server generating the payment request and the first signature information is as follows.

[0080] After the user places an order on the merchant APP, the merchant APP can obtain the ordering user identity information based on the order information of the target order, and then send the ordering user identity information together with the order request to the merchant server 21.

[0081] The merchant server 21 stores the ordering user identity information locally, then generates payment information including the user information parameter state, and associates the user information parameter state with the user identity information.

[0082] The merchant server 21 locally stores a merchant private key issued by a trusted institution. The merchant server 21 signs the payment request using the merchant private key to obtain the first signature information. The merchant server 21 sends the payment request and the first signature information to the merchant APP.

[0083] In an optional implementation, the merchant app can include a pre-set fallback address in the payment request. This fallback address allows the payment platform to perform a fallback operation when returning the payment credential token, returning the payment credential token directly to the merchant app. By setting the fallback address, it is ensured that the user's payment credential token is returned to a trusted merchant app. Even if an attacker can forge a payment request, the process from generating the payment credential token to sending it to the merchant app cannot be interrupted because it is essentially an atomic operation. In this way, potential attacks can be automatically detected.

[0084] S402: In response to the payment platform verifying the first signature information, obtaining the payment credential returned by the payment platform and the payment user identity information transmitted by the payment platform through the user information parameter.

[0085] Specifically, the payment platform can verify the first signature information using the merchant's public key. The merchant's public key can be pre-stored locally by the payment platform. For example, the payment platform can pre-store the merchant server 21's digital certificate, which contains the merchant's public key. The digital certificate can also be sent to the payment platform by the merchant server 21 along with the payment request, and stored locally by the payment platform.

[0086] After the payment platform verifies the first signature using the merchant's public key, it confirms the merchant app's identity is trustworthy. Based on the payment request, the payment platform then obtains authorization information from the user. After obtaining the authorization information, it queries the locally stored payment user identity information, writes the payment user identity information into the user information parameter "state" included in the payment request, and generates a payment credential token. The payment platform returns the payment credential token and the user information parameter "state" to the merchant app.

[0087] In an optional implementation, the payment platform can perform a bounce operation based on the bounce address carried in the payment request, and return the payment credential token and user information parameter state to the merchant APP, thereby ensuring that the payment credential token and user information parameter state can be sent to a trusted merchant APP.

[0088] S404: Verify the user information based on the user information parameters.

[0089] Specifically, after obtaining the user information parameter state and payment credential token returned by the payment platform, the merchant server 21 can extract the payment user identity information from the user information parameter state. At the same time, the merchant server 21 can retrieve the associated ordering user identity information locally based on the user information parameter state.

[0090] The merchant server 21 compares the payment user identity information and the ordering user identity information to see if they are consistent. If they are consistent, it is determined that the user information verification is successful. If they are inconsistent, it is determined that the user information verification has failed.

[0091] S406: After the user information is verified, the payment credential is verified with the payment platform so that the payment platform completes the payment operation for the target order.

[0092] Specifically, a payment credential token is a temporary certificate confirming the user's payment for the target order, and it has a short validity period. During this validity period, the merchant server 21 can use this temporary certificate to request a transfer from the platform server. Platform server 22 verifies the validity of the payment credential token. If verified, it executes the transfer operation, transferring the funds corresponding to the target order to the merchant account. After the transfer is completed, platform server 22 also returns the payment result to merchant server 21. Merchant server 21 returns the payment result to the merchant app, which then updates the order status of the target order.

[0093] In an optional embodiment, to ensure the security of the payment credential token verification process, the merchant server 21 may also sign the payment credential token with the merchant's private key to obtain a second signature. The verification request, the second signature, and the payment credential token are then sent to the payment platform. After verifying the second signature, the payment platform trusts the merchant server 21 and, after verifying the payment credential token, proceeds with payment for the target order.

[0094] Corresponding to the above-mentioned third-party payment system, in some embodiments, a third-party payment method is also provided. Please refer to Figure 5, which shows a flow chart of the third-party payment method, which is applicable to the payment platform; the method includes steps S500 to S508.

[0095] S500: In response to the payment request from the third-party server, request the user to authorize the payment operation.

[0096] Specifically, the payment platform includes a platform APP and a platform server 22. The specific steps for the payment platform to request the user to authorize this payment operation are as follows: After the platform APP obtains the payment request from the third-party server, it obtains the order information of the target order based on the payment request, and requests authorization from the user to pay for the target order.

[0097] After obtaining the user's authorization information, the platform APP sends the authorization information, payment information, and the first signature information sent synchronously with the payment information to the platform server 22. Among them, the first signature information is obtained by the third-party server using the merchant's private key to sign the payment information.

[0098] In an optional embodiment, the payment request also carries a bounce address, which enables the platform app to return the user information parameter state and payment credential token to the third-party server through the trusted channel provided by the bounce address. Specifically, after receiving the payment request, the platform app will obtain the bounce address carried in the payment request and then store the bounce address locally. When the user information parameter state and payment credential token are returned by the platform server 22, the platform app will execute a bounce operation based on the bounce address and return the user information parameter state and payment credential token to the third-party server.

[0099] S502: In response to the user authorization, verify the first signature information sent synchronously with the payment request.

[0100] The platform server 22 can verify the first signature information using the merchant's public key. The merchant's public key can be pre-stored locally by the platform server 22. For example, the platform server 22 can pre-store a digital certificate of a third-party server, which contains the merchant's public key. The digital certificate can also be sent by the third-party server to the platform app when sending a payment request. The platform app then sends the digital certificate to the platform server 22, which then stores the digital certificate locally.

[0101] After the platform server 22 verifies the first signature information using the merchant's public key and passes the verification, it trusts the third-party server.

[0102] S504: After verifying the first signature information, a payment credential is generated, and the locally stored ordering user identity information is written into the user information parameter in the payment request.

[0103] Specifically, after confirming that the third-party server is trustworthy, the platform server 22 can obtain the locally stored payment user identity information based on the user's authorization information, and then write the payment user identity information into the user information parameter state.

[0104] At the same time, the platform server 22 generates a payment credential token. This token is a temporary certificate confirming the user's payment for the target order and is valid for a short period of time. During this period, the third-party server can use this temporary certificate to request a transfer from the platform server 22. The platform server 22 verifies the validity of the payment credential token and, if successful, executes the transfer, transferring the funds corresponding to the target order to the merchant's account.

[0105] S506: Send the payment credentials and user information parameters to the third-party server.

[0106] The platform server 22 sends the payment credential token and user information parameter state to the platform APP, and then the platform APP sends the payment credential token and user information parameter state to the third-party server.

[0107] In an optional implementation, the third-party server pre-sets a bounce address and includes it in the payment request. When the platform app sends the payment token and user information parameter state, it performs a bounce operation based on the bounce address, ensuring that the payment token and user information parameter state are returned to the third-party server through the trusted channel specified by the bounce address.

[0108] S508: In response to the cancellation request from the third-party server, the payment credentials sent synchronously with the cancellation request are verified. After the verification is passed, the payment operation for the target order is executed.

[0109] The third-party server will send a verification request and a payment credential token to the platform server 22. The platform server will only execute the payment operation for the target order after verifying the validity of the payment credential token.

[0110] In an optional embodiment, the third-party server sends a second signature simultaneously with the verification request and payment credential token to platform server 22. This second signature is obtained by signing the payment credential token with the merchant's key. Accordingly, upon receiving the verification request, platform server 22 verifies the second signature using the pre-stored merchant public key. Upon successful verification, the server trusts the third-party server and verifies the validity of the payment credential token. Upon confirming the validity of the payment credential token, platform server 22 executes payment for the target order.

[0111] In an optional embodiment, after completing the payment operation for the target order, the platform server 22 feeds back payment operation completion information to the third-party server, so that the third-party server updates the order status of the target order based on the payment operation completion information.

[0112] Those skilled in the art will appreciate that the various modules or steps of the present invention described above can be implemented using a general-purpose computing device, can be centralized on a single computing device, or can be distributed across a network of multiple computing devices. Alternatively, they can be implemented using program code executable by a computing device, and thus, can be stored in a storage device and executed by the computing device. In some cases, the steps shown or described herein can be performed in a different order than that described herein, or can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0113] The various embodiments in this specification are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the system embodiments are generally similar to the method embodiments, so the description is relatively simple. For relevant parts, refer to the description of the method embodiments.

[0114] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0115] It should be noted that the above examples are merely specific embodiments of the present invention. Obviously, the present invention is not limited to the above examples, and many similar variations are possible. All variations directly derived from or associating with the present invention by those skilled in the art are intended to fall within the scope of protection of the present invention.

Claims

1. A third-party payment method, applicable to a third-party server, comprising: In response to the user's ordering operation for the target order, a payment request and first signature information are generated, and the payment request and the first signature information are sent to the payment platform; the payment request carries a user information parameter associated with the identity information of the ordering user; In response to the payment platform verifying the first signature information, obtaining the payment credential returned by the payment platform and the payment user identity information transmitted by the payment platform through the user information parameter; verifying the user information based on the user information parameters; After the user information is verified, the payment credential is verified with the payment platform so that the payment platform completes the payment operation for the target order.

2. According to the method as claimed in claim 1, the payment request also carries a bounce address; the payment platform returns the user information parameters and the payment credentials to the third-party server based on the trusted channel provided by the bounce address.

3. The method according to claim 2, wherein the third-party service end includes a merchant APP and a merchant server; in response to a user's order operation for a target order, generating a payment request and first signature information, and sending the payment request and the first signature information to a payment platform, specifically comprising: In response to the user's order placement operation for the target order, the merchant APP sends an order request to the merchant server; The merchant server generates the payment request in response to the order request, and signs the payment request with the merchant private key to obtain the first signature information; The merchant server returns the payment request and the first signature information to the merchant APP; After adding the bounce address to the payment request, the merchant APP sends the payment request to the payment platform, so that the payment platform can perform a bounce based on the bounce address and return the payment credentials and the identity information collection parameters to the merchant APP.

4. The method according to claim 1, verifying the user information based on the user information parameter, specifically comprising: Obtaining the payment user identity information carried in the user information parameter; Querying the ordering user identity information associated with the user information parameters locally; The payment user identity information and the ordering user identity information are verified for consistency. If the verification result is consistent, it is determined that the user information verification has passed; if the verification result is inconsistent, it is determined that the user information verification has failed.

5. The method according to claim 1, after verifying the user information, reimbursing the payment credential to the payment platform, specifically comprising: In response to verifying the user information, the merchant server generates a verification request and signs the payment credential with the merchant private key to obtain second signature information; The cancellation request, the second signature information and the payment credential are sent to the payment platform, so that the payment platform executes the payment operation for the target order after verifying the second signature information and the payment credential.

6. The method of claim 1, further comprising: In response to the payment operation completion information fed back by the payment platform, the order status of the target order is updated.

7. A third-party payment method, applicable to a payment platform, comprising: In response to the payment request from the third-party server, request the user to authorize the payment operation; In response to the user authorization, verifying the first signature information sent synchronously with the payment request; After verifying the first signature information, a payment credential is generated, and the locally stored ordering user identity information is written into the user information parameter in the payment request; Sending the payment credentials and the user information parameters to the third-party server; In response to the verification request of the third-party service end, the payment credential sent synchronously with the verification request is verified, and after the verification is passed, the payment operation for the target order is executed.

8. According to the method as claimed in claim 7, the payment request also carries a bounce address; the payment platform returns the user information parameters and the payment credentials to the third-party server based on the trusted channel provided by the bounce address.

9. The method according to claim 8, wherein the payment platform comprises a platform APP and a platform server; the specific steps performed by the platform APP and the platform server include: In response to the payment request, the platform APP requests the user to authorize the payment operation; In response to the user authorization, the platform APP obtains the bounce address carried in the payment request, and sends the payment request, the first signature information transmitted synchronously with the payment request, and the user's authorization information to the platform server; After verifying the first signature information, the platform server generates the payment credential and writes the locally stored ordering user identity information into the user information parameter in the payment request; The platform server returns the user information parameters and the payment credentials to the platform APP; The platform APP returns the user information parameters and the payment credentials to the third-party server based on the trusted channel provided by the bounce address.

10. The method according to claim 7, in response to the verification request of the third-party server, verifying the payment credential sent synchronously with the verification request, and after the verification is passed, executing the payment operation for the target order, specifically comprising: In response to the cancellation request from the third-party server, verifying the second signature information transmitted synchronously with the cancellation request; After verifying the second signature information, checking the payment credential; After the payment credential is verified, the payment operation for the target order is executed.

11. The method of claim 7, further comprising: After the payment operation for the target order is completed, payment operation completion information is fed back to the third-party server, so that the third-party server updates the order status of the target order based on the payment operation completion information.

12. A third-party payment system, including a third-party service end and a payment platform; The third-party server is used to execute the method as described in any one of claims 1 to 6, and the payment platform is used to execute the method as described in any one of claims 7 to 11, so as to realize the user's payment operation for the target order on the third-party server.

Images