Electronic payment processing method and device, electronic equipment, computer readable storage medium and computer program product

Abstract

The invention provides an electronic payment processing method and device, electronic equipment, a computer readable storage medium and a computer program product. The method comprises the steps that an order placing request sent by a client and initiated by a target object is received, an order corresponding to the order placing request is generated, the target object at least has a first payment mode and a second payment mode, and payment accounts associated with the first payment mode and the second payment mode are different; receiving a first payment request sent by the client for paying the order based on the first payment mode, and performing payment operation based on a first payment account corresponding to the first payment mode; and in response to payment operation failure and receiving a second payment request which is sent by the client and is used for switching to a second payment mode to pay the order, sending prompt information to the client, the prompt information being used for prompting that the order is invalid, and re-sending a new order placing request. According to the method and the device, repeated payment can be avoided under the condition that the user has multiple payment modes.

Description

TECHNICAL FIELD

[0001] The present application relates to the payment technical field, and in particular to an electronic payment processing method and device, an electronic device, a computer readable storage medium and a computer program product. BACKGROUND

[0002] With the popularization of Internet technology, more and more users choose to use electronic payment to complete transactions in the transaction process. When the user has a payment card (such as a relative card), the user can choose to use his own payment method (such as cash or a bank card) to pay, or can choose to use the relative card to pay. However, since the user involves two parties (including the donor of the relative card and the recipient of the relative card) when using the relative card to pay, switching payment using different payment methods will cause the same order to be routed to different order sets. For example, the user first uses his own payment method to pay for the order, at which time the order is routed to order set 1 of the third-party payment platform. When the payment fails due to a timeout request or network anomalies, the user switches to use the relative card to pay for the order, at which time the order is routed to order set 2 of the third-party payment platform, i.e., the same order appears in different order sets at the same time, which can cause the problem of repeated payment. SUMMARY

[0003] The embodiments of the present application provide an electronic payment processing method, device, electronic device, computer readable storage medium and computer program product, which can avoid the occurrence of repeated payment when the user has multiple payment methods, and improve the user's payment experience.

[0004] The technical solutions of the embodiments of the present application are as follows:

[0005] The embodiments of the present application provide an electronic payment processing method, which includes:

[0006] Receiving a target object initiated by a client sending an order request, generating an order corresponding to the order request, wherein the target object has at least a first payment method and a second payment method, and the payment account associated with the first payment method and the second payment method is different;

[0007] Receiving the client sending a first payment request based on the first payment method to pay for the order, and performing a payment operation based on the first payment account corresponding to the first payment method;

[0008] In response to the payment operation failure, and receiving the client sending a second payment request switching to the second payment method to pay for the order, sending a prompt message to the client, wherein the prompt message is used to prompt the order to be invalid, and a new order request is sent again.

[0009] The embodiment of the present application provides an electronic payment processing device, comprising:

[0010] The receiving module is used for receiving a placing order request initiated by a target object sent by a client, wherein the target object has at least a first payment method and a second payment method, and payment accounts associated with the first payment method and the second payment method are different;

[0011] The generating module is used for generating an order corresponding to the placing order request;

[0012] The receiving module is further used for receiving a first payment request for paying the order based on the first payment method sent by the client;

[0013] The payment module is used for performing a payment operation based on a first payment account corresponding to the first payment method;

[0014] The sending module is used for, in response to a failure of the payment operation and receiving a second payment request for paying the order by switching to the second payment method sent by the client, sending prompt information to the client, wherein the prompt information is used for prompting that the order is invalid and a new placing order request is resent.

[0015] In the above scheme, the device further comprises an obtaining module used for, after the generating module generates the order corresponding to the placing order request, obtaining a list of available payment methods of the target object based on placing order credentials of the order, wherein the list of available payment methods at least includes the first payment method and the second payment method; and the sending module is further used for sending the list of available payment methods to the client.

[0016] In the above scheme, when the first payment account corresponding to the first payment method is a payment-on-behalf account associated with the target object, the device further comprises an analyzing module used for analyzing the first payment request to obtain the payment-on-behalf account carried by the first payment request; and the payment module is further used for, in response to existing placing order results of the order and the payment-on-behalf account being consistent with a first payment account corresponding to the first payment method included in the list of available payment methods, performing a payment operation on the order based on the payment-on-behalf account.

[0017] In the scheme, when the first payment account corresponding to the first payment mode is a payment account of the target object itself, the analysis module is further configured to analyze the first payment request to obtain the payment account of the target object itself carried by the first payment request; and the payment module is further configured to, in response to the existence of the order placement result and the payment account of the target object itself being consistent with the first payment account corresponding to the first payment mode included in the available payment list, perform a payment operation on the order based on the payment account of the target object itself.

[0018] In the scheme, the device further includes a storage module configured to, after the generation module generates the order corresponding to the order placement request, combine a merchant number and a merchant order number corresponding to the order, add a first string to the combination result, and perform a hash processing on the combination result after the first string is added to obtain a corresponding hash value; serialize the order placement result of the order into a corresponding second string, and store the order in a manner that the hash value is used as a key and the second string is used as a value.

[0019] In the scheme, the first payment account is one of a payment account of the target object itself and a payment account associated with the target object, and the second payment account corresponding to the second payment mode is the other one of the payment account of the target object itself and the payment account.

[0020] In the scheme, the first payment request is sent by the client after receiving a selection operation of the target object for the first payment mode, and the first payment request carries the first payment account corresponding to the first payment mode; the device further includes a routing module configured to, before the payment module performs a payment operation based on the first payment account corresponding to the first payment mode, route the order to an order set corresponding to the first payment account according to the first payment account corresponding to the first payment mode, and the first payment account is used to perform a payment on the orders in the order set.

[0021] In the scheme, when the first payment account is the payment account of the target object itself, the routing module is further configured to route the order to a first order set corresponding to the payment account of the target object itself according to the payment account of the target object itself, and the payment account of the target object itself is used to perform a payment on the orders in the first order set.

[0022] In the scheme, when the first payment account is a payment-on-behalf account associated with the target object, the routing module is further configured to route the order to a second order set corresponding to the payment-on-behalf account according to the payment-on-behalf account, where the payment-on-behalf account is used to pay for the orders in the second order set.

[0023] In the scheme, the analysis module is further configured to analyze the second payment request to obtain a second payment account corresponding to the second payment manner carried by the second payment request; and the sending module is further configured to send prompt information to the client in response to the payment object corresponding to the second payment account being different from the payment object corresponding to the first payment account.

[0024] Embodiments of the present application provide an electronic payment processing method, comprising:

[0025] In response to receiving an order placement operation triggered by a target object in a client, sending an order placement request to a server, wherein the target object has at least a first payment manner and a second payment manner, payment accounts associated with the first payment manner and the second payment manner are different, and the order placement request is used to request the server to generate a corresponding order;

[0026] In response to receiving a selection operation of the target object for the first payment manner, sending a first payment request to the server, wherein the first payment request is used to request the server to perform a payment operation on the order based on a first payment account corresponding to the first payment manner;

[0027] In response to the payment operation failing and receiving a switching operation of the target object for the second payment manner, sending a second payment request to the server;

[0028] Outputting prompt information sent by the server in response to the second payment request, wherein the prompt information is used to prompt that the order is invalid and to resend a new order placement request.

[0029] Embodiments of the present application provide an electronic payment processing device, comprising:

[0030] The sending module is configured to send an order placement request to a server in response to receiving an order placement operation triggered by a target object in a client, wherein the target object has at least a first payment manner and a second payment manner, payment accounts associated with the first payment manner and the second payment manner are different, and the order placement request is used to request the server to generate a corresponding order;

[0031] The sending module is further configured to send, in response to receiving the selection operation of the target object for the first payment method, a first payment request to the server, where the first payment request is used to request the server to perform a payment operation on the order based on a first payment account corresponding to the first payment method.

[0032] The sending module is further configured to send, in response to receiving the selection operation of the target object for the first payment method, a first payment request to the server, where the first payment request is used to request the server to perform a payment operation on the order based on a first payment account corresponding to the first payment method.

