Payment processing method and device, storage medium and electronic equipment

Abstract

The application discloses a payment processing method and device, a storage medium and an electronic device. It relates to the field of Internet of Things. The method comprises the following steps: acquiring a demand scenario type corresponding to a demand party, wherein the demand party has a payment demand with a financial institution; determining at least one target component in N preset functional processing components based on the demand scenario type, wherein N is a positive integer greater than or equal to 1, and the N functional processing components are components providing corresponding processing capabilities in a payment process between the demand party and the financial institution; and obtaining a target server for realizing the payment process between the demand party and the financial institution based on the at least one target component. Through the application, the problem of low efficiency of constructing a target server in the related art is solved.

Description

Technical Field

[0001] This application relates to the field of the Internet of Things, and more specifically, to a payment processing method, apparatus, storage medium, and electronic device. Background Technology

[0002] Currently, with the development of the internet, financial institutions urgently need to implement digital and intelligent online payment services in addition to traditional collection services. This has significantly increased the demand for server infrastructure for payment processing. Among related technologies, relying on manual development results in long development cycles, depends heavily on the subjective processing efficiency of technical personnel, and incurs high time and manpower costs for debugging. This makes it difficult to handle payment processing solutions that need to be launched and applied quickly, leading to unsatisfactory server construction efficiency.

[0003] There is currently no effective solution to the problem of unsatisfactory efficiency in building target servers in related technologies. Summary of the Invention

[0004] The main objective of this application is to provide a payment processing method, apparatus, storage medium, and electronic device to solve the problem of unsatisfactory efficiency in building target servers in related technologies.

[0005] To achieve the above objectives, according to one aspect of this application, a payment processing method is provided. The method includes: obtaining a demand scenario type corresponding to a demander, wherein there is a payment demand between the demander and a financial institution; based on the demand scenario type, determining at least one target component from a preset set of N functional processing components, wherein N is a positive integer greater than or equal to 1, and the N functional processing components are components that provide corresponding processing capabilities in the payment process between the demander and the financial institution; and based on the at least one target component, obtaining a target server for implementing the payment process between the demander and the financial institution.

[0006] To achieve the above objectives, according to another aspect of this application, a payment processing apparatus is provided. The apparatus includes: an acquisition module, configured to acquire a demand scenario type corresponding to a demander, wherein there is a payment demand between the demander and a financial institution; a determination module, configured to determine at least one target component from a preset set of N functional processing components based on the demand scenario type, wherein N is a positive integer greater than or equal to 1, and the N functional processing components are components that provide corresponding processing capabilities in the payment process between the demander and the financial institution; and a construction module, configured to obtain a target server for implementing the payment process between the demander and the financial institution based on the at least one target component.

[0007] To achieve the above objectives, according to another aspect of this application, a non-volatile storage medium is provided, the non-volatile storage medium storing a plurality of instructions adapted for loading by a processor and executing any one of the payment processing methods described herein.

[0008] This application employs the following steps: obtaining the demand scenario type corresponding to the demand party, wherein there is a payment demand between the demand party and the financial institution; based on the demand scenario type, determining at least one target component from a preset set of N functional processing components, where N is a positive integer greater than or equal to 1, and the N functional processing components are components that provide corresponding processing capabilities in the payment process between the demand party and the financial institution; based on the at least one target component, obtaining a target server for implementing the payment process between the demand party and the financial institution. This achieves the goal of improving the automation level of the target server by identifying demand scenarios and decomposing functional components, solving the problem of unsatisfactory efficiency in constructing target servers in related technologies. Thus, it achieves the effect of improving the construction efficiency of the target server. Attached Figure Description

[0009] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0010] Figure 1 This is a flowchart of an optional payment processing method provided according to an embodiment of this application;

[0011] Figure 2 This is a payment flowchart of an optional payment processing method provided according to an embodiment of this application;

[0012] Figure 3 This is a schematic diagram of an optional payment processing method provided according to an embodiment of this application; and

[0013] Figure 4 This is a schematic diagram of a payment processing device provided according to an embodiment of this application. Detailed Implementation

[0014] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0015] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0016] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0017] It should be noted that all information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) disclosed herein are information and data authorized by the user or fully authorized by all parties. For example, if an interface is set up between the target server and the requesting party or financial institution, a request to obtain the relevant information must be sent to the aforementioned requesting party or financial institution through the interface before obtaining the relevant information, and the relevant information can be obtained after receiving the consent information from the aforementioned requesting party or financial institution.

