Business processing method and device based on mobile payment, equipment, medium and product

Abstract

The invention discloses a service processing method, device and equipment based on mobile payment, a medium and a product. The invention relates to the technical field of computers. The method comprises the steps of obtaining a request parameter from a target transaction request of a target transaction service sent by a target access party, determining a target configuration identifier according to a target payment channel and a target payment scene in the request parameter, and searching a target configuration item corresponding to the target configuration identifier from a configuration file stored in a preset cache, wherein the target configuration item comprises configuration items corresponding to different configuration identifiers respectively, the configuration items comprise a preset transaction code and a preset message structure corresponding to the preset transaction code, performing message interaction with an online banking side based on the preset transaction code in the target configuration item, and responding to the target transaction request according to a message interaction result. The preset message structure is used for message assembly and / or message analysis. By adopting the technical scheme, the service stability can be enhanced, the maintenance cost can be reduced, and the access timeliness of the access party can be improved.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of computer technology, and in particular, to a business processing method, device, equipment, medium and product based on mobile payment. Background Art

[0002] In modern payment scenarios, mobile payment has developed into a mainstream payment method, but with the rapid development of mobile payment technology, payment scenarios are constantly changing.

[0003] At present, the overall mobile payment logic is implemented in a hard-coded way on the business side. When a new docking channel is needed, it needs to be adapted by adding a new interface, and when the downstream changes, it also needs to be adapted by adjusting the code. The existing solution has poor flexibility and is more challenging for developers to understand the business. In changing scenarios, frequent code adjustments increase the instability of the overall service, and the development of new interfaces takes a certain amount of time, which is difficult to ensure timeliness. In addition, with the changes in personnel or engineering maintenance teams and daily business iterations, different coding styles and coding levels are mixed. The maintenance of a large number of hard-coded interfaces often leads to an exponential increase in the difficulty of overall service maintenance and high maintenance costs. Summary of the invention

[0004] The embodiments of the present invention provide a mobile payment-based business processing method, device, equipment, storage medium and product, which can optimize the existing mobile payment-based business processing solution.

[0005] In a first aspect, an embodiment of the present invention provides a mobile payment-based service processing method, which is applied to a mobile payment-based service side, including:

[0006] Acquire request parameters from a target transaction request of a target transaction service sent by a target access party, wherein the request parameters include a target payment channel and a target payment scenario, the target payment channel is used to indicate a connection method between the target access party and the service side, and the target payment scenario is used to indicate a payment method for a target user side to pay the target access party;

[0007] Determine a target configuration identifier according to the target payment channel and the target payment scenario;

[0008] Searching for a target configuration item corresponding to the target configuration identifier from a configuration file stored in a preset cache, wherein the configuration file is configured by a management side, the configuration file includes configuration items corresponding to different configuration identifiers, and the configuration items include a preset transaction code and a preset message structure corresponding to the preset transaction code;

[0009] Based on the preset transaction code in the target configuration item, message interaction is performed with the online banking side, and the target transaction request is responded to according to the message interaction result, wherein the preset message structure in the target configuration item is used for message assembly and / or message parsing in the process of message interaction with the online banking side.

[0010] In a second aspect, an embodiment of the present invention further provides a mobile payment-based service processing device, which is configured on a mobile payment-based service side and includes:

[0011] A request parameter acquisition module, used to acquire request parameters from a target transaction request of a target transaction service sent by a target access party, wherein the request parameters include a target payment channel and a target payment scenario, wherein the target payment channel is used to indicate a connection method between the target access party and the service side, and the target payment scenario is used to indicate a payment method for a target user side to pay the target access party;

[0012] A target configuration identifier determination module, used to determine a target configuration identifier according to the target payment channel and the target payment scenario;

[0013] a target configuration item search module, configured to search for a target configuration item corresponding to the target configuration identifier from a configuration file stored in a preset cache, wherein the configuration file is configured by the management side, the configuration file includes configuration items corresponding to different configuration identifiers, and the configuration items include a preset transaction code and a preset message structure corresponding to the preset transaction code;

[0014] A message interaction module is used to perform message interaction with the online banking side based on the preset transaction code in the target configuration item, and respond to the target transaction request according to the message interaction result, wherein the preset message structure in the target configuration item is used for message assembly and / or message parsing in the process of message interaction with the online banking side.

[0015] In a third aspect, an embodiment of the present invention further provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, a business processing method based on mobile payment as described in any one of the embodiments of the present invention is implemented.

[0016] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a business processing method based on mobile payment as described in any one of the embodiments of the present invention.

[0017] In a fifth aspect, an embodiment of the present invention further provides a computer program product, including a computer program, which, when executed by a processor, implements a business processing method based on mobile payment as described in any one of the embodiments of the present invention.

[0018] The mobile payment-based business processing solution provided in the embodiment of the present invention is applied to the business side based on mobile payment, obtains request parameters from a target transaction request of a target transaction business sent by a target access party, determines a target configuration identifier according to a target payment channel and a target payment scenario in the request parameters, searches for a target configuration item corresponding to the target configuration identifier from a configuration file stored in a preset cache, the configuration file is configured by a management side, and includes configuration items corresponding to different configuration identifiers, the configuration items include preset transaction codes and preset message structures corresponding to the preset transaction codes, performs message interaction with an online banking side based on the preset transaction codes in the target configuration items, and responds to the target transaction request according to the message interaction result, and the preset message structure in the target configuration item is used for message assembly and / or message parsing in the process of message interaction with the online banking side. By adopting the above technical solution, the management side configures the transaction code and message structure in advance for different payment channels and different payment scenarios. When processing the access party's request, the business side reads the target configuration items corresponding to the request parameters in the cached configuration file, and uses the target configuration items to flexibly implement the payment process, thereby avoiding the frequent adjustment of the code caused by the existing hard-coding solution and increasing the instability of the overall service, thereby improving the service stability, facilitating the reduction of maintenance costs, and improving the timeliness of access for new access parties. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for use in the embodiments are briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without creative work.

[0020] Figure 1 A flowchart of a mobile payment-based business processing method provided by an embodiment of the present invention;

[0021] Figure 2 A flowchart of another mobile payment-based business processing method provided by an embodiment of the present invention;

