Payment method and system and storage medium

Abstract

The embodiment of the invention provides a payment method and system and a storage medium. According to the payment method, when an interaction page of a commercial tenant system is displayed on terminal equipment, the commercial tenant system collects equipment information of the terminal equipment, and payment operation is initiated for a target transaction in the interaction page of the commercial tenant system in response to detection of a target account. The merchant system sends a payment request and equipment information to the wallet system through the intermediate service system; the wallet system executes a risk control process on the payment request based on the equipment information to obtain a risk control result, determines a payment result corresponding to the payment request based on the risk control result, and sends the payment result to the merchant system through the intermediate service system; and the merchant system displays the payment result on an interaction page of the merchant system. In the process that the merchant system, the wallet system and the intermediate service system execute the payment method, the terminal equipment does not jump to an interaction page of the wallet system.

Description

[0001] This application claims the priority of a Singaporean patent application with the application number 10202402923Q filed on September 20, 2024, the entire content of which is incorporated herein by reference. Technical Field

[0002] This specification relates to the field of Internet technologies, and particularly to a payment method, system, and storage medium. Background Art

[0003] In the fields of transactions and payments, when an interactive page of a merchant system is displayed on a terminal device, a user can initiate a payment operation for a certain transaction in the merchant system to trigger the wallet system to make a payment for the transaction. The wallet system needs to perform risk prevention and control for the transaction to ensure the payment security of the user. For example, the payment process is as follows: When the user initiates a payment operation for the transaction on the interactive page of the merchant system, the terminal device jumps to the interactive page of the wallet system. After the terminal device jumps to the interactive page of the wallet system, the wallet system can collect the device information of the terminal device and perform risk prevention and control for the transaction based on the above device information. For example, the wallet system can compare the above device information with the device information associated with the current account of the wallet system to identify whether the current account is a stolen account. When it is identified that the current account is not a stolen account, the wallet system continues to execute the subsequent payment process. When it is identified that the current account is a stolen account, the wallet system can reject the payment, thereby achieving risk prevention and control.

[0004] In the above payment process, the terminal device needs to jump from the merchant system to the wallet system. During the jump process, the payment process takes a long time due to resource loading and other situations, and the payment process of cross-system jump is relatively cumbersome. Each additional jump may affect the payment success probability due to network and other reasons, resulting in poor user experience. To solve the above problems, there are currently some payment solutions where the terminal device does not jump from the merchant system to the wallet system throughout the payment process. However, these above payment solutions increase the difficulty of risk control for the wallet system. Therefore, how to enable the wallet system to perform effective risk control when the terminal device does not jump to the wallet system is an urgent problem to be solved currently.

[0005] The content in the background art section is only the information known to the inventor personally, and does not represent that the above information has entered the public domain before the filing date of this disclosure, nor does it represent that it can become the prior art of this disclosure. Summary of the Invention

[0006] This specification provides a payment method, system, and storage medium, which can achieve effective risk control without cross-system jump and improve user experience.

[0007] In a first aspect, this specification provides a payment method, which is applied to an intermediate service system that provides intermediate services between a merchant system and a wallet system. The method includes: when an interaction page of the merchant system is displayed on a terminal device, receiving device information and a payment request from the merchant system, where the device information is collected by the merchant system for the terminal device, and the payment request indicates that a target account requests to use the wallet system to pay for a target transaction in the merchant system; sending the payment request and the device information to the wallet system, where the device information is used for the risk control process of the payment request by the wallet system; receiving a payment result corresponding to the payment request from the wallet system; and sending the payment result to the merchant system so that the merchant system can display the payment result in the interaction page of the merchant system. During the execution of the payment method by the intermediate service system, the terminal device does not jump to the interaction page of the wallet system.

[0008] In a second aspect, this specification provides a payment method, which is applied to a wallet system. The method includes: when an interaction page of a merchant system is displayed on a terminal device and a target account initiates a payment operation for a target transaction in the interaction page of the merchant system, receiving device information and a payment request from an intermediate service system, where the device information is collected by the merchant system for the terminal device, and the intermediate service system provides intermediate services between the merchant system and the wallet system; performing a risk control process on the payment request based on the device information to obtain a risk control result; determining a payment result corresponding to the payment request based on the risk control result; and sending the payment result to the intermediate service system so that the payment result can be displayed in the interaction page of the merchant system. During the execution of the payment method by the wallet system, the terminal device does not jump to the interaction page of the wallet system.

[0009] In a third aspect, this specification provides a payment method, which is applied to a merchant system. The method includes: when an interaction page of the merchant system is displayed on a terminal device, collecting device information of the terminal device; in response to detecting that a target account initiates a payment operation for a target transaction in the interaction page of the merchant system, sending the device information and a payment request to an intermediate service system, where the device information is used for the risk control process of the payment request by the wallet system, and the intermediate service system is used to provide intermediate services between the merchant system and the wallet system; and receiving a payment result corresponding to the payment request from the intermediate service system and displaying the payment result in the interaction page of the merchant system. During the execution of the payment method by the merchant system, the terminal device does not jump to the interaction page of the wallet system.

[0010] Fourth aspect, this specification also provides an intermediate service system, including: at least one storage medium storing at least one instruction set for payment; and at least one processor communicatively connected to the at least one storage medium, wherein when the at least one processor runs, it reads the at least one instruction set and executes a payment method according to the instruction of the at least one instruction set. The payment method includes: when an interactive page of the merchant system is displayed on the terminal device, receiving device information and a payment request from the merchant system, where the device information is collected by the merchant system for the terminal device, and the payment request represents that a target account requests to use the wallet system for payment in the merchant system; sending the payment request and the device information to the wallet system, where the device information is used for the risk control process of the payment request by the wallet system; receiving a payment result corresponding to the payment request from the wallet system; and sending the payment result to the merchant system so that the merchant system can display the payment result on the interactive page of the merchant system. Wherein, during the execution of the payment method by the intermediate service system, the terminal device does not jump to the interactive page of the wallet system.

[0011] Fifth aspect, this specification also provides a wallet system, including: at least one storage medium storing at least one instruction set for payment; and at least one processor communicatively connected to the at least one storage medium, wherein when the at least one processor runs, it reads the at least one instruction set and executes a payment method according to the instruction of the at least one instruction set. The payment method includes: when an interactive page of the merchant system is displayed on the terminal device and a target account initiates a payment operation for a target transaction on the interactive page of the merchant system, receiving device information and a payment request from an intermediate service system, where the device information is collected by the merchant system for the terminal device, and the intermediate service system provides an intermediate service between the merchant system and the wallet system; performing a risk control process on the payment request based on the device information to obtain a risk control result; determining a payment result corresponding to the payment request based on the risk control result; and sending the payment result to the intermediate service system so that the payment result can be displayed on the interactive page of the merchant system. Wherein, during the execution of the payment method by the wallet system, the terminal device does not jump to the interactive page of the wallet system.

[0012] Sixth aspect, this specification also provides a merchant system, including: at least one storage medium storing at least one instruction set for payment; and at least one processor communicatively connected to the at least one storage medium, wherein when the at least one processor runs, it reads the at least one instruction set and executes a payment method according to the indication of the at least one instruction set. The payment method includes: when an interaction page of the merchant system is displayed on a terminal device, collecting device information of the terminal device, and in response to detecting that a target account initiates a payment operation for a target transaction in the interaction page of the merchant system, sending the device information and a payment request to an intermediate service system. The device information is used for a risk control process of the wallet system for the payment request. The intermediate service system is used to provide an intermediate service between the merchant system and the wallet system, and receiving a payment result corresponding to the payment request from the intermediate service system and displaying the payment result in the interaction page of the merchant system. Wherein, during the execution of the payment method by the merchant system, the terminal device does not jump to an interaction page of the wallet system.

[0013] Seventh aspect, this specification provides a computer-readable non-transitory storage medium, wherein at least one instruction set is stored in the computer-readable non-transitory storage medium, and when the at least one instruction set is executed by at least one processor, it implements the payment method as described in the first aspect or the second aspect or the third aspect.

