Resource transfer method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a resource transfer method and device, electronic equipment and a computer readable storage medium, and relates to the technical field of Internet. The method comprises the following steps: in response to a resource transfer operation initiated for a target resource transfer scene, calling a resource transfer interface corresponding to the target resource transfer scene to initiate resource transfer to a server; receiving information returned by the resource transfer interface or the server; if it is determined that resource transfer is abnormal according to the information, an abnormal reason is determined according to the information, a target processing strategy matched with the abnormal reason is obtained, the target processing strategy comprises interface information of a target processing interface, and the target processing interface is different from the resource transfer interface; and calling the target processing interface to obtain a calling result. According to the embodiment of the invention, the problem that the service of the resource transfer interface is affected due to the fact that the resource transfer interface is called by both resource transfer and resource transfer retry in the prior art when large-scale resource transfer abnormity occurs is avoided.

Description

Technical Field

[0001] The present application relates to the field of Internet technology. Specifically, the present application relates to a resource transfer method, device, electronic device, computer-readable storage medium, and computer program product. Background Art

[0002] With the development of Internet technology, there are more and more virtual resource transfers on the Internet, and virtual resources are transferred from one virtual resource account to another, such as transferring money, sending red envelopes, etc.

[0003] The client initiates resource transfer by calling the preset resource transfer interface. If there is an exception in the resource transfer link, the client will call the resource transfer interface again to initiate resource transfer retry, that is, re-initiate resource transfer. However, when large-scale exceptions occur, the client retry rate will be amplified by dozens or even hundreds of times, thereby affecting the service of the resource transfer interface. Summary of the Invention

[0004] The embodiments of the present application provide a resource transfer method, apparatus, electronic device, computer-readable storage medium, and computer program product that can solve the above-mentioned problems of the prior art. The technical solution is as follows:

[0005] According to one aspect of an embodiment of the present application, a resource transfer method is provided, the method comprising:

[0006] In response to a resource transfer operation initiated for a target resource transfer scenario, calling a resource transfer interface corresponding to the target resource transfer scenario to initiate resource transfer to a server;

[0007] receiving information returned by the resource transfer interface or the server;

[0008] If a resource transfer exception is determined based on the information, determining a cause of the exception based on the information, and obtaining a target processing strategy that matches the cause of the exception, the target processing strategy including interface information of a target processing interface, the target processing interface being an interface corresponding to the target resource transfer scenario and different from the resource transfer interface;

[0009] According to the target processing strategy, the target processing interface is called to obtain a calling result.

[0010] According to another aspect of an embodiment of the present application, a resource transfer device is provided, the device comprising:

[0011] a transfer initiating module, configured to, in response to a resource transfer operation initiated for a target resource transfer scenario, call a resource transfer interface corresponding to the target resource transfer scenario to initiate resource transfer to a server;

[0012] An information receiving module, configured to receive information returned by the resource transfer interface or the server;

[0013] a policy acquisition module configured to, if a resource transfer exception is determined based on the information, determine a cause of the exception based on the information, and acquire a target processing policy that matches the cause of the exception, the target processing policy including interface information of a target processing interface, the target processing interface being an interface corresponding to the target resource transfer scenario and different from the resource transfer interface;

[0014] The target interface calling module is used to call the target processing interface according to the target processing strategy to obtain a calling result.

[0015] As an optional implementation, the policy acquisition module determines the cause of the abnormality based on the information, including:

[0016] According to the information, which is a fault code returned by the server and indicating that the service execution failed, it is determined that the cause of the exception is that the service execution failed when the network connection is normal.

[0017] As an optional implementation manner, the policy acquisition module acquires a target processing policy that matches the cause of the exception, including:

[0018] Sending a request to the resource transfer interface to obtain a target processing policy;

[0019] receiving a query policy returned by the resource transfer interface in response to the request, the query policy including interface information of the query interface and a first threshold for retrying to call the query interface before obtaining a payment result, the query interface being used to query the server for a payment result of a recent payment;

[0020] The target interface calling module calls the target processing interface according to the target processing strategy to obtain a calling result, including:

[0021] Using the order query interface as the target processing interface;

[0022] The order query interface is called until a call result is obtained, or the number of times the order query interface is retried to reach the first threshold before a payment result is obtained.

[0023] As an optional implementation, the policy acquisition module determines the cause of the abnormality based on the information, including:

[0024] According to the information, the first fault code returned by the server is not related to server overload, and the cause of the abnormality is determined to be a network connection abnormality; or

[0025] According to the information, it is response information returned by the resource transfer interface. According to the response information, it is determined that the error does not require payment retry, and the cause of the exception is determined to be a resource transfer interface call exception.

[0026] As an optional implementation manner, the policy acquisition module acquires a target processing policy that matches the cause of the exception, including:

[0027] If the cause of the exception is a network connection exception, the first retry strategy obtained in advance from the resource transfer authorization directory is used as the target processing strategy;

[0028] If the cause of the exception is a resource transfer interface call exception, the second retry strategy in the response information is used as the target processing strategy;

[0029] The first retry strategy and the second retry strategy both include interface information of the resource transfer retry interface, and the resource transfer retry interface is used to initiate resource transfer to the server.

[0030] As an optional implementation manner, the transfer initiating module calls a resource transfer interface corresponding to the target resource transfer scenario to initiate resource transfer to the server, and the process also includes:

[0031] Calling the resource transfer authorization directory;

[0032] Determine that the call is successful, and obtain the first retry strategy from the resource transfer authorization directory.

[0033] As an optional implementation, the first retry strategy further includes a second threshold for retrying to call the resource transfer retry interface before the resource transfer is successful; the second retry strategy further includes a third threshold for retrying to call the resource transfer retry interface before the resource transfer is successful;

[0034] The target interface calling module calls the target processing interface according to the target processing strategy to obtain a calling result, including:

[0035] Calling the resource transfer retry interface to initiate resource transfer to the server;

[0036] If it is determined that the resource transfer is abnormal, then determine whether the network connection is abnormal;

[0037] If it is determined that the network connection is abnormal, continue to execute the first retry strategy;

[0038] If it is determined that the network connection is normal and it is determined that the resource transfer retry interface needs to be retried, the second retry strategy is continued to be executed.

[0039] As an optional implementation, the resource transfer retry interface is also used to count the real-time traffic of initiating resource transfer to the server. If the real-time traffic is greater than the preset fourth threshold, the call failure information is returned to the terminal that subsequently initiates resource transfer to the server.

[0040] According to another aspect of an embodiment of the present application, an electronic device is provided. The electronic device includes a memory, a processor, and a computer program stored in the memory. The processor executes the computer program to implement the steps of the above-mentioned resource transfer method.