[0018] To address the aforementioned problems, this invention provides a payment processing method. Figure 1 This is a flowchart of the payment processing method provided according to the embodiments of this application, such as... Figure 1 As shown, the method includes the following steps:

[0019] Step S102: Obtain the demand scenario type corresponding to the demander, wherein there is a payment demand between the aforementioned demander and the financial institution.

[0020] Step S104: Based on the above-mentioned demand scenario type, at least one target component is determined from the preset N types of functional processing components, where N is a positive integer greater than or equal to 1, and the above-mentioned N types of functional processing components are components that provide corresponding processing capabilities in the payment process between the above-mentioned demand party and the above-mentioned financial institution.

[0021] Step S106: Based on the above-mentioned at least one target component, a target server is obtained for implementing the payment process between the above-mentioned demand party and the above-mentioned financial institution.

[0022] It's understandable that to create a target server that meets the client's needs, it's necessary to first identify the client's specific payment processing scenario. Different scenario types require different processing functionalities. Based on the scenario type, at least one target component is determined from a set of N pre-defined processing components. These N components provide the corresponding processing capabilities for the payment process between the client and the financial institution; they can be viewed as N processing components derived from breaking down the existing payment process. Once at least one target component is identified, the target server is constructed, enabling payment processing between the client and the financial institution. Through this process, based on the scenario type, the client's actual payment processing needs are identified, and the target component for building the target server is automatically selected from the pre-defined N processing components. This automates the target server construction process and improves efficiency.

[0023] The payment processing method provided in this application embodiment, through step S102, obtains the demand scenario type corresponding to the demand party, wherein there is a payment demand between the demand party and the financial institution; step S104, based on the demand scenario type, determines at least one target component from a preset set of N functional processing components, wherein N is a positive integer greater than or equal to 1, and the N functional processing components are components that provide corresponding processing capabilities in the payment process between the demand party and the financial institution; step S106, based on the at least one target component, obtains a target server, which is used to implement the payment process between the demand party and the financial institution. This achieves the goal of improving the automation level of the target server by identifying the demand scenario and decomposing functional components, solving the problem of unsatisfactory efficiency in constructing target servers in related technologies. Thus, it achieves the effect of improving the construction efficiency of the target server.

[0024] In one optional embodiment, the above-mentioned N functional processing components include at least a payment inquiry page component, a bill processing component, a payment authentication component, and an accounting processing component, wherein the payment inquiry page component is used to query payment information, the bill processing component is used to query bills and reconcile bills, the payment authentication component is used to perform identity authentication and proxy payment authentication, and the accounting processing component is used to generate accounting reports.

[0025] It's understandable that, based on the standard payment functions for the application scenario, the payment process has been functionally broken down. These functionalities have been encapsulated, resulting in at least a payment inquiry page component, a bill processing component, a payment authentication component, and an account processing component. Each of these N functional processing components can be used independently or combined with other components to collaboratively complete the payment process.

[0026] In one optional embodiment, determining at least one target component from a set of N pre-defined functional processing components based on the aforementioned demand scenario type includes: determining the target processing capability of the demand party based on the aforementioned demand scenario type, wherein the target processing capability is used to support the payment process between the demand party and the financial institution; and determining at least one target component from the aforementioned N functional processing components based on the aforementioned target processing capability.

[0027] It is understandable that, due to different demanders, the corresponding demand scenarios change accordingly. Therefore, it is necessary to determine the target processing capability for each demander. This target processing capability needs to be implemented by pre-defined functional components. Thus, based on the target processing capability, at least one target component is determined from N possible functional processing components. It should be noted that a demand scenario type may correspond to multiple processing capabilities. Selecting the necessary target processing capability according to the specific needs of the demander is beneficial for improving the efficiency of perceiving the demander's needs.

[0028] Alternatively, the demand scenarios of the demand side may be of various types, such as: payment agencies with online systems that have some accounting processing capabilities, or payment functions embedded in virtual programs, etc.