[0014] Other functions of the payment method, system, and storage medium provided in this specification will be partially listed in the following description. The creative aspects of the payment method, system, and storage medium provided in this specification can be fully explained by practicing or using the methods, devices, and combinations described in the following detailed examples. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] To more clearly illustrate the technical solutions in the embodiments of this specification, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the following drawings are only some embodiments of this specification. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0016] Figure 1 Shows a schematic diagram of cross-system jump provided according to an embodiment of this specification;

[0017] Figure 2 Shows a schematic diagram of non-cross-system jump provided according to an embodiment of this specification;

[0018] Figure 3 Shows a schematic diagram of a payment scenario provided according to an embodiment of this specification;

[0019] Figure 4 Shows the hardware structure diagram of a service system provided according to an embodiment of this specification;

[0020] Figure 5 Shows the schematic flowchart of a payment method provided according to an embodiment of this specification;

[0021] Figure 6 Shows the schematic flowchart of an identity verification process provided according to an embodiment of this specification;

[0022] Figure 7 Shows a schematic diagram of the payment result without cross - system jump provided according to an embodiment of this specification;

[0023] Figure 8 Shows another schematic diagram of the payment result without cross - system jump provided according to an embodiment of this specification;

[0024] Figure 9 Shows the schematic flowchart of another payment method provided according to an embodiment of this specification; and

[0025] Figure 10 Shows another schematic flowchart of an identity verification process provided according to an embodiment of this specification. Detailed implementation manners

[0026] The following description provides specific application scenarios and requirements of this specification, aiming to enable those skilled in the art to manufacture and use the content in this specification. For those skilled in the art, various partial modifications to the disclosed embodiments are obvious, and without departing from the spirit and scope of this specification, the general principles defined here can be applied to other embodiments and applications. Therefore, this specification is not limited to the shown embodiments, but has the broadest scope consistent with the claims.

[0027] The terms used here are only for the purpose of describing specific example embodiments and are not restrictive. For example, unless the context clearly indicates otherwise, the singular forms "a", "an" and "the" used here may also include the plural forms. When used in this specification, the terms "include", "comprise" and / or "contain" mean that the associated integers, steps, operations, elements and / or components exist, but do not exclude the existence of one or more other features, integers, steps, operations, elements, components and / or groups, or the addition of other features, integers, steps, operations, elements, components and / or groups in the system / method.

[0028] In view of the following description, these and other features of the present specification, as well as the operations and functions of the relevant elements of the structure, and the combination and manufacturing economy of the components can be significantly improved. Referring to the accompanying drawings, all of which form a part of the present specification. However, it should be clearly understood that the drawings are for illustrative and descriptive purposes only and are not intended to limit the scope of the present specification. It should also be understood that the drawings are not drawn to scale.

[0029] The flowcharts used in the present specification illustrate the operations implemented by the system according to some embodiments in the present specification. It should be clearly understood that the operations of the flowchart may not be implemented in sequence. On the contrary, the operations may be implemented in reverse order or simultaneously. In addition, one or more other operations may be added to the flowchart. One or more operations may be removed from the flowchart.

[0030] There is often a risk of account takeover (ATO) on the network, that is, criminals access an account through technical means without the authorization of the legitimate user. The ATO risk can also be referred to as the risk of account theft. In the payment field, the ATO risk will not only cause property losses to legitimate users, but also bring claims losses to the wallet system. Therefore, before making a payment for a certain transaction, the wallet system needs to identify the ATO risk, that is, to identify whether the wallet account associated with the current transaction is a stolen account. If it is a stolen account, the wallet system can reject the current payment. If it is not a stolen account, the wallet system can make a payment for the current transaction.

[0031] Generally, when a wallet system conducts ATO risk identification, it can adopt a risk control solution based on device consistency. Specifically, the wallet system can maintain a database that stores the device information of the commonly used devices corresponding to each wallet account. Among them, the commonly used device refers to a device that has been used once or multiple times by the wallet account within a historical time period. The device information can be a set of device parameters that can uniquely identify a device. In some embodiments, the wallet system can perform specific operations on the device information to obtain an identifier that can uniquely represent the device information, and store the identifier in the above database. The above identifier can also be called a device fingerprint. At this time, the database stores the device fingerprints of the commonly used devices corresponding to each wallet account. After the wallet system receives a payment request sent by a certain wallet account through a terminal device, it can match the device information of the terminal device with the device fingerprint corresponding to the wallet account in the database (for example, perform specific operations on the device information of the terminal device to obtain a target identifier, and match the target identifier with the device fingerprint corresponding to the wallet account in the database), and identify whether the terminal device is the commonly used device corresponding to the wallet account based on the matching result. For example, if it is a commonly used device, it is considered that the wallet account is not a stolen account and there is no ATO risk. If it is not a commonly used device, it is considered that the wallet account is a stolen account and there is an ATO risk.

[0032] The following separately introduces the payment risk control solutions and payment processes corresponding to the cross-system jump scenario (that is, the terminal device jumps from the merchant system to the wallet system during the payment process) and the non-cross-system jump scenario (that is, the terminal device does not jump from the merchant system to the wallet system during the payment process).

[0033] Cross-system jump scenario

[0034] The merchant system outputs an interactive page through the terminal device, and the user can initiate a transaction on the interactive page through the target account (or target account number). For the said transaction, when the user initiates a payment operation on the interactive page of the merchant system, the terminal device will jump from the interactive page of the merchant system to the interactive page of the wallet system. The user can perform the payment process on the interactive page output by the wallet system through the terminal device. After the terminal device jumps to the wallet system, the wallet system can collect the device information of the terminal device and execute a risk control solution (such as the ATO risk identification solution described above) based on the device information to obtain a risk control result. Furthermore, the wallet system can determine the payment result of the said transaction according to the risk control result. The wallet system can feedback the payment result to the merchant system, and the merchant system displays the payment result to the user through the terminal device.

[0035] For example Figure 1As shown, the user initiates a target transaction to purchase Product 2 through the target account on the interaction page A of the merchant system. After the user clicks "Settle", the terminal device will display the interaction page B of the merchant system to the user. The user can select a payment method on the interaction page B. For example, the user clicks "Payment Method 2". At this time, the page displayed on the terminal device will jump from the interaction page B to the interaction page 1 of the wallet system, and the interaction page 1 displays "Payment service in progress..." to the user. The wallet system makes a risk control decision on the current transaction based on the device information of the terminal device (such as the ATO risk identification scheme described above) to obtain a risk control result. Further, the wallet system can determine the payment result based on the risk control result and feedback the payment result to the merchant system. The merchant system can output the interaction page D through the terminal device to display the payment result to the user. Among them, the device information required for the above risk control process is collected by the wallet system from the terminal device after the terminal device jumps from the merchant system to the wallet system.

[0036] However, in the payment scheme adopting the above cross-system jump scenario, the payment process takes a long time due to situations such as resource loading, and the cross-system jump payment process is relatively cumbersome. Each additional jump may affect the payment success probability due to reasons such as network, resulting in a poor user experience.

[0037] Non-cross-system jump scenario

[0038] For the said transaction, when the user initiates a payment operation on the interaction page of the merchant system, the terminal device will not jump from the interaction page of the merchant system to the interaction page of the wallet system. The merchant system can send a payment request corresponding to the target transaction to the wallet system. In response to the payment request, the wallet system instructs the merchant system to conduct multiple identity verifications on the user.

[0039] For example Figure 2 As shown, the content before the user selects a payment method on the interaction page B refers to the description in the cross-system jump scenario and will not be elaborated here. After the user selects "Payment Method 2" on the interaction page B, the terminal device does not jump to the interaction page of the wallet system. That is to say, the interaction page of the merchant system is still displayed to the user subsequently. For example, the merchant system displays an identity verification page to the user, and the user can enter multiple identity verification information in the identity verification information input area. Or, the merchant system displays multiple identity verification pages to the user, and the user can enter one type of identity verification information in the identity verification information input area of each identity verification page. Subsequently, the merchant system will display the payment result to the user through the interaction page D.