[0033] The output module is configured to output prompt information sent by the server in response to the second payment request, where the prompt information is used to prompt that the order is invalid and a new order request is to be sent again.

[0034] In the foregoing solution, the apparatus further includes a receiving module configured to receive a list of available payment methods of the target object sent by the server before the sending module responds to the selection operation of the target object for the first payment method, where the list of available payment methods at least includes the first payment method and the second payment method.

[0035] In the foregoing solution, the apparatus further includes an obtaining module configured to obtain a first payment account corresponding to the first payment method, and the sending module is further configured to send the first payment request carrying the first payment account to the server, and the obtaining module is further configured to obtain a second payment account corresponding to the second payment method, and the sending module is further configured to send the second payment request carrying the second payment account to the server.

[0036] In the foregoing solution, the sending module is further configured to, after the output module outputs the prompt information sent by the server in response to the second payment request, send, in response to receiving a new order operation triggered by the target object in the client, a new order request to the server, so that the server generates a new order based on the new order request.

[0037] An electronic device is provided in an embodiment of the present application, and the electronic device includes:

[0038] A memory is configured to store executable instructions.

[0039] A processor is configured to execute the executable instructions stored in the memory, so as to implement the electronic payment processing method provided in the embodiments of the present application.

[0040] A computer readable storage medium is provided in an embodiment of the present application, and the computer readable storage medium stores computer executable instructions, and is configured to be executed by a processor, so as to implement the electronic payment processing method provided in the embodiments of the present application.

[0041] An embodiment of the present application provides a computer program product comprising a computer program or computer executable instructions for implementing the electronic payment processing method provided by the embodiment of the present application when executed by a processor.

[0042] The embodiment of the present application has the following beneficial effects:

[0043] In the case that the target object has multiple payment methods, and the payment accounts associated with different payment methods are different, when the target object first selects a first payment method to pay for an order, and then switches to a second payment method to pay for the order after the payment fails, the prompt information for prompting that the order has expired and needs to be re-ordered is sent, so that the same order can be routed to different order centers, and the problem of repeated payment when switching different payment methods is avoided. BRIEF DESCRIPTION OF DRAWINGS

[0044] Figure 1 FIG. 1 is a schematic diagram of an architecture of an electronic payment processing system 100 provided by an embodiment of the present application;

[0045] Figure 2A FIG. 5 is a schematic diagram of the structure of an electronic device 500 provided by an embodiment of the present application;

[0046] Figure 2B FIG. 6 is a schematic diagram of the structure of an electronic device 600 provided by an embodiment of the present application;

[0047] Figure 3 FIG. 7 is a schematic diagram of a flow of an electronic payment processing method provided by an embodiment of the present application;

[0048] Figure 4 FIG. 8 is a schematic diagram of a flow of an electronic payment processing method provided by an embodiment of the present application;

[0049] Figure 5 FIG. 9 is a schematic diagram of a flow of an electronic payment processing method provided by an embodiment of the present application;

[0050] Figure 6 FIG. 10 is a schematic diagram of a process of gifting a relative card provided by an embodiment of the present application;

[0051] Figure 7 FIG. 11 is a schematic diagram of a process of receiving a relative card provided by an embodiment of the present application;

[0052] Figure 8 FIG. 12 is a schematic diagram of a rule of order routing on the side of a third-party payment platform provided by an embodiment of the present application;

[0053] Figure 9 FIG. 13 is a schematic diagram of a flow of an electronic payment processing method provided by an embodiment of the present application. DETAILED DESCRIPTION

[0054] In order to make the purposes, technical solutions and advantages of the present application clearer, the following will further describe the present application in conjunction with the accompanying drawings, and the described embodiments should not be regarded as limitations to the present application. All other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of protection of the present application.

[0055] In the following description, "some embodiments" are referred to, which describe a subset of all possible embodiments, but it can be understood that "some embodiments" can be the same or different subsets of all possible embodiments, and can be combined with each other without conflict.

[0056] It can be understood that, in the embodiments of the present application, data related to user information and the like are involved, and when the embodiments of the present application are applied to specific products or technologies, user permission or consent needs to be obtained, and the collection, use and processing of related data need to comply with relevant laws, regulations and standards of countries and regions.

[0057] In the following description, the terms "first\second\..." are only to distinguish similar objects, and do not represent a specific order of the objects. It can be understood that "first\second\..." can be interchanged in a specific order or sequence as allowed, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0058] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present application belongs. The terms used herein are only for the purpose of describing the embodiments of the present application and are not intended to limit the present application.

[0059] Before the embodiments of the present application are further described in detail, the terms and phrases involved in the embodiments of the present application are explained, and the terms and phrases involved in the embodiments of the present application are applicable to the following explanations.

[0060] 1) In response to: a condition or state indicating that the operation performed depends on, when the dependent condition or state is met, one or more operations performed can be real-time or have a set delay; in the absence of special instructions, there is no restriction on the execution order of the multiple operations performed.

[0061] 2) Electronic payment: refers to payment transactions through the Internet, mobile devices or other electronic channels. Compared with traditional cash payment and bank transfer, electronic payment is more convenient and fast, allowing consumers to make payment transactions at any time and any place, while reducing the security risks brought by cash.

[0062] 3) Order: generally refers to a transaction voucher or instruction generated by a consumer when purchasing goods or services. Generally, an order generally contains the following information: the name of the goods or services, quantity, unit price, total price, and payment method, etc.

[0063] 4) Relative card: a kind of payment function, users can conveniently open a relative card for friends on an instant messaging client, realize "Ta consumption, I pay", focus on solving the problem that relatives and friends have no available payment methods, after receiving the relative card sent by the friend, the user can select the relative card as the payment channel when paying. Among them, the user who sends the relative card can be called the gift card (or gift) side of the relative card, for example, it can be his parents, children, etc.; the user who receives the relative card can be called the receiving (or receiving) side of the relative card, for example, after receiving the instant messaging message sent by the gift card side, the receiving side can receive the relative card given by the gift card side.

[0064] 5) Relative card limit: when the gift card side (for example, user A) of the relative card gives the receiving side (for example, user B) of the relative card, the receiving side can set the upper limit of the relative card consumption per month, and the receiving side can use the relative card within the limit of the relative card consumption limit, for example, assuming that user A gives user B a relative card with a consumption limit of 3000 yuan per month, user B can consume within the limit of 3000 yuan.

[0065] 6) Payment explicit error: refers to the error of the payment result, the flow can be terminated, for example, including payment password error, insufficient balance and other error information.

[0066] 7) Payment non-explicit error: refers to the error of the payment result, which may have been successful, at which time the order can be completed by checking or re-paying, for example, including request timeout, network exception and other error information.

[0067] The electronic payment processing method, device, electronic equipment, computer readable storage medium and computer program product provided by the embodiments of the application can avoid repeated payment in the case that the user has multiple payment methods, and improve the user's payment experience. The electronic device provided by the embodiments of the application is described below. The electronic device provided by the embodiments of the application can be implemented as a terminal device, or as a server, or can be implemented by a server and a terminal device. The electronic payment processing method provided by the embodiments of the application is taken as an example for description.

[0068] For example, referring to Figure 1 , Figure 1is a schematic diagram of an architecture of an electronic payment processing system 100 provided by an embodiment of the present application, for implementing an application of supporting avoiding repeated payment in the case that a user has multiple payment methods, thereby improving the payment experience of the user, as shown in Figure 1 The electronic payment processing system 100 includes a server 200, a network 300, and a terminal device 400, where the network 300 can be a local area network or a wide area network, or a combination of the two, and the terminal device 400 is a terminal device associated with a target object (for example, user 1), and a client 410 runs on the terminal device 400, and the client 410 can be various types of clients, for example, including instant messaging clients, e-commerce shopping clients, browsers, and the like.

[0069] In some embodiments, taking the target object as an example of user 1, where the user 1 has at least a first payment method and a second payment method, and the payment account associated with the first payment method and the second payment method is different, for example, the payment account associated with the first payment method can be the payment account of the user 1 himself, and the payment account associated with the second payment method can be the payment account of a payment agent (i.e., a payment account, for example, the payment account of user 2 who gives a family card to user 1). When the terminal device 400 receives a user 1 triggered order operation (for example, a transfer operation or a red envelope operation, etc.) in the client 410 (for example, an instant messaging client), it can send a corresponding order request to the server 200 through the network 300. After the server 200 receives the order request sent by the terminal device 400, it can respond and generate a corresponding order. Next, assuming that the client 410 receives a selection operation of the user 1 for the first payment method (for example, using a family card to pay), it sends a first payment request for paying the order based on the first payment method to the server 200 through the network 300, where the first payment request is used to request the server 200 to perform a payment operation based on the first payment account (for example, the payment account of user 2) corresponding to the first payment method. Subsequently, when the client 410 detects that the payment operation fails, and receives a switching operation of the user 1 for the second payment method (for example, assuming that the user 1 switches to use his own bank card to pay), it sends a second payment request for switching to the second payment method to pay the order to the server 200 through the network 300. After the server 200 receives the second payment request sent by the client 410, it detects that the second payment account corresponding to the second payment request is different from the first payment account, and can return prompt information to the client 410 through the network 300, prompting that the order has been invalidated and needs to send a new order request, thereby avoiding the problem of repeated payment in the case that the user has multiple payment methods, and improving the payment experience of the user.

[0070] In other embodiments, the embodiments of the present application can also be implemented by means of cloud technology. Cloud technology refers to a kind of hosting technology that unifies a series of resources such as hardware, software, network, etc. in a wide area network or a local area network to realize data calculation, storage, processing and sharing.

[0071] Cloud technology is a general term for network technology, information technology, integration technology, management platform technology and application technology applied based on cloud computing business model, can form a resource pool, and be used on demand, flexibly and conveniently. Cloud computing technology will become an important support. The background service of the technical network system needs a large amount of computing and storage resources.

[0072] In the example, Figure 1 The server 200 in the example can be a stand-alone physical server, a server cluster or a distributed system composed of multiple physical servers, or a cloud server providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and basic cloud computing services such as big data and artificial intelligence platforms. The terminal device 400 can be a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a smart watch, a vehicle-mounted terminal, etc., but is not limited thereto. The terminal device 400 and the server 200 can be connected directly or indirectly through wired or wireless communication, and the embodiments of the present application do not limit the connection mode.

[0073] In some embodiments, the terminal device or the server can also implement the electronic payment processing method provided by the embodiments of the present application by running various computer executable instructions or computer programs. For example, the computer executable instructions can be microprogram level commands, machine instructions or software instructions. The computer program can be a native program or a software module in the operating system; can be a native application program (APP), i.e. a program that needs to be installed in the operating system to run, such as an instant messaging APP; or can be a small program that can be embedded into any APP, i.e. a program that only needs to be downloaded into a browser environment to run. In summary, the above computer executable instructions can be any form of instructions, and the above computer programs can be any form of application programs, modules or plug-ins.

[0074] The structure of the electronic device provided by the embodiments of the present application will be described below. Taking the electronic device as an example, Figure 1 Taking the server 200 shown in the example as an example, referring to Figure 2A , Figure 2A is a structural schematic diagram of the server 200 provided by the embodiments of the present application, Figure 2AThe illustrated server 200 includes at least one processor 210, memory 240, and at least one network interface 220. The various components of server 200 are coupled together by a bus system 230, which is used for the communication of information among the components and to control the overall operation of the server 200. The bus system 230 can be implemented using any one or more of a variety of bus structures, including a memory bus or memory controller, a peripheral bus, a video bus, an IDE bus, a Firewire bus, etc. In this regard, the bus system 230 can be implemented using any one or more of a variety of bus architectures, including a Memory Bus with a Memory Controller, a Peripheral Component Interconnect (PCI) bus, a Universal Serial Bus (USB), IEEE 1394 bus, etc. Figure 2A The various buses are shown collectively in Figure 2 as bus system 230 for the sake of clarity.

[0075] The processor 210 can be an integrated circuit chip, with the processing capability to execute instructions. For example, the processor can be a general purpose processor, a Digital Signal Processor (DSP), or other programmable logic device, discrete gate or transistor logic, discrete hardware components, etc. The general purpose processor can be a microprocessor, or any conventional processor, etc.

[0076] The memory 240 can be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard drives, optical drives, etc. The memory 240 optionally includes one or more storage devices remotely located from the processor 210.

[0077] The memory 240 includes volatile memory or nonvolatile memory, or both. Nonvolatile memory can be read only memory (ROM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, etc. Volatile memory can be random access memory (RAM), static RAM, dynamic RAM, etc.

[0078] In some embodiments, the memory 240 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or superset thereof, which are described in the example below.

[0079] The operating system 241 includes a system program for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks.

[0080] The network communication module 242 is used to communicate with other computing devices via one or more (wired or wireless) network interfaces 220, examples of which include Bluetooth, Wireless Fidelity (WiFi), and Universal Serial Bus (USB), etc.

[0081] In some embodiments, the apparatus provided by the embodiments of the present application can be implemented in software, Figure 2A The electronic payment processing apparatus 243 stored in the memory 240 is shown, which can be software in the form of programs and plug-ins, etc., including the following software modules: a receiving module 2431, a generating module 2432, a payment module 2433, a sending module 2434, an obtaining module 2435, an analyzing module 2436, a storage module 2437, and a routing module 2438. These modules are logical, and thus can be combined or further split according to the implemented functions. It should be noted that, in order to facilitate expression, all the above modules are shown at one time, but should not be regarded as excluding the implementation that the electronic payment processing apparatus 243 can only include the receiving module 2431, the generating module 2432, the payment module 2433, and the sending module 2434. The functions of the modules will be described below. Figure 2A The functions of the modules will be described below.

[0082] The structure of the terminal device 400 shown in the Figure 1 The structure of the terminal device 400 shown in the Figure 2B , Figure 2B The structure of the terminal device 400 shown in the Figure 2B The terminal device 400 includes a memory 460 for storing executable instructions, and a processor 420 for processing the executable instructions stored in the memory 460 to implement the electronic payment processing method provided by the embodiments of the present application. In addition, the electronic payment processing apparatus 465 stored in the memory 460 can be software in the form of programs and plug-ins, etc., including the following software modules: a sending module 4651, an output module 4652, a receiving module 4653, and an obtaining module 4654. These modules are logical, and thus can be combined or further split according to the implemented functions. It should be noted that, in order to facilitate expression, all the above modules are shown at one time, but should not be regarded as excluding the implementation that the electronic payment processing apparatus 465 can only include the sending module 4651, the output module 4652, the receiving module 4653, and the obtaining module 4654. Figure 2BFor the convenience of expression, all the above modules are shown at one time, but should not be considered as excluding the implementation that only includes the sending module 4651 and the output module 4652 in the electronic payment processing apparatus 465. The functions of the respective modules will be described below. In addition, the terminal device 400 further includes at least one network interface 430, a user interface 440 (including an output apparatus 441 and an input apparatus 442), and a bus system 450, and the memory 460 can further store an operating system 461, a network communication module 462, a presentation module 463 (for enabling presentation of information via one or more output apparatuses 441 (for example, including a display screen, a loudspeaker, etc.) associated with the user interface 440, for example, a user interface for operating peripheral devices and displaying content and information), and an input processing module 464 (for detecting and interpreting one or more user inputs or interactions from one or more input apparatuses 442), and the roles of the above components are similar to those of the corresponding components of the server 470, which are described above and will not be repeated here. Figure 2A The roles of the corresponding components are similar, and the descriptions of the above Figure 2A will be referred to here. The embodiments of the present application will not be described again.

[0083] The electronic payment processing method provided by the embodiments of the present application will be described in detail below from the perspective of interaction between the terminal device and the server.

[0084] Referring to Figure 3 , Figure 3 is a flowchart of the electronic payment processing method provided by the embodiments of the present application, which will be described in combination with the steps shown in Figure 3 .

[0085] It should be noted that Figure 3 the steps performed by the terminal device can be executed by various forms of computer programs running on the terminal device, and are not limited to the client, for example, can also be the operating system, software modules, scripts, and applets described above, and therefore the following examples of the client should not be considered as limiting the embodiments of the present application. In addition, for the convenience of description, the terminal device and the client running on the terminal device will not be specifically distinguished in the following.

[0086] In step 101, the terminal device sends a placing order request to the server in response to receiving a placing order operation triggered by a target object in the client.

[0087] Here, the target object can have at least a first payment method and a second payment method, wherein the payment account associated with the first payment method and the second payment method is different, for example, the first payment account corresponding to the first payment method can be one of the payment account of the target object (for example, user 1) itself and the payment account associated with the target object, and the second payment account corresponding to the second payment method can be the other one of the payment account of the target object itself and the payment account.

[0088] In some embodiments, taking the target object as user 1 for example, the terminal device can send a corresponding order request to the server when receiving an order operation (such as a transfer operation or a red envelope operation, etc.) triggered by user 1 in the client (such as an instant messaging client), where the order request can carry the identifier of user 1, such as the instant messaging account used by user 1 when logging in to the instant messaging client.

[0089] In step 102, the server generates a corresponding order in response to the order request.

[0090] In some embodiments, after receiving the order request sent by the terminal device through the network, the server can respond and generate a corresponding order, where the order can include the name of the merchant, the total price, the order time and the like.

[0091] In some embodiments, referring to Figure 4 , Figure 4 is a flowchart of an electronic payment processing method provided by the embodiments of the present application, as Figure 4 shown, after performing step 102 shown in Figure 3 , the server can further perform step 107 and step 108 shown in Figure 4 , which will be described in combination with the steps shown in Figure 4 .

[0092] In step 107, the server obtains a list of available payment methods of the target object based on the order credentials of the order.

[0093] Here, the list of available payment methods of the target object at least includes the first payment method and the second payment method described above.

[0094] In some embodiments, taking the target object as user 1 for example, after the server generates a corresponding order in response to the order request sent by the terminal device, the server can further obtain a list of available payment methods of user 1 based on the order credentials of the order, for example, assuming that the list of available payment methods of user 1 includes the first payment method and the second payment method described above, where the first payment method can be to select a relative card for payment, and the second payment method can be to select a bank card of user 1 for payment.

[0095] In step 108, the server sends the list of available payment methods to the terminal device.

[0096] In some embodiments, after obtaining the list of available payment methods of the target object (e.g., user 1) based on the order-based order placing credential, the server can further send the obtained list of available payment methods of the target object to the terminal device through the network for display in the terminal device. For example, after receiving the list of available payment methods of the target object sent by the server, the terminal device can call the human-computer interaction interface of the client to display the list of available payment methods of the target object for selection by the target object.

[0097] In some other embodiments, referring to Figure 5 , Figure 5 is a flowchart of an electronic payment processing method provided by an embodiment of the present application, as shown in Figure 5 , after performing step 102 shown in Figure 3 , the server can further perform step 109 and step 110 shown in Figure 5 , which will be described in combination with the steps shown in Figure 5 .

[0098] In step 109, the server combines the merchant number and the merchant order number corresponding to the order, adds a first string in the combination result, and performs hash processing on the combination result after adding the first string to obtain a corresponding hash value.

[0099] In some embodiments, after generating the corresponding order in response to the order placing request sent by the terminal device, the server can further combine the merchant number and the merchant order number corresponding to the order, add a first string (i.e., perform salt processing) in the combination result, and then perform hash processing on the combination result after adding the first string, for example, using a hash algorithm (also known as a hash algorithm) to perform hash processing on the combination result after adding the first string to obtain a corresponding hash value, wherein the hash algorithm (SHA, Secure Hash Algorithm) is an algorithm that can map data of any length to data of a fixed length. The mapping process is one-way, i.e., it is easy to go from the original data (i.e., input) to the mapping result (i.e., output), but it is very difficult to go from the output to the input. Common hash algorithms include SHA-1, SHA-256, and Message-Digest Algorithm 5 (e.g., MD5).

[0100] In step 110, the order placing result of the order is serialized into a corresponding second string, and the order is stored with the hash value as the key and the second string as the value.

[0101] In some embodiments, after generating the corresponding order in response to the order placement request sent by the terminal device, the server can also serialize the order placement result of the order into a corresponding second string, and then store the order in a manner that the hash value obtained in step 109 is used as the key and the second string is used as the value. Serialization refers to the process of converting a data structure or object into a specific format, so that the data can be saved to a file, database, or transmitted over a network. The purpose of serialization is to convert data in memory into a persistent format so that it can be reloaded into memory when needed, and data exchange between different systems is possible. In this way, storing the order in the form of key-value pairs can improve the efficiency of subsequent order searching.

[0102] In step 103, the terminal device sends a first payment request to the server in response to receiving the selection operation of the target object for the first payment method.

[0103] In some embodiments, when the terminal device receives the selection operation of the target object for the first payment method, it can obtain the first payment account corresponding to the first payment method and send a first payment request carrying the first payment account to the server.

[0104] For example, taking user 1 as the target object, the terminal device can display a list of available payment methods for user 1 on the human-computer interaction interface. When receiving the selection operation of user 1 for the first payment method in the list of available payment methods, for example, receiving the selection of a relative card for payment, the terminal device can obtain the first payment account corresponding to the first payment method, for example, the payment account of the card giver (e.g., user 2) of the relative card, and send a first payment request carrying the first payment account to the server. The first payment request can be used to request the server to perform a payment operation based on the first payment account corresponding to the first payment method.

[0105] In step 104, the server performs a payment operation based on the first payment account corresponding to the first payment method in response to the first payment request.

[0106] In some embodiments, when the server receives the first payment request sent by the terminal device to pay for the order based on the first payment method, it can perform a payment operation based on the first payment account corresponding to the first payment method.

[0107] For example, after receiving the first payment request sent by the terminal device, the server can parse the first payment request to obtain the first payment account carried by the first payment request. Then, the server can perform a payment operation on the order based on the first payment account, for example, perform a corresponding deduction operation on the first payment account based on the amount to be paid carried by the order to complete the payment of the order.

[0108] In some embodiments, the first payment request can be sent by the client when receiving a selection operation of the target object for the first payment method, where the first payment request can carry a first payment account corresponding to the first payment method. Before performing a payment operation on the order based on the first payment account corresponding to the first payment method, the server can further perform the following processing: routing the order to an order set corresponding to the first payment account according to the first payment account corresponding to the first payment method, where the first payment account is used to pay for the orders in the order set.

[0109] For example, when the first payment account is a payment account of the target object itself, the server can implement the above-mentioned routing of the order to the order set corresponding to the first payment account according to the first payment method by the following way: routing the order to a first order set (e.g., order set 1) corresponding to the payment account of the target object itself according to the payment account of the target object itself, where the payment account of the target object itself is used to pay for the orders in the first order set. For example, taking the target object as user 1 for example, when user 1 selects to use his own payment method to pay, the order can be routed to the order set 1 of the background server of the third-party payment platform, where the orders in the order set 1 correspond to user 1.

[0110] For example, when the first payment account is a payment account of the target object itself, the server can implement the above-mentioned routing of the order to the order set corresponding to the first payment account according to the first payment method by the following way: routing the order to a first order set (e.g., order set 1) corresponding to the payment account of the target object itself according to the payment account of the target object itself, where the payment account of the target object itself is used to pay for the orders in the first order set. For example, taking the target object as user 1 for example, when user 1 selects to use his own payment method to pay, the order can be routed to the order set 1 of the background server of the third-party payment platform, where the orders in the order set 1 correspond to user 1.

[0111] In some embodiments, when the first payment account corresponding to the first payment method is a payment account associated with the target object, for example, the target object selects to use a relative card to pay, the server can implement the above-mentioned payment operation based on the first payment account corresponding to the first payment method by the following way: analyzing the first payment request to obtain the payment account carried by the first payment request; in response to the existence of the order placement result (i.e., indicating that the order placement has been successful) and the consistency of the payment account and the first payment account corresponding to the first payment method included in the list of available payment methods, performing a payment operation on the order based on the payment account.

[0112] For example, taking the target object as user 1, when user 1 selects to use the relative card to make payment, the terminal device can send a payment request carrying the payment account of the gift card party (for example, user 2) of the relative card to the server. After receiving the payment request sent by the terminal device, the server can parse the payment request to extract the payment account of user 2 carried by the payment request, and compare it with the payment account of the gift card party of the relative card in the list of available payment methods of user 1 obtained based on the order placing credential. When the two are consistent, the server can perform a payment operation on the order based on the payment account of user 2.

[0113] It should be noted that when the server detects that the payment account of user 2 carried by the payment request is inconsistent with the payment account of the gift card party of the relative card in the list of available payment methods of user 1 obtained based on the order placing credential, the terminal device can return prompt information for prompting errors, that is, the server can report errors.

[0114] In other embodiments, when the first payment account corresponding to the first payment method is the payment account of the target object itself, for example, the target object selects to use his own bank card to make payment, the server can implement the above-mentioned payment operation based on the first payment account corresponding to the first payment method in the following way: parsing the first payment request to obtain the payment account of the target object itself carried by the first payment request; in response to the existence of the order placing result, and the payment account of the target object itself being consistent with the first payment account corresponding to the first payment method included in the list of available payments, performing a payment operation on the order based on the payment account of the target object itself.

[0115] For example, taking the target object as user 1, when user 1 selects to use his own bank card or cash to make payment, the terminal device can send a payment request carrying the payment account of user 1 itself to the server. After receiving the payment request sent by the terminal device, the server can parse the payment request to obtain the payment account of user 1 itself carried by the payment request. Then the server can compare the parsed payment account of user 1 itself with the payment account of user 1 itself in the list of available payment methods of user 1 obtained based on the order placing credential. When the two are consistent, the server can perform a payment operation on the order based on the payment account of user 1 itself. When the two are inconsistent, the server can report errors, for example, it can return prompt information for prompting errors to the terminal device.

[0116] In step 105, the terminal device sends a second payment request to the server in response to the failure of the payment operation and receiving the switching operation of the target object for the second payment method.

[0117] In some embodiments, when the terminal device receives the notification message returned by the server that the payment by the first payment method fails, and receives the switching operation of the target object for the second payment method, the terminal device can obtain the second payment account corresponding to the second payment method, and send a second payment request carrying the second payment account to the server.

[0118] For example, when the user 1 switches to select the second payment method to pay for the order because the first payment method fails due to a request timeout or network exception, the terminal device can obtain the second payment account corresponding to the second payment method, and send a second payment request carrying the second payment account to the server. For example, when the user 1 selects to use a relative card (i.e., the first payment method) to pay for the order, but switches to select his own bank card (i.e., the second payment method) to pay for the order because the payment fails due to a request timeout or network exception, the terminal device can obtain the payment account of the user 2, and send a payment request carrying the payment account of the user 2 to the server.

[0119] In step 106, the server sends prompt information to the terminal device in response to the second payment request.

[0120] Here, the prompt information can be used to prompt the target object that the order has expired and needs to send a new order request.

[0121] In some embodiments, the server can implement step 106 in the following manner: parsing the second payment request to obtain the second payment account corresponding to the second payment method carried by the second payment request; in response to the payment object corresponding to the second payment account being different from the payment object corresponding to the first payment account, sending prompt information to the client.

[0122] For example, when the server receives the second payment request sent by the terminal device to switch to the second payment method to pay for the order, the server can first parse the second payment request sent by the terminal device to obtain the second payment account corresponding to the second payment method (e.g., the payment account of the user 1), and then the server can further determine whether the payment object corresponding to the second payment account is the same as the payment object corresponding to the first payment account. If the payment object corresponding to the second payment account is the user 1, and the payment object corresponding to the first payment account (e.g., the payment account of the gift card of the relative card) is the user 2, i.e., the payment objects corresponding to the two are different, the server can send prompt information to the terminal device to prompt that the order has expired and needs to be ordered again. In this way, the same order can be routed to different order sets, and the problem of repeated payment can be avoided.

[0123] In some embodiments, after the terminal device outputs the prompt information sent by the server in response to the second payment request, the terminal device can further perform the following processing: in response to receiving a new order operation triggered by the target object in the client, the terminal device sends a new order request to the server, so that the server generates a new order based on the new order request.

[0124] In some embodiments, after the terminal device outputs the prompt information sent by the server in response to the second payment request, the terminal device can further perform the following processing: in response to receiving a new order operation triggered by the target object in the client, the terminal device sends a new order request to the server, so that the server generates a new order based on the new order request.

[0125] For example, taking the target object as user 1, after user 1 obtains the prompt information output by the terminal device, user 1 can place a new order, for example, the terminal device receives a new order operation triggered by user 1 in the client (for example, an instant messaging client), and sends a new order request to the server through the network. The server responds to the new order request sent by the terminal device and generates a new order, and then user 1 can select to pay for the new order using the second payment method.

[0126] The electronic payment processing method provided by the embodiments of the present application can avoid routing the same order to different order sets when the target object selects the first payment method to pay for the order and then switches to the second payment method to pay for the order after the payment fails, thereby avoiding the problem of repeated payment when switching between different payment methods.

[0127] In the following, an exemplary application of the embodiments of the present application in an actual application scenario will be described.

[0128] For the payment scenario in which the user has a relative card, using the relative card for payment involves two parties, namely the card donor (for example, user 2) and the card recipient (for example, user 1). For the same order, different users will place the order in different order sets when performing the payment operation, that is, using different payment methods to switch payment will cause the same order to be routed to different order sets, and if stable routing cannot be ensured, the problem of repeated payment will occur.

[0129] In view of this, the electronic payment processing method provided in the embodiments of the present application can ensure that the receiver of the relative card can use his own payment method to make payment or use the relative card to make payment without repeated payment in the payment scenario in which the user has a relative card through the payment order mapping technology. In this way, the user can reuse the order placement result when encountering an explicit payment failure error and retry operation, repeated order placement can be avoided, repeated payment can be intercepted, and thus the safety of the user's funds is ensured and the payment experience of the user is improved.

[0130] First, the process of gifting a relative card is described below.

[0131] For example, referring to Figure 6 , Figure 6 is a process diagram of gifting a relative card provided in the embodiments of the present application, as shown in Figure 6 , the user can gift a relative card to a friend or relative in the instant messaging client, that is, in the "me" -> "service" -> "wallet" -> "relative card" of the instant messaging client. The user can select a gift object, for example, a friend in the address book, set a monthly consumption upper limit, verify the payment password of the user, and set a preferred payment method after the payment password verification is successful. When the user's friend or relative receives the relative card and uses the relative card to make payment, the payment is preferentially deducted from the payment method set by the gift giver.

[0132] Next, the process of receiving a relative card is described below.

[0133] For example, referring to Figure 7 , Figure 7 is a process diagram of receiving a relative card provided in the embodiments of the present application, as shown in Figure 7 , after the user receives the relative card gifted by a friend or relative, the user can use the relative card to make payment when sending a red packet to another user. When making payment, the payment is preferentially deducted from the payment method set by the gift giver, for example, the payment is preferentially deducted from the spare change. That is, the technical solution provided in the embodiments of the present application can be applied to a business scenario in which the user uses a relative card to make social payment, for example, the user can use the relative card to make face-to-face payment or send a red packet.

[0134] Next, the electronic payment processing method provided in the embodiments of the present application is described below.

[0135] In order to enable the user with a relative card to make payment successfully using his own payment method or the relative card, the technical solution provided in the embodiments of the present application needs to meet the following conditions:

[0136] The rule of order routing on the third-party payment platform side is defined:

[0137] For example, referring to Figure 8 ,Figure 8 is a rule diagram of order routing of a third-party payment platform provided by an embodiment of the present application, as shown in Figure 8 When the receiver of the relative card uses his own payment method (such as cash or bank card, etc.) to make payment, the third-party payment platform considers that the receiver of the relative card is the current user, and then uses the account of the receiver (i.e. the user himself) to route the order set, i.e. routes to the third-party payment platform according to the account of the receiver (i.e. the user himself). When the receiver of the relative card uses the received relative card to make payment, the third-party payment platform considers that the card issuer is the current user, and then uses the account of the card issuer to route the order set, i.e. routes to the third-party payment platform according to the account of the card issuer. In addition, for the same order, once the order set is determined, the order set cannot be changed in the future, and only the same user's payment method can be reused. For example, if the user selects his own payment method, the order can only continue to use the user's own payment method in the future. If the user selects to use the relative card A to make payment, the order can only continue to use the relative card A in the future, and cannot use other relative cards or the user's own payment method to make payment.

[0138] The technical implementation of the relative card payment order mapping will be further described below.

[0139] In some embodiments, the merchant number and the merchant order number corresponding to the order can be combined, and a random salt value (such as a string) can be added to the combined result. Then, the combined result after adding the salt value can be subjected to hash processing (or hash processing), and the obtained hash value can be used as a session key (Session Key). The result after serializing the result information (assuming it is TenpayPrepayResult) of requesting the third-party payment platform to place an order can be saved as a value (Value) to save the order mapping. In addition, a set order (SetTradeMapping) and get order (GetTradeMapping) method can be provided, and finally the order mapping can be stored by a non-relational (NoSQL) social payment storage server. The corresponding exemplary code is as follows:

[0140] Message TenpayPrepayResult{

[0141] optional string retcode=1;

[0142] optional string trade_token=2; / / third-party payment platform interface returns trade_token

[0143] optional string transaction id=3; / / order number generated by third-party payment platform

[0144] optional unit64 pay_uin=4; / / actual account number, which affects the routing of the order set of the third-party payment platform of trade_token\transaction_id

[0145] optional unit32 place_order_time=5; / / order time

[0146] optional string payer_remark=6; / / user's remark for pay_uni

[0147] optional string prepay_id=7; / / this field is based on trade_token, and adds a business prefix

[0148] optional string req_key=8; / / req_key in terminal device request parameter, usually with a business prefix similar to sns_f2f.

[0149] The electronic payment processing method provided by the embodiments of the present application will be described below. Figure 9

[0150] For example, taking sending a red envelope as an example, refer to Figure 9 , Figure 9 is a flowchart of the electronic payment processing method provided by the embodiments of the present application, which will be described in combination with the steps shown in Figure 9 .

[0151] In step 201, the instant messaging client receives a user-triggered red envelope sending operation.

[0152] In some embodiments, the user can send a red envelope to other users in the instant messaging client.

[0153] In step 202, the instant messaging client sends a red envelope sending request to the social application server.

[0154] In step 203, the social application server sends an order request to the social payment gateway server.

[0155] In step 204, the social payment gateway server queries the user's relative card information from the relative card server, and when the user does not have a relative card, steps 205 and 206 are executed; when the user has a relative card, steps 207 and 208 are executed.​

[0156] In step 205, the social payment gateway server sends an order request to the background server of the third-party payment platform.

[0157] In step 206, the social payment gateway server saves the order result in the social payment storage server with the first order credential generated by the background server of the third-party payment platform as the key.

[0158] In some embodiments, after receiving the order request sent by the social payment gateway server, the background server of the third-party payment platform can generate a corresponding first order credential (supposed to be denoted as cft_prepay_id), and return the generated first order credential to the social payment gateway server, so that the social payment gateway server stores the order result in the social payment storage server with the first order credential as the key, wherein the order result carries a no-intimate payment mark (i.e. allow_qmf = false), to represent that the user has no intimate card.

[0159] In step 207, the social payment gateway server generates a second order credential on the instant messaging client side.

[0160] In step 208, the social payment gateway server saves the order result in the social payment storage server with the second order credential as the key.

[0161] In some embodiments, the second order credential can be denoted as wxpay_prepay_id, and the social payment gateway server can store the order result in the social payment storage server with the second order credential as the key, wherein the order result carries an intimate payment mark (i.e. allow_qmf = true), to represent that the user has an intimate card.

[0162] In step 209, the social payment gateway server returns the second order credential to the social application server.

[0163] In step 210, the social application server returns the second order credential to the instant messaging client.

[0164] In step 211, the instant messaging client sends the second order credential to the social payment server to obtain a list of available payment methods of the user.

[0165] In step 212, the social payment server queries the intimate card list of the user from the intimate card server.

[0166] In step 213, the social payment server obtains the list of available payment methods of the user from the background server of the third-party payment platform.

[0167] In step 214, the social payment server returns the list of available payment methods of the user to the IM client.

[0168] In step 215, it is determined whether the user selects the family card for payment. If yes, steps 216-227 are performed. If no, steps 228-238 are performed.

[0169] In step 216, the IM client receives the payment password input by the user.

[0170] In some embodiments, the user can select to use the family card for payment in the IM client and input the payment password.

[0171] In step 217, the IM client sends a payment request to the social payment server.

[0172] Here, the payment request can carry the binding card serial number of the family card.

[0173] In step 218, the social payment server queries the account information of the card giver of the current family card in the family card server.

[0174] Here, the social payment server can take the account queried in the family card server as the account for ordering (supposed to be payer_uin).

[0175] In step 219, the social payment server queries the payment ordering information on the IM client side from the social payment storage server.

[0176] In step 220, it is determined whether there is ordering result information. If yes, steps 221-223 are performed. If no, steps 224-227 are performed.

[0177] In step 221, it is determined whether the payer_uin for ordering and the queried account of the card giver are consistent. If no, step 222 is performed. If yes, step 223 is performed.

[0178] In step 222, the social payment server returns error information to the IM client.

[0179] In step 223, the social payment server sends a first ordering credential to the background server of the third-party payment platform to perform payment based on the payment password.

[0180] In some embodiments, when the payer_uin for ordering and the queried account of the card giver are consistent, the social payment server can pass the first ordering credential to the background server of the third-party payment platform to request the background server of the third-party payment platform to perform payment operation based on the payment password input by the user.

[0181] In step 224, the social payment server sends an order placement request to the background server of the third-party payment platform.

[0182] Here, the order placement request can carry the account information (i.e. the uin of the gift card giver) of the gift card giver, so that the background server of the third-party payment platform routes the order based on the uin of the gift card giver.

[0183] In step 225, the background server of the third-party payment platform returns the first order placement credential to the social payment server.

[0184] In step 226, the social payment server saves the payment account in the order placement result as the account of the gift card giver in the social payment storage server.

[0185] In some embodiments, the social payment server can save the payer_uin in the TenPrepayResult information as the uin of the gift card giver in the social payment storage server.

[0186] In step 227, the social payment server sends the first order placement credential to the background server of the third-party payment platform to perform payment based on the payment password.

[0187] Here, the social payment server can pass the first order placement credential to the background server of the third-party payment platform to request the background server of the third-party payment platform to perform payment operation based on the payment password input by the user.

[0188] In step 228, the instant messaging client receives the selection operation of the user for other payment methods.

[0189] Here, the user can also select to use his own payment method (such as cash or bank card) to pay in the instant messaging client.

[0190] In step 229, the instant messaging client sends a payment request to the social payment server.

[0191] In step 230, it is verified whether the user has no relative card, if yes, step 231 is executed; if not, steps 232 to 239 are executed.

[0192] In step 231, the social payment server requests the background server of the third-party payment platform to perform payment operation.

[0193] Here, when the social payment server determines that the user has no relative card (i.e. allow_qmf = fasle), it no longer requests the background server of the third-party payment platform to place an order, but directly performs payment, because the order has been placed before.

[0194] In step 232, it is judged whether there is an order result, if yes, steps 233-235 are executed, if no, steps 236-239 are executed.

[0195] In step 233, it is judged whether the account number of the order and the account number of the relative card receiver are consistent, if no, step 234 is executed, if yes, step 235 is executed.

[0196] In step 234, the social payment server returns error information to the instant messaging client.

[0197] In step 235, the social payment server requests the background server of the third-party payment platform to perform a payment operation.

[0198] Here, it can be firstly judged whether the payer_uin of the order and the account number of the relative card receiver are consistent, if not, error is returned, if yes, the order is not continued and the payment is directly performed.

[0199] In step 236, the social payment server sends an order request to the background server of the third-party payment platform.

[0200] Here, the order request can carry the account information (i.e. the uin of the receiver) of the receiver of the relative card, so that the background server of the third-party payment platform routes the order based on the uin of the receiver.

[0201] In step 237, the background server of the third-party payment platform returns the first order credential to the social payment server.

[0202] In step 238, the social payment server saves the payment account number in the order result as the account number of the receiver in the social payment storage server.

[0203] In step 239, the social payment server sends the first order credential to the background server of the third-party payment platform to perform a payment based on a payment password.

[0204] Here, the social payment server can save the payer_uin in the TenPrepayResult information as the uin of the receiver in the social payment storage server, and then can pass the cft_prepay_id to the background server of the third-party payment platform, so that the background server of the third-party payment platform performs a payment operation based on the payment password input by the user.

[0205] In summary, the electronic payment processing method provided by the embodiments of the present application has the following beneficial effects:

[0206] In the payment scenario where the user has a relative card, by implementing the payment routing stability control technology, that is, specifying the order routing rules on the third-party payment platform side, the technical implementation of relative card payment order mapping, and the verification and transmission of routing information when the user initiates payment, the stability of the routing when the user selects relative card payment or other payment methods is ensured. In this way, when the user encounters an explicit payment failure error, the reuse of the order placement result when retrying operation is avoided, repeated order placement and repeated payment are intercepted, the safety of the user's funds is ensured, the risk of fund loss is avoided, and the user's payment experience is improved.

[0207] The following continues to illustrate an exemplary structure of the electronic payment processing apparatus 243 provided by the embodiments of the present application, which is implemented as a software module. In some embodiments, as shown in Figure 2A The software module stored in the electronic payment processing apparatus 243 of the memory 240 can include a receiving module 2431, a generating module 2432, a payment module 2433, and a sending module 2434.

[0208] The receiving module 2431 is configured to receive a target object initiated order placement request sent by a client, wherein the target object has at least a first payment method and a second payment method, and the payment accounts associated with the first payment method and the second payment method are different. The generating module 2432 is configured to generate an order corresponding to the order placement request. The receiving module 2431 is further configured to receive a first payment request for paying the order based on the first payment method sent by the client. The payment module 2433 is configured to perform a payment operation based on the first payment account corresponding to the first payment method. The sending module 2434 is configured to, in response to a failure of the payment operation and receiving a second payment request for switching to the second payment method to pay the order sent by the client, send prompt information to the client, wherein the prompt information is used to prompt the order to be invalid and to resend a new order placement request.

[0209] In some embodiments, the electronic payment processing apparatus 243 further includes an obtaining module 2435 configured to, after the generating module 2432 generates the order corresponding to the order placement request, obtain a list of available payment methods of the target object based on the order placement credentials of the order, wherein the list of available payment methods includes at least the first payment method and the second payment method. The sending module 2434 is further configured to send the list of available payment methods to the client.

[0210] In some embodiments, when the first payment account corresponding to the first payment method is a payment account associated with the target object, the electronic payment processing apparatus 243 further comprises an analysis module 2436 configured to analyze the first payment request to obtain the payment account associated with the target object carried by the first payment request; and the payment module 2433 is further configured to, in response to the existence of the order placement result, and the payment account associated with the target object being consistent with the first payment account corresponding to the first payment method included in the list of available payment methods, perform a payment operation on the order based on the payment account associated with the target object.

[0211] In some embodiments, when the first payment account corresponding to the first payment method is a payment account of the target object itself, the analysis module 2436 is further configured to analyze the first payment request to obtain the payment account of the target object itself carried by the first payment request; and the payment module 2433 is further configured to, in response to the existence of the order placement result, and the payment account of the target object itself being consistent with the first payment account corresponding to the first payment method included in the list of available payment methods, perform a payment operation on the order based on the payment account of the target object itself.

[0212] In some embodiments, the electronic payment processing apparatus 243 further comprises a storage module 2437 configured to, after the generation module 2432 generates the order corresponding to the order placement request, combine the merchant number and the merchant order number corresponding to the order, add a first string to the combination result, and perform a hash processing on the combination result after the first string is added to obtain a corresponding hash value; serialize the order placement result of the order into a corresponding second string, and store the order in a manner that the hash value is used as a key and the second string is used as a value.

[0213] In some embodiments, the first payment account is one of a payment account of the target object itself and a payment account associated with the target object, and the second payment account corresponding to the second payment method is the other one of the payment account of the target object itself and the payment account associated with the target object.

[0214] In some embodiments, the first payment request is sent by the client after receiving the selection operation of the target object for the first payment method, wherein the first payment request carries the first payment account corresponding to the first payment method; the electronic payment processing apparatus 243 further comprises a routing module 2438 configured to, before the payment module 2433 performs the payment operation based on the first payment account corresponding to the first payment method, route the order to an order set corresponding to the first payment account according to the first payment account corresponding to the first payment method, wherein the first payment account is used to perform a payment on the orders in the order set.

[0215] In some embodiments, when the first payment account is the target object's own payment account, the routing module 2438 is also used to route the order to the first order set corresponding to the target object's own payment account according to the target object's own payment account, wherein the target object's own payment account is used to pay for the orders in the first order set.

[0216] In some embodiments, when the first payment account is a payment agent account associated with the target object, the routing module 2438 is further used to route the order to a second order set corresponding to the payment agent account according to the payment agent account, wherein the payment agent account is used to pay for orders in the second order set.

[0217] In some embodiments, the parsing module 2436 is also used to parse the second payment request to obtain the second payment account corresponding to the second payment method carried in the second payment request; the sending module is also used to send a prompt message to the client in response to the payment object corresponding to the second payment account being different from the payment object corresponding to the first payment account.

[0218] The following continues to describe the exemplary structure of the electronic payment processing device 465 provided in the embodiment of the present application as a software module. In some embodiments, such as Figure 2B As shown, the software modules stored in the electronic payment processing device 465 of the memory 460 may include: a sending module 4651 and an output module 4652.

[0219] Sending module 4651 is used to send an order request to the server in response to receiving an order operation triggered by the target object in the client, wherein the target object has at least a first payment method and a second payment method, the payment accounts associated with the first payment method and the second payment method are different, and the order request is used to request the server to generate a corresponding order; sending module 4651 is also used to send a first payment request to the server in response to receiving a selection operation for the first payment method by the target object, wherein the first payment request is used to request the server to perform a payment operation on the order based on the first payment account corresponding to the first payment method; sending module 4651 is also used to send a second payment request to the server in response to a payment operation failure and receiving a switch operation for the second payment method by the target object; output module 4652 is used to output a prompt message sent by the server in response to the second payment request, wherein the prompt message is used to prompt that the order is invalid and resend a new order request.

[0220] In some embodiments, the electronic payment processing device 465 also includes a receiving module 4653, which is used to receive a list of available payment methods for the target object sent by the server before the sending module 4651 responds to receiving the target object's selection operation for the first payment method, wherein the list of available payment methods includes at least the first payment method and the second payment method.

[0221] In some embodiments, the electronic payment processing device 465 also includes an acquisition module 4654, which is used to obtain a first payment account corresponding to a first payment method; a sending module 4651 is also used to send a first payment request carrying the first payment account to a server; the acquisition module 4654 is also used to obtain a second payment account corresponding to a second payment method; the sending module 4651 is also used to send a second payment request carrying the second payment account to a server.

[0222] In some embodiments, the sending module 4651 is also used to send a new order request to the server in response to receiving a new order operation triggered by the target object in the client after the output module outputs the prompt information sent by the server in response to the second payment request, so that the server generates a new order based on the new order request.

[0223] It should be noted that the description of the device of the embodiment of the present application is similar to the description of the method embodiment above, and has similar beneficial effects as the method embodiment, so it will not be repeated here. Figure 3 、 Figure 4 ,or Figure 5 The present invention should be understood by referring to the description of any one of the accompanying drawings.

[0224] The present invention provides a computer program product comprising a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the computer device to perform the electronic payment processing method described above in the present invention.

[0225] The embodiment of the present application provides a computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, the processor will execute the electronic payment processing method provided by the embodiment of the present application, for example, Figure 3 、 Figure 4 ,or Figure 5 The electronic payment processing method is shown.

[0226] In some embodiments, the computer-readable storage medium can be a memory such as a FRAM, ROM, PROM, EPROM, EEPROM, flash memory, a magnetic surface memory, an optical disk, or a CD-ROM, etc.; or various devices including one or any combination of the above memories.

[0227] In some embodiments, the executable instructions can be in the form of programs, software, software modules, scripts, or code, written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0228] By way of example, the executable instructions can be deployed in instances in which the program is executed on a single electronic device, or on multiple electronic devices located at a single site, or on multiple electronic devices distributed across multiple sites and interconnected via a communication network.

[0229] The above merely provides an example of the embodiments of the present application, and is not intended to limit the protection scope of the present application. Any modification, equivalent replacement, and improvement made within the spirit and scope of the present application shall fall within the protection scope of the present application.

Claims

1. An electronic payment processing method, characterized by, The method comprises: receiving a placing order request initiated by a target object sent by a client, and generating an order corresponding to the placing order request, wherein the target object has at least a first payment method and a second payment method, and the first payment method and the second payment method are associated with different payment accounts; receiving a first payment request for paying for the order based on the first payment method sent by the client, and performing a payment operation based on a first payment account corresponding to the first payment method; in response to a failure of the payment operation and receiving a second payment request for switching to the second payment method to pay for the order sent by the client, sending prompt information to the client, wherein the prompt information is used to prompt that the order is invalid, and a new placing order request is re-sent.

2. The method of claim 1, wherein, After the order corresponding to the placing order request is generated, the method further comprises: based on placing order credentials of the order, obtaining a list of available payment methods of the target object, wherein the list of available payment methods at least includes the first payment method and the second payment method; sending the list of available payment methods to the client.

3. The method of claim 2, wherein, When the first payment account corresponding to the first payment method is a payment account associated with the target object, the payment operation based on the first payment account corresponding to the first payment method comprises: parsing the first payment request to obtain the payment account carried by the first payment request; in response to the existence of the placing order result of the order and the payment account being consistent with the first payment account corresponding to the first payment method included in the list of available payment methods, performing a payment operation on the order based on the payment account.

4. The method of claim 2, wherein, When the first payment account corresponding to the first payment method is a payment account of the target object itself, the payment operation based on the first payment account corresponding to the first payment method comprises: parsing the first payment request to obtain the payment account of the target object itself carried by the first payment request; in response to the existence of the placing order result of the order and the payment account of the target object itself being consistent with the first payment account corresponding to the first payment method included in the list of available payment methods, performing a payment operation on the order based on the payment account of the target object itself.

5. The method of claim 1, wherein, After the order corresponding to the placing order request is generated, the method further comprises: combining a merchant number and a merchant order number corresponding to the order, adding a first string to the combination result, and performing hash processing on the combination result after adding the first string to obtain a corresponding hash value; serializing the placing order result of the order into a corresponding second string, and storing the order in a manner that the hash value is a key and the second string is a value.

6. The method of claim 1, wherein, The first payment account is one of a payment account of the target object itself and a payment account associated with the target object, and the second payment account corresponding to the second payment method is the other one of the payment account of the target object itself and the payment account associated with the target object.

7. The method of claim 1, wherein, The first payment request is sent by the client when the target object receives a selection operation for the first payment method, wherein the first payment request carries a first payment account corresponding to the first payment method; Before the payment operation based on the first payment account corresponding to the first payment method, the method further comprises: According to the first payment account corresponding to the first payment method, the order is routed to the order set corresponding to the first payment account, wherein the first payment account is used to pay for the order in the order set.

8. The method of claim 7, wherein, When the first payment account is the payment account of the target object itself, the order is routed to the first order set corresponding to the payment account of the target object itself according to the first payment account corresponding to the first payment method, wherein the payment account of the target object itself is used to pay for the order in the first order set. When the first payment account is the payment account of the target object itself, the order is routed to the first order set corresponding to the payment account of the target object itself according to the first payment account corresponding to the first payment method, wherein the payment account of the target object itself is used to pay for the order in the first order set.

9. The method of claim 7, wherein, When the first payment account is the payment account of the target object itself, the order is routed to the first order set corresponding to the payment account of the target object itself according to the first payment account corresponding to the first payment method, wherein the payment account of the target object itself is used to pay for the order in the first order set. When the first payment account is the payment account of the target object itself, the order is routed to the first order set corresponding to the payment account of the target object itself according to the first payment account corresponding to the first payment method, wherein the payment account of the target object itself is used to pay for the order in the first order set.

10. The method according to any one of claims 1 to 9, characterized in that, The method comprises: In response to receiving a target object triggered order operation in a client, a server is sent to send an order request, wherein the target object has at least a first payment method and a second payment method, the payment accounts associated with the first payment method and the second payment method are different, and the order request is used to request the server to generate a corresponding order; In response to receiving a selection operation of the target object for the first payment method, a first payment request is sent to the server, wherein the first payment request is used to request the server to perform a payment operation on the order based on the first payment account corresponding to the first payment method; 11. An electronic payment processing method characterized by comprising: In response to the payment operation failure, and receiving the switching operation of the target object for the second payment method, a second payment request is sent to the server; Output the prompt information sent by the server in response to the second payment request, wherein the prompt information is used to prompt the order to be invalid, and a new order request is sent again. Before the response to receiving the selection operation of the target object for the first payment method, the method further comprises: ​ ​ 12. The method of claim 11, wherein, ​ receive the list of available payment methods of the target object sent by the server, wherein the list of available payment methods at least includes the first payment method and the second payment method.

13. The method of claim 11, wherein, the sending of the first payment request to the server comprises: obtaining a first payment account corresponding to the first payment method, and sending a first payment request carrying the first payment account to the server; the sending of the second payment request to the server comprises: obtaining a second payment account corresponding to the second payment method, and sending a second payment request carrying the second payment account to the server.

14. The method of claim 11, wherein, After the output of the prompt information sent by the server in response to the second payment request, the method further comprises: in response to receiving a new order operation triggered by the target object in the client, sending a new order request to the server to enable the server to generate a new order based on the new order request.

15. An electronic payment processing apparatus, characterized by comprising: The apparatus comprises: a receiving module configured to receive an order request initiated by a target object sent by a client, wherein the target object has at least a first payment method and a second payment method, and payment accounts associated with the first payment method and the second payment method are different; a generating module configured to generate an order corresponding to the order request; the receiving module is further configured to receive a first payment request for paying for the order based on the first payment method sent by the client; a payment module configured to perform a payment operation based on a first payment account corresponding to the first payment method; a sending module configured to, in response to a failure of the payment operation and in response to receiving a second payment request for paying for the order based on the second payment method sent by the client, send a prompt information to the client, wherein the prompt information is used to prompt that the order is invalid and to resend a new order request.

16. An electronic payment processing apparatus, characterized by comprising: The apparatus comprises: a sending module configured to, in response to receiving an order operation triggered by a target object in a client, send an order request to a server, wherein the target object has at least a first payment method and a second payment method, payment accounts associated with the first payment method and the second payment method are different, and the order request is used to request the server to generate a corresponding order; the sending module is further configured to, in response to receiving a selection operation of the target object for the first payment method, send a first payment request to the server, wherein the first payment request is used to request the server to perform a payment operation for the order based on a first payment account corresponding to the first payment method; the sending module is further configured to, in response to a failure of the payment operation and in response to receiving a switching operation of the target object for the second payment method, send a second payment request to the server; an output module configured to output a prompt information sent by the server in response to the second payment request, wherein the prompt information is used to prompt that the order is invalid and to resend a new order request.

17. An electronic device, comprising: comprises: a memory configured to store executable instructions; A processor for implementing the electronic payment processing method of any one of claims 1 to 10, or any one of claims 11 to 14, when executing the executable instructions stored in the memory.

18. A computer-readable storage medium storing computer-executable instructions, wherein execution of the computer-executable instructions by one or more processors of a computing system causes the one or more processors to perform operations comprising: The computer executable instructions, when executed by the processor, implement the electronic payment processing method of any one of claims 1 to 10, or any one of claims 11 to 14.

19. A computer program product comprising computer programs or computer executable instructions, characterized in that, The computer program or computer executable instructions, when executed by the processor, implement the electronic payment processing method of any one of claims 1 to 10, or any one of claims 11 to 14.

Images