[0029] As an optional embodiment, the above method further includes: identifying the above-mentioned demand scenario types and determining X candidate processing capabilities, wherein X is a positive integer greater than or equal to 1; determining the predetermined processing capability of the above-mentioned demand party, wherein the predetermined processing capability is a specific type of processing capability provided between the above-mentioned demand party and the above-mentioned financial institution in the payment process; and eliminating processing capabilities that match the predetermined processing capability from the above-mentioned X candidate processing capabilities to obtain the target processing capability.

[0030] It is understandable that since the requesting party may already have some online implementations of payment functions, in order to make use of existing resources, the type of demand scenario is identified, and the processing capabilities that are the same as the predetermined processing capabilities among the X types of candidate processing capabilities are removed, thereby obtaining the target processing capability. This avoids the process of repeated construction and improves the utilization rate of existing resources.

[0031] As an optional embodiment, the above-mentioned acquisition of the demand scenario type corresponding to the demander includes: acquiring the historical payment information of the demander in a predetermined historical period; and using a preset machine learning model to identify the historical payment information and determine the demand scenario type of the demander.

[0032] It is understandable that obtaining historical payment information from the requester within a predetermined historical period is crucial. This information reflects the processing methods employed during that period, such as whether some functions were handled manually offline or online. By using a pre-defined machine learning model to identify this historical payment information, the requester's existing processing capabilities and online processing capabilities can be determined, thereby identifying the type of request scenario. Through this process, using machine learning algorithms to identify a large amount of historical payment information improves the ability and efficiency of identifying different types of request scenarios.

[0033] As an optional embodiment, the above-mentioned machine learning model is obtained by the following method: determining a preset initial model; obtaining a payment processing sample set with labels, wherein the labels are used to identify the demand scenario type of the corresponding payment processing sample; and using the payment processing sample set to train the above-mentioned initial model to obtain the above-mentioned machine learning model.

[0034] Understandably, in order to obtain a machine learning model with strong recognition capabilities and high accuracy, a pre-set initial model is trained using a payment processing sample set with labels. It should be noted that the tagged payment processing sample set can be continuously updated, and the machine learning model can be trained multiple times according to a predetermined iteration cycle to continuously improve the model's recognition accuracy.

[0035] As an optional embodiment, obtaining the target server includes: determining a first interface type used by the financial institution to establish interaction; preprocessing the at least one target component to obtain the target server, such that the interface type between the target server and the financial institution matches the first interface type.

[0036] It's understandable that since the server platforms used by financial institutions for online payment processing are pre-built, while the target server required by the client is constructed later, there might be issues where the pre-built N functional processing components cannot be directly matched with the financial institution's reserved interfaces. Therefore, it's necessary to determine the primary interface type used by the financial institution to establish interaction, align the target server with this primary interface type, and preprocess at least one target component to ensure that the interface type between the target server and the financial institution matches the primary interface type, thus obtaining the target server. Through this process, software-level support is provided for successful connection between the target server and the financial institution.

[0037] Optionally, the above interface types can be multiple, such as providing API (Application Programming Interface), H5 (5th Generation HTML Interface), APP (Application Programming Interface) bridging and other access methods.

[0038] As an optional embodiment, the method further includes: when the demand side has a preset server, determining a second interface type for the preset server to establish interaction, wherein the preset server is used to provide the demand side with predetermined processing capabilities, the predetermined processing capabilities being specific types of processing capabilities in the payment process between the demand side and the financial institution; preprocessing the at least one target component to obtain an initial server, such that the interface type between the initial server and the preset server matches the second interface type, and the interface type between the initial server and the financial institution matches the first interface type; combining the initial server and the preset server to obtain the target server.

[0039] It is understandable that, given the existence of a pre-existing server on the requesting party's end, it is assumed that the requesting party already possesses a pre-existing server capable of performing some functions. The processing capabilities need to be supplemented to enable the requesting party to process payments with financial institutions. The pre-existing server may not be directly compatible with any of the various processing components or financial institutions. Therefore, it is necessary to determine the second interface type used by the pre-existing server to establish interaction. At least one target component needs to be pre-processed to obtain an initial server whose interface type matches the second interface type with the pre-existing server and whose interface type matches the first interface type with the financial institution. The initial server is then combined with the pre-existing server to obtain the target server. Through this process, the target server and the requesting party's existing pre-existing server are connected at the software level, enabling the utilization of the requesting party's existing online payment function server. After combining the initial server and the pre-existing server, the system connects to the financial institution to collaboratively process payments. Utilizing the pre-existing server reduces the number of functional components that need to be processed, further improving the construction efficiency of the target server.