[0040] Since the terminal device does not jump to the wallet system, it is difficult for the wallet system to collect the device information of the terminal device, resulting in the wallet system being unable to perform ATO risk identification based on the device information, and thus it is more difficult for the wallet system to implement payment risk control. To ensure the payment security of users, the risk control strategy adopted by the wallet system is to let the merchant system perform enhanced identity verification on all trading users without discrimination, such as performing identity verification on users in multiple dimensions. The multiple dimensions include at least two of the following: static password, dynamic password (such as verification code), and biometric information such as face and fingerprint. With this risk control strategy, users need to enter multiple different identity verification information each time they make a payment, resulting in a poor experience and easily causing users to cancel the payment, affecting the payment success rate. And if multiple identity verification information of users is stolen, this solution still cannot achieve effective risk control.

[0041] In view of this, this specification provides a payment method, system and storage medium, aiming to enable the wallet system to achieve effective risk control and improve user experience without cross-system jumping.

[0042] Figure 3 The figure shows a schematic diagram of a payment scenario provided according to an embodiment of this specification.

[0043] As Figure 3 shown, Scenario 001 includes the current user 110, the terminal device 120, the merchant system 10, and the wallet system 20. Among them, the merchant system 10 includes a merchant client 122 and a merchant server 132. The wallet system 20 includes a wallet client 124 and a wallet server 134. As Figure 3 shown, the merchant client 122 and the wallet client 124 are deployed in the terminal device 120. The current user 110 may be a legitimate user or an illegal element who steals the relevant information of a legitimate user.