[0041] According to another aspect of the embodiments of the present application, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of the above-mentioned resource transfer method are implemented.

[0042] According to one aspect of an embodiment of the present application, a computer program product is provided, including a computer program, which implements the steps of the above-mentioned resource transfer method when executed by a processor.

[0043] The beneficial effects of the technical solution provided by the embodiments of the present application are:

[0044] In response to the resource transfer operation initiated for the target resource transfer scenario, the resource transfer interface corresponding to the target resource transfer scenario is called to initiate resource transfer to the server, resource transfer is diverted according to different resource transfer scenarios, the possibility of traffic overload is reduced, information returned by the resource transfer interface or the server is received, and if the payment is determined to be abnormal, the cause of the abnormality is further determined based on the information and a target processing strategy matching the cause of the abnormality is obtained. The target processing strategy of the embodiment of the present application includes interface information of the target processing interface; the target processing interface is determined based on the interface information. According to the target processing strategy, the target processing interface is called to obtain a call result; the target processing interface and the resource transfer interface are interfaces corresponding to the target resource transfer scenario and different from the resource transfer interface. This ensures that when a resource transfer abnormality occurs, the resource transfer interface will not be called, avoiding the problem of affecting the service of the resource transfer interface due to the resource transfer and resource transfer retry calling the resource transfer interface when a large-scale resource transfer abnormality occurs. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for describing the embodiments of the present application.

[0046] Figure 1 A schematic diagram of the system architecture of an example system for implementing resource transfer provided in an embodiment of the present application;

[0047] Figure 2 A schematic diagram of a resource transfer method provided in an embodiment of the present application;

[0048] Figure 3A A schematic diagram of an operation interface for sending a red envelope through a first application provided in an embodiment of the present application;

[0049] Figure 3B A schematic diagram of an operation interface for transferring money through a first application provided in an embodiment of the present application;

[0050] Figure 4 A schematic diagram of a resource transfer method provided in an embodiment of the present application;

[0051] Figure 5 A schematic diagram of a resource transfer interface and a resource transfer retry interface split for different resource transfer scenarios provided in an embodiment of the present application;

[0052] Figure 6 A schematic diagram of a resource transfer method provided in an embodiment of the present application;

[0053] Figure 7 A flowchart of another resource transfer method provided in an embodiment of the present application;

[0054] Figure 8 A schematic diagram of the structure of a resource transfer device provided in an embodiment of the present application;

[0055] Figure 9 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0056] The following describes the embodiments of the present application in conjunction with the accompanying drawings. It should be understood that the embodiments described below in conjunction with the accompanying drawings are exemplary descriptions for explaining the technical solutions of the embodiments of the present application and do not constitute a limitation on the technical solutions of the embodiments of the present application.

[0057] Those skilled in the art will understand that, unless otherwise stated, the singular forms "a", "an" and "the" used herein may also include plural forms. It should be further understood that the terms "including" and "comprising" used in the embodiments of the present application mean that the corresponding features can be implemented as the presented features, information, data, steps, operations, elements and / or components, but do not exclude implementation as other features, information, data, steps, operations, elements, components and / or combinations thereof supported by the present technical field. It should be understood that when we say that an element is "connected" or "coupled" to another element, the element can be directly connected or coupled to the other element, or it can refer to that the element and the other element establish a connection relationship through an intermediate element. In addition, the "connection" or "coupling" used here can include wireless connection or wireless coupling. The term "and / or" used here indicates at least one of the items defined by the term, for example, "A and / or B" can be implemented as "A", or as "B", or as "A and B".

[0058] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0059] First, several terms involved in this application are introduced and explained:

[0060] 1. Resources

[0061] In computer technology, resources generally refer to virtual resources that correspond to physical resources in the real world, such as storage space, computing power, e-books, bank account balances, e-wallet account balances, and virtual currency balances. In the context of electronic payment, resources can refer to the amount of money in a bank account or e-wallet account.

[0062] 2. Resource Transfer

[0063] Resource transfer involves changing the ownership of a resource from one party to another. For example, if the resource is a bank account balance or an e-wallet account balance, resource transfer involves transferring part or all of the balance from one user account (the "transfer-out account") to another user account (the "transfer-in account"). In electronic payment applications, resource transfer can involve commercial payments and social payments (red envelopes, transfers, face-to-face payments, etc.).

[0064] 3. Application Programming Interface (API)

[0065] The API interface is an important part of the application. It is an entry point for the application to operate data. This entry point can be a function or class method, or a URL address or a network address. When the client calls this entry point, the application will execute the corresponding code operation to complete the corresponding function for the client. In order to facilitate the response to the caller, the response data can contain three attributes: status code (code), information description (message) and response data (data). The client can quickly know the interface based on the status code and information description. If the status code returns successfully, it will start processing the data. Array type data. The Object structure of the data is guaranteed through the list field. For example:

[0066] {code: "SUCCESS", / / Return code, the [Interface Return Code] section after the details will say data: {}, / / Data message: "Success" / / Store response information prompts, displayed to client users [Must be semantically Chinese prompts]}

[0067] The client initiates resource transfer by calling the preset resource transfer interface. If there is an exception in the resource transfer link, in one case, the client will call the resource transfer interface again to initiate a resource transfer retry, that is, re-initiate the resource transfer. However, since resource transfer and resource transfer retry use the same resource transfer interface, when a large-scale exception occurs, it will cause the client retry to be amplified by dozens or even hundreds of times, thereby affecting the service of the resource transfer interface; in another case, the client does not initiate a resource transfer retry, and the backend directly returns an error. At this time, the user may think that the resource transfer has failed and will re-initiate the resource transfer, which will cause the user to initiate resource transfer multiple times and repeated deductions.

[0068] The resource transfer method, device, electronic device, computer-readable storage medium, and computer program product provided in this application are intended to solve the above technical problems in the prior art.

[0069] The following describes several exemplary embodiments to illustrate the technical solutions of the embodiments of the present application and the technical effects produced by the technical solutions of the present application. It should be noted that the following embodiments can refer to, draw on, or combine with each other, and the same terms, similar features, and similar implementation steps in different embodiments will not be repeated.

[0070] Figure 1 A schematic diagram of an example system 100 is shown in which the various methods described herein may be implemented according to an embodiment of the present invention.

[0071] refer to Figure 1The example system 100 includes a client device 110 associated with a user 102, a first server 120, a front-end device 130, and a second server 140. A network 150 communicatively couples the client device 110, the first server 120, the front-end device 130, and the second server 140.