[0040] This invention also provides a specific implementation method. Figure 2 This is a payment flowchart illustrating an optional payment processing method provided in an embodiment of this application, such as... Figure 2As shown, to functionally decompose the payment process, the above process is explained first: users using payment agencies first check their bills, then select a payment method, then make the payment, and finally the payment agency verifies the bill, which is then processed by the financial institution and clearing organization. Therefore, to adapt to changing integration needs, the entire payment process needs to be reasonably decomposed and encapsulated. Based on the component-based development concept and the combination of page and non-page service models, the process is decomposed into four capabilities: payment inquiry page, bill processing (including overdue bill inquiry and bill verification), payment authentication (page service), and accounting processing (backend service).

[0041] These four capabilities are encapsulated as components, which can be output independently or combined with each other. By assembling these four capability components, services can be provided for various scenarios.

[0042] Figure 3 This is a schematic diagram of an optional payment processing method provided according to an embodiment of this application, such as... Figure 3 As shown, two types of demand sides are illustrated: payment agencies and virtual service platforms. The first type is payment agencies, which facilitate the configuration and deployment of payment services, enabling them to quickly connect to and launch payment items. The second type is virtual service platforms, which provide access to a single point of contact with financial institutions to launch a certain range of full payment categories. The following explanation, based on these two scenarios, illustrates how a combination of payment inquiry pages, bill processing (including overdue bill inquiries and bill reconciliation), payment authentication (page service), and accounting processing (backend service) can achieve rapid output of payment scenarios.

[0043] exist Figure 3 Payment collection agencies and virtual service platforms select the required service capabilities and target functional components. At least one of these target components can be combined in a manner similar to... Figure 3 The various service templates shown, once configured, can be used to process payments according to different online payment channels, including various application services or network settings on mobile and PC platforms. It should be noted that... Figure 3 The water and electricity fees mentioned are merely examples of payment services and are not intended to be specific.

[0044] Payment collection agencies can have the following five demand scenarios. The first scenario is a complete output, which combines components such as payment inquiry pages, bill processing, payment authentication, and accounting. When a payment collection agency itself does not have an online payment system and has no special needs, it can manage bills through channels provided by financial institutions. At the same time, its customers can make payments through various channels of financial institutions. These four services are delivered together to provide payment collection agencies with a one-stop service that is development-free, secure, reliable, and quick to launch.

[0045] The second type of demand scenario for payment agencies involves payment pages and accounting output, including a combination of components such as payment inquiry pages, payment authentication, and accounting processing. Most payment agencies already have their own internal management systems, meaning they have the ability to manage bills. In this case, they only need to use the other three capabilities to connect with financial institutions and process payments through the institutions' existing channels, ensuring smooth accounting.

[0046] The third type of demand scenario for payment processing agencies is account processing output with authentication, which combines components such as payment authentication and account processing. For some payment processing agencies that have their own payment channels, or for users or organizations with special requirements for the page, they can use only payment authentication and account processing services to meet their fund processing needs.

[0047] The fourth type of demand scenario for payment agencies is accounting output without authentication requirements, which is handled by the accounting processing component. For some special cases, payment agencies have developed special payment authentication methods, such as when someone else makes the payment on their behalf, in which case only the accounting processing service can be used.

[0048] The fifth type of demand scenario for payment collection agencies is page output, which includes a combination of components such as payment inquiry pages and payment authentication. For some special cases, where payment collection agencies have already integrated with other financial institutions' products, but the channels are not diverse enough, page service output can be used to quickly enrich these channels.

[0049] The virtual service platform can be configured for three main scenarios. The first scenario involves a complete output, combining components such as payment inquiry pages, bill processing, payment authentication, and accounting. When the virtual service platform requires quick integration and has no special needs, it can provide these four services as a whole. The virtual service platform does not need to concern itself with the internal logic of the financial institution; once the payment item is entered, all processing is handled by the financial institution. It is suitable for embedding into various apps and public accounts both inside and outside financial institutions. Due to different use cases, various access methods are available, including API, H5, and app bridging.