[0044] In some embodiments, Scenario 001 further includes an intermediate service system 30, and the intermediate service system 30 is used to provide intermediate services between the merchant system 10 and the wallet system 20. The intermediate service system 30 includes an intermediate server 136. In some embodiments, the intermediate service system 30 may further include an intermediate service client ( Figure 3(not shown), the intermediate service client can be deployed in the terminal device 120. The intermediate service client provides a cashier desk for the user, and the user can initiate a payment at the cashier desk. In some embodiments, the intermediate service client can be integrated into the merchant client 122 in a certain form. For example, the cashier desk is integrated into the merchant client 122 in the form of an SDK (Software Development Kit). When the user initiates a settlement for a certain transaction in the merchant client 122, the merchant client 122 calls the SDK to render the cashier desk page so that the user can initiate a payment on the cashier desk page.

[0045] In some embodiments, the terminal device 120 may be installed with one or more applications (APPs). The APPs include, but are not limited to: web browser APPs, search APPs, chat APPs, shopping APPs, video APPs, financial management APPs, instant messaging tools, email clients, social platform software, and so on. For example, the terminal device 120 is installed with an APP of the merchant system (i.e., the merchant client 122) and an APP of the wallet system (i.e., the wallet client 124).

[0046] The terminal device 120 may include a mobile device, a tablet computer, a laptop computer, a built-in device of a motor vehicle, or the like, or any combination thereof. In some embodiments, the mobile device may include a smart home device, a smart mobile device, a virtual reality device, an augmented reality device, or the like, or any combination thereof. In some embodiments, the smart home device may include a smart TV, a desktop computer, etc., or any combination. In some embodiments, the smart mobile device may include a smart phone, a personal digital assistant, a gaming device, a navigation device, etc., or any combination thereof. In some embodiments, the virtual reality device or the augmented reality device may include a virtual reality helmet, virtual reality glasses, virtual reality patches, augmented reality helmets, augmented reality glasses, augmented reality patches, or the like, or any combination thereof. For example, the virtual reality device or the augmented reality device may include AR glasses, a head-mounted display, VR, etc. In some embodiments, the built-in device in the motor vehicle may include an in-vehicle computer, an in-vehicle TV, etc. In some embodiments, the terminal device 120 may be a device with positioning technology for positioning the location of the terminal device 120.

[0047] Exemplarily, the terminal device 120 can display an interaction page to the current user 110. The current user 110 can perform corresponding operations on the interaction page to achieve interaction with the merchant system and / or the wallet system.

[0048] In some embodiments, the merchant system 10 and the wallet system 20 cooperate with each other to execute the payment method provided in the embodiments of this specification. During the execution process, what the terminal device 120 presents to the current user 110 is the interaction page of the merchant system, that is, the terminal device does not jump to the interaction page of the wallet system.

[0049] In some embodiments, the merchant system 10, the wallet system 20, and the intermediate service system 30 cooperate with each other to execute the payment method provided in the embodiments of this specification. Similarly, during the execution process, what the terminal device 120 presents to the current user 110 is the interaction page of the merchant system, that is, the terminal device does not jump to the interaction page of the wallet system.

[0050] Specifically, during the execution of the payment method provided in the embodiments of this specification, the specific operations performed by each system, as well as the client and server within the system, are introduced in detail in the subsequent method P500 and will not be elaborated here.

[0051] Among them, the merchant server 132 and / or the wallet server 134 can be various types of servers. For example, it can be a cloud server or a local server.

[0052] The communication connection medium between the merchant client 122 and the merchant server 132, between the wallet client 124 and the wallet server 134, and between the merchant server 132, the intermediate server 136, and the wallet server 134 can be a network. The network can facilitate the exchange of information or data.

[0053] In some embodiments, the network can be any type of wired or wireless network, or a combination thereof. For example, the network can include a cable network, a wired network, an optical fiber network, a telecommunication network, an intranet, the Internet, a local area network (LAN), a wide area network (WAN), a wireless local area network (WLAN), a metropolitan area network (MAN), a public switched telephone network (PSTN), a Bluetooth networkTM, a short-range wireless network (ZigBeeTM), a near field communication (NFC) network, or a similar network.

[0054] In some embodiments, the network may include one or more network access points. For example, the network may include wired or wireless network access points, such as base stations or Internet exchange points. Through these access points, one or more components of the terminal device 120 and the merchant server 132 can be connected to the network to exchange data or information; one or more components of the terminal device 120 and the wallet server 134 can be connected to the network to exchange data or information; one or more components of the merchant server 132, the wallet server 134, and the intermediate server 136 can be connected to the network to exchange data or information.

[0055] Figure 4 FIG. shows a hardware structure diagram of a service system 300 provided according to an embodiment of the present specification. Among them, the service system 300 may be a merchant system 10, a wallet system 20, or an intermediate service system 30.

[0056] As Figure 4 shown, the service system 300 may include at least one storage medium 303 and at least one processor 302. In some embodiments, the service system 300 may further include a communication port 304 and an internal communication bus 301. In some embodiments, the service system 300 may further include I / O components 305.

[0057] The internal communication bus 301 can connect different system components. For example, the internal communication bus 301 can connect the storage medium 303, the processor 302, the communication port 304, and the I / O components 305.

[0058] The I / O components 305 support input / output between the service system 300 and other components.

[0059] The communication port 304 is used for data communication between the service system 300 and the outside world. For example, the communication port 304 can be used for data communication between the service system 300 and the network. The communication port 304 can be a wired communication port or a wireless communication port.

[0060] The storage medium 303 may include a data storage device. The data storage device may be a non-transitory storage medium or a transitory storage medium. For example, the data storage device may include one or more of a magnetic disk 3031, a read-only storage medium (ROM) 3032, or a random access storage medium (RAM) 3033. The storage medium 303 further includes at least one instruction set stored in the data storage device. The instruction set includes computer program code, and the computer program code may include programs, routines, objects, components, data structures, processes, modules, etc. for executing the payment method provided in the embodiments of the present specification.

[0061] At least one processor 302 may be communicatively connected to at least one storage medium 303. The at least one processor 302 is configured to execute the above-mentioned at least one instruction set. When the service system 300 is running, the at least one processor 302 reads the at least one instruction set and, according to the instructions of the at least one instruction set, executes the payment method provided in the embodiments of the present specification. The processor 302 may execute all the steps included in the payment method. The processor 302 may be in the form of one or more processors. In some embodiments, the processor 302 may include one or more hardware processors, such as a microcontroller, a microprocessor, a reduced instruction set computer (RISC), an application-specific integrated circuit (ASIC), an application-specific instruction set processor (ASIP), a central processing unit (CPU), a graphics processing unit (GPU), a physics processing unit (PPU), a microcontroller unit, a digital signal processor (DSP), a field-programmable gate array (FPGA), an advanced RISC machine (ARM), a programmable logic device (PLD), any circuit or processor capable of executing one or more functions, etc., or any combination thereof.

[0062] For illustrative purposes only, only one processor 302 is shown in the service system 300 in the drawings. However, it should be noted that the service system 300 in the present specification may also include multiple processors. Therefore, the operations and / or method steps disclosed in the present specification may be executed by one processor or jointly executed by multiple processors. For example, if it is described in the present specification that the processor 302 of the service system 300 executes step A and step B, it should be understood that step A and step B may also be jointly or separately executed by two different processors 302 (for example, the first processor executes step A, the second processor executes step B, or the first and second processors jointly execute steps A and B).

[0063] Figure 5 An interaction diagram of the payment method P500 provided in the embodiments of the present specification is shown. As Figure 5 shown, the payment method P500 is executed in cooperation with the current user, the merchant system, the intermediate service system, and the wallet system. The intermediate service system provides intermediate services for the merchant system and the wallet system and may include an intermediate client and an intermediate server, or only include an intermediate server. The intermediate service system is, for example, an acquirer system. The payment method P500 includes S510 to S590.

[0064] S510: When an interaction page of the merchant system is displayed on the terminal device, the merchant system collects the device information of the terminal device.

[0065] The interaction page of the merchant system can be understood as: a page provided by the merchant system or output by the merchant system through a terminal device and used for interaction between the current user and the merchant system. The merchant system includes a merchant client and a merchant server.

[0066] For example, the interaction page is a page displayed by the merchant client to the current user through a terminal device. The current user can interact with the merchant client through this page and can also interact with the merchant server through this page.

[0067] Specifically, the interaction between the current user and the merchant system can refer to Figure 1 or Figure 2 the relevant parts and descriptions thereof, which will not be elaborated here.

[0068] Exemplarily, in the case where the terminal device displays the interaction page of the merchant system, the merchant client can collect the device information of the terminal device. In some embodiments, the intermediate service system can provide a cashier service to the merchant system. The merchant client can integrate an SDK corresponding to the cashier service, and the merchant client can collect the device information of the terminal device through this SDK. In some embodiments, when the merchant client detects that the target user initiates a settlement on the transaction page of the merchant system, it renders the cashier page through this SDK and collects the device information of the terminal device through this SDK.

[0069] In some embodiments, the device information of the terminal device includes at least one of the following:

[0070] The hardware parameters of the terminal device, the software parameters of the terminal device, the network parameters of the terminal device, and the behavior characteristics of the current user of the terminal device.

[0071] Exemplarily, the hardware parameters include but are not limited to: the type of central processing unit (CPU), the memory capacity, the hard disk serial number, the media access control (MAC) address, the universal serial bus (USB) device, the graphics card information, etc. The software parameters include but are not limited to: the type of operating system, the version of the operating system, the font, the screen resolution, the time zone, the language setting, etc. The network parameters include but are not limited to: the Internet Protocol (IP) address, the network location, the information of the Internet service provider (ISP), the network connection type (such as Wi-Fi, cellular data), etc. The behavior characteristics include but are not limited to browsing habits, click frequencies, residence times, etc.

[0072] In this embodiment, the device information collected by the merchant system is relatively comprehensive, providing a basis for the subsequent risk control process of payment requests.

[0073] S520: The current user initiates a payment operation for a target transaction through a target account on the interaction page of the merchant system.

[0074] The target account is an account registered or applied for by a legitimate user in the merchant system and can be used to initiate target transactions in the merchant system. The current user may be the legitimate user or an illegal element who steals the relevant information of the legitimate user.

[0075] Exemplarily, the current user initiates a payment operation for a target transaction through a target account on the interaction page displayed by the merchant client. The initiation of the payment operation is, for example Figure 1 as shown, by clicking on virtual buttons such as "Payment Method 2". It can be understood that the interaction page of the merchant system mentioned in S510 and the interaction page of the merchant system mentioned in S520 can be the same page or different pages, and the embodiments of this specification do not limit this.

[0076] S530: In response to detecting the payment operation, the merchant system sends the device information and the payment request to an intermediate service system (such as an intermediate server).

[0077] Among them, the payment request may contain information related to the target transaction, such as the payment amount, payment account, etc.

[0078] There can be multiple ways to implement the merchant system sending the payment request and the device information to the intermediate service system. In some embodiments, the merchant system can send the payment request and the device information simultaneously. That is, the merchant system carries the payment request and the device information in one message and sends it out. In this case, the message sent by the merchant system to the intermediate service system contains the payment request and the device information. For example, in S510, after the merchant system collects the device information of the terminal device, it can first store the device information. After detecting the payment operation, the merchant system sends the payment request and the device information to the intermediate service system. In some embodiments, the merchant system can send the payment request and the device information successively. For example, the merchant system first sends the payment request and then sends the device information, or the merchant system first sends the device information and then sends the payment request. For example, in S510, after the merchant system collects the device information of the terminal device, it can immediately send the device information to the intermediate service system, and after detecting the payment operation, it sends the payment request to the intermediate service system. That is to say, the payment request and the device information can be carried in different messages and sent out by the merchant system.

[0079] In addition, when the merchant system sends the device information, it can send the device information itself or relevant information that can represent the device information. When the merchant system sends relevant information that can represent the device information, this specification does not limit the form of the relevant information. For example, the merchant system can process the device information or perform a specified operation to obtain result information, and send the above result information to the intermediate service system. After receiving the result information, the intermediate service system or the wallet system can deduce the device information based on the above result information. Another example is that the merchant system can process the device information through a specific tool to obtain an identifier (i.e., device fingerprint) that can uniquely represent the device information, and send the identifier to the intermediate service system. The above specific tool can be a device fingerprint SDK (software development kit).

[0080] In some embodiments, the device information sent by the merchant system to the intermediate service system in S530 can be part of the device information collected by the merchant system in S510.

[0081] For example, the merchant client or the merchant server selects some representative parameters in the device information that do not involve device privacy and sends the above parameters to the intermediate service system.

[0082] In the above embodiments, considering privacy issues, the merchant system tries to transmit some information that can be used for payment risk control to the intermediate service system, providing a basis for the payment risk control of downstream systems (such as the intermediate service system and the wallet system), thereby improving the accuracy of the risk control of downstream systems.

[0083] Exemplarily, in S510, after the merchant client collects the device information of the terminal device, it can send the device information to the merchant server. In S520, the merchant client generates a payment request in response to detecting the payment operation. The merchant client sends the payment request to the merchant server. After receiving the payment request, the merchant server sends the payment request and the device information to the intermediate service system (intermediate server).

[0084] In some embodiments, before executing S530, the merchant system can also perform risk control on the target transaction to obtain risk control advice information. Thus, in S530, in response to the payment operation, the merchant system can also send the risk control advice information to the intermediate service system. The risk control advice information is used for the risk control process of the payment request by downstream systems (the intermediate service system or the wallet system). For example, the merchant system can send the risk control advice information, the payment request, and the device information simultaneously, or send the risk control advice information, the payment request, and the device information sequentially.

[0085] Exemplarily, the merchant system performs risk identification on the target transaction based on at least one of the internal information of the merchant system and the device information, and generates the risk control recommendation information.

[0086] Wherein, the internal information of the merchant system includes at least one of the following: transaction information of the target transaction, and user information corresponding to the target account.

[0087] The transaction information of the target transaction includes, but is not limited to: transaction amount, transaction item, transaction time, logistics address, etc.

[0088] The user information corresponding to the target account includes, but is not limited to: registration information of the target account in the merchant system; and user behavior data of the target account in the merchant system. The user behavior data includes, but is not limited to: browsing habits, click frequency, preferences, stay time, transaction frequency, etc.

[0089] The merchant system can perform risk identification on the target transaction based on multiple methods. Here are several examples, and the embodiments of this specification do not limit this.

[0090] For example, after obtaining the internal information or device information, the risk control personnel of the merchant system obtain the risk identification result according to manual experience, and input the risk identification result into the merchant system. The merchant system generates the risk control recommendation information based on the risk identification result.

[0091] For example, the merchant system presets a risk identification model, and inputs the internal information and / or device information into the risk identification model to obtain the risk control recommendation information.

[0092] For example, the merchant system presets multiple risk identification conditions (or risk identification rules), and obtains the risk control recommendation information based on the internal information and / or device information, and the multiple risk identification conditions. The risk identification conditions are, for example, whether the recent transaction frequency of the target account exceeds a threshold.

[0093] During the risk identification process of the merchant system, at least one risk can be identified. The at least one risk includes, but is not limited to, the risk of whether the target account has been stolen, Root risk, jailbreak risk, hijacking injection risk, emulator risk, etc. Among them, the Root risk refers to: security risks related to the terminal device or the system installed on the terminal device being granted superuser privileges. The jailbreak risk refers to: the risk of bypassing the operating system restrictions on the terminal device to obtain root-level system access rights. The hijacking injection risk refers to: the terminal device allowing an attacker to manipulate or deceive users or the system by injecting malicious code or tampering with data streams. The emulator risk refers to: the risk that there may be an emulator on the terminal device that can be exploited to obtain access rights to the host system.

[0094] It can be understood that the risk identification process can be executed on the merchant client or on the merchant server, and the embodiments of this specification do not limit this.

[0095] Exemplarily, the merchant system can also determine the risk control recommendation information based on the device information. For example, the merchant system can perform ATO risk identification based on the device information on the merchant side to obtain the risk control recommendation information. The process of the merchant system performing ATO risk identification is similar to the process of the wallet system performing ATO risk identification described above. For example, the merchant system obtains the device information of the common device corresponding to the target account in the database, matches the device information of the common device with the device information of the current terminal device to obtain a matching result, and then obtains the risk control recommendation information based on the matching result.

[0096] In this embodiment, the merchant system can collect relatively comprehensive device information and has relatively rich internal information, and can master the behavior traces of lawbreakers. Some of this information involves privacy and cannot be transmitted to the downstream system. Therefore, the merchant system pre-identifies the risks of the target transaction based on this multi-dimensional information, and then transmits the risk control recommendation information to the intermediate service system. This method can solve the problem that the downstream system cannot accurately perform risk control due to the inability to collect device information. Moreover, in this embodiment, by the merchant system transmitting the risk control recommendation information to the downstream system, it can assist the downstream system in performing the risk control process for payment requests, achieving the purpose of joint prevention and control by the merchant system, the intermediate service system, and the wallet system, and can improve the accuracy of payment risk control in the non-jump scenario.

[0097] In some embodiments, the risk control recommendation information at least characterizes the risk level of the target transaction.

[0098] Among them, the risk level reflects the high / low or severity of the risk corresponding to the target transaction. For example, the risk level of the target transaction can be high risk, medium risk, or low risk. Or, the risk level of the target transaction can be at risk or risk-free.

[0099] In some embodiments, the risk control recommendation information may also characterize the risk control strategy corresponding to the target transaction.

[0100] For example, if the risk level characterized by the risk control recommendation information is high risk, the risk control strategy corresponding to the target transaction may be interception. Or, if the risk level characterized by the risk control recommendation information is medium risk, the risk control strategy corresponding to the target transaction may be to strengthen identity verification, such as using multiple identity verification methods to verify the identity of the current user, or using specific identity verification methods to verify the identity of the current user. Or, if the risk level characterized by the risk control recommendation information is low risk, the risk control strategy corresponding to the target transaction may be to release, that is, the payment of the target transaction can be completed without identity verification.

[0101] S540: The intermediate service system sends device information and a payment request to the wallet system. Correspondingly, the wallet system receives the device information and the payment request. The device information can be used for the risk control process of the payment request by the wallet system (such as the wallet server).

[0102] In some embodiments, before S530, the merchant system may also perform risk identification on the target transaction based on at least one of the internal information of the merchant system and the device information, and generate risk control recommendation information. In S530, in response to the payment operation, the merchant system may send the payment request, the device information, and the risk control recommendation information to the intermediate service system. In S540, the intermediate service system sends the payment request, the device information, and the risk control recommendation information to the wallet system. Both the device information and the risk control recommendation information can be used for the risk control process of the payment request by the wallet system.

[0103] In some embodiments, the intermediate service system may also have the ability to provide risk control services. In S530, in response to the payment operation, the merchant system sends the payment request and the device information to the intermediate service system. After receiving the payment request and the device information, the intermediate service system may perform risk identification on the target transaction based on at least one of the internal information of the intermediate service system, the payment request, and the device information to obtain risk control recommendation information. In S540, the intermediate service system may send the payment request, the device information, and the risk control recommendation information to the wallet system simultaneously; or send the risk control recommendation information, the payment request, and the device information in sequence. In this embodiment, the risk control recommendation information is provided by the intermediate service system. This realizes the joint risk control of the intermediate service system and the wallet system, and can improve the accuracy of the risk control result.

[0104] Among them, the internal information of the intermediate service system includes at least one of the following: historical transaction information corresponding to the target account, and the historical transaction information is the transaction information of historical transactions participated by the target account within a historical time period. The transaction information of the historical transactions includes but is not limited to: transaction amount, transaction items, transaction time, logistics address, etc.

[0105] Exemplarily, the intermediate service system can identify the risk of the target transaction based on multiple methods. Here are several examples, and the embodiments of this specification do not limit this.

[0106] For example, after the risk control personnel of the intermediate service system obtain the internal information, the payment request, and the device information, they obtain the risk identification result according to manual experience and input the risk identification result into the intermediate service system. The intermediate service system generates the risk control recommendation information based on the risk identification result.

[0107] For example, the intermediate service system presets a risk identification model and inputs at least one of the internal information, the payment request, and the device information into the risk identification model to obtain the risk control recommendation information.

[0108] For example, the intermediate service system presets multiple risk identification conditions (or risk identification rules) and obtains the risk control recommendation information based on at least one of the internal information, the payment request, and the device information, as well as the multiple risk identification conditions. The risk identification conditions are such as whether the recent transaction frequency of the target account exceeds a threshold.

[0109] During the process of risk identification by the intermediate service system, at least one risk that can be identified is as described above and will not be elaborated further.

[0110] It can be understood that the risk identification process can be executed on the intermediate server, and the embodiments of this specification do not limit this.

[0111] Exemplarily, the intermediate service system can also determine the risk control recommendation information based on the device information. For example, the intermediate service system can perform ATO risk identification based on the device information to obtain the risk control recommendation information. The process of the intermediate service system performing ATO risk identification is similar to the process of the wallet system performing ATO risk identification described above and will not be elaborated further.

[0112] In the above embodiments, the wallet system can determine the severity of the risk corresponding to the target transaction through the risk control recommendation information, and then can decide whether it is necessary to further identify the risk of the target transaction to achieve strict risk control and avoid the problem that high-risk target transactions cannot be accurately identified. Moreover, the wallet system can also determine which level of identity verification method to adopt for the payment of the target transaction based on the risk level represented by the risk control recommendation information, and perform identity verification on the current user in a targeted manner.

[0113] S550: The wallet system executes a risk control process on the payment request based on the device information to obtain a risk control result.

[0114] Exemplarily, the wallet system performs risk identification on the target transaction based on the device information to obtain the risk level of the target transaction. The manner in which the wallet system performs risk identification based on the device information may refer to the description above and will not be elaborated here.

[0115] In some embodiments, when the wallet system also receives risk control recommendation information provided by the merchant system or the intermediate service system, the wallet system may execute a risk control process on the payment request based on the risk control recommendation information and the device information to obtain a risk control result.

[0116] In this embodiment, during the payment risk control process, in addition to considering the risk control recommendation information, the wallet system itself also performs risk identification based on the available information. That is, the merchant system, the intermediate service system, and the wallet system perform joint prevention and control, using the information available to two or more systems as the basis for risk control, with a more comprehensive consideration dimension, which can improve the accuracy of risk control.

[0117] It can be understood that the risk identification process may be executed on the wallet server or by a risk control service provider cooperating with the wallet system. The embodiments of this specification do not limit this. The following takes the execution on the wallet server as an example for illustration.

[0118] Exemplarily, the wallet server determines the first risk level corresponding to the target transaction based on the risk control recommendation information; performs risk identification on the target transaction based on the device information to obtain the second risk level corresponding to the target transaction; and determines the risk control result based on the first risk level and the second risk level.

[0119] The wallet server may determine the second risk level in the following manner.

[0120] For example, the wallet server performs risk identification on the target transaction based on the device information to obtain the second risk level. The manner in which the wallet server performs risk identification based on the device information may refer to the description above and will not be elaborated here.

[0121] For another example, the wallet server performs risk identification on the target transaction based on the internal information of the wallet system and the device information to obtain the second risk level. The internal information of the wallet system includes at least one of the following: the user information corresponding to the payment request, and the transaction information corresponding to the target transaction.

[0122] The user information corresponding to the payment request can be understood as: information related to the payment account within the wallet system associated with the target account. The user information includes, but is not limited to, the user registration information of the payment account, historical payment information, and historical device information. The historical device information is the device information of the terminal device involved in the historical payment process of the payment account. The wallet server can obtain the internal information by looking up in the database of the wallet system based on the payment request. The way the wallet server performs risk identification based on the internal information and / or the device information is similar to that of the merchant system and the intermediate service system, which can be referred to the above description and will not be elaborated here.

[0123] The wallet server can determine the risk control result in the following way.

[0124] Exemplarily, if the first risk level is greater than the second risk level, the wallet server takes the first risk level as the risk control result; or, if the first risk level is less than the second risk level, the wallet server takes the second risk level as the risk control result; or, if the first risk level is equal to the second risk level, the wallet server takes the first risk level or the second risk level as the risk control result.

[0125] In this example, the wallet system takes the risk identification result with a high risk level as the final risk control result, making the risk control more strict and effectively protecting the payment security of users.

[0126] S560: The wallet system determines the payment result corresponding to the payment request based on the risk control result.

[0127] Exemplarily, if the risk level corresponding to the risk control result is higher than or equal to the first preset risk level, the wallet server determines that the payment result is payment failure. If the risk level corresponding to the risk control result is lower than or equal to the second preset risk level, the wallet server determines to execute the payment process to obtain the payment result.

[0128] Among them, the risk degree of the first preset risk level is higher than that of the second preset risk level. For example, the first preset risk level is high risk, and the second preset risk level is low risk.

[0129] Exemplarily, if the risk level corresponding to the risk control result is lower than the first preset risk level and higher than the second preset risk level, before determining the payment result, the payment method P500 further includes Figure 6 the identity verification steps as shown:

[0130] S5610: The wallet system sends an identity verification instruction to the intermediate service system. Correspondingly, the intermediate service system receives the identity verification instruction.

[0131] In some embodiments, the identity verification instruction includes a target identity verification method.

[0132] For example, the target identity verification method includes, but is not limited to, one or more of the following: password identity verification, verification code identity verification, face identity verification, iris identity verification, fingerprint identity verification, etc.

[0133] S5620: The intermediate service system sends an identity verification instruction to the merchant system. Correspondingly, the merchant system receives the identity verification instruction.

[0134] Exemplarily, the intermediate server sends an identity verification instruction to the merchant server, and the merchant server sends the identity verification instruction to the terminal device or the merchant client.

[0135] S5630: In response to the identity verification instruction, the merchant system displays an identity verification page on the interaction page of the merchant system and obtains the identity verification information collected through the identity verification page.

[0136] In some embodiments, the merchant system displays an identity verification page corresponding to the target identity verification method on the interaction page of the merchant system.

[0137] For example, Figure 7 or Figure 8 As shown, the merchant client in the merchant system displays an identity verification page to the current user. The identity verification page displays the target identity verification method and an identity verification information input area. The current user inputs the identity verification information corresponding to the target identity verification method in the input area. For example, if the identity verification method displayed on the identity verification page is password identity verification, the current user needs to input a password in the input area, and so on.

[0138] S5640: The merchant system sends the identity verification information to the intermediate service system. Correspondingly, the intermediate service system receives the identity verification information.

[0139] Exemplarily, after the identity verification information is input, the merchant client or the terminal device can send the identity verification information to the merchant server, and the merchant server can send the identity verification information to the intermediate server.

[0140] S5650: The intermediate service system sends the identity verification information to the wallet system so that the wallet system can perform identity verification based on the identity verification information. Correspondingly, the wallet system receives the identity verification information.

[0141] Exemplarily, the intermediate server can send the identity verification information to the wallet server, and the wallet server performs identity verification of the current user based on the identity verification information.

[0142] S5660: The wallet system determines the payment result based on the identity verification information.

[0143] Exemplarily, if the wallet server determines that the identity verification is passed, it executes the payment process to obtain the payment result. Alternatively, if the wallet server determines that the identity verification is not passed, it determines that the payment result is a payment failure.

[0144] Thus, the identity verification is completed when the risk level corresponding to the risk control result is lower than the first preset risk level and higher than the second preset risk level, and the payment result is obtained.

[0145] S570: The wallet system sends the payment result to the intermediate service system. Correspondingly, the intermediate service system receives the payment result.

[0146] S580: The intermediate service system sends the payment result to the merchant system. Correspondingly, the merchant system receives the payment result.

[0147] Exemplarily, the intermediate server sends the payment result to the merchant server, and the merchant server sends the payment result to the merchant client or the terminal device.

[0148] S590: The merchant system displays the payment result on the interaction page.

[0149] For example, Figure 7 or Figure 8 as shown, after the current user inputs the identity verification information, the merchant client jumps to the interaction page E and displays "Payment service in progress..." to the current user. As Figure 7 shown, if the identity verification is passed, the merchant client displays the interaction page D1 and shows the payment result of "Payment successful!" to the current user. As Figure 8 shown, if the identity verification is not passed, the merchant client displays the interaction page D2 and shows the payment result of "Payment cannot be made!" or "Payment failed!" to the current user.

[0150] It should be noted that the payment method P500 may also have other variations. For example, in S530, the merchant system sends the payment request and the risk control recommendation information to the intermediate service system simultaneously or sequentially, but does not send the device information. In S540, the intermediate service system sends the payment request and the risk control recommendation information to the wallet system simultaneously or sequentially, but does not send the device information. At this time, S550 can be replaced with the wallet system executing a risk control process on the payment request based on the risk control recommendation information to obtain the risk control result. For example, the wallet system directly adopts the risk control recommendation information as the final risk control result. Another example is that the wallet system determines the third risk level based on the internal information of the wallet system, determines the first risk level based on the risk control recommendation information, and then determines the risk control result based on the first risk level and the third risk level. The specific implementation of the wallet system determining the risk control result can refer to the above description and will not be elaborated here.

[0151] Figure 9 Shows an interaction diagram of the payment method P900 provided by the embodiments of this specification. As Figure 9 shown, the payment method P900 is executed in cooperation by the current user (the current user of the terminal device or the current user of the target account), the merchant system, and the wallet system. This payment method P900 includes S910 to S970.

[0152] S910: When the interaction page of the merchant system is displayed on the terminal device, the merchant system collects the device information of the terminal device.

[0153] S920: The current user initiates a payment operation for the target transaction on the interaction page of the merchant system through the target account.

[0154] S910 - S920 is similar to S510 - S520, and can be referred to the above description, so it will not be elaborated here.

[0155] S930: In response to detecting the payment operation, the merchant system sends the device information and the payment request to the wallet system. The device information can be used for the risk control process of the payment request by the wallet system.

[0156] S930 is similar to S530, the difference is that the receiving entities of the device information and the payment request are different, and other aspects can be referred to the above description, so it will not be elaborated here.

[0157] S940: The wallet system executes a risk control process on the payment request based on the device information to obtain a risk control result.

[0158] It should be noted that S940 is similar to S550, and can be referred to the above description, so it will not be elaborated here.

[0159] S950: The wallet system determines the payment result corresponding to the payment request based on the risk control result.

[0160] Exemplarily, if the risk level corresponding to the risk control result is higher than or equal to the first preset risk level, the wallet server determines that the payment result is payment failure. If the risk level corresponding to the risk control result is lower than or equal to the second preset risk level, the wallet server determines to execute the payment process to obtain the payment result.

[0161] Among them, the risk degree of the first preset risk level is higher than that of the second preset risk level. For example, the first preset risk level is high risk, and the second preset risk level is low risk.

[0162] Exemplarily, if the risk level corresponding to the risk control result is lower than the first preset risk level and higher than the second preset risk level, before determining the payment result, the payment method P900 further includes as Figure 10The identity verification steps shown are as follows:

[0163] S9510: The wallet system sends an identity verification instruction to the merchant system. Correspondingly, the merchant system receives the identity verification instruction.

[0164] S9520: In response to the identity verification instruction, the merchant system displays an identity verification page on the interaction page of the merchant system and obtains the identity verification information collected through the identity verification page.

[0165] S9530: The merchant system sends the identity verification information to the wallet system so that the wallet system can perform identity authentication based on the identity verification information. Correspondingly, the wallet system receives the identity verification information.

[0166] S9540: The wallet system determines the payment result based on the identity verification information.

[0167] S960: The wallet system sends the payment result to the merchant system. Correspondingly, the merchant system receives the payment result.

[0168] S970: The merchant system displays the payment result on the interaction page of the merchant system.

[0169] Among them, S950 - S970 is similar to S560 - S590. The difference is that the messages transmitted between the merchant system and the wallet system do not need to be forwarded by the intermediate service system. For other details, reference can be made to the above description and will not be elaborated here.

[0170] It should be noted that the payment method P900 can also have other variations. For example, in S930, the merchant system sends a payment request and risk control advice information to the wallet system, but does not send the device information. At this time, S940 can be replaced with the wallet system performing a risk control process on the payment request based on the risk control advice information to obtain a risk control result. For subsequent implementation, reference can be made to the above description and will not be elaborated here.

[0171] In summary, for the payment method, system, and storage medium provided in this specification, in a payment scenario where the terminal device does not perform cross-system jumps, the merchant system can collect the device information of the terminal device and transmit it to the wallet system, enabling the wallet system to obtain the device information of the terminal device and perform payment risk control based on the device information. This can avoid the problem that the wallet system cannot collect device information and thus cannot perform effective risk control (for example, when an illegal user uses a stolen account for payment, the wallet system cannot intercept the risky transaction in a timely manner). Moreover, the intermediate service system can also make risk control decisions based on the rich information that the merchant system can collect and provide risk control advice information to the wallet system, thereby realizing joint risk control between the intermediate service system and the wallet system and improving the accuracy and controllability of risk control. Further, the wallet system can also adopt different identity verification strategies for users of transactions with different risk levels based on the risk control results, avoiding disturbing low-risk users and enhancing the user experience.

[0172] On the other hand, this specification provides a computer-readable non-transitory storage medium storing at least one set of executable instructions for payment. When the executable instructions are executed by a processor, the executable instructions direct the processor to perform the steps of method P500 or P900 described in this specification. In some possible implementation manners, various aspects of this specification can also be implemented in the form of a program product, which includes program code. When the program product runs on the service system 300, the program code is used to cause the service system 300 to perform the steps of method P500 or P900 described in this specification. The program product for implementing the above method can use a portable compact disc read-only memory (CD-ROM) to include program code and can run on the service system 300. However, the program product of this specification is not limited to this. In this specification, the readable storage medium can be any tangible medium that contains or stores a program, and this program can be used by or in combination with an instruction execution system. The program product can use any combination of one or more readable media. The readable media can be a readable signal medium or a readable storage medium. The readable storage medium can, for example, but not be limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of the readable storage medium include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. The computer-readable storage medium can include a data signal propagated in a baseband or as part of a carrier wave, in which the readable program code is carried. Such a propagated data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The readable storage medium can also be any readable medium other than the readable storage medium, and this readable medium can send, propagate, or transmit a program used by or in combination with an instruction execution system, apparatus, or device. The program code included on the readable storage medium can be transmitted using any appropriate medium, including but not limited to wireless, wired, optical cable, RF, etc., or any suitable combination of the above. The program code for performing the operations of this specification can be written in any combination of one or more programming languages, and the programming languages include object-oriented programming languages - such as Java, C++, etc., and also include conventional procedural programming languages - such as the "C" language or similar programming languages. The program code can be executed entirely on the service system 300, partially on the service system 300, executed as an independent software package, partially on the service system 300 and partially on a remote computing device, or entirely on a remote computing device.

[0173] The term "and / or" in the embodiments of this specification describes the association relationship of associated objects and indicates that three relationships can exist. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone. The character " / " generally indicates that the associated objects before and after are in an "or" relationship.

[0174] The terms "first", "second", etc. in this specification are used to distinguish similar or like objects or entities, and do not necessarily imply a limitation on a specific order or sequence.

[0175] The "plurality" mentioned in the embodiments of this specification should be understood to mean two or more if there is no special statement.

[0176] The specific embodiments of this specification are described above. 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 a different order than in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require a specific order or a sequential order to achieve the desired result. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0177] In summary, after reading this detailed disclosure, those skilled in the art will understand that the foregoing detailed disclosure may be presented only by way of example and may not be restrictive. Although not explicitly stated here, those skilled in the art can understand that this specification is intended to encompass various reasonable changes, improvements, and modifications to the embodiments. These changes, improvements, and modifications are intended to be proposed by this specification and are within the spirit and scope of the exemplary embodiments of this specification.