[0072] The client device 110 includes a display screen 114 and a first application 112 that interacts with the user 102 via the display screen 114. As will be described later, the first application 112 is used by the user 102 to initiate resource transfer. The first application 112 can be a client application provided by an Internet service provider (for example, Tencent) or a mini-program (liteapp) as a lightweight application. In the case where the first application 112 is a client application, the first application 112 can be installed in the client device 110. When the first application 112 is a mini-program, the first application 112 can be opened directly on the client device 110 by searching for relevant information of the first application 112 (such as the name of the first application 101, etc.), scanning a graphic code (such as a barcode, a QR code, etc.) of the first application 112, etc., without installing the first application 112.

[0073] Client device 110 may be any type of mobile computing device, including a mobile computer or a mobile computing device (e.g., devices, personal digital assistants (PDAs), laptop computers, notebook computers, tablet computers such as Apple iPad™, netbooks, etc.), mobile phones (e.g., cellular phones, such as Smartphone, Apple iPhone, realized Android TM Operating system phone, equipment, devices, etc.), wearable computing devices (e.g. smart watches, head-mounted devices, including smart glasses, such as Glass TM , etc.) or other types of mobile devices. In some embodiments, the client device 110 may also be a stationary computing device.

[0074] The first server 120 is typically a backend server (cluster) of an internet service provider, on which a backend application (not shown) may be run that interacts with the first application 112 at the client device 110 to process resource transfer services. In some embodiments, the first server 120 maintains both the user account 122 of the user 102 and the reservation account 124 of the resource transfer service entity 160, and thus the transfer of resources from the reservation account 124 to the user account 122 can be completed quickly, for example, at the level of seconds. In such an embodiment, both the user account 122 and the reservation account 124 are electronic wallet accounts (e.g., WeChat Wallet). Typically, the reservation account 124 is pre-filled with resources of the resource transfer service entity 160.

[0075] The front-end device 130 is typically a computing device set up by the resource transfer service entity 160 at the location where the resource transfer business is handled on-site, such as a computing device used by staff working at the location or a self-service computing device set up at the location. In the car purchase scenario, the front-end device 130 can be a computing device set up at a 4S store, such as a computing device used by sales staff or a self-service computing device used by car buyers. The front-end device 130 includes a second application 132, which is used to (directly or indirectly) obtain a resource transfer code from the client device 110 to initiate a resource transfer operation to the second server 140, as will be further described below.

[0076] The second server 140 is a backend server (cluster) of the resource transfer service entity 160, which interacts with the front-end device 130 to process resource transfer services. The first server 120 and the second server 140 are typically server computers with large amounts of memory and processor resources, but other embodiments are also possible.

[0077] Each of the client device 110, the first server 120, the front-end device 130, and the second server 140 may include at least one communication interface (not shown) capable of communicating over the network 150. Such a communication interface may be one or more of the following: any type of network interface (e.g., a network interface card (NIC)), a wired or wireless (such as an IEEE 802.11 wireless LAN (WLAN)) wireless interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth™ interface, a Near Field Communication (NFC) interface, etc. Additional examples of communication interfaces are described elsewhere herein.

[0078] Examples of network 150 include local area network (LAN), wide area network (WAN), personal area network (PAN), and / or a combination of communication networks such as the Internet. Alternatively or additionally, for security purposes, the front-end device 130 and the second server 140 may communicate through the private network 162 of the resource transfer service entity 160.

[0079] An embodiment of this application provides a resource transfer method, which can be applied to Figure 1 the first application shown in Figure 2 As shown, the method includes:

[0080] S101. In response to a resource transfer operation initiated for a target resource transfer scenario, call a resource transfer interface corresponding to the target resource transfer scenario to initiate a resource transfer to the server.

[0081] In the embodiments of this application, different resource transfer interfaces are preset for different resource transfer scenarios. The embodiments of this application do not specifically limit the type of resource transfer scenarios. For example, it can be red envelope sending, face-to-face transfer, order payment, etc.

[0082] Please refer to Figure 3A , which exemplarily shows a schematic diagram of the operation interface for sending red envelopes through the first application. As shown in the figure, in this interface, the user can click on the input box 3101 to enter the amount of the red envelope. In addition, to enrich the fun of sending red envelopes, the user can also enter a note in the input box 3102, such as "Congratulations on getting rich and having great luck", and can further click on the control 3103 to trigger the process of selecting a red envelope cover. Finally, the user clicks on the control 3104 "Put money into the red envelope", and the client, in response to the initiated resource operation, calls the resource transfer interface to initiate a resource transfer to the server.

[0083] Please refer to Figure 3B , which exemplarily shows a schematic diagram of the operation interface for making a transfer through the first application. As shown in the figure, at the upper position of this interface, the nickname of the recipient of the transfer and the last character of the real name will be displayed. In the figure, the nickname of the recipient of the transfer is "A bit handsome", and the last character of the real name of this object is "handsome". The user can click on the input box 3201 and enter the amount to be transferred by operating the digital control, and can further click on the control 3202 to add a transfer note. Then click on the transfer control 3202, and the client, in response to the initiated resource operation, calls the resource transfer interface to initiate a resource transfer to the server.

[0084] The server in the embodiments of this application may be Figure 1The first server in the payment process, the first application initiates payment to the first server by calling the resource transfer interface. Specifically, the first application can call the resource transfer interface and send resource transfer information to the first server, such as the payee's account, the transfer amount, the payer's account, etc. The first server performs resource transfer based on the received resource transfer information.

[0085] S102: Receive information returned by the resource transfer interface or the server.

[0086] By calling the resource transfer interface, the embodiment of the present application can receive information returned by the resource transfer interface or the server. The information may indicate that the resource transfer of the first application is successful, or it may indicate that the resource transfer is abnormal. Specifically, it can be indicated by different status codes. For example, when status codes -561, -562, -563, etc. are received, the first application is informed that an abnormal situation such as server overload has occurred.

[0087] S103: If it is determined that the resource transfer is abnormal according to the information, determine the cause of the abnormality according to the information, and obtain a target processing strategy that matches the cause of the abnormality.

[0088] The embodiment of the present application performs an exception analysis based on the returned information. If it is determined that the resource transfer is abnormal, the cause of the exception is further determined based on the information, and a target processing strategy matching the cause of the exception is obtained.

[0089] In the embodiment of the present application, failure of payment is referred to as payment abnormality. For example, network abnormality, request timeout, interface error, and system failure are all payment abnormalities. The information in the embodiment of the present application carries a status code indicating the resource transfer status, so the first application can determine the cause of the abnormality based on the status code, and thus obtain the corresponding target execution strategy based on the specific cause of the abnormality.

[0090] The target processing strategy of the embodiment of the present application at least includes the interface information of the target processing interface. On the one hand, the target processing interface and the resource transfer interface are different interfaces, which ensures that when a resource transfer exception occurs, the resource transfer interface will not be called, avoiding the problem of affecting the service of the resource transfer interface due to the resource transfer and resource transfer retry calling the resource transfer interface when a large-scale resource transfer exception occurs. On the other hand, the target processing interface also needs to correspond to the target resource transfer scenario, thereby further dispersing the total flow of resource transfer and reducing the possibility of overload. At the same time, the resource transfer processes of different resource transfer scenarios are decoupled from each other. When maintaining the resource interface and target processing interface of different resource transfer scenarios, it will not affect the use of other resource transfers, thereby improving the user's selectivity.

[0091] In some embodiments, the target processing strategy of the present application may also include the maximum number of retries to call the target processing interface. That is, the target processing strategy instructs the client to retry calling the target processing interface after a payment exception, and either obtain the target call result before the maximum number of retries, or no longer call the target processing interface when the target call result is not obtained after the maximum number of retries, so as to save power of the terminal.

[0092] S104: According to the target processing strategy, call the target processing interface to obtain a call result.

[0093] The embodiment of the present application responds to a resource transfer operation initiated for a target resource transfer scenario, calls a resource transfer interface corresponding to the target resource transfer scenario to initiate a resource transfer to a server, diverts the resource transfer according to different resource transfer scenarios, reduces the possibility of traffic overload, receives information returned by the resource transfer interface or the server, and performs an exception analysis on the information. If a payment exception is determined, the cause of the exception is further determined based on the information and a target processing strategy matching the cause of the exception is obtained. The target processing strategy of the embodiment of the present application includes interface information of the target processing interface; the target processing interface is determined based on the interface information, and the target processing interface is called according to the target processing strategy to obtain a call result; the target processing interface and the resource transfer interface are interfaces corresponding to the target resource transfer scenario and different from the resource transfer interface. This ensures that the resource transfer interface will not be called when a resource transfer exception occurs, avoiding the problem of affecting the service of the resource transfer interface due to the resource transfer and resource transfer retry calling the resource transfer interface when a large-scale resource transfer exception occurs.

[0094] Based on the above embodiments, as an optional embodiment, determining the cause of the abnormality according to the information includes:

[0095] According to the fault code returned by the server and indicating the failure of the service execution, it is determined that the cause of the abnormality is that the service execution failed when the network connection is normal.

[0096] It should be noted that a fault code is a type of status code. If the first application receives a fault code returned by the server indicating a service execution failure, it can be seen that, on the one hand, the network connection is normal, but on the other hand, no clear result of resource transfer failure has been obtained. Furthermore, the embodiment of the present application obtains a target processing strategy that matches the cause of the exception, including:

[0097] Sending a request to the resource transfer interface to obtain a target processing policy;

[0098] Receive the order query strategy returned by the resource transfer interface according to the request.

[0099] After determining that the business execution fails under normal network connection, the embodiment of the present application sends a request to the resource transfer interface to obtain the target processing strategy. That is, the target processing strategy of the embodiment of the present application is pre-configured on the resource transfer interface side. When the resource transfer interface receives the request, it returns the query strategy to the first application.

[0100] The order checking strategy includes the interface information of the order checking interface, which is used to query the server for the payment result of the most recent payment. That is to say, in an embodiment of the present application, if it is determined that the business execution has failed when the network connection is normal, the resource transfer interface will not be called to re-initiate the payment. Instead, another interface, namely the order checking interface, will be called to inquire whether the resource transfer just now is successful. In the embodiment of the present application, if the resource transfer is not clearly failed, if the resource transfer is retried, it may result in multiple repeated deductions and cause user complaints. Checking the order (that is, querying the result of the resource transfer) confirms the result of this payment, does not initiate multiple payments, has no financial risk, and no longer repeatedly initiates resource transfers, thereby avoiding resource disputes and waste of computing power.

[0101] Furthermore, the order checking strategy of the embodiment of the present application also sets a first threshold for retrying to call the order checking interface before obtaining the payment result. That is, the order checking strategy instructs the client to retry calling the order checking interface after a payment exception occurs, and either obtain the target call result before the maximum number of retries, or no longer call the target processing interface if the target call result is not obtained after the maximum number of retries is reached, so as to save terminal power. Furthermore, according to the target processing strategy, calling the target processing interface to obtain the call result includes:

[0102] Using the order query interface as the target processing interface;

[0103] The order query interface is called until a call result is obtained, or the number of times the order query interface is retried to reach the first threshold before a payment result is obtained.

[0104] See Figure 4 , which exemplarily shows a flow chart of a resource transfer method provided in an embodiment of the present application, as shown in the figure, including:

[0105] S401: A first application invokes a resource transfer interface corresponding to the target resource transfer scenario to initiate resource transfer to a server;

[0106] S402. Determine whether the resource transfer is successful by receiving information returned by the server or the resource transfer interface indicating that the resource transfer is successful. If the resource transfer is successful, the process ends. If the transfer fails, execute S403.

[0107] S403, judging whether the network connection is abnormal by whether the information returned by the server or the resource transfer interface is received, if the network connection is abnormal, executing S404, if the network connection is normal, executing S405;

[0108] S404: The underlying network of the first application calls the resource transfer interface to initiate resource transfer to the server at a preset interval. After each call, if the resource transfer is determined to be successful, the process ends; if the resource transfer is abnormal and the retry threshold is not reached, the process returns to step S403; if it fails and the retry threshold is reached (for example, two times), the process ends;

[0109] S405: Determine that the service execution has failed, send a request to the resource transfer interface to obtain a target processing policy, and receive a document query policy returned by the resource transfer interface in response to the request. The document query policy includes interface information of the document query interface and a first threshold for retrying to call the document query interface before obtaining a payment result.

[0110] S406: Call the query interface to query the result of resource transfer;

[0111] S407. Determine whether the resource transfer is successful based on the query result. If the resource transfer is successful, the process ends. If the resource transfer fails, execute S408.

[0112] S408. Determine whether to continue searching the order based on whether the number of times the order query interface is retried reaches a first threshold. If yes, return to S406. If no, the process ends.

[0113] Based on the above embodiments, as an optional embodiment, determining the cause of the abnormality according to the information includes:

[0114] According to the information, the first fault code returned by the server is not related to server overload, and the cause of the abnormality is determined to be a network connection abnormality;

[0115] According to the information, it is response information returned by the resource transfer interface. According to the response information, it is determined that the error does not require payment retry, and the cause of the exception is determined to be a resource transfer interface call exception.

[0116] The embodiments of the present application provide solutions for determining the cause of abnormalities for the server and resource transfer interface respectively:

[0117] For the server, since the server may return a status code indicating various information, the embodiment of the present application will indicate a fault, but the fault indicated is a fault code that is not related to server overload as the first fault code. If the first fault code returned by the server is received, it is determined that the cause of the abnormality is a network connection abnormality.

[0118] For the resource transfer interface, if the response information returned by the resource transfer interface indicates that it is not an error that does not require payment retry, it is determined that the cause of the exception is a resource transfer interface call exception.

[0119] Based on the above embodiments, as an optional embodiment, obtaining a target processing strategy that matches the cause of the exception includes:

[0120] If the cause of the exception is a network connection exception, the first retry strategy obtained in advance from the resource transfer authorization directory is used as the target processing strategy.

[0121] If the cause of the exception is a resource transfer interface call exception, the second retry strategy in the response information is used as the target processing strategy.

[0122] The embodiments of the present application provide different methods for obtaining target processing strategies according to different abnormal causes, thereby improving operability in practical applications.

[0123] Taking WeChat as an example, the page address that the merchant requests to open the WeChat payment checkout counter is called the "resource transfer authorization directory". The merchant's actual resource transfer authorization directory must be consistent with the one set in the WeChat payment merchant platform, otherwise an error will be reported. Therefore, before calling resource transfer, it is usually necessary to obtain the resource transfer authorization directory first. The embodiment of the present application pre-stores the first retry strategy in the resource transfer authorization directory, so that when it is determined that the network connection with the server is abnormal, the target processing strategy can also be obtained.

[0124] If the cause of the exception is determined to be a resource transfer interface call exception based on the response information returned by the resource transfer interface, the embodiment of the present application will also pre-store the second retry strategy in the response information, so that the first application can use the second retry strategy in the response information as the target processing strategy.

[0125] The first retry strategy and the second retry strategy of the embodiment of the present application both include interface information of the resource transfer retry interface. The resource transfer retry interface is used to initiate resource transfer to the server. That is to say, when performing a resource transfer retry, the present application no longer continues to call the resource transfer interface as in the prior art, but calls a new interface, namely the resource transfer retry interface. The functions of the resource transfer retry interface and the resource transfer interface are similar, and both are used to initiate resource transfer to the server. However, the difference is that for the same resource transfer operation initiated, the resource transfer interface will be called the first time a resource transfer is initiated to the server, and the resource transfer retry interface will be called during subsequent retries, thereby reducing the traffic pressure on the resource transfer interface. It should be understood that the resource transfer retry interface is a different interface from the resource transfer interface.

[0126] See Figure 5 , which exemplarily shows a schematic diagram of the resource transfer interface and resource transfer retry interface split according to different resource transfer scenarios in the embodiment of the present application. As shown in the figure, the first branch from top to bottom of the resource transfer scenario of the first application indicates that there are two major categories of scenarios, namely commercial payment scenarios and social payment scenarios. The resource transfer object of the commercial payment scenario is usually an organization. For example, purchasing tickets for a scenic spot through a mini program belongs to a commercial payment scenario. The resource transfer object of the social payment scenario is usually an individual. For example, sending red envelopes, face-to-face payments, and transfers all belong to social payment scenarios. The first-level resource transfer interface for the social payment scenario is mmpayWebproxy, and the first-level resource transfer interface for the commercial payment scenario is mmWebproxy.

[0127] The social payment scenario includes two secondary resource transfer interfaces: mmpaytransferlogisvr interface and mmpayf2ftansferlogisvr interface. The mmpaytransferlogisvr interface is a resource transfer interface for transferring money to individuals, and the mmpayf2ftansferlogisvr interface is a resource transfer interface for scan code payment. The commercial payment scenario also includes two secondary resource transfer interfaces: mmpayhbtransferlogisvr interface and mmpaytftransferlogisvr interface. The mmpayhbtransferlogisvr interface is a resource transfer interface for sending red envelopes, and the mmpaytftransferlogisvr interface is a resource transfer interface for transferring money. For the mmpaytransferlogisvr interface, the embodiment of the present application constructs a resource transfer retry interface for the same scenario that retries to initiate resource transfer to the server: mmpaybusitetryproxyappsvr interface. For the mmpayf2ftansferlogisvr interface, the embodiment of the present application constructs a resource transfer retry interface for the same scenario that retries to initiate resource transfer to the server: mmpayf2ftryproxyappsvr interface. For the two resource transfer interfaces in the commercial payment scenario, the embodiment of the present application constructs a common resource transfer retry interface mmpaysnsretryproxyappsvr interface. The embodiment of the present application splits out different resource interfaces for different resource transfer scenarios, and configures corresponding resource transfer retry interfaces for different resource transfer interfaces to maintain and retry the initiation of resource transfer to avoid mutual impact and mutual isolation.

[0128] Based on the above embodiments, as an optional embodiment, calling a resource transfer interface corresponding to the target resource transfer scenario to initiate resource transfer to the server, further comprising:

[0129] Calling the resource transfer authorization directory;

[0130] Determine that the call is successful, and obtain the first retry strategy from the resource transfer authorization directory.

[0131] Before calling the resource transfer interface to initiate resource transfer to the server, the embodiment of the present application first calls the resource transfer authorization directory. If the call is successful, it will continue to call the resource transfer interface corresponding to the target resource transfer scenario to initiate resource transfer to the server. In addition, the present application will pre-select and store the first retry strategy in the resource transfer authorization directory, so that the first application can obtain the first retry strategy when the resource transfer authorization directory is successfully called.

[0132] Based on the above embodiments, as an optional embodiment, the first retry strategy also includes a second threshold for retrying to call the resource transfer retry interface before the resource transfer is successful; the second retry strategy also includes a third threshold for retrying to call the resource transfer retry interface before the resource transfer is successful.

[0133] The first retry strategy and the second retry strategy of the embodiment of the present application both include a threshold value for the number of times the resource transfer retry interface is retried before the resource transfer is successful. The size relationship between the second threshold value and the third threshold value can be the same or different. The reason why the embodiment of the present application sets two retry strategies is that the two retry strategies have different focuses. The first retry strategy obtained by calling the resource transfer authorization directory is used as a fallback strategy, which is a secondary strategy and a static strategy. The second retry strategy obtained through the resource transfer interface is a primary strategy, and the second retry strategy of the present application can also be dynamically adjusted, and the threshold value for the number of retries can be adjusted according to real-time traffic.

[0134] In this embodiment of the application, calling the target processing interface to obtain the calling result includes:

[0135] Calling the resource transfer retry interface to initiate resource transfer to the server;

[0136] If it is determined that the resource transfer is abnormal, then determine whether the network connection is abnormal;

[0137] If it is determined that the network connection is abnormal, continue to execute the first retry strategy;

[0138] If it is determined that the network connection is normal, and it is determined based on the information returned by the resource transfer interface that it is necessary to retry calling the resource transfer retry interface, then the second retry strategy will continue to be executed.

[0139] It should be noted that the resource transfer process can be divided into three steps. The first step is to place an order, that is, to determine the amount and object of the resource transfer. The second step is to pull the cashier and display the resource transfer method (for example, display the bank card list). At this time, it is necessary to call the resource transfer authorization directory. The third step is to enter the transaction password. When performing the third step, the information returned by the resource transfer interface may not be received due to network connection abnormalities, that is, the second retry strategy cannot be obtained. Therefore, at this time, the first retry strategy is executed as a backup strategy.

[0140] It should be understood that continuing to execute the first retry strategy in the embodiment of the present application means judging whether to continue to call the resource transfer retry interface to initiate resource transfer to the server based on the second threshold indicated in the first retry strategy. Similarly, continuing to execute the second retry strategy means judging whether to continue to call the resource transfer retry interface to initiate resource transfer to the server based on the third threshold indicated in the second retry strategy.

[0141] See Figure 6 , which exemplarily shows a flow chart of a resource transfer method according to another embodiment of the present application, as shown in the figure, including:

[0142] S601: The first application initiates a resource transfer process;

[0143] S602: Call the resource transfer authorization directory;

[0144] S603: Determine whether the resource transfer authorization directory is successfully called; if successful, receive the first retry strategy in the resource transfer authorization directory; if unsuccessful, end the process;

[0145] S604: Calling a resource transfer interface corresponding to the target resource transfer scenario to initiate resource transfer to the server;

[0146] S605: Determine whether the resource transfer is successful by receiving information returned by the server or the resource transfer interface indicating that the resource transfer is successful. If the resource transfer is successful, the process ends. If the resource transfer is abnormal, execute S606.

[0147] S606: Determine whether the information returned by the server or the resource transfer interface is not received due to a network connection anomaly. If the information is not received due to a network connection anomaly, execute S607; if the information is received, execute S608;

[0148] S607: Determine whether the first fault code returned by the server is received. If so, the process ends; if not, execute S609;

[0149] S608: Determine whether the transfer failed as explicitly indicated. If so, terminate the process (the background determines whether an explicit error is reported, does not return the query policy, and terminates the process). If not, it indicates that the first application has received the resource transfer interface message normally, and uses the second retry policy carried in the response message of the resource transfer interface to retry the resource transfer.

[0150] S609: Call the resource transfer retry interface to initiate resource transfer to the server;

[0151] S610, call the query interface to check whether the resource transfer is successful, if so, end the process, if not, execute S611;

[0152] S611. Determine whether the network connection is abnormal. If the network connection is abnormal, continue to execute the first retry strategy until the first retry strategy is executed, and return to execute S609. If the network connection is normal, execute S612.

[0153] S612: Determine whether to continue retrying to call the resource transfer retry interface. If retry is required, determine whether to retry to initiate resource transfer to the server according to the second retry strategy. If retry is not required, end the process.

[0154] Based on the above embodiments, as an optional embodiment, the resource transfer retry interface is also used to count the real-time traffic of initiating resource transfer to the server. If the real-time traffic is greater than the preset fourth threshold, a call failure message is returned to the terminal that subsequently initiates resource transfer to the server.

[0155] It should be understood that according to the solution of the embodiment of the present application, any terminal running the first application that wants to retry initiating resource transfer to the server will call the resource transfer retry interface. The resource transfer retry interface of the embodiment of the present application has a flow limiting capability. When any first application calls the resource transfer retry interface, the resource transfer retry interface will calculate the real-time traffic. If the real-time traffic is not less than the preset fourth threshold, the resource transfer process is not affected and can be called normally by each terminal. If the real-time traffic is greater than the preset fourth threshold, in order to ensure that the resource transfer call is within an acceptable range for the server, the resource transfer retry interface will return a call failure message to the terminal that subsequently initiates resource transfer to the server. The embodiment of the present application can ensure the core resource transfer process while also ensuring that the resource transfer is retried under abnormal circumstances to ensure the availability of resource transfer, greatly improving the user experience.

[0156] Based on the above embodiments, the fourth threshold value of the resource transfer retry interface configuration of the embodiment of the present application can be related to time and scenario. For example, in the red envelope sending scenario, the fourth threshold value of daily time is 10,000, that is, 10,000 applications are allowed to initiate retries to send red envelopes at the same time per unit time. During major holidays, such as the Spring Festival, the fourth threshold value is 40,000. In the face-to-face payment scenario, the fourth threshold value of daily time is 10,000, and the fourth threshold value during the Spring Festival can be 20,000. By providing a flexible and configurable fourth threshold value, the smooth execution of resource transfer can be ensured and the user experience can be improved.

[0157] See Figure 7 , which exemplarily shows a flow chart of a resource transfer method according to another embodiment of the present application, as shown in the figure, including:

[0158] S701: In response to a resource transfer operation initiated for a target resource transfer scenario, a resource transfer interface corresponding to the target resource transfer scenario is called to initiate resource transfer to a server;

[0159] S702: Receive information returned by the resource transfer interface or the server;

[0160] S703: If the resource transfer is determined to be abnormal based on the information, determine whether the current availability requirement is higher than a preset level. If not, execute S704; if higher, execute S707.

[0161] S704: Determine, based on the information indicating the fault code returned by the server indicating the failure of service execution, that the cause of the exception is the failure of service execution when the network connection is normal;

[0162] S705: Send a request to the resource transfer interface to obtain a target processing strategy, and receive a query strategy returned by the resource transfer interface according to the request;

[0163] S706: Use the order query interface as the target processing interface and call the order query interface until a call result is obtained, or the number of times the order query interface is retried before obtaining a payment result reaches the first threshold, and the process ends.

[0164] S707. If the information is the first fault code returned by the server, the cause of the exception is determined to be a network connection abnormality, and S708 is executed. If the information is a response message returned by the resource transfer interface, it is determined based on the response message that the error does not require a payment retry, and the cause of the exception is determined to be a resource transfer interface call abnormality, and S708' is executed.

[0165] S708: Use the first retry strategy obtained in advance from the resource transfer authorization directory as the target processing strategy;

[0166] S708', using the second retry strategy in the response information as the target processing strategy;

[0167] S709: Call the resource transfer retry interface to initiate resource transfer to the server;

[0168] S710: If it is determined that the resource transfer is abnormal, determine whether the network connection is abnormal. If it is determined that the network connection is abnormal, execute S711; if it is determined that the network connection is normal, execute S711';