[0050] The second type of demand scenario for virtual service platforms is the output of payment services with authentication, which includes a combination of components such as bill processing, payment authentication, and accounting. When the virtual service platform has special requirements for the page, and the general payment inquiry page cannot meet them, a separate page can be developed, using only the other three services. In this way, the workload can be reduced to front-end development, achieving the goal of rapid output.

[0051] The third type of demand scenario for virtual service platforms is billing resource output, including billing processing component processing. This is suitable for large platforms that have channels and accounting processing capabilities but lack payment billing resources. By connecting with financial institutions to charge enterprises, they can quickly obtain billing processing capabilities.

[0052] Through the above methods, the specific implementation methods provided by this invention can achieve the following effects: by identifying application scenarios and decomposing functions in the payment process, a lightweight, standardized, modular, dynamic, and customized construction method is provided to facilitate the rapid launch of payment services. In practical applications, relying on the above methods, rapid platform integration within two weeks and the launch of collection services such as donation zones within 12 hours have been achieved, greatly improving the construction efficiency of payment processing servers.

[0053] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0054] This application also provides a payment processing device. It should be noted that the payment processing device of this application can be used to execute the payment processing method provided in this application. The payment processing device provided in this application is described below.

[0055] Figure 4 This is a schematic diagram of a payment processing device according to an embodiment of this application. Figure 4 As shown, the device includes: an acquisition module 402, a determination module 404, and a construction module 406, which will be described in detail below.

[0056] The acquisition module 402 is used to acquire the demand scenario type corresponding to the demand party, wherein there is a payment demand between the aforementioned demand party and the financial institution.

[0057] The determination module 404, connected to the acquisition module 402, is used to determine at least one target component from the preset N functional processing components based on the above-mentioned demand scenario type, where N is a positive integer greater than or equal to 1, and the above-mentioned N functional processing components are components that provide corresponding processing capabilities in the payment process between the above-mentioned demand party and the above-mentioned financial institution.

[0058] The construction module 406, connected to the determination module 404, is used to obtain a target server for implementing the payment process between the aforementioned demander and the aforementioned financial institution based on at least one of the aforementioned target components.

[0059] The payment processing device provided in this application includes an acquisition module 402 for acquiring the demand scenario type corresponding to the demand party, wherein there is a payment demand between the demand party and the financial institution; a determination module 404, connected to the acquisition module 402, for determining at least one target component from a preset set of N functional processing components based on the demand scenario type, wherein N is a positive integer greater than or equal to 1, and the N functional processing components are components that provide corresponding processing capabilities in the payment process between the demand party and the financial institution; and a construction module 406, connected to the determination module 404, for obtaining a target server for implementing the payment process between the demand party and the financial institution based on the at least one target component. This achieves the goal of improving the automation level of the target server by identifying the demand scenario and decomposing functional components, solving the problem of unsatisfactory efficiency in constructing target servers in related technologies, and thus improving the construction efficiency of the target server.

[0060] It should be noted that the above modules can be implemented by software or hardware. For example, for the latter, it can be implemented in the following ways: the above modules can be located in the same processor; or the above modules can be located in different processors in any combination.

[0061] It should be noted that the acquisition module 402, determination module 404, and construction module 406 mentioned above correspond to steps S102 to S106 in the embodiments. The instances and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the content disclosed in the above embodiments. It should be noted that the above modules, as part of the device, can run in a computer terminal.

[0062] It should be noted that the optional or preferred implementation methods of this embodiment can be found in the relevant descriptions in the embodiments, and will not be repeated here.

[0063] The aforementioned payment processing device includes a processor and a memory. All of the aforementioned units are stored in the memory as program units, and the processor executes the aforementioned program units stored in the memory to realize the corresponding functions.

[0064] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and the payment processing server can be built by adjusting kernel parameters.

[0065] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0066] This invention provides a non-volatile storage medium storing a program that, when executed by a processor, implements the above-described payment processing method.

[0067] This invention provides a processor for running a program, wherein the program executes the payment processing method described above.

[0068] This invention provides an electronic device, including a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it performs the following steps: obtaining the demand scenario type corresponding to the demander, wherein the demander and the financial institution have a payment demand; based on the demand scenario type, determining at least one target component from a preset set of N functional processing components, where N is a positive integer greater than or equal to 1, and the N functional processing components are components that provide corresponding processing capabilities in the payment process between the demander and the financial institution; and based on the at least one target component, obtaining a target server for implementing the payment process between the demander and the financial institution. The device in this document can be a server, PC, PAD, mobile phone, etc.