[0178] In addition, certain terms in this specification have been used to describe the embodiments of this specification. For example, "one embodiment", "an embodiment", and / or "some embodiments" mean that the specific features, structures, or characteristics described in connection with that embodiment may be included in at least one embodiment of this specification. Therefore, it should be emphasized and understood that two or more references to "an embodiment" or "one embodiment" or "alternative embodiments" in various parts of this specification do not necessarily refer to the same embodiment. Additionally, the specific features, structures, or characteristics may be appropriately combined in one or more embodiments of this specification.

[0179] It should be understood that in the foregoing description of the embodiments of this specification, in order to help understand a feature and for the purpose of simplifying this specification, this specification combines various features in a single embodiment, figure or its description. However, this does not mean that the combination of these features is necessary. When reading this specification, it is entirely possible for a person skilled in the art to mark out some of the devices as separate embodiments. In other words, the embodiments in this specification can also be understood as the integration of multiple secondary embodiments. This is also true when the content of each secondary embodiment is less than all the features of a single aforementioned disclosed embodiment.

[0180] Each patent, patent application, publication of patent applications, and other materials, such as articles, books, specifications, publications, documents, articles, etc., cited herein, except to the extent that it is inconsistent or conflicting with this document or that has a limiting effect on the broadest scope of the claims, may be incorporated herein by reference and used for all purposes now or hereafter associated with this document. In addition, in the event of any inconsistency or conflict between the description, definition, and / or use of a term in any material and the description, definition, and / or use of a term in this document, the term in this document shall prevail.