[0022] Figure 3 A schematic diagram of a business processing process provided by an embodiment of the present invention;

[0023] Figure 4 A schematic diagram of the structure of a mobile payment-based service processing device provided by an embodiment of the present invention;

[0024] Figure 5 It is a structural schematic diagram of an electronic device for implementing the business processing method based on mobile payment according to an embodiment of the present invention. DETAILED DESCRIPTION

[0025] The present invention will be further described in detail below in conjunction with the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are only used to explain the present invention, rather than to limit the present invention. It should also be noted that, for ease of description, only parts related to the present invention, rather than all structures, are shown in the accompanying drawings.

[0026] It should be noted that similar numbers and letters represent similar items in the following figures. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. At the same time, in the description of the present invention, the terms "first", "second", etc. are only used to distinguish the description and cannot be understood as indicating or implying relative importance. The acquisition, storage, use, processing, etc. of data in the technical solution of this application comply with the relevant provisions of national laws and regulations. It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned, and they should be regarded as exemplary. The purpose is only to illustrate the feasibility of the implementation of the technical solution of this application, but it does not mean that the applicant has or will necessarily use the solution.

[0027] Figure 1 A flowchart of a business processing method based on mobile payment is provided for an embodiment of the present invention. The embodiment of the present disclosure is applicable to the situation where the business side based on mobile payment processes the payment process related requests of the access party. The method can be executed by a business processing device based on mobile payment, and the device can be implemented in the form of software and / or hardware. Optionally, it can be implemented by an electronic device, which can be a server or other device configured as a business side based on mobile payment.

[0028] like Figure 1 As shown, the method includes:

[0029] Step 101: Obtain request parameters from a target transaction request of a target transaction service sent by a target access party, wherein the request parameters include a target payment channel and a target payment scenario, the target payment channel is used to indicate a connection method between the target access party and the service side, and the target payment scenario is used to indicate a payment method for a target user side to pay the target access party.

[0030] In the embodiment of the present invention, the business side based on mobile payment can be understood as a service end in a financial institution (such as a bank) system for connecting with the access party for mobile payment business, which can be implemented by a distributed system. The access party can be a payment system used by a merchant or a business, which can also be called a merchant system. The merchant system is generally developed by a third party commissioned by the merchant. The merchant system needs to access the business side to obtain relevant services in the mobile payment business provided by banks and other financial institutions. The merchant systems of different merchants are generally developed independently. Banks need to configure corresponding payment channels for different access parties. The payment channel is used to indicate the connection method between the access party and the business side. There can be many types of payment channels, such as applications (Application, APP), web pages (such as H5 pages) or mini programs, etc. For the same type of payment channels, different access parties also correspond to different payment channels. For example, access party a and access party b both connect with the business side through mini programs, but because the merchant system is independently developed, the specific implementation of the mini program is different, so it also corresponds to different payment channels. When a user uses a mobile device to make a payment at a merchant, the merchant can collect the payment through the merchant system. Generally, the user is supported to choose the payment method they are accustomed to, that is, to choose a suitable third-party payment system for payment. Different third-party payment systems correspond to different payment methods, that is, different third-party payment systems can correspond to different payment scenarios.

[0031] Exemplarily, the target access party may be the access party that currently sends a transaction request to the business side, and the transaction request for the target transaction business sent is recorded as the target transaction request. The target transaction business may be any transaction business based on mobile payment. The request parameters in the target transaction request include the current payment channel (recorded as the target payment channel) and the current payment scenario (recorded as the target payment scenario), wherein the target payment channel may exist in the request parameters in the form of a channel identifier (such as a channel number), and the target payment scenario may exist in the request parameters in the form of a scenario identifier (such as a scenario number).

[0032] In a specific application scenario, assuming that the target user buys a coat in clothing store A and chooses to pay through third-party payment system B, the merchant system of clothing store A generates a target transaction request based on the channel identifier of the payment channel pre-configured by the business side and the scenario identifier of the third-party payment system B, and sends it to the business side. The business side can then receive the target transaction request and obtain the request parameters therein.

[0033] Optionally, the request parameters may also include transaction information. The transaction information may include, for example, the business identifier of the target transaction business, the payment amount or the transaction time, etc. The business side may record the transaction information.

[0034] Step 102: Determine a target configuration identifier according to the target payment channel and the target payment scenario.

[0035] Exemplarily, the configuration identifier can be represented by a combination of a channel identifier and a scenario identifier. After obtaining the target payment channel and the target payment scenario from the target transaction request, the target configuration identifier is determined according to the corresponding combination of the target channel identifier and the target scenario identifier.

[0036] Step 103: searching for a target configuration item corresponding to the target configuration identifier from a configuration file stored in a preset cache, wherein the configuration file is configured by a management side, the configuration file includes configuration items corresponding to different configuration identifiers, and the configuration items include a preset transaction code and a preset message structure corresponding to the preset transaction code.

[0037] Exemplarily, the management side sets corresponding configuration items for different configuration identifiers, that is, for different payment scenarios and combinations of different payment scenarios, corresponding configuration items are set respectively. Each configuration item includes a preset transaction code corresponding to the configuration identifier and a preset message structure corresponding to the preset transaction code. The preset transaction code is a transaction code set by the management side for the configuration identifier. The transaction code can be understood as an interface identifier of an interface for message interaction with the online banking side. The preset transaction code can include, for example, a payment transaction code and a query transaction code. For each preset transaction code, a corresponding message structure for message interaction can be set, which is recorded as a preset message structure. The preset message structure can include, for example, a basic message structure and a payment status response message structure. The basic message structure can be used to construct a message structure of a basic message such as a payment request message or a payment status query message; the payment status response message structure can include a success message structure, a failure message structure, and a processing message structure, which can be used to parse the online banking response message returned by the online banking side for the payment status query message.

[0038] In the disclosed embodiment, compared with the hard-coded solution in the prior art, after receiving a transaction request, it is necessary to determine the configuration identifier and obtain the corresponding configuration item. In order to improve the efficiency of transaction request processing, the configuration file is stored in a preset cache. The configuration file can be directly written into the preset cache by the management side after generating the configuration file, or the management side can first write the configuration file into the preset database after generating the configuration file, and then the business side obtains the configuration file from the preset database and writes it into the preset cache in a scheduled or real-time manner. Optionally, the preset cache can be a local application cache of the business side. If the business side is implemented based on a distributed system, the preset cache can be an application shared cache, etc., which is not specifically limited. Optionally, the business side and the management side act as the server of the banking system, and the preset cache can also be a shared cache of the business side and the management side.