[0069] This application also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialization program with the following method steps: obtaining the demand scenario type corresponding to the demand party, wherein there is a payment demand between the demand party and the financial institution; based on the demand scenario type, determining at least one target component from a preset set of N functional processing components, wherein N is a positive integer greater than or equal to 1, and the N functional processing components are components that provide corresponding processing capabilities in the payment process between the demand party and the financial institution; and based on the at least one target component, obtaining a target server for implementing the payment process between the demand party and the financial institution.

[0070] Optionally, the aforementioned computer program product is also suitable for executing an initialization program with the following method steps: determining at least one target component from a preset set of N functional processing components based on the aforementioned demand scenario type, including: determining the target processing capability of the demand party based on the aforementioned demand scenario type, the target processing capability being used to support the payment process between the demand party and the financial institution; and determining at least one target component from the aforementioned N functional processing components based on the aforementioned target processing capability.

[0071] Optionally, the aforementioned computer program product is also suitable for executing an initialization program with the following method steps: the method further includes: identifying the aforementioned demand scenario type, determining X candidate processing capabilities, where X is a positive integer greater than or equal to 1; determining the predetermined processing capability of the aforementioned demand party, wherein the predetermined processing capability is a specific type of processing capability provided between the aforementioned demand party and the aforementioned financial institution in the payment process; and eliminating processing capabilities that match the predetermined processing capability from the aforementioned X candidate processing capabilities to obtain the target processing capability.

[0072] Optionally, the aforementioned computer program product is also suitable for executing an initialization program with the following method steps: obtaining the demand scenario type corresponding to the demander includes: obtaining the historical payment information of the demander in a predetermined historical period; using a preset machine learning model to identify the historical payment information and determine the demand scenario type of the demander.

[0073] Optionally, the aforementioned computer program product is also suitable for executing an initialization program with the following method steps: the aforementioned machine learning model is obtained by the following methods: determining a preset initial model; obtaining a payment processing sample set carrying labels, wherein the labels are used to identify the demand scenario type of the corresponding payment processing sample; and using the aforementioned payment processing sample set to train the aforementioned initial model to obtain the aforementioned machine learning model.

[0074] Optionally, the aforementioned computer program product is also suitable for executing an initialization program having the following method steps: obtaining the target server includes: determining a first interface type used by the financial institution to establish interaction; preprocessing the at least one target component to obtain the target server, such that the interface type between the target server and the financial institution matches the first interface type.

[0075] Optionally, the aforementioned computer program product is also suitable for executing an initialization program with the following method steps: the method further includes: when the aforementioned demander has a preset server, determining a second interface type used by the preset server to establish interaction, wherein the preset server is used to provide the aforementioned demander with predetermined processing capabilities, the predetermined processing capabilities being specific types of processing capabilities provided between the aforementioned demander and the aforementioned financial institution in the payment process; preprocessing the aforementioned at least one target component to obtain an initial server, such that the interface type between the initial server and the preset server matches the aforementioned second interface type, and the interface type between the initial server and the aforementioned financial institution matches the aforementioned first interface type; combining the aforementioned initial server and the aforementioned preset server to obtain the aforementioned target server.

[0076] Optionally, the aforementioned computer program product is also suitable for executing an initialization program with the following method steps: the aforementioned N functional processing components include at least a payment inquiry page component, a bill processing component, a payment authentication component, and an accounting processing component, wherein the aforementioned payment inquiry page component is used to query payment information, the aforementioned bill processing component is used for bill inquiry and bill reconciliation, the aforementioned payment authentication component is used for identity authentication and proxy payment authentication, and the aforementioned accounting processing component is used to generate accounting reports.

[0077] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0078] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0079] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0080] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0081] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0082] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0083] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0084] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0085] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0086] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A payment processing method, characterized in that, include: Obtain the demand scenario type corresponding to the demand party, wherein there is a payment demand between the demand party and the financial institution; Based on the aforementioned demand scenario type, at least one target component is determined from a set of N pre-defined functional processing components, where N is a positive integer greater than or equal to 1, and the N functional processing components are components that provide corresponding processing capabilities in the payment process between the demand party and the financial institution. Based on the at least one target component, a target server is obtained for implementing the payment process between the demander and the financial institution. The step of determining at least one target component from a set of N preset functional processing components based on the demand scenario type includes: identifying the demand scenario type and determining X candidate processing capabilities, where X is a positive integer greater than or equal to 1; determining the predetermined processing capability of the demand party, wherein the predetermined processing capability is a specific type of processing capability provided between the demand party and the financial institution in the payment process; and eliminating processing capabilities that match the predetermined processing capability from the X candidate processing capabilities to obtain the target processing capability. Wherein, obtaining the target server involves: determining the first interface type used by the financial institution to establish interaction; preprocessing the at least one target component to obtain the target server, such that the interface type between the target server and the financial institution matches the first interface type; The method further includes: when the demand side has a preset server, determining a second interface type for the preset server to establish interaction, wherein the preset server is used to provide the demand side with predetermined processing capabilities, the predetermined processing capabilities being specific types of processing capabilities in the payment process between the demand side and the financial institution; preprocessing the at least one target component to obtain an initial server, such that the interface type between the initial server and the preset server matches the second interface type, and the interface type between the initial server and the financial institution matches the first interface type; combining the initial server and the preset server to obtain the target server.

2. The method according to claim 1, characterized in that, The step of determining at least one target component from a set of N preset functional processing components based on the required scenario type includes: Based on the aforementioned demand scenario type, the target processing capacity of the demand party is determined, and the target processing capacity is used to support the payment process between the demand party and the financial institution. Based on the target processing capability, at least one target component is determined from the N types of functional processing components.

3. The method according to claim 1, characterized in that, The acquisition of the demand scenario type corresponding to the demander includes: Obtain the historical payment information of the demander during the predetermined historical period; A pre-set machine learning model is used to identify the historical payment information and determine the demand scenario type of the demand party.

4. The method according to claim 3, characterized in that, The machine learning model is obtained through the following method: Determine the preset initial model; Obtain a set of payment processing samples with tags, wherein the tags are used to identify the demand scenario type of the corresponding payment processing sample; The initial model is trained using the payment processing sample set to obtain the machine learning model.

5. The method according to any one of claims 1 to 4, characterized in that, The N functional processing components include at least a payment inquiry page component, a bill processing component, a payment authentication component, and an accounting processing component. The payment inquiry page component is used to query payment information, the bill processing component is used for bill inquiry and bill reconciliation, the payment authentication component is used for identity authentication and proxy payment authentication, and the accounting processing component is used to generate accounting reports.

6. A payment processing device, characterized in that, include: The acquisition module is used to acquire the demand scenario type corresponding to the demand party, wherein there is a payment demand between the demand party and the financial institution. The determination module is used to determine at least one target component from a set of N functional processing components based on the demand scenario type, where N is a positive integer greater than or equal to 1, and the N functional processing components are components that provide corresponding processing capabilities in the payment process between the demand party and the financial institution. A construction module is used to obtain a target server based on the at least one target component for implementing the payment process between the demander and the financial institution; The determining module is further configured to identify the type of demand scenario, determine X candidate processing capabilities, where X is a positive integer greater than or equal to 1; determine the predetermined processing capability of the demand party, wherein the predetermined processing capability is a specific type of processing capability provided by the demand party and the financial institution in the payment process; and eliminate processing capabilities that match the predetermined processing capability from the X candidate processing capabilities to obtain the target processing capability. The construction module is further configured to determine the first interface type used by the financial institution to establish interaction; preprocess the at least one target component to obtain a target server, such that the interface type between the target server and the financial institution matches the first interface type; The device is further configured to, when the demand side has a preset server, determine a second interface type for establishing interaction by the preset server, wherein the preset server is configured to provide the demand side with predetermined processing capabilities, the predetermined processing capabilities being specific types of processing capabilities in the payment process between the demand side and the financial institution; preprocess the at least one target component to obtain an initial server, such that the interface type between the initial server and the preset server matches the second interface type, and the interface type between the initial server and the financial institution matches the first interface type; combine the initial server and the preset server to obtain the target server.

7. A non-volatile storage medium, characterized in that, The non-volatile storage medium stores multiple instructions, which are adapted to be loaded by a processor and executed by the payment processing method according to any one of claims 1 to 5.

Images