[0181] Finally, it should be understood that the embodiments of the application disclosed herein are explanations of the principles of the embodiments of this specification. Other modified embodiments are also within the scope of this specification. Therefore, the embodiments disclosed in this specification are only used as examples and not as limitations. Those skilled in the art can adopt alternative configurations according to the embodiments in this specification to implement the applications in this specification. Therefore, the embodiments of this specification are not limited to the embodiments accurately described in the application.

Claims

1. A payment method, applied to an intermediary service system providing an intermediary service between a merchant system and a wallet system, the method comprising: When the terminal device displays the interactive page of the merchant system, receiving device information and a payment request from the merchant system, wherein the device information is obtained by the merchant system collecting the terminal device, and the payment request represents a request by the target account to use the wallet system in the merchant system to pay for the target transaction; Sending the payment request and the device information to the wallet system, where the device information is used for the risk control process of the wallet system for the payment request; receiving a payment result corresponding to the payment request from the wallet system; as well as sending the payment result to the merchant system so that the merchant system displays the payment result in an interactive page of the merchant system, Wherein, during the process of the intermediate service system executing the payment method, the terminal device does not jump to the interactive page of the wallet system.

2. The method according to claim 1, wherein: Before receiving the payment result, the method further includes: Send risk control suggestion information to the wallet system, where the risk control suggestion information is used in the risk control process of the wallet system for the payment request.

3. The method according to claim 2, wherein: Before sending the risk control suggestion information to the wallet system, the method further includes: Based on the internal information of the intermediate service system and at least one of the device information, the target transaction is risk identified to generate the risk control recommendation information, wherein the internal information of the intermediate service system at least includes historical transaction information corresponding to the target account.

4. The method according to claim 2, wherein: The risk control recommendation information at least represents the risk level of the target transaction.

5. The method according to claim 1, wherein: Before receiving the payment result, the method further includes: Receiving a verification instruction from the wallet system; Sending the verification instruction to the merchant system so that the merchant system can collect the verification information through the verification page; Receiving the authentication information from the merchant system; and The authentication information is sent to the wallet system so that the wallet system performs identity authentication based on the authentication information.

6. According to the method of claim 5, the authentication instruction includes a target authentication method so that the merchant system displays an authentication page corresponding to the target authentication method.

7. The method according to claim 1, wherein: The device information includes at least one of the following: Hardware parameters of the terminal device; Software parameters of the terminal device; Network parameters of the terminal device; and Behavioral characteristics of the current user of the terminal device.

8. A payment method, applied to a wallet system, comprising: When the terminal device displays an interactive page of the merchant system and the target account initiates a payment operation for the target transaction in the interactive page of the merchant system, receiving a payment request and device information from an intermediate service system, wherein the device information is collected by the merchant system from the terminal device, and the intermediate service system provides an intermediate service between the merchant system and the wallet system; Execute a risk control process on the payment request based on the device information to obtain a risk control result; Determining a payment result corresponding to the payment request based on the risk control result; as well as Sending the payment result to the intermediate service system so as to display the payment result on the interactive page of the merchant system, Wherein, during the process of the wallet system executing the payment method, the terminal device does not jump to the interactive page of the wallet system.

9. The method according to claim 8, wherein: The method further comprises: Receiving risk control suggestion information from the intermediate service system; The performing a risk control process on the payment request based on the device information to obtain a risk control result includes: A risk control process is performed on the payment request based on the risk control suggestion information and the device information to obtain the risk control result.

10. The method according to claim 9, wherein: The risk control suggestion information at least represents the risk level of the target transaction, and the risk control process is performed on the payment request based on the risk control suggestion information and the device information to obtain the risk control result, including: Determining a first risk level corresponding to the target transaction based on the risk control suggestion information; Performing risk identification on the target transaction based on the device information to obtain a second risk level corresponding to the target transaction; and The risk control result is determined based on the first risk level and the second risk level.

11. The method according to claim 10, wherein: The performing risk identification on the target transaction based on the device information to obtain a second risk level corresponding to the target transaction includes: The target transaction is subjected to risk identification based on internal information of the wallet system and the device information to obtain the second risk level, wherein the internal information of the wallet system at least includes user information corresponding to the payment request.

12. The method according to claim 10, wherein: The determining the risk control result based on the first risk level and the second risk level includes: If the first risk level is greater than the second risk level, the first risk level is used as the risk control result; If the first risk level is lower than the second risk level, the second risk level is used as the risk control result; or If the first risk level is equal to the second risk level, the first risk level or the second risk level is used as the risk control result.

13. The method according to claim 8, wherein: The determining, based on the risk control result, a payment result corresponding to the payment request, includes any one of the following: If the risk level corresponding to the risk control result is higher than or equal to the first preset risk level, the payment result is payment failure; If the risk level corresponding to the risk control result is lower than or equal to the second preset risk level, executing the payment process to obtain the payment result; or If the risk level corresponding to the risk control result is lower than the first preset risk level and higher than the second preset risk level, a verification instruction is sent to the intermediate service system, and verification information collected by the merchant system through the verification page is received from the intermediate service system, and the payment result is determined based on the verification information.

14. The method according to claim 8, wherein: The device information includes at least one of the following: Hardware parameters of the terminal device; Software parameters of the terminal device; Network parameters of the terminal device; and Behavioral characteristics of the current user of the terminal device.

15. A payment method, applied to a merchant system, comprising: When the terminal device displays the interactive page of the merchant system, collecting device information of the terminal device; In response to detecting that the target account initiates a payment operation for the target transaction in the interactive page of the merchant system, sending a payment request and the device information to the intermediate service system, wherein the device information is used for the risk control process of the wallet system for the payment request, and the intermediate service system is used to provide an intermediate service between the merchant system and the wallet system; as well as receiving a payment result corresponding to the payment request from the intermediate service system, and displaying the payment result on an interactive page of the merchant system, Wherein, during the process of the merchant system executing the payment method, the terminal device does not jump to the interactive page of the wallet system.

16. An intermediate service system for providing intermediate services between a merchant system and a wallet system, comprising: at least one storage medium storing at least one instruction set for making a payment; as well as At least one processor is communicatively connected to the at least one storage medium, wherein the at least one processor reads the at least one instruction set when running, and executes a payment method according to instructions of the at least one instruction set, wherein the payment method includes: When the terminal device displays the interactive page of the merchant system, receiving device information and a payment request from the merchant system, wherein the device information is obtained by the merchant system collecting the terminal device, and the payment request represents that the target account requests to use the wallet system to make payment in the merchant system. Sending the payment request and the device information to the wallet system, where the device information is used for the risk control process of the wallet system for the payment request, receiving a payment result corresponding to the payment request from the wallet system, and sending the payment result to the merchant system so that the merchant system displays the payment result in an interactive page of the merchant system, Wherein, during the process of the intermediate service system executing the payment method, the terminal device does not jump to the interactive page of the wallet system.

17. The intermediate service system according to claim 16, wherein: Before receiving the payment result, the at least one processor further: Send risk control suggestion information to the wallet system, where the risk control suggestion information is used in the risk control process of the wallet system for the payment request.

18. A wallet system comprising: at least one storage medium storing at least one instruction set for making a payment; as well as At least one processor is communicatively connected to the at least one storage medium, wherein the at least one processor reads the at least one instruction set when running, and executes a payment method according to instructions of the at least one instruction set, wherein the payment method includes: When the terminal device displays an interactive page of the merchant system and the target account initiates a payment operation for the target transaction in the interactive page of the merchant system, receiving a payment request and device information from the intermediate service system, wherein the device information is collected by the merchant system from the terminal device, The intermediate service system provides intermediate services between the merchant system and the wallet system. Based on the device information, a risk control process is performed on the payment request to obtain a risk control result. determining a payment result corresponding to the payment request based on the risk control result, and Sending the payment result to the intermediate service system so as to display the payment result on the interactive page of the merchant system, Wherein, during the process of the wallet system executing the payment method, the terminal device does not jump to the interactive page of the wallet system.

19. A merchant system comprising: at least one storage medium storing at least one instruction set for making a payment; as well as At least one processor is communicatively connected to the at least one storage medium, wherein the at least one processor reads the at least one instruction set when running, and executes a payment method according to instructions of the at least one instruction set, wherein the payment method includes: When the terminal device displays the interactive page of the merchant system, collecting device information of the terminal device, In response to detecting that the target account initiates a payment operation for the target transaction in the interactive page of the merchant system, sending a payment request and the device information to the intermediate service system, wherein the device information is used for the risk control process of the wallet system for the payment request, and the intermediate service system is used to provide an intermediate service between the merchant system and the wallet system, and receiving a payment result corresponding to the payment request from the intermediate service system, and displaying the payment result on an interactive page of the merchant system, Wherein, during the process of the merchant system executing the payment method, the terminal device does not jump to the interactive page of the wallet system.

20. A computer-readable non-transitory storage medium, wherein: The computer-readable non-transitory storage medium stores at least one instruction set, and when the at least one instruction set is executed by at least one processor, the method according to any one of claims 1 to 15 is implemented.

Images