[0169] S711: Continue to execute the first retry strategy;

[0170] S711′: Determine that it is necessary to retry calling the resource transfer retry interface, and continue to execute the second retry strategy.

[0171] The embodiment of the present application provides a resource transfer device, such as Figure 8 As shown, the resource transfer device may include: a transfer initiating module 801, an information receiving module 802, a policy obtaining module 803 and a target interface calling module 804, wherein:

[0172] The transfer initiating module 801 is configured to, in response to a resource transfer operation initiated for a target resource transfer scenario, call a resource transfer interface corresponding to the target resource transfer scenario to initiate resource transfer to a server;

[0173] An information receiving module 802 is configured to receive information returned by the resource transfer interface or the server;

[0174] a policy acquisition module 803 configured to, if a resource transfer exception is determined based on the information, determine a cause of the exception based on the information, and acquire a target processing policy that matches the cause of the exception, the target processing policy including interface information of a target processing interface, the target processing interface being an interface corresponding to the target resource transfer scenario and different from the resource transfer interface;

[0175] The target interface calling module 804 is used to call the target processing interface according to the target processing strategy to obtain a calling result.

[0176] Based on the above embodiments, as an optional embodiment, the policy acquisition module determines the cause of the abnormality according to the information, including:

[0177] According to the information, which is a fault code returned by the server and indicating that the service execution failed, it is determined that the cause of the exception is that the service execution failed when the network connection is normal.

[0178] Based on the above embodiments, as an optional embodiment, the strategy acquisition module acquires a target processing strategy that matches the cause of the exception, including:

[0179] Sending a request to the resource transfer interface to obtain a target processing policy;

[0180] receiving a query policy returned by the resource transfer interface in response to the request, the query policy including interface information of the query interface and a first threshold for retrying to call the query interface before obtaining a payment result, the query interface being used to query the server for a payment result of a recent payment;

[0181] The target interface calling module calls the target processing interface according to the target processing strategy to obtain a calling result, including:

[0182] Using the order query interface as the target processing interface;

[0183] The order query interface is called until a call result is obtained, or the number of times the order query interface is retried to reach the first threshold before a payment result is obtained.

[0184] Based on the above embodiments, as an optional embodiment, the policy acquisition module determines the cause of the abnormality according to the information, including:

[0185] According to the information, the first fault code returned by the server is not related to server overload, and the cause of the abnormality is determined to be a network connection abnormality; or

[0186] According to the information, it is response information returned by the resource transfer interface. According to the response information, it is determined that the error does not require payment retry, and the cause of the exception is determined to be a resource transfer interface call exception.

[0187] Based on the above embodiments, as an optional embodiment, the strategy acquisition module acquires a target processing strategy that matches the cause of the exception, including:

[0188] If the cause of the exception is a network connection exception, the first retry strategy obtained in advance from the resource transfer authorization directory is used as the target processing strategy;

[0189] If the cause of the exception is a resource transfer interface call exception, the second retry strategy in the response information is used as the target processing strategy;

[0190] The first retry strategy and the second retry strategy both include interface information of the resource transfer retry interface, and the resource transfer retry interface is used to initiate resource transfer to the server.

[0191] Based on the above embodiments, as an optional embodiment, the transfer initiating module calls the resource transfer interface corresponding to the target resource transfer scenario to initiate resource transfer to the server, and the method further includes:

[0192] Calling the resource transfer authorization directory;

[0193] Determine that the call is successful, and obtain the first retry strategy from the resource transfer authorization directory.

[0194] Based on the above embodiments, as an optional embodiment, the first retry strategy further includes a second threshold for retrying to call the resource transfer retry interface before the resource transfer is successful; the second retry strategy further includes a third threshold for retrying to call the resource transfer retry interface before the resource transfer is successful;

[0195] The target interface calling module calls the target processing interface according to the target processing strategy to obtain a calling result, including:

[0196] Calling the resource transfer retry interface to initiate resource transfer to the server;

[0197] If it is determined that the resource transfer is abnormal, then determine whether the network connection is abnormal;

[0198] If it is determined that the network connection is abnormal, continue to execute the first retry strategy;

[0199] If it is determined that the network connection is normal and it is determined that the resource transfer retry interface needs to be retried, the second retry strategy is continued to be executed.

[0200] Based on the above embodiments, as an optional embodiment, the resource transfer retry interface is also used to count the real-time traffic for initiating resource transfer to the server. If the real-time traffic is greater than the preset fourth threshold, the call failure information is returned to the terminal that subsequently initiates resource transfer to the server.

[0201] The device of the embodiment of the present application can execute the method provided by the embodiment of the present application, and its implementation principle is similar. The actions performed by each module in the device of each embodiment of the present application correspond to the steps in the method of each embodiment of the present application. For the detailed functional description of each module of the device, please refer to the description in the corresponding method shown in the previous text, and will not be repeated here.

[0202] An embodiment of the present application provides an electronic device, including a memory, a processor, and a computer program stored in the memory. The processor executes the computer program to implement the steps of a resource transfer method. Compared with related technologies, the method can achieve the following: in response to a resource transfer operation initiated for a target resource transfer scenario, calling a resource transfer interface corresponding to the target resource transfer scenario to initiate a resource transfer to a server, diverting the resource transfer according to different resource transfer scenarios to reduce the possibility of traffic overload; receiving information returned by the resource transfer interface or the server, and performing an abnormality analysis on the information. If a payment abnormality is determined, further determining the cause of the abnormality based on the information and obtaining a target processing strategy matching the cause of the abnormality. The target processing strategy of the embodiment of the present application includes interface information of the target processing interface; determining the target processing interface based on the interface information; calling the target processing interface based on the target processing strategy to obtain a call result; the target processing interface and the resource transfer interface are interfaces corresponding to the target resource transfer scenario and different from the resource transfer interface. This ensures that the resource transfer interface will not be called when a resource transfer abnormality occurs, avoiding the problem in the prior art of affecting the service of the resource transfer interface due to both resource transfer and resource transfer retry calling the resource transfer interface when a large-scale resource transfer abnormality occurs.

[0203] In an alternative embodiment, an electronic device is provided, such as Figure 9 As shown, Figure 9 The electronic device 4000 shown includes: a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which may be used for data exchange between the electronic device and other electronic devices, such as data transmission and / or data reception. It should be noted that in actual applications, the number of transceivers 4004 is not limited to one, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present application.

[0204] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 4001 may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and the like.

[0205] Bus 4002 may include a path for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, for example. Bus 4002 may be divided into an address bus, a data bus, a control bus, and so on. For ease of illustration, bus 4002 is represented by a single thick line in the figure, but this does not indicate that there is only one bus or only one type of bus.

[0206] The memory 4003 can be a ROM (Read Only Memory) or other types of static storage devices that can store static information and instructions, a RAM (Random Access Memory) or other types of dynamic storage devices that can store information and instructions, or an EEPROM (Electrically Erasable Programmable Read Only Memory), a CD-ROM (Compact Disc Read Only Memory) or other optical disk storage, optical disk storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium that can be used to carry or store computer programs and can be read by a computer, without limitation here.

[0207] The memory 4003 is used to store the computer program for executing the embodiment of the present application, and the execution is controlled by the processor 4001. The processor 4001 is used to execute the computer program stored in the memory 4003 to implement the steps shown in the above method embodiment.

[0208] An embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps and corresponding contents of the aforementioned method embodiment can be implemented.

[0209] An embodiment of the present application also provides a computer program product, including a computer program, which can implement the steps and corresponding contents of the aforementioned method embodiment when executed by a processor.

[0210] The terms "first," "second," "third," "fourth," "1," "2," and the like (if any) in the specification and claims of this application and the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequential sequence. It should be understood that the terms used in this manner are interchangeable where appropriate, so that the embodiments of the application described herein can be implemented in an order other than that shown or described in the drawings.

[0211] It should be understood that, although each operation step is indicated by arrows in the flowchart of the embodiment of the present application, the order of implementation of these steps is not limited to the order indicated by the arrows. Unless otherwise clearly stated herein, in some implementation scenarios of the embodiment of the present application, the implementation steps in each flowchart can be performed in other orders according to demand. In addition, some or all of the steps in each flowchart can include multiple sub-steps or multiple stages based on actual implementation scenarios. Some or all of these sub-steps or stages can be executed at the same time, and each sub-step or stage in these sub-steps or stages can also be executed at different times respectively. Under different scenarios at the execution time, the execution order of these sub-steps or stages can be flexibly configured according to demand, and the embodiment of the present application does not limit this.

[0212] The above description is only an optional implementation method for some implementation scenarios of this application. It should be pointed out that for ordinary technicians in this technical field, without departing from the technical concept of the solution of this application, the use of other similar implementation methods based on the technical ideas of this application also falls within the protection scope of the embodiments of this application.

Claims

1. A resource transfer method, characterized in that: include: In response to a resource transfer operation initiated for a target resource transfer scenario, calling a resource transfer interface corresponding to the target resource transfer scenario to initiate resource transfer to a server; receiving information returned by the resource transfer interface or the server; If a resource transfer exception is determined based on the information, determining a cause of the exception based on the information, and obtaining a target processing strategy that matches the cause of the exception, the target processing strategy including interface information of a target processing interface, the target processing interface being an interface corresponding to the target resource transfer scenario and different from the resource transfer interface; According to the target processing strategy, the target processing interface is called to obtain a calling result.

2. The method according to claim 1, characterized in that Determining the cause of the abnormality according to the information includes: According to the information, which is a fault code returned by the server and indicating that the service execution failed, it is determined that the cause of the exception is that the service execution failed when the network connection is normal.

3. The method according to claim 2, characterized in that The obtaining of a target processing strategy that matches the cause of the exception includes: Sending a request to the resource transfer interface to obtain a target processing policy; receiving a query policy returned by the resource transfer interface in response to the request, the query policy including interface information of the query interface and a first threshold for retrying to call the query interface before obtaining a payment result, the query interface being used to query the server for a payment result of a recent payment; The step of calling the target processing interface to obtain a calling result according to the target processing strategy includes: Using the order query interface as the target processing interface; The order query interface is called until a call result is obtained, or the number of times the order query interface is retried to reach the first threshold before a payment result is obtained.

4. The method according to claim 1, wherein Determining the cause of the abnormality according to the information includes: According to the information, the first fault code returned by the server is not related to server overload, and the cause of the abnormality is determined to be a network connection abnormality; or According to the information, it is response information returned by the resource transfer interface. According to the response information, it is determined that the error does not require payment retry, and the cause of the exception is determined to be a resource transfer interface call exception.

5. The method according to claim 4, characterized in that The obtaining of a target processing strategy that matches the cause of the exception includes: If the cause of the exception is a network connection exception, the first retry strategy obtained in advance from the resource transfer authorization directory is used as the target processing strategy; If the cause of the exception is a resource transfer interface call exception, the second retry strategy in the response information is used as the target processing strategy; The first retry strategy and the second retry strategy both include interface information of the resource transfer retry interface, and the resource transfer retry interface is used to initiate resource transfer to the server.

6. The method according to claim 5, characterized in that The calling of the resource transfer interface corresponding to the target resource transfer scenario to initiate resource transfer to the server also includes: Calling the resource transfer authorization directory; Determine that the call is successful, and obtain the first retry strategy from the resource transfer authorization directory.

7. The method according to claim 5, characterized in that The first retry strategy further includes a second threshold for retrying to call the resource transfer retry interface before the resource transfer is successful; the second retry strategy further includes a third threshold for retrying to call the resource transfer retry interface before the resource transfer is successful; The step of calling the target processing interface to obtain a calling result according to the target processing strategy includes: Calling the resource transfer retry interface to initiate resource transfer to the server; If it is determined that the resource transfer is abnormal, then determine whether the network connection is abnormal; If it is determined that the network connection is abnormal, continue to execute the first retry strategy; If it is determined that the network connection is normal and it is determined that the resource transfer retry interface needs to be retried, the second retry strategy is continued to be executed.

8. The method according to any one of claims 4 to 7, characterized in that: The resource transfer retry interface is also used to count the real-time traffic of initiating resource transfer to the server. If the real-time traffic is greater than a preset fourth threshold, a call failure message is returned to the terminal that subsequently initiates resource transfer to the server.

9. A resource transfer device, characterized in that: include: a transfer initiating module, configured to, in response to a resource transfer operation initiated for a target resource transfer scenario, call a resource transfer interface corresponding to the target resource transfer scenario to initiate resource transfer to a server; An information receiving module, configured to receive information returned by the resource transfer interface or the server; a policy acquisition module configured to, if a resource transfer exception is determined based on the information, determine a cause of the exception based on the information, and acquire a target processing policy that matches the cause of the exception, the target processing policy including interface information of a target processing interface, the target processing interface being an interface corresponding to the target resource transfer scenario and different from the resource transfer interface; The target interface calling module is used to call the target processing interface according to the target processing strategy to obtain a calling result.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory, wherein: The processor executes the computer program to implement the resource transfer method according to any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the resource transfer method according to any one of claims 1 to 8 is implemented.

12. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the resource transfer method according to any one of claims 1 to 8 is implemented.

Images