[0039] Step 104: perform message interaction with the online banking side based on the preset transaction code in the target configuration item, and respond to the target transaction request according to the message interaction result, wherein the preset message structure in the target configuration item is used for message assembly and / or message parsing in the process of performing message interaction with the online banking side.

[0040] Exemplarily, the transaction request sent by the access party to the business side may include a payment request or a payment status query request, etc. After the target configuration item is queried, the required preset transaction code and the preset message structure corresponding to the preset transaction code can be read from the target configuration item according to the specific transaction request type, and the message is assembled based on the read preset message structure. The assembled message is sent to the online banking side by calling the interface corresponding to the read preset transaction code. After receiving the response message returned by the online banking side, the response message is parsed according to the read preset message structure, and then the message interaction result for responding to the target transaction request is obtained, and then the message interaction result is used to interact with the access party to respond to the target transaction request.

[0041] The mobile payment-based business processing method provided in an embodiment of the present invention is applied to a business side based on mobile payment, obtains request parameters from a target transaction request of a target transaction business sent by a target access party, determines a target configuration identifier according to a target payment channel and a target payment scenario in the request parameters, searches for a target configuration item corresponding to the target configuration identifier from a configuration file stored in a preset cache, the configuration file is configured by a management side, and includes configuration items corresponding to different configuration identifiers, the configuration items include preset transaction codes and preset message structures corresponding to the preset transaction codes, performs message interaction with an online banking side based on the preset transaction codes in the target configuration items, and responds to the target transaction request according to the message interaction result, and the preset message structure in the target configuration item is used for message assembly and / or message parsing in the process of message interaction with the online banking side. By adopting the above technical solution, the management side configures the transaction code and message structure in advance for different payment channels and different payment scenarios. When processing the access party's request, the business side reads the target configuration items corresponding to the request parameters in the cached configuration file, and uses the target configuration items to flexibly implement the payment process, avoiding the frequent code adjustments caused by the existing hard-coding solution and increasing the instability of the overall service, which is convenient for reducing maintenance costs and improving the timeliness of access for new access parties.

[0042] In some embodiments, the target transaction request includes a target payment status query request, the preset transaction code includes a preset query transaction code, the preset message structure includes a basic message structure and a payment status response message structure, and the payment status response message structure includes a success message structure, a failure message structure, and a processing message structure. Wherein, the message interaction with the online banking side based on the preset transaction code in the target configuration item includes: using the basic message structure corresponding to the preset query transaction code in the target configuration item to assemble the target payment status query message; based on the preset query transaction code in the target configuration item, sending the target payment status query message to the online banking side; receiving the online banking response message corresponding to the target payment status query message returned by the online banking side; using the payment status response message structure corresponding to the preset query transaction code in the target configuration item, parsing the online banking response message corresponding to the target payment status query message to obtain the online banking payment result, wherein the online banking payment result includes payment success, payment failure, and payment processing, and the message interaction result includes the online banking payment result. The advantage of this setting is that when the target transaction request is a payment status query request, the payment status query message can be assembled according to the basic message structure in the target configuration item, and the payment status query message can be sent by calling the interface corresponding to the query transaction code in the target configuration item. Finally, the online banking response message can be quickly and accurately parsed according to the payment status response message structure in the target configuration item, thereby obtaining an accurate online banking payment result and improving the flexibility of payment status query.

[0043] For example, when the online banking side modifies the query transaction code and / or the structure of the corresponding network response message for a certain payment channel or a certain payment scenario, the corresponding configuration items can be modified through the management side without changing the code, so that the modification can take effect quickly and ensure the stability of the overall mobile payment service.

[0044] Figure 2 A flowchart of another mobile payment-based business processing method provided by an embodiment of the present invention is optimized based on the above optional embodiments, and the preset query transaction code includes a preferred query transaction code and an alternative query transaction code. Figure 2 As shown, the method may include:

[0045] Step 201: Obtain request parameters from a target transaction request of a target transaction service sent by a target access party, wherein the target transaction request includes a target payment status query request, and the request parameters include a target payment channel and a target payment scenario.

[0046] Step 202: Determine a target configuration identifier according to a target payment channel and a target payment scenario.

[0047] Step 203: search for a target configuration item corresponding to the target configuration identifier from a configuration file stored in a preset cache, wherein the configuration item includes a preset query transaction code and a basic message structure and a payment status response message structure corresponding to the preset query transaction code, and the preset query transaction code includes a preferred query transaction code and an alternative query transaction code.

[0048] Exemplarily, the preferred query transaction code can be used to query the payment status of all preset payment scenarios corresponding to a preset payment channel, and the corresponding interface is equivalent to the unified general query interface provided by the online banking side; the alternative query transaction code can be used to query the payment status of a single payment scenario corresponding to a certain payment channel, and the corresponding interface is equivalent to the dedicated query interface provided by the online banking side that can penetrate into the third-party payment system. The general query interface corresponds to the local database on the online banking side, and the payment status data corresponding to different payment channels needs to be synchronized to the local database. However, due to the possibility of delay or failure in data synchronization, the corresponding data may not exist in the local database. In this case, the relevant data in the corresponding third-party payment system can be queried through the dedicated query interface, and the corresponding payment status can be quickly obtained.

[0049] Step 204: assemble a first payment status query message using the basic message structure corresponding to the preferred query transaction code in the target configuration item.

[0050] The target payment status query message includes a first payment status query message. Exemplarily, when performing a payment status query, the payment status is first queried based on the preferred query transaction code to prioritize the consistency of the query result with the data in the local database of the online banking side.

[0051] Step 205: Based on the preferred query transaction code in the target configuration item, a first payment status query message is sent to the online banking side.

[0052] Exemplarily, the first payment status query message is sent to the online banking side by calling an interface corresponding to the preferred query transaction code on the online banking side.

[0053] Step 206: Receive a first online banking response message corresponding to the first payment status query message returned by the online banking side.

[0054] Exemplarily, after receiving the first payment status query message, the interface corresponding to the preferred query transaction code on the online banking side queries the payment status in the local database according to the first payment status query message, and generates a first online banking response message according to the query result.

[0055] Step 207: using the payment status response message structure corresponding to the preferred query transaction code in the target configuration item, parse the first online banking response message to obtain the first online banking payment result.

[0056] Exemplarily, the payment status response message structure includes a success message structure, a failure message structure and a processing message structure. These three message structures can be used in turn to parse the first online banking response message. If the parsing is successful using a certain message structure, the payment status corresponding to the message structure can be determined as the parsing result. For example, if the first online banking response message is parsed using the success message structure and the parsing is successful, the payment status is payment success, that is, the first online banking payment result is payment success.

[0057] Step 208: If the result of the first online banking payment is payment in progress, a basic message structure corresponding to the alternative query transaction code in the target configuration item is used to assemble a second payment status query message.

[0058] Exemplarily, if the first online banking response message is parsed successfully using the processing message structure, the payment status is processing, that is, the first online banking payment result is payment processing, indicating that it is temporarily impossible to determine whether the payment is successful. The basic message structure corresponding to the alternative query transaction code in the target configuration item can be used to assemble the second payment status query message, and then the query is performed through the dedicated query interface corresponding to the alternative query transaction code to improve the query efficiency.

[0059] Optionally, if the first online banking payment result is payment processing, and the time interval from the first sending of the first payment status query message to the online banking side is less than a preset time length (such as 10 seconds), the first payment status query message can be sent to the online banking side again. If the above time interval is greater than or equal to the preset time length, the basic message structure corresponding to the alternative query transaction code in the target configuration item is used to assemble the second payment status query message.

[0060] Optionally, the configuration item also includes a preset error code list; wherein the method further includes: if the first online banking payment result obtained by parsing the message is a payment failure, obtaining a target error code corresponding to the first online banking payment result, wherein the error code is used to indicate the type of payment failure; if the target error code exists in the preset error code list in the target configuration item, determining that the first online banking payment result is payment processing. The advantage of such a setting is that it can improve the fault tolerance of the business side and improve the accuracy of the payment status query result.

[0061] For example, since the online banking side generally determines whether a payment has failed based on a variety of determination conditions, if a certain determination condition is not met, it can be determined as a failure. Different determination conditions correspond to different payment failure types, and some payment failure types (recorded as preset failure types) may be considered as ignorable failure types as the business logic of the online banking side changes. For example, although the determination condition corresponding to the preset failure type is not met, it will not be considered a payment failure. The online banking side can provide the preset failure type to the business side, so that the business side can continue to determine whether it is a preset failure type when the message parsing result is a payment failure. If it is a preset failure type, it can still be considered as payment processing rather than a payment failure. In an embodiment of the present invention, a preset error code list is included in the configuration item, and the error code in the preset error code list is used to represent the above-mentioned preset failure type, so that the preset failure type that needs to be ignored can be dynamically updated by configuring the preset error code list.

[0062] Optionally, if the target error code does not exist in the preset error code list in the target configuration item, it is determined that the first online banking payment result is a payment failure.

[0063] Step 209: Send a second payment status query message to the online banking side based on the alternative query transaction code in the target configuration item.

[0064] Exemplarily, by calling the interface corresponding to the alternative query transaction code on the online banking side, a second payment status query message is sent to the online banking side.

[0065] Step 210: Receive a second online banking response message corresponding to the second payment status query message returned by the online banking side.

[0066] Step 211: Use the payment status response message structure corresponding to the alternative query transaction code in the target configuration item to parse the second online banking response message to obtain the second online banking payment result.

[0067] Optionally, there are multiple alternative query transaction codes; wherein, the method further includes: if the online banking payment result corresponding to the first alternative query transaction code is payment processing, the basic message structure corresponding to the second alternative query transaction code is used to assemble a new payment status query message, and based on the second alternative query transaction code, the new payment status query message is sent to the online banking side until the online banking payment result corresponding to the new payment status query message is payment success or payment failure, or until all alternative query transaction codes in the target configuration item have been called for the target payment status query request, wherein the second alternative query transaction code is an alternative transaction code that has not been currently called for the target payment status query request. The advantage of such a setting is that by increasing the number of alternative query transaction codes, the query success rate of the payment status can be further improved.

[0068] Among them, the first alternative query transaction code can be any alternative query transaction code currently used, and the online banking payment result corresponding to the first alternative query transaction code can specifically be the basic message structure corresponding to the first alternative query transaction code, assembling the corresponding payment status query message, and sending the payment status query message to the online banking side based on the first alternative query transaction code. The online banking payment result corresponding to the payment status query message returned by the online banking side is received. Optionally, multiple alternative query transaction codes in the target configuration item are stored in a preset order. When the alternative query transaction code is needed, the alternative query transaction code is obtained in sequence in the preset order. Assuming that there are three alternative query transaction codes, which are respectively recorded as alternative query transaction code a, alternative query transaction code b and alternative query transaction code c, alternative query transaction code a is first obtained as the first alternative query transaction code. If the online banking payment result corresponding to alternative query transaction code a is payment processing, the basic message structure corresponding to alternative query transaction code b (second alternative query transaction code) is used to assemble a new payment status query message, and message interaction is performed with the online banking side to obtain the corresponding online banking payment result. If the online banking payment result is success or failure at this time (and the corresponding target error code does not exist in the preset error code list), the query can be stopped. If it is processing, the alternative query transaction code c can be regarded as the new second alternative query transaction code and the query can continue.

[0069] Step 212: respond to the target payment status query request according to the second online banking payment result.

[0070] The mobile payment-based business processing method provided by the embodiment of the present invention configures transaction codes and message structures in advance for combinations of different payment channels and different payment scenarios through the management side, wherein the transaction code includes a preferred query transaction code and an alternative query transaction code for querying the payment status. When processing the payment status query request of the access party, the business side reads the target configuration item corresponding to the request parameter in the cached configuration file, and first uses the preferred query transaction code and the corresponding message structure in the target configuration item to interact with the online banking side. If the queried payment result is in processing, the alternative query transaction code and the corresponding message structure can be used to interact with the online banking side, thereby effectively improving the query efficiency and query success rate of the payment status, and ensuring the consistency of the payment status query results in distributed scenarios.

[0071] In some embodiments, it also includes: for each configuration item in the configuration file, after each preset query transaction code in the current configuration item is called within a preset time period, the online banking payment result returned by the online banking side is the proportion of successful payment and failed payment, and the ranking result of each preset query transaction code corresponding to the current configuration item is determined according to the proportion; feedback of configuration suggestion information to the management side, wherein the configuration suggestion information includes the ranking results corresponding to each configuration item in the configuration file, and the configuration suggestion information is used for the management side to update the preferred query transaction code in each configuration item in the configuration file. The advantage of such a setting is that the configuration suggestion information is fed back to the management side according to the statistics after each preset query transaction code is called, so that the management side can more reasonably and timely adjust the preferred query transaction code, which is conducive to further improving the efficiency and success rate of payment status query.

[0072] Exemplarily, after a preset query transaction code (including the preferred query transaction code and the alternative query transaction code) is called, if the online banking payment result returned by the online banking side is payment success or payment failure, it means that the final state result of the payment result can be queried through the preset query transaction code, and no other query transaction code is needed for subsequent query, which is equivalent to the query success through the preset query transaction code. The preset time period can be set according to actual needs, such as 0:00 to 24:00 every day, or from Monday to Sunday, etc. If the preset query transaction code is called N times within the preset time period, among which the online banking payment results returned by the online banking side n times are payment success or payment failure, the proportion is n / N. Exemplarily, for all preset query transaction codes corresponding to the current configuration item, after being sorted in descending order according to the above proportion, the sorting result is returned to the management side. The sorting result can be a complete sorting or the preset query transaction code ranked first. If the preset query transaction code ranked first is not the current preferred preset query transaction code, the management side can update the preferred preset query transaction code to the preset query transaction code ranked first.

[0073] In some embodiments, the target transaction request includes a target payment request, the preset transaction code includes a preset payment transaction code, and the preset message structure includes a payment message structure; wherein the message interaction with the online banking side based on the preset transaction code in the target configuration item includes: assembling the target payment request message using the payment message structure corresponding to the preset payment transaction code in the target configuration item; and sending the target payment request message to the online banking side based on the preset payment transaction code in the target configuration item. The advantage of such a setting is that when the target transaction request is a payment request, the payment request message can be assembled according to the payment message structure corresponding to the preset payment transaction code in the target configuration item, and the payment request message can be sent by calling the interface corresponding to the preset payment transaction code, thereby improving the flexibility of assembling and sending the payment request message.

[0074] In some embodiments, the configuration item also includes a channel message structure, wherein the channel message structure is used for message assembly and / or message parsing during message interaction with the access party. The advantage of such a setting is that the system changes of the access party can be quickly adapted.

[0075] For example, as mentioned above, the merchant system is generally developed by a third party commissioned by the merchant. If the merchant needs to replace the entrusted third party or the merchant system needs to be upgraded, causing the message structure of the access party's system to change, the channel message structure in the configuration item can be modified to quickly adapt to the access party's system changes without reconfiguring the payment channel for the access party, thereby enhancing the robustness of the business side.

[0076] In some embodiments, the business side is implemented based on a distributed system; the method further includes: in response to a preset timed task in the distributed system being triggered, reading the latest configuration file from a preset database, and writing the latest configuration file into the preset cache, so as to overwrite the obsolete configuration file in the preset cache with the latest configuration file, wherein the configuration file in the preset database is written by the management side. The advantage of such a setting is that the configuration file configured by the management side is only written into the database, and the configuration file is read and written into the cache by the distributed timed task on the business side, rather than being directly written into the cache by the management side, thereby improving the security of the configuration file. In addition, in a distributed scenario, the preset timed tasks in the distributed system can be used to accurately implement the timed update of the configuration file in the preset cache.

[0077] Exemplarily, the distributed system includes a preset number of application nodes. When the preset timed task is triggered, the target application node can be determined from the preset number of application nodes, and the configuration file is updated through the target application node based on the distributed lock, so as to avoid resource conflicts caused by multiple application nodes executing the same configuration file update task at the same time. Optionally, in response to the preset timed task in the distributed system being triggered, the latest configuration file is read from the preset database, including: in response to the preset timed task in the distributed system being triggered, if it is determined that the distributed lock corresponding to the configuration file update task is held, the latest configuration file is read from the preset database.

[0078] In some embodiments, it also includes: in response to the preset call instruction of the management side, reading the latest configuration file from the preset database, and writing the latest configuration file into the preset cache, so as to use the latest configuration file to overwrite the old configuration file in the preset cache, wherein the management side sends the preset call instruction to the business side after modifying the configuration file. The advantage of such a setting is that an interface is provided to the management side, so that after the management side updates the configuration file, it can implement instant update of the configuration by calling the interface, thereby improving the timeliness of the configuration update.

[0079] Figure 3 A schematic diagram of a business processing process provided by an embodiment of the present invention, such as Figure 3 As shown, the management side configures payment channels and payment scenarios, and configures configuration items for each group of payment channels and payment scenarios, including configuration of payment transaction codes, preferred query transaction codes, alternative query transaction codes, basic message structure, success message structure, failure message structure, processing message structure and error code list. After the configuration is completed, each configuration item can be in a pending state. If the activation event of a configuration item is triggered by the management side, the pending state is changed to the enabled state. The configuration file includes configuration items in the enabled state, and the configuration file is written to the database. The business side reads the configuration file from the database through a scheduled task or in real time, and updates it to the cache. When receiving a transaction request from the access party, the configuration is queried from the cache, the call corresponding to the transaction code is executed, and the message is parsed according to the message structure in the configuration item, and then the subsequent business processing on the business side is performed.

[0080] Optionally, the management side may provide a front-end page related to the configuration items, and the merchant may intuitively view the configuration contents in the configuration file through the front-end page, so as to manage or optimize the merchant system more efficiently.

[0081] Figure 4 A schematic diagram of a mobile payment-based service processing device provided by an embodiment of the present invention is shown in FIG. Figure 4 As shown, the device comprises:

[0082] The request parameter acquisition module 401 is used to acquire request parameters from the target transaction request of the target transaction service sent by the target access party, wherein the request parameters include a target payment channel and a target payment scenario, the target payment channel is used to indicate the docking method between the target access party and the service side, and the target payment scenario is used to indicate the payment method for the target user side to pay the target access party;

[0083] A target configuration identifier determination module 402, configured to determine a target configuration identifier according to the target payment channel and the target payment scenario;

[0084] The target configuration item search module 403 is used to search for the target configuration item corresponding to the target configuration identifier from the configuration file stored in the preset cache, wherein the configuration file is configured by the management side, the configuration file includes configuration items corresponding to different configuration identifiers, and the configuration items include a preset transaction code and a preset message structure corresponding to the preset transaction code;

[0085] The message interaction module 404 is used to perform message interaction with the online banking side based on the preset transaction code in the target configuration item, and respond to the target transaction request according to the message interaction result, wherein the preset message structure in the target configuration item is used for message assembly and / or message parsing in the process of message interaction with the online banking side.

[0086] The mobile payment-based business processing device provided in the embodiment of the present invention configures the transaction code and message structure in advance for the combination of different payment channels and different payment scenarios through the management side. When processing the access party's request, the business side reads the target configuration items corresponding to the request parameters in the cached configuration file, and uses the target configuration items to flexibly implement the payment process, avoiding the frequent adjustment of the code caused by the existing hard-coding solution and increasing the instability of the overall service, which is convenient for reducing maintenance costs and improving the timeliness of access for new access parties.

[0087] Optionally, the target transaction request includes a target payment status query request, the preset transaction code includes a preset query transaction code, the preset message structure includes a basic message structure and a payment status response message structure, and the payment status response message structure includes a success message structure, a failure message structure, and a processing message structure;

[0088] Wherein, the message interaction module includes:

[0089] A first message assembling unit, configured to assemble a target payment status query message using a basic message structure corresponding to the preset query transaction code in the target configuration item;

[0090] A first message sending unit, configured to send the target payment status query message to the online banking side based on the preset query transaction code in the target configuration item;

[0091] A first message receiving unit, configured to receive an online banking response message corresponding to the target payment status query message returned by the online banking side based on the preset query transaction code in the target configuration item;

[0092] The first message parsing unit is used to adopt the payment status response message structure corresponding to the preset query transaction code in the target configuration item, and parse the online banking response message corresponding to the target payment status query message to obtain the online banking payment result, wherein the online banking payment result includes payment success, payment failure and payment processing, and the message interaction result includes the online banking payment result.

[0093] Optionally, the preset query transaction code includes a preferred query transaction code and an alternative query transaction code; wherein the first message assembling unit is used to: adopt the basic message structure corresponding to the preferred query transaction code in the target configuration item to assemble a first payment status query message, wherein the target payment status query message includes the first payment status query message;

[0094] Wherein, the first message receiving unit is used to: receive a first online banking response message corresponding to the first payment status query message returned by the online banking side;

[0095] The first message parsing unit is used to: adopt the payment status response message structure corresponding to the preferred query transaction code in the target configuration item to perform message parsing on the first online banking response message to obtain the first online banking payment result;

[0096] Wherein, the message interaction module also includes:

[0097] A second message assembling unit, configured to assemble a second payment status query message using a basic message structure corresponding to the alternative query transaction code in the target configuration item if the first online banking payment result is payment in progress;

[0098] A second message sending unit, configured to send the second payment status query message to the online banking side based on the alternative query transaction code in the target configuration item;

[0099] A second message receiving unit, configured to receive a second online banking response message corresponding to the second payment status query message returned by the online banking side;

[0100] The second message parsing unit is used to adopt the payment status response message structure corresponding to the alternative query transaction code in the target configuration item to perform message parsing on the second online banking response message to obtain a second online banking payment result.

[0101] Optionally, the configuration item also includes a preset error code list; wherein the device also includes:

[0102] an error code acquisition module, configured to acquire a target error code corresponding to the first online banking payment result if the first online banking payment result obtained through message parsing is payment failure, wherein the error code is used to indicate the type of payment failure;

[0103] The result determination module is used to determine that the first online banking payment result is payment processing if the target error code exists in the preset error code list in the target configuration item.

[0104] Optionally, the number of the candidate query transaction codes is multiple; wherein the device further includes:

[0105] A cyclic calling module is used for, if the online banking payment result corresponding to the first alternative query transaction code is payment processing, using the basic message structure corresponding to the second alternative query transaction code, assembling a new payment status query message, and sending the new payment status query message to the online banking side based on the second alternative query transaction code, until the online banking payment result corresponding to the new payment status query message is payment success or payment failure, or until all the alternative query transaction codes in the target configuration item have been called for the target payment status query request, wherein the second alternative query transaction code is an alternative transaction code that has not been currently called for the target payment status query request.

[0106] Optionally, the device further comprises:

[0107] A sorting module, for counting, for each configuration item in the configuration file, the percentage of successful payment and failed payment returned by the online banking side after each preset query transaction code in the current configuration item is called within a preset period of time, and determining the sorting result of each preset query transaction code corresponding to the current configuration item according to the percentage;

[0108] A configuration suggestion feedback module is used to feed back configuration suggestion information to the management side, wherein the configuration suggestion information includes the ranking results corresponding to each configuration item in the configuration file, and the configuration suggestion information is used for the management side to update the preferred query transaction code in each configuration item in the configuration file.

[0109] Optionally, the target transaction request includes a target payment request, the preset transaction code includes a preset payment transaction code, and the preset message structure includes a payment message structure; wherein the message interaction module includes:

[0110] A third message assembling unit, configured to assemble a target payment request message using the payment message structure corresponding to the preset payment transaction code in the target configuration item;

[0111] The third message sending unit is used to send the target payment request message to the online banking side based on the preset payment transaction code in the target configuration item.

[0112] Optionally, the configuration item also includes a channel message structure, wherein the channel message structure is used for message assembly and / or message parsing during message interaction with the access party.

[0113] Optionally, the service side is implemented based on a distributed system; and the device further includes:

[0114] A first configuration update module is used to respond to a preset timed task in a distributed system being triggered, read the latest configuration file from a preset database, and write the latest configuration file into the preset cache, so as to overwrite the obsolete configuration file in the preset cache with the latest configuration file, wherein the configuration file in the preset database is written by the management side.

[0115] Optionally, the device further comprises:

[0116] The second configuration update module is used to respond to the preset call instruction of the management side, read the latest configuration file from the preset database, and write the latest configuration file into the preset cache, so as to use the latest configuration file to overwrite the obsolete configuration file in the preset cache, wherein the management side sends the preset call instruction to the business side after modifying the configuration file.

[0117] The mobile payment-based business processing device provided in the embodiment of the present invention can execute the mobile payment-based business processing method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0118] Figure 5 A schematic diagram of the structure of an electronic device 10 that can be used to implement an embodiment of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices (such as helmets, glasses, watches, etc.) and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present invention described and / or required herein.

[0119] like Figure 5As shown, the electronic device 10 includes at least one processor 11, and a memory connected to the at least one processor 11, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., wherein the memory stores a computer program that can be executed by at least one processor, and the processor 11 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 12 or the computer program loaded from the storage unit 18 to the random access memory (RAM) 13. In the RAM 13, various programs and data required for the operation of the electronic device 10 can also be stored. The processor 11, the ROM 12, and the RAM 13 are connected to each other through a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0120] A number of components in the electronic device 10 are connected to the I / O interface 15, including: an input unit 16, such as a keyboard, a mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a disk, an optical disk, etc.; and a communication unit 19, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0121] The processor 11 may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The processor 11 executes the various methods and processes described above, such as a business processing method based on mobile payment.

[0122] In some embodiments, the business processing method based on mobile payment can be implemented as a computer program, which is tangibly contained in a computer-readable storage medium, such as a storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 10 via the ROM 12 and / or the communication unit 19. When the computer program is loaded into the RAM 13 and executed by the processor 11, one or more steps of the business processing method based on mobile payment described above can be performed. Alternatively, in other embodiments, the processor 11 can be configured to execute the business processing method based on mobile payment in any other appropriate manner (for example, by means of firmware).

[0123] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0124] Computer programs for implementing the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that when the computer program is executed by the processor, the functions / operations specified in the flow chart and / or block diagram are implemented. The computer program may be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a stand-alone software package, or entirely on a remote machine or server.

[0125] In the context of the present invention, a computer-readable storage medium may be a tangible medium that may contain or store a computer program for use by or in combination with an instruction execution system, device or equipment. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0126] To provide interaction with a user, the systems and techniques described herein may be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or trackball) through which the user can provide input to the electronic device. Other types of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form (including acoustic input, voice input, or tactile input).

[0127] The systems and techniques described herein may be implemented in a computing system that includes backend components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes frontend components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such backend components, middleware components, or frontend components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0128] A computing system may include a client and a server. The client and the server are generally remote from each other and usually interact through a communication network. The client and server relationship is generated by computer programs running on the corresponding computers and having a client-server relationship with each other. The server may be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system to solve the defects of difficult management and weak business scalability in traditional physical hosts and VPS services.

[0129] An embodiment of the present invention further provides a computer program product, including a computer program, which, when executed by a processor, implements a mobile payment-based business processing method as provided in any embodiment of the present application.

[0130] In the process of implementation, the computer program product can be written in one or more programming languages ​​or a combination thereof to perform the computer program code of the present invention, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (for example, using an Internet service provider to connect through the Internet).

[0131] The mobile payment-based business processing apparatus, device, storage medium and product provided in the above embodiments can execute the mobile payment-based business processing method provided in any embodiment of the present application, and have the corresponding functional modules and beneficial effects of executing the method. For technical details not described in detail in the above embodiments, please refer to the mobile payment-based business processing method provided in any embodiment of the present application.

[0132] Note that the above are only preferred embodiments of the present invention and the technical principles used. Those skilled in the art will understand that the present invention is not limited to the specific embodiments herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in more detail through the above embodiments, the present invention is not limited to the above embodiments, and may include more other equivalent embodiments without departing from the concept of the present invention, and the scope of the present invention is determined by the scope of the appended claims.

Claims

1. A business processing method based on mobile payment, characterized in that: Applied to the business side based on mobile payment, including: Acquire request parameters from a target transaction request of a target transaction service sent by a target access party, wherein the request parameters include a target payment channel and a target payment scenario, the target payment channel is used to indicate a connection method between the target access party and the service side, and the target payment scenario is used to indicate a payment method for a target user side to pay the target access party; Determine a target configuration identifier according to the target payment channel and the target payment scenario; Searching for a target configuration item corresponding to the target configuration identifier from a configuration file stored in a preset cache, wherein the configuration file is configured by a management side, the configuration file includes configuration items corresponding to different configuration identifiers, and the configuration items include a preset transaction code and a preset message structure corresponding to the preset transaction code; Based on the preset transaction code in the target configuration item, message interaction is performed with the online banking side, and the target transaction request is responded to according to the message interaction result, wherein the preset message structure in the target configuration item is used for message assembly and / or message parsing in the process of message interaction with the online banking side.

2. The method according to claim 1, characterized in that The target transaction request includes a target payment status query request, the preset transaction code includes a preset query transaction code, the preset message structure includes a basic message structure and a payment status response message structure, and the payment status response message structure includes a success message structure, a failure message structure, and a processing message structure; The message interaction with the online banking side based on the preset transaction code in the target configuration item includes: Using the basic message structure corresponding to the preset query transaction code in the target configuration item, assembling the target payment status query message; Based on the preset query transaction code in the target configuration item, sending the target payment status query message to the online banking side; Receiving an online banking response message corresponding to the target payment status query message returned by the online banking side; The payment status response message structure corresponding to the preset query transaction code in the target configuration item is adopted to parse the online banking response message corresponding to the target payment status query message to obtain the online banking payment result, wherein the online banking payment result includes payment success, payment failure and payment processing, and the message interaction result includes the online banking payment result.

3. The method according to claim 2, characterized in that The preset query transaction code includes a preferred query transaction code and an alternative query transaction code; Wherein, the basic message structure corresponding to the preset query transaction code in the target configuration item is adopted to assemble the target payment status query message, including: Using the basic message structure corresponding to the preferred query transaction code in the target configuration item, assembling a first payment status query message, wherein the target payment status query message includes the first payment status query message; The receiving of the online banking response message corresponding to the target payment status query message returned by the online banking side includes: receiving a first online banking response message corresponding to the first payment status query message returned by the online banking side; Wherein, using the payment status response message structure corresponding to the preset query transaction code in the target configuration item, parsing the online banking response message corresponding to the target payment status query message to obtain the online banking payment result, including: Using the payment status response message structure corresponding to the preferred query transaction code in the target configuration item, parsing the first online banking response message to obtain a first online banking payment result; Wherein, the method further comprises: If the first online banking payment result is payment in progress, assembling a second payment status query message using the basic message structure corresponding to the alternative query transaction code in the target configuration item; Based on the alternative query transaction code in the target configuration item, sending the second payment status query message to the online banking side; receiving a second online banking response message corresponding to the second payment status query message returned by the online banking side; The payment status response message structure corresponding to the alternative query transaction code in the target configuration item is adopted to parse the second online banking response message to obtain the second online banking payment result.

4. The method according to claim 3, characterized in that The configuration items also include a preset error code list; Wherein, the method further comprises: If the first online banking payment result obtained through message parsing is payment failure, obtaining a target error code corresponding to the first online banking payment result, wherein the error code is used to indicate the type of payment failure; If the target error code exists in the preset error code list in the target configuration item, it is determined that the first online banking payment result is payment in progress.

5. The method according to claim 3, characterized in that: The number of the candidate query transaction codes is multiple; Wherein, the method further comprises: If the online banking payment result corresponding to the first alternative query transaction code is payment processing, the basic message structure corresponding to the second alternative query transaction code is used to assemble a new payment status query message, and based on the second alternative query transaction code, the new payment status query message is sent to the online banking side until the online banking payment result corresponding to the new payment status query message is payment success or payment failure, or until all alternative query transaction codes in the target configuration item have been called for the target payment status query request, wherein the second alternative query transaction code is an alternative transaction code that has not been currently called for the target payment status query request.

6. The method according to claim 5, characterized in that Also includes: For each configuration item in the configuration file, after each preset query transaction code in the current configuration item is called within a preset period of time, the online banking payment result returned by the online banking side is the proportion of successful payment and failed payment, and the ranking result of each preset query transaction code corresponding to the current configuration item is determined according to the proportion; Feedback configuration suggestion information to the management side, wherein the configuration suggestion information includes the ranking results corresponding to each configuration item in the configuration file, and the configuration suggestion information is used for the management side to update the preferred query transaction code in each configuration item in the configuration file.

7. The method according to claim 1, characterized in that The target transaction request includes a target payment request, the preset transaction code includes a preset payment transaction code, and the preset message structure includes a payment message structure; The message interaction with the online banking side based on the preset transaction code in the target configuration item includes: Assembling a target payment request message using the payment message structure corresponding to the preset payment transaction code in the target configuration item; Based on the preset payment transaction code in the target configuration item, the target payment request message is sent to the online banking side.

8. The method according to claim 1, characterized in that The configuration item also includes a channel message structure, wherein the channel message structure is used for message assembly and / or message parsing during message interaction with the access party.

9. The method according to claim 1, characterized in that: The business side is implemented based on a distributed system; The method further comprises: In response to a preset scheduled task in a distributed system being triggered, the latest configuration file is read from a preset database, and the latest configuration file is written into the preset cache, so as to overwrite the obsolete configuration file in the preset cache with the latest configuration file, wherein the configuration file in the preset database is written by the management side.

10. The method according to claim 9, characterized in that Also includes: In response to a preset call instruction from the management side, the latest configuration file is read from a preset database, and the latest configuration file is written into the preset cache, so as to overwrite the obsolete configuration file in the preset cache with the latest configuration file, wherein the management side sends the preset call instruction to the business side after modifying the configuration file.

11. A business processing device based on mobile payment, characterized in that: Configured on the business side based on mobile payment, including: A request parameter acquisition module, used to acquire request parameters from a target transaction request of a target transaction service sent by a target access party, wherein the request parameters include a target payment channel and a target payment scenario, wherein the target payment channel is used to indicate a connection method between the target access party and the service side, and the target payment scenario is used to indicate a payment method for a target user side to pay the target access party; A target configuration identifier determination module, used to determine a target configuration identifier according to the target payment channel and the target payment scenario; a target configuration item search module, configured to search for a target configuration item corresponding to the target configuration identifier from a configuration file stored in a preset cache, wherein the configuration file is configured by the management side, the configuration file includes configuration items corresponding to different configuration identifiers, and the configuration items include a preset transaction code and a preset message structure corresponding to the preset transaction code; A message interaction module is used to perform message interaction with the online banking side based on the preset transaction code in the target configuration item, and respond to the target transaction request according to the message interaction result, wherein the preset message structure in the target configuration item is used for message assembly and / or message parsing in the process of message interaction with the online banking side.

12. The device according to claim 11, characterized in that The target transaction request includes a target payment status query request, the preset transaction code includes a preset query transaction code, the preset message structure includes a basic message structure and a payment status response message structure, and the payment status response message structure includes a success message structure, a failure message structure, and a processing message structure; Wherein, the message interaction module includes: A first message assembling unit, configured to assemble a target payment status query message using a basic message structure corresponding to the preset query transaction code in the target configuration item; A first message sending unit, configured to send the target payment status query message to the online banking side based on the preset query transaction code in the target configuration item; A first message receiving unit, configured to receive an online banking response message corresponding to the target payment status query message returned by the online banking side based on the preset query transaction code in the target configuration item; The first message parsing unit is used to adopt the payment status response message structure corresponding to the preset query transaction code in the target configuration item, and parse the online banking response message corresponding to the target payment status query message to obtain the online banking payment result, wherein the online banking payment result includes payment success, payment failure and payment processing, and the message interaction result includes the online banking payment result.

13. An electronic device, characterized in that: The method comprises a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the method according to any one of claims 1 to 10 when executing the computer program.

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

15. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the computer program implements the method according to any one of claims 1 to 10.

Images