Payment request response method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a payment request response method and device, electronic equipment, a storage medium and a program product. The method can be used in financial cloud field. The method comprises the following steps: in response to a payment request initiated by a target object at a first client, identifying a payment contract pre-stored by the target object at the first client; sending a plurality of contract payment systems corresponding to the payment contract to the first client, and receiving a target payment system fed back by the first client and selected by a target object based on the contract payment system; forwarding the payment request to the target payment system, and receiving a processing result fed back by the target payment system based on the payment request; and sending the processing result to the first client to respond to the payment request.

Description

Technical Field

[0001] The present application relates to the field of financial cloud, and in particular to a payment request response method, device, electronic device, storage medium and program product. Background Art

[0002] In the modern e-commerce and mobile payment environment, the efficiency and security of payment processing are crucial. With the surge in the number of online transactions, the traditional single payment method can no longer meet the diverse needs of users. Therefore, it is particularly important to integrate multiple payment systems and provide flexible payment solutions.

[0003] Users face many inconveniences when making cross-platform and cross-system payments. Traditional payment methods often require users to set up payment information separately on each platform, which not only increases the burden on users, but also reduces payment efficiency and security.

[0004] Furthermore, there is an urgent need for a technical solution that can achieve seamless integration between different payment systems and improve the convenience and security of payment. Summary of the invention

[0005] The embodiments of the present application provide a payment request response method, device, electronic device, storage medium and program product to achieve the technical effect of realizing seamless connection between different payment systems and improving the convenience and security of payment.

[0006] In a first aspect, an embodiment of the present application provides a method for responding to a payment request, comprising: responding to a payment request initiated by a target object at a first client, identifying a payment contract pre-stored by the target object at the first client; sending multiple contract payment systems corresponding to the payment contract to the first client, and receiving feedback from the first client on a target payment system selected by the target object based on the contract payment system; forwarding the payment request to the target payment system, receiving a processing result fed back by the target payment system based on the payment request; and sending the processing result to the first client to respond to the payment request.

[0007] In a second aspect, an embodiment of the present application provides a payment request response device, including:

[0008] An identification module is used to respond to a payment request initiated by a target object at a first client and identify a payment contract pre-stored by the target object at the first client; a sending module is used to send multiple contract payment systems corresponding to the payment contract to the first client and receive feedback from the first client that the target object selects a target payment system based on the contract payment system; a forwarding module is used to forward the payment request to the target payment system and receive a processing result fed back by the target payment system based on the payment request; a response module is used to send the processing result to the first client in response to the payment request.

[0009] In a third aspect, an embodiment of the present application provides a payment request response device, including: a memory, a processor;

[0010] The memory stores computer-executable instructions;

[0011] The processor executes the computer-executable instructions stored in the memory, so that the processor executes the above first aspect and / or various possible implementations of the first aspect.

[0012] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the first aspect above and / or various possible implementations of the first aspect.

[0013] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the above first aspect and / or various possible implementation methods of the first aspect.

[0014] The payment request response method, device, electronic device, storage medium and program product provided in the embodiment of the present application are as follows: when the target object (such as a user) initiates a payment request on the first client, the system first identifies the payment contract pre-stored by the user on the first client. This step ensures the personalization and automation of the payment process because the user's payment preferences and information have been pre-set and stored. Sending contract payment system options: The system sends multiple contract payment system options corresponding to the payment contract to the first client, allowing users to select their preferred payment system for transactions. Enable the target object to choose a suitable payment method according to their needs and preferences. The system receives the choice made by the target object based on the contract payment system fed back by the first client, ensuring the accuracy of the payment process and user satisfaction. Once the target payment system is determined, the system forwards the payment request to the selected target payment system for processing. This step is the key to achieving cross-system payment, which ensures that the payment request can be processed correctly, regardless of the target payment system. The system receives the processing result of the target payment system based on the payment request feedback, which may include information such as payment success, failure or additional verification required. Finally, the system sends the processing result back to the first client in response to the original payment request. This provides users with timely feedback, letting them know whether the payment is successful, achieving the technical effect of realizing seamless connection between different payment systems and improving the convenience and security of payment. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0016] Figure 1 A schematic diagram of a cross-platform transaction scenario in a related field provided for this application;

[0017] Figure 2 Schematic diagram of the payment request response method provided in this application Figure 1 ;

[0018] Figure 3 A schematic diagram of the structure of a payment request response device provided in this application;

[0019] Figure 4 A schematic diagram of the structure of a payment request response device provided in this application.

[0020] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0021] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0022] Figure 1 A schematic diagram of a cross-platform transaction scenario in a related field provided for this application, such as Figure 1 As shown, the specific application scenario of this application is that users initiate payment requests on different clients. In the prior art, users face many inconveniences when making cross-platform and cross-system payments. Traditional payment methods often require users to set payment information separately on each platform, which not only increases the burden on users, but also reduces the efficiency and security of payment.

[0023] The response method for payment request provided by the present application, when the target object (such as a user) initiates a payment request on the first client, the system first identifies the payment contract pre-stored by the user on the first client. This step ensures the personalization and automation of the payment process because the user's payment preferences and information have been pre-set and stored. Sending contract payment system options: The system sends multiple contract payment system options corresponding to the payment contract to the first client, allowing users to select their preferred payment system for transactions. Enable the target object to choose a suitable payment method according to their needs and preferences. The system receives the choice made by the target object based on the contract payment system fed back by the first client, ensuring the accuracy of the payment process and user satisfaction. Once the target payment system is determined, the system forwards the payment request to the selected target payment system for processing. This step is the key to achieving cross-system payment, which ensures that the payment request can be processed correctly, regardless of the target payment system. The system receives the processing result of the target payment system based on the payment request feedback, which may include payment success, failure, or information requiring additional verification. Finally, the system sends the processing result back to the first client in response to the original payment request. This provides users with timely feedback, letting them know whether the payment is successful, achieving the technical effect of realizing seamless connection between different payment systems and improving the convenience and security of payment.

[0024] It should be noted that the method and device for responding to payment requests of the present application can be used in the field of financial cloud, and can also be used in any field other than the field of financial cloud. The application field of the method and device for responding to payment requests of the present application is not limited.

[0025] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0026] Figure 2 Schematic diagram of the payment request response method provided in this application Figure 1 ,like Figure 2 As shown, the method includes:

[0027] S201, in response to a payment request initiated by a target object at a first client, identifying a payment contract pre-stored by the target object at the first client;

[0028] S202, sending multiple contract payment systems corresponding to the payment contract to the first client, and receiving a target payment system selected by the target object based on the contract payment system in feedback from the first client;

[0029] S203, forwarding the payment request to the target payment system, and receiving a processing result fed back by the target payment system based on the payment request;

[0030] S204: Send the processing result to the first client to respond to the payment request.

[0031] The payment request response method provided in the embodiment of the present application is that when the target object (such as a user) initiates a payment request on the first client, the system first identifies the payment contract pre-stored by the user on the first client. This step ensures the personalization and automation of the payment process because the user's payment preferences and information have been pre-set and stored. Sending contract payment system options: The system sends multiple contract payment system options corresponding to the payment contract to the first client, allowing users to select their preferred payment system for transactions. Enable the target object to choose a suitable payment method according to their needs and preferences. The system receives the choice made by the target object based on the contract payment system fed back by the first client, ensuring the accuracy of the payment process and user satisfaction. Once the target payment system is determined, the system forwards the payment request to the selected target payment system for processing. This step is the key to achieving cross-system payment, which ensures that the payment request can be processed correctly, regardless of the target payment system. The system receives the processing result of the target payment system based on the payment request feedback, which may include information on payment success, failure, or additional verification. Finally, the system sends the processing result back to the first client in response to the original payment request. This provides users with timely feedback, letting them know whether the payment is successful, achieving the technical effect of realizing seamless connection between different payment systems and improving the convenience and security of payment.

[0032] In an optional embodiment, in response to a first signing request initiated by a target object, a first system to be signed indicated by the first signing request is identified; the first signing request is forwarded to the first system to be signed, and a first signing result fed back by the first system to be signed is received; if the first signing result indicates that the signing request is successful, first signing information is sent to the first client, wherein the first signing information is used to instruct the first client to change the signing status of the first system to be signed to a contract payment system.

[0033] When the target object (such as a user) initiates a contract request at the first client, the system first identifies the system to be contracted indicated by the request. Forwarding the contract request: The system forwards the contract request to the identified system to be contracted for further processing. The system waits for and receives feedback from the system to be contracted, which indicates whether the contract request is successful. If the contract request is successful, the system sends contract information to the first client, which is used to notify the client to update its database or status to reflect the new contract payment system status.

[0034] In an optional embodiment, in response to a second signing request initiated by the target object, a second system to be signed indicated by the signing request is identified; the second signing request is forwarded to a server of the second system to be signed, and a second signing result fed back by the server of the second system to be signed is received; if the second signing result indicates that the signing request is successful, second signing information is sent to a second client corresponding to the second system to be signed, wherein the second signing information is used to instruct the second client to change the signing status of the second system to be signed to a contract payment system.

[0035] Respond to the contract signing request: When the target object (such as a user) initiates the second contract signing request on the first client, the system first identifies the second contract signing system indicated by this request. Forward the contract signing request: The system forwards the second contract signing request to the server of the second contract signing system for further processing. Receive the contract signing result: The system waits for and receives feedback from the second contract signing system, which indicates whether the second contract signing request is successful. Send contract signing information: If the second contract signing request is successful, the system will send contract signing information to the second client corresponding to the second contract signing system. This information is used to notify the second client to update its database or status to reflect the new contract payment system status. Users can manage multiple contract signing requests on a unified interface, which improves the convenience of operation. Coordinated operations between multiple different systems and clients are achieved to complete complex business processes while maintaining high efficiency.

[0036] In an optional embodiment, the first identity information of the target object pre-stored in the first client is forwarded to the first system to be signed; the second identity information corresponding to the target object carried in the first signing request is forwarded to the first system to be signed; the comparison result fed back by the first system to be signed is received, and the first signing result fed back by the first system to be signed is determined based on the comparison result, wherein the comparison information is obtained after the first system to be signed compares the first identity information and the second identity information.

[0037] That is to say, the system forwards the first identity information of the target object pre-stored in the first client to the first system to be signed. This step ensures that the system to be signed can obtain the identity data pre-stored by the user, which is convenient for subsequent verification and processing. The system also forwards the second identity information corresponding to the target object carried in the first contract request to the first system to be signed. This information is usually provided by the user to further verify the identity and improve the security and accuracy of the contract process. After receiving the two identity information, the first system to be signed compares them and generates a comparison result. The result includes the matching of the identity information and any possible differences or anomalies, providing a basis for subsequent decision-making. Based on the comparison result fed back by the first system to be signed, the system determines the contract result of the first system to be signed. If the identity information matches successfully and there is no anomaly, the contract request is approved; otherwise, the request may be rejected or require further verification. Through the verification of dual identity information, the security of the contract process is improved and the risk of fraud is reduced. The automated process speeds up the contract signing process and improves the user experience. Centralized management of contract requests and results facilitates monitoring and auditing, and improves operational efficiency.

[0038] Optionally, the first system to be signed compares the first identity information with the second identity information in the following method:

[0039] Obtaining an association indicator between the first identity information and the second identity information stored in a server of the first system to be signed;

[0040] When it is determined that the association index is greater than or equal to the set threshold, the association index is used as the association between the first identity information and the second identity information;

[0041] When it is determined that the correlation index is less than the set threshold, the following steps are performed in sequence:

[0042] Acquire an identity set, wherein the correlation index between each identity information of the identity set and the second identity information is greater than a set threshold;

[0043] The following three steps are executed in a loop until the identity set is empty or the identity set includes the first identity information:

[0044] Taking out a candidate identity information from the identity set, wherein the association index between the candidate identity information and the second identity information in the identity set is the largest;

[0045] Obtain multiple associated identity information of the identity information to be selected;

[0046] For each associated identity information of the to-be-selected identity information, the following steps are performed: updating the association index of the associated identity information and the second identity information according to the following formula: R=MAX(r, r1*r2), wherein R is the association index of the associated identity information and the second identity information after the update, r is the association index of the associated identity information and the second identity information before the update, r1 is the association index of the to-be-selected identity information and the second identity information, and r2 is the association index of the to-be-selected identity information and the associated identity information; when the updated association index of the associated identity information and the second identity information is greater than a set threshold and the associated identity information is not in the identity set, inserting the associated identity information into the identity set;

[0047] When the identity set is empty, or the identity set includes the first identity information, the association index between the first identity information and the second identity information is used as the association between the first identity information and the second identity information. When the association is greater than a preset threshold, it can be considered that the comparison result between the first identity information and the second identity information is identity consistency.

[0048] In an optional embodiment, the risk control system receiving the target payment system determines the risk control strength of the payment request based on the risk control information fed back by the payment request and the risk attribute set indicated in the risk control information; wherein the risk control system comprises: a plurality of preset risk attribute sets, wherein each preset risk attribute set comprises: a preset risk item, a preset risk attribute value, and a mapping relationship between the preset risk item and the preset risk attribute value.

[0049] In one embodiment, the method further includes obtaining multiple risk attribute sets according to the following method:

[0050] Acquire multiple cross-system payment transaction data, wherein the multiple cross-system payment transaction data include multiple payment risk data; for each cross-system payment transaction data, determine each attribute included in the cross-system payment transaction data and the corresponding attribute value; arrange and combine each attribute included in the cross-system payment transaction data and the corresponding attribute value to obtain multiple potential attribute sets corresponding to the cross-system payment transaction data, wherein each potential attribute set includes multiple attribute pairs, and each attribute pair includes an attribute and a corresponding attribute value;

[0051] For each payment risk data, the multiple potential attribute sets corresponding to the payment risk data are taken as the multiple potential risk attribute sets corresponding to the payment risk data; for each potential risk attribute set corresponding to the payment risk data, the cross-system payment transaction data in the corresponding multiple potential attribute sets containing the potential risk attribute set are taken as the cross-system payment transaction data corresponding to the potential risk attribute set; the proportion of payment risk data in the cross-system payment transaction data corresponding to the potential risk attribute set is taken as the risk probability corresponding to the potential risk attribute set; the potential risk attribute set whose corresponding risk probability is greater than the set value is taken as the risk attribute set.

[0052] In an optional embodiment, when the risk attribute set is empty, the processing method corresponding to the payment request is determined to be no processing; when the risk attribute set is not empty, multiple alternative processing methods matching the risk attribute set are screened out from a preset transaction processing library, wherein the preset transaction processing library includes: a preset risk attribute set, a preset processing method, and a mapping relationship between the preset risk attribute set and the preset processing method; the corresponding target sequence relationship between the multiple alternative processing methods is identified, and the processing method with the lowest risk control intensity among the multiple alternative processing methods is determined as the target processing method according to the target sequence relationship.

[0053] When the risk attribute set is empty, the payment request will be considered as not requiring special processing. The system will directly execute the default action to ensure the smooth progress of the transaction without additional risk assessment and intervention.

[0054] When the risk attribute set is not empty, the system will filter out multiple alternative processing methods that match the risk attribute set from the preset transaction processing library. These processing methods include the preset risk attribute set, the preset processing method and their mapping relationship.

[0055] The system will identify the corresponding target order relationship between multiple alternative processing methods. This step aims to determine the processing method that best suits the current risk situation based on the risk control strength of different processing methods to ensure the security and reliability of transactions. Based on the target order relationship, the system will select the processing method with the lowest risk control strength as the target processing method. This selection ensures that while meeting security requirements, the impact on the user's trading experience is minimized.

[0056] In an optional embodiment, multiple historical payment requests initiated by the target object and historical processing methods corresponding to the multiple historical payment requests are obtained; the number of failures of the historical payment requests corresponding to each historical processing method in the multiple historical payments is determined, and the failure ratio corresponding to each historical processing method is determined according to the number of failures; according to the failure ratio, the first-order relationship of processing the historical processing methods is determined; and the first-order relationship corresponding to the historical processing method that matches the multiple alternative processing methods is determined as the target order relationship.

[0057] Obtaining historical payment data: The system first collects multiple historical payment requests initiated by the target object and their corresponding processing methods. This data is the basis for evaluating the effectiveness of different processing methods.

[0058] Calculate the failure ratio: For each historical processing method, the system counts the number of failed historical payment requests and calculates the failure ratio accordingly. This step helps identify which processing methods have performed poorly in history.

[0059] Determine the first-order relationship: Based on the calculated failure ratio, the system determines the first-order relationship of the historical processing methods. This order relationship reflects the reliability and efficiency of the processing methods, where the processing methods with low failure ratios are ranked higher. Apply the target order relationship: The system determines the first-order relationship corresponding to the historical processing methods that match multiple alternative processing methods as the target order relationship. This ensures that when selecting the target processing method, priority is given to the processing methods that have performed well historically. By analyzing historical data to guide current decisions, the accuracy and reliability of processing method selection are improved. Giving priority to processing methods that have performed well historically helps reduce the risk of new transaction failures. As more data is accumulated, the system can continuously adjust and optimize the processing method selection logic.

[0060] In one embodiment, determining the order of processing methods according to the corresponding failure ratios includes:

[0061] For any two processing methods, when the failed payment transaction request corresponding to the first processing method in the processing method is included in the failed payment transaction request corresponding to the second processing method, and the failure probability corresponding to the first processing method is less than the set failure probability value, it is determined that the risk control strength of the first processing method is stronger than the risk control strength of the second processing method.

[0062] The method for responding to a payment request provided by the embodiment of the present application is that when the target object (such as a user) initiates a payment request on the first client, the system first identifies the payment contract pre-stored by the user on the first client. This step ensures the personalization and automation of the payment process because the user's payment preferences and information have been pre-set and stored. Sending contract payment system options: The system sends multiple contract payment system options corresponding to the payment contract to the first client, allowing users to select their preferred payment system for transactions. Enable the target object to choose a suitable payment method according to their needs and preferences. The system receives the choice made by the target object based on the contract payment system fed back by the first client, ensuring the accuracy of the payment process and user satisfaction. Once the target payment system is determined, the system forwards the payment request to the selected target payment system for processing. This step is the key to achieving cross-system payment, which ensures that the payment request can be processed correctly, regardless of the target payment system. The system receives the processing result of the target payment system based on the payment request feedback, which may include information about payment success, failure, or additional verification required. Finally, the system sends the processing result back to the first client in response to the original payment request. This provides users with timely feedback, letting them know whether the payment is successful, achieving the technical effect of realizing seamless connection between different payment systems and improving the convenience and security of payment.

[0063] Figure 3 A schematic diagram of the structure of the payment request response device provided by this application, such as Figure 3 As shown, the payment request response device 30 provided in this embodiment includes:

[0064] An identification module 301 is used to identify a payment contract pre-stored by the target object in the first client in response to a payment request initiated by the target object in the first client;

[0065] The sending module 302 is used to send multiple contract payment systems corresponding to the payment contract to the first client, and receive the target payment system selected by the target object based on the contract payment system in feedback from the first client; the forwarding module 303 is used to forward the payment request to the target payment system, and receive the processing result fed back by the target payment system based on the payment request;

[0066] The response module 304 is used to send the processing result to the first client to respond to the payment request.

[0067] In one possible implementation, the device also includes: a modification module, which is used to respond to a first signing request initiated by a target object, identify a first system to be signed indicated by the first signing request; forward the first signing request to the first system to be signed, and receive a first signing result fed back by the first system to be signed; if the first signing result indicates that the signing request is successful, send first signing information to the first client, wherein the first signing information is used to instruct the first client to change the signing status of the first system to be signed to a contract payment system.

[0068] In one possible implementation, the device also includes: a first signing module, used to respond to a second signing request initiated by the target object, identify the second system to be signed indicated by the signing request; forward the second signing request to the server of the second system to be signed, and receive a second signing result fed back by the server of the second system to be signed; if the second signing result indicates that the signing request is successful, send second signing information to the second client corresponding to the second system to be signed, wherein the second signing information is used to instruct the second client to change the signing status of the second system to be signed to a contract payment system.

[0069] In a possible implementation, the device also includes: a second signing module, used to forward the first identity information of the target object pre-stored in the first client to the first system to be signed; forward the second identity information corresponding to the target object carried in the first signing request to the first system to be signed; receive the comparison result fed back by the first system to be signed, and determine the first signing result fed back by the first system to be signed based on the comparison result, wherein the comparison information is obtained after the first system to be signed compares the first identity information and the second identity information.

[0070] In one possible implementation, the device also includes: a risk control module, which is used to receive risk control information fed back by the risk control system of the target payment system based on the payment request, and determine the risk control strength of the payment request according to the risk attribute set indicated in the risk control information; wherein the risk control system includes: multiple preset risk attribute sets, each of which includes: preset risk items, preset risk attribute values, and a mapping relationship between the preset risk items and preset risk attribute values, determine the processing method of the payment request according to the risk control strength, and forward the processing method to the target payment system.

[0071] In one possible implementation, the risk control module is also used to, when the risk attribute set is empty, determine that the processing method corresponding to the payment request is not to process; when the risk attribute set is not empty, filter out multiple alternative processing methods that match the risk attribute set from a preset transaction processing library, wherein the preset transaction processing library includes: a preset risk attribute set, a preset processing method, and a mapping relationship between the preset risk attribute set and the preset processing method; identify the corresponding target sequence relationship between the multiple alternative processing methods, and determine the processing method with the lowest risk control intensity among the multiple alternative processing methods as the target processing method according to the target sequence relationship.

[0072] In a possible implementation, the risk control module is also used to obtain multiple historical payment requests initiated by the target object and historical processing methods corresponding to the multiple historical payment requests; determine the number of failures of the historical payment requests corresponding to each historical processing method in the multiple historical payments, and determine the failure ratio corresponding to each historical processing method based on the number of failures; determine the first-order relationship of processing the historical processing methods based on the failure ratio; and determine the first-order relationship corresponding to the historical processing method that matches the multiple alternative processing methods as the target order relationship.

[0073] The payment request response device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail in this embodiment.

[0074] Figure 4 This is a schematic diagram of the structure of the payment request response device provided by this application. Figure 4 As shown, the electronic device 40 provided in this embodiment includes: at least one processor 401 and a memory 402. Optionally, the device 40 also includes a communication component 403. The processor 401, the memory 402 and the communication component 403 are connected via a bus 404.

[0075] In a specific implementation process, at least one processor 401 executes the computer-executable instructions stored in the memory 402, so that at least one processor 401 executes the above method.

[0076] The specific implementation process of the processor 401 can be found in the above method embodiment, and its implementation principle and technical effect are similar, so this embodiment will not be repeated here.

[0077] In the above embodiments, it should be understood that the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the invention may be directly implemented as being executed by a hardware processor, or may be executed by a combination of hardware and software modules in the processor.

[0078] The memory may include a high-speed memory (Random Access Memory, RAM), and may also include a non-volatile memory (Non-volatile Memory, NVM), such as at least one disk memory.

[0079] The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the bus in the drawings of the present application is not limited to only one bus or one type of bus.

[0080] The present application also provides a computer program product, including a computer program, which implements the above method when executed by a processor.

[0081] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the above method is implemented.

[0082] The above-mentioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general or special-purpose computer.

[0083] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (Application Specific Integrated Circuits, referred to as: ASIC). Of course, the processor and the readable storage medium can also exist in the device as discrete components.

[0084] The division of units is only a logical function division, and there may be other divisions in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

[0085] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0086] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0087] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0088] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

[0089] Finally, it should be noted that those skilled in the art will readily conceive of other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. The present invention is intended to cover any variations, uses or adaptations of the present invention, which follow the general principles of the present invention and include common knowledge or customary technical means in the art not disclosed by the present invention, are not limited to the precise structure described above and shown in the drawings, and may be modified and changed in various ways without departing from the scope thereof. The scope of the present invention is limited only by the appended claims.

Claims

1. A payment request response method, characterized in that: include: In response to a payment request initiated by a target object at the first client, identifying a payment contract pre-stored by the target object at the first client; Sending multiple contract payment systems corresponding to the payment contract to the first client, and receiving a target payment system selected by the target object based on the contract payment system in feedback from the first client; Forwarding the payment request to the target payment system, and receiving a processing result fed back by the target payment system based on the payment request; The processing result is sent to the first client to respond to the payment request.

2. The method according to claim 1, characterized in that Before sending the plurality of contract payment systems corresponding to the payment contract to the first client, the method further includes: In response to a first contract signing request initiated by a target object, identifying a first system to be signed with indicated by the first contract signing request; Forwarding the first contract signing request to the first system to be signed, and receiving a first contract signing result fed back by the first system to be signed; If the first signing result indicates that the signing request is successful, the first signing information is sent to the first client, wherein the first signing information is used to instruct the first client to change the signing status of the first system to be signed to a contract payment system.

3. The method according to claim 1, characterized in that Before sending the plurality of contract payment systems corresponding to the payment contract to the first client, the method further includes: In response to a second contract signing request initiated by the target object, identifying a second system to be signed with indicated by the contract signing request; forwarding the second contract signing request to the server of the second system to be signed, and receiving the second contract signing result fed back by the server of the second system to be signed; If the second signing result indicates that the signing request is successful, second signing information is sent to the second client corresponding to the second system to be signed, wherein the second signing information is used to instruct the second client to change the signing status of the second system to be signed to a contract payment system.

4. The method according to claim 2, characterized in that: Forwarding the first contract signing request to the first system to be signed, and receiving a first contract signing result fed back by the first system to be signed, the method further includes: forwarding the first identity information of the target object pre-stored in the first client to the first system to be signed; Forwarding the second identity information corresponding to the target object carried in the first contract signing request to the first system to be signed; Receive a comparison result fed back by the first system to be signed, and determine a first signing result fed back by the first system to be signed based on the comparison result, wherein the comparison result is obtained after the first system to be signed compares the first identity information and the second identity information.

5. The method according to claim 1, characterized in that Before sending the processing result to the first client to respond to the payment request, the method includes: The risk control system receiving the target payment system determines the risk control strength of the payment request based on the risk control information fed back by the payment request and the risk attribute set indicated in the risk control information; wherein the risk control system comprises: a plurality of preset risk attribute sets, wherein each preset risk attribute set comprises: a preset risk item, a preset risk attribute value, and a mapping relationship between the preset risk item and the preset risk attribute value; A processing method for the payment request is determined according to the risk control strength, and the processing method is forwarded to the target payment system.

6. The method according to claim 5, characterized in that Determining the risk control strength of the payment request according to the risk attribute set indicated in the risk control information, the method further comprising: When the risk attribute set is empty, determining that the processing method corresponding to the payment request is not processing; When the risk attribute set is not empty, a plurality of alternative processing methods matching the risk attribute set are screened out from a preset transaction processing library, wherein the preset transaction processing library includes: a preset risk attribute set, a preset processing method, and a mapping relationship between the preset risk attribute set and the preset processing method; Identify the target order relationship corresponding to the multiple alternative processing methods, and determine the processing method with the lowest risk control intensity among the multiple alternative processing methods as the target processing method according to the target order relationship.

7. The method according to claim 6, characterized in that Identifying the target order relationship between the multiple alternative processing modes includes: Obtaining multiple historical payment requests initiated by the target object and historical processing methods corresponding to the multiple historical payment requests; Determine the number of failures of historical payment requests corresponding to each historical processing method in the multiple historical payments, and determine the failure ratio corresponding to each historical processing method according to the number of failures; Determining a first order relationship of a processing history processing method according to the failure ratio; The first order relationship corresponding to the historical processing methods matching the multiple candidate processing methods is determined as the target order relationship.

8. A payment request response device, characterized in that: include: an identification module, configured to respond to a payment request initiated by a target object at the first client and identify a payment contract pre-stored by the target object at the first client; A sending module, used for sending a plurality of contract payment systems corresponding to the payment contract to the first client, and receiving a target payment system selected by a target object based on the contract payment system in feedback from the first client; A forwarding module, used for forwarding the payment request to the target payment system, and receiving a processing result fed back by the target payment system based on the payment request; The response module is used to send the processing result to the first client to respond to the payment request.

9. A payment request response device, characterized in that: include: Memory, processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the processor performs the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 7 when executed by a processor.

Images