Payment Engine Configuration Method, Device, Electronic Device, and Storage Medium

Abstract

The present invention provides a configuration method for a payment engine, including: obtaining payment instructions, payment protocols, and scripts in a configuration service, and generating an executable code object; receiving a payment request and verifying the validity of the payment request; initializing local thread variables as a context, and storing the generated executable code object and the payment request in the context; obtaining the payment request from the context, generating corresponding business transaction model objects and payment transaction model objects, and storing them in a database; obtaining the payment stage configuration specified in the payment protocol, constructing a payment stage executable object, and storing the payment stage executable object in the database, obtaining the payment channel definition and payment channel interface to be requested in the payment stage from the payment transaction model object, sending a request to the payment channel, and executing the payment stage.

Description

Technical Field

[0001] This document relates to, but is not limited to, the payment field. Background Art

[0002] In the payment field, there are diverse fund changes. Different payment processes require different fund processing channels for interaction. The messages and business logics required for bank outpayments, WeChat and Alipay deductions, and internal channel fund changes are different. There is a lack of a unified routing specification to distribute different processing channels for different fund changes.

[0003] The execution strategies in the payment stage are different. The content and quantity of the payment stages included in the payment process of each scenario are different. After receiving a payment request, when to execute this action, how to execute it, and after execution, what is the mapping relationship between the execution status of this stage and the overall payment status, whether the next payment stage needs to be executed, and which payment stage needs to be executed. There is a lack of a complete payment solution.

[0004] In the prior art, there are various payment system solutions in the payment field (such as chain receipt collection combined with an independent payment routing system to build a payment middle platform), but there is a lack of an engine mode related to the payment process to solve diverse payment scenarios with a general-purpose process.

[0005] The disadvantages of the prior art are mainly in the following two aspects:

[0006] First, the cost is relatively high. Due to the numerous business forms, most of the responsibility chains need to be customized according to the business process, and it is very difficult to achieve an abstract and general responsibility chain. The development cost, business access cost, and maintenance cost are very high.

[0007] Second, it is not flexible enough. Since the development mode is code-based, new code needs to be released to take effect. The time for new processes to go online is long, and it is impossible to meet rapid manual intervention for abnormal situations. Summary of the Invention

[0008] The following presents an overview of various exemplary technical solutions. Some simplifications and omissions can be made in the following overview, which is intended to highlight and introduce some aspects of various exemplary technical solutions, but does not limit the scope of the present invention. A detailed description of the exemplary technical solutions sufficient to allow a person of ordinary skill in the art to generate and use the concepts of the present invention will be presented in the subsequent sections.

[0009] To solve the above technical problems, the technical solution of the present invention provides a configuration method for a payment engine, including: obtaining payment instructions, payment protocols, and scripts in a configuration service, and generating executable code objects; receiving a payment request and verifying the validity of the payment request; initializing local thread variables as the context, and storing the generated executable code objects and the payment request in the context; obtaining the payment request from the context, generating corresponding business transaction model objects and payment transaction model objects, and storing them in a database; obtaining the payment stage configuration specified in the payment protocol, constructing an executable object for the payment stage, and storing the executable object for the payment stage in the database, obtaining the payment channel definition and payment channel interface to be requested in the payment stage from the payment transaction model object, and sending a request to the payment channel to execute the payment stage.

[0010] Optionally, the method further includes, after storing the executable object for the payment stage in the database, sending a payment stage initialization completion event to subscribers.

[0011] Optionally, the method further includes: reading the information of the next payment stage to be executed after the execution of the current payment stage from the payment protocol, generating an executable object, and linking it to the current payment stage object; after the execution of the current stage, checking the mapping relationship between the execution result of the current payment stage and the status of the entire payment process, confirming whether the entire payment process has been completed, if not, taking out the execution information of the next payment stage linked in the current payment stage, and executing the next payment stage, repeating this action until all payment stages have been executed or the entire payment process is completed.

[0012] Optionally, the method further includes: after the payment channel returns a response, putting the execution result of the payment stage into the payment transaction model object in the context, updating the execution information of the payment stage to the database, and sending a payment stage execution completion event to relevant subscribers.

[0013] Optionally, the method further includes, after all payment stages are completed or the entire payment process is completed, sending a notification event to each subscriber to notify the payment result.

[0014] Optionally, the configuration service includes one of the following: Diamond, Apollo.

[0015] Another technical solution of the present invention provides a configuration device for a payment engine, including: a configuration initialization module configured to obtain payment instructions, payment protocols, and scripts in a configuration service and generate executable code objects; a parameter verification module configured to receive a payment request and verify the validity of the payment request; an initialization context module configured to initialize local thread variables as a context and store the generated executable code objects and the payment request in the context; an initialization transaction model module configured to obtain the payment request from the context, generate corresponding business transaction model objects and payment transaction model objects, and store them in a database; a stage execution module configured to obtain the payment stage configuration specified in the payment protocol, construct an executable object for the payment stage, and store the executable object for the payment stage in the database, obtain the payment channel definition and payment channel interface to be requested in the payment stage from the payment transaction model object, send a request to the payment channel, and execute the payment stage.

[0016] Optionally, the stage execution module is further configured to: read information about the next payment stage to be executed after the execution of the current payment stage from the payment protocol, generate an executable object, and link it to the current payment stage object; after the execution of the current stage, check the mapping relationship between the execution result of the current payment stage and the status of the entire payment process to confirm whether the entire payment process has been completed. If not, take out the execution information of the next payment stage linked in the current payment stage and execute the next payment stage, and loop this action until all payment stages have been executed or the entire payment process is completed.

[0017] Optionally, the device further includes: a notification module configured to send at least one of the following to subscribers: a payment stage initialization completion event, a payment stage execution completion event, and a payment result notification after all payment stages are completed or the entire payment process is completed.

[0018] Another technical solution of the present invention also provides an electronic device, including: a processor, a memory, and a computer program running on the memory, where the processor implements the steps of the method described in any of the above technical solutions when executing the computer program.

[0019] Another technical solution of the present invention also provides a computer-readable storage medium, where the computer program implements the steps of the method described in any of the above technical solutions when executed by a processor.

[0020] The technical solutions of the present invention mainly have the following two beneficial effects:

[0021] First, in the way of using a payment engine, the engine doesn't need to care about how the internal business logic is specifically executed, but only standardizes the execution process of the main process; use configurations to describe the business process and how the process details are advanced. In this way, diverse payment forms are incorporated into a unified process. When new services are connected or existing services change, there is no need to modify the main code of the payment engine. Instead, it can be achieved by modifying the configurations (such as payment protocols and scripts), enabling real-time modification, real-time release, and real-time effectiveness, thus saving development costs, service connection costs, and maintenance costs.

[0022] Second, it can achieve real-time modification, real-time release, and real-time effectiveness, making the entire payment process very flexible and dynamically meeting different scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] To better understand various exemplary embodiments, reference may be made to the accompanying drawings, in which:

[0024] Figure 1 shows a schematic flowchart of a configuration method for a payment engine provided by an embodiment;

[0025] Figure 2A shows a schematic flowchart of step S101 in the configuration method for a payment engine provided by an embodiment, Figure 2B shows a schematic flowchart of step S105 in the configuration method for a payment engine provided by an embodiment;

[0026] Figure 3 shows a schematic structural diagram of a configuration device for a payment engine provided by an embodiment.

[0027] For ease of understanding, the same reference numerals have been used to refer to elements having substantially the same or similar structures and / or substantially the same or similar functions. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0028] The description and the drawings illustrate the principles of the present invention. Therefore, it will be understood that those skilled in the art will be able to design various arrangements that, although not explicitly described or shown herein, embody the principles of the present invention and are included within the scope of the present invention. In addition, all examples cited herein are mainly for the purpose of explicit teaching to help readers understand the principles of the present invention and the concepts provided by the inventors to deepen the field. And all examples should be considered as not limited to such specifically cited examples and conditions. Additionally, as used herein, unless otherwise indicated (e.g., "or alternatively" or "or in the alternative"), the term "or" refers to a non-exclusive or (i.e., and / or). And the various embodiments described herein are not necessarily mutually exclusive, as some embodiments can be combined with one or more other embodiments to form new embodiments.

[0029] Glossary:

[0030] Payment Agreement: During the payment process, there are multiple fund changes, including changes between internal accounts and fund changes through third-party channels. The payment agreement determines the payment process flow and standardizes the fund flow throughout the payment link.

[0031] Payment Phase: A component of the payment agreement that describes how each step is specifically executed.

[0032] Payment Instruction: Specifies which payment agreement to adopt based on multiple business dimensions.

[0033] Current Phase Code: The phase code that identifies this phase.

[0034] Source Phase Code: Exists in business forms such as refund and associated payment, and identifies the phase code of the original payment transaction.

[0035] Current Step Code: Identifies which step in this payment agreement this phase needs to be executed.

[0036] Source Step Code: Exists in business forms such as refund and associated payment, and identifies the step code of the original payment transaction.

[0037] Fund Source Construction Script: The script for constructing the request message in each fund change step.

[0038] Channel Instruction Script: The component script for the request message of each third-party channel.

[0039] Execution Plan: Describes the specific execution information of the payment phase, including the triggering method (immediate execution, scheduled execution, external trigger execution), whether to ensure success, the execution policy script, whether to retry in case of exception, etc.

[0040] Phase Instruction Status Mapping: The correspondence between the execution status of the payment phase and the execution status of the entire payment process.

[0041] The first embodiment provides a configuration method for a payment engine. Refer to Figure 1 , the method includes:

[0042] Step S101: Obtain the payment instruction, payment agreement, and script in the configuration service and generate an executable code object;

[0043] This step is the configuration initialization, and the specific steps are as Figure 2AAs shown, the service starts, initializes the configuration in the configuration service. The configuration can be Diamond, Apollo, etc., which can be a remote service or a distributed cache. The configuration service contains payment instructions, payment protocols, scripts, routing, fee calculation rules, etc. After initializing the configuration in the configuration service, initialize the payment protocol configuration, routing configuration, fee calculation rule configuration, Groovy and other script configurations. After the initialization is complete, obtain the configuration in the configuration service and load it into the local cache, generate payment instructions, payment protocols, scripts, and generate executable code objects, such as Java objects.

[0044] Step S102: Receive a payment request and verify the validity of the payment request; initialize local thread variables as the context, and store the generated executable code object and the payment request in the context.

[0045] This step is parameter verification. When receiving a payment request, non-null verification and format verification can be performed on the payment request message to determine whether the request is valid and whether the format is correct.

[0046] Step S103: Initialize local thread variables as the context, and store the generated executable code object and the payment request in the context.

[0047] This step is to initialize the context, create local thread variables, initialize local thread variables as the context, and store the generated executable code object and the payment request in the context.

[0048] Step S104: Obtain the payment request from the context, generate corresponding business transaction model objects and payment transaction model objects, and store them in the database.

[0049] This step is to initialize the transaction model. Obtain the payment request object from the context, generate corresponding business transaction model objects and payment transaction model objects, put them in the context for later use, and process them. Set the payment status to initialized, and store the business transaction model objects and payment transaction model objects in the database.

[0050] Step S105: Obtain the payment stage configuration specified in the payment protocol, construct an executable object for the payment stage, and store the executable object for the payment stage in the database. Obtain the payment channel definition and payment channel interface to be requested in the payment stage from the payment transaction model object, send a request to the payment channel, and execute the payment stage.

[0051] This step is as Figure 2BAs shown below, the specific steps can be as follows: Read the payment transaction model object from the context, obtain the payment protocol ID, and then obtain the payment stage configuration specified in the payment protocol. Construct an executable object for the payment stage and persist this object to the database. Send a payment stage initialization completion event and the events carried in the current payment stage to the subscriber. The subscriber can receive the events after the execution of the current payment stage and then process the corresponding business logic. Then, read the information of the next payment stage to be executed after the execution of the current payment stage from the payment protocol, generate an executable object, and link it to the current payment stage object. Before the payment stage is actually executed, determine whether the current stage is executable. If it is executable, obtain the payment channel definition and payment channel interface required for this payment stage from the payment transaction model object, and then send an HTTP or DUBBO request. After the channel returns a response, put the payment stage execution result into the payment transaction model object in the context, update the payment stage execution information to the database, and send a payment stage execution completion event to the relevant subscribers. After the stage is executed, check the mapping relationship between the execution result of the current payment stage and the status of the entire payment process to confirm whether the entire payment process has been completed. If it has not been completed, take out the execution information of the next payment stage linked in the current payment stage and execute the next payment stage. Loop through the payment stage execution process and event publishing until all payment stages have been executed or the entire payment process has been completed. Determine whether this request has been processed based on the payment stage execution status and the entire payment process execution status.

[0052] Optionally, the payment instructions are loaded into the local cache in the form of a configuration at project startup and an executable code object is generated. After receiving a payment request, match the payment instructions to determine the specific payment protocol to be executed.

[0053] Optionally, the payment protocol is loaded into the local cache in the form of a configuration at project startup and an executable code object is generated. After the payment instructions specify the payment protocol to be executed, check whether there is a pre-payment stage selection script in the payment protocol. If there is a pre-script, determine which payment stage to execute first according to the pre-script; if there is no pre-script, default to execute the first payment stage. After the execution of the current payment stage, map the execution status of the payment stage to the execution status of the entire payment process to determine whether the entire payment process has ended. If it has not ended, continue to execute the subsequent stages. Loop through this action until the entire payment process ends.

[0054] Optionally, the payment stage specifies how to execute the stage execution process, assemble the request message for the corresponding funding source according to the funding source selection script, assemble the channel interaction information according to the channel instruction script, check the execution plan, and specifically execute this payment stage according to the execution plan. Map the execution result according to the stage instruction status to determine whether the entire payment process has been completely ended after the execution of the current payment stage.

[0055] Optionally, the method further includes the step of sending a notification event to each subscriber after all payment stages are completed or the entire payment process is finished, notifying the payment result.

[0056] For example, when a user wants to initiate a payment request, first, access the financial gateway through the network. Second, reach the cashier desk. Third, reach the payment engine. The payment engine obtains the payment protocol, payment instructions, payment protocol, and script from a remote configuration service (such as diamond) and generates an executable code object; receives the payment request and verifies its validity; initializes local thread variables as the context and stores the generated executable code object and the payment request in the context; obtains the payment request from the context, generates corresponding business transaction model objects and payment transaction model objects, and stores them in the database; obtains the payment stage configuration specified in the payment protocol, constructs an executable object for the payment stage, and stores the executable object for the payment stage in the database, and then performs stage execution. Here, the stage can be customized. For example, in the first stage, a coupon is deducted. Then the payment engine will obtain the information of the coupon, verify its validity, and after verification, deduct the amount of the coupon from the payment amount. After the first stage is completed, it will check whether there is a second stage. If there is a second stage, it will execute the second stage. For example, the second stage is integral deduction. After verification, according to the integral deduction amount, it will then check whether there is a third stage until there is no next stage to end this step. Fourth, reach the payment channel, obtain the payment channel definition and payment channel interface required for the payment stage from the payment transaction model object, and send an HTTP or DUBBO request to the payment channel to execute the payment. For example, pay through channels such as banks, WeChat, and Alipay. Using different channels for payment can be achieved by modifying the configuration without modifying the overall framework of the payment engine.

[0057] In this embodiment, using the payment engine method, the engine does not need to care about how the internal business logic is specifically executed, but only standardizes the execution process of the main process; uses remote configuration to describe the business process and how the process details are advanced. In this way, diverse payment forms (such as banks, WeChat, Alipay, etc.) are incorporated into a unified process. When new services are accessed or existing services change, there is no need to modify the main code of the payment engine. Instead, it can be achieved by modifying the configuration (such as the payment protocol and script, etc.), achieving real-time modification, real-time release, and real-time effectiveness, saving development costs, service access costs, and maintenance costs. It can achieve real-time modification, real-time release, and real-time effectiveness, making the entire payment process very flexible and dynamically meeting different scenarios.

[0058] The second embodiment provides a configuration device 300 for a payment engine, including:

[0059] Configure the initialization module 301 to obtain the payment instruction, payment protocol, and script in the configuration service and generate an executable code object. That is, perform parameter verification. Receive a payment request, and can perform non-empty verification and format verification on the payment request message to determine whether the request is valid and whether the format is correct.

[0060] The parameter verification module 302 is configured to receive a payment request and verify the validity of the payment request. That is, perform parameter verification. Receive a payment request, and can perform non-empty verification and format verification on the payment request message to determine whether the request is valid and whether the format is correct.

[0061] The initialization context module 303 is configured to initialize local thread variables as the context, and store the generated executable code object and the payment request in the context. That is, initialize the context, create local thread variables, initialize the local thread variables as the context, and store the generated executable code object and the payment request in the context.

[0062] The initialization transaction model module 304 is configured to obtain the payment request from the context, generate the corresponding business transaction model object and payment transaction model object, and store them in the database. That is, initialize the transaction model, obtain the payment request object from the context, generate the corresponding business transaction model object and payment transaction model object, put them in the context for backup, and perform processing. Set the payment status to initialization, and store the business transaction model object and the payment transaction model object in the database.

[0063] The phase execution module 305 is configured to obtain the payment phase configuration specified in the payment protocol, construct an executable object for the payment phase, and store the executable object for the payment phase in the database. Obtain the payment channel definition and payment channel interface to be requested in the payment phase from the payment transaction model object, send a request to the payment channel, and execute the payment phase.

[0064] Optionally, the phase execution module 305 is further configured to: read the payment flow model object from the context, obtain the payment protocol ID, and then obtain the payment phase configuration specified in the payment protocol, construct an executable object for the payment phase, and persist the object to the database, send a payment phase initialization completion event and the events carried in the current payment phase to the subscriber, and the subscriber can receive the events after the execution of the current payment phase and then process the corresponding business logic. Then read the information of the next payment phase to be executed after the execution of the current payment phase from the payment protocol, generate an executable object, and link it to the current payment phase object. Before the payment phase is actually executed, determine whether the current phase is executable. If it is executable, obtain the payment channel definition and payment channel interface required for this payment phase from the payment flow model object in the context, and then send an HTTP or DUBBO request. After the channel returns a response, put the payment phase execution result into the payment flow model object in the context, update the payment phase execution information to the database, and send a payment phase execution completion event to the relevant subscribers. After the phase is executed, check the mapping relationship between the execution result of the current payment phase and the status of the entire payment process to confirm whether the entire payment process has been completed. If not, take out the execution information of the next payment phase linked in the current payment phase and execute the next payment phase. Loop through the payment phase execution process and event publishing until all payment phases have been executed or the entire payment process has been completed. Determine whether this request has been processed based on the payment phase execution status and the entire payment process execution status.

[0065] Optionally, the device further includes: a notification module configured to send at least one of the following to the subscriber: a payment phase initialization completion event, a payment phase execution completion event, and a notification of the payment result after all payment phases are completed or the entire payment process is completed.

[0066] The third embodiment further provides an electronic device, including: a processor, a memory, and a computer program running on the memory. When the processor executes the computer program, it implements the steps of the method in any of the above embodiments, such as steps S101 to S105, or when the processor executes the computer program, it implements the functions of each module / unit in the above embodiments, such as Figure 1 the functions of the units 201 to 205 shown. The computer program may be divided into one or more modules / units, and the one or more modules / units are stored in the memory and executed by the processor. The one or more modules / units may be a series of computer program instruction segments capable of performing specific functions, and the instruction segments are used to describe the execution process of the computer program in the electronic device.

[0067] The electronic device may be a mobile terminal such as a smart phone, or a computing device such as a desktop computer, a notebook, a palm computer, and a cloud server. The electronic device may include, but is not limited to, a processor and a memory, and may include more or fewer components, or combine certain components. For example, the electronic device may further include an input / output device, a network access device, a bus, etc. The so-called processor may be a central processing unit (CPU), or may also be other general-purpose processors, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. The memory may be an internal storage unit of the electronic device, such as a hard disk or memory of the electronic device. The memory may also be an external storage device of the electronic device, such as a plug-in hard disk equipped on the electronic device, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. Further, the memory may also include both the internal storage unit and the external storage device of the electronic device.

[0068] The fourth embodiment further provides a computer-readable storage medium, and when the computer program is executed by a processor, the steps of the method in any of the above embodiments are implemented.

[0069] In each embodiment of the present application, each functional unit can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of a software functional unit. If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, to implement all or part of the processes in the above-mentioned embodiment methods of the present application, it can also be completed by instructing relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, the steps of the above-mentioned various method embodiments can be implemented. Among them, the computer program includes computer program code, and the computer program code can be in the form of source code, object code, executable file or some intermediate form, etc. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal, and software distribution medium, etc. It should be noted that the content included in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium does not include electrical carrier signals and telecommunication signals.

[0070] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the above-mentioned division of each functional unit and module is used as an example. In actual applications, the above-mentioned functions can be allocated to different functional units and modules according to needs, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. Each functional unit and module in the embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of a software functional unit. In addition, the specific names of each functional unit and module are only for the convenience of mutual distinction and do not limit the protection scope of the present application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the foregoing method embodiments and will not be elaborated herein.

[0071] In the above embodiments, the descriptions of the various embodiments have their own emphases. For parts not described in detail or recorded in a certain embodiment, reference may be made to the relevant descriptions of other embodiments. Those of ordinary skill in the art can realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. A professional technician can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application.

[0072] In the embodiments provided in this application, it should be understood that the disclosed systems, electronic devices, and methods can be implemented in other ways. For example, the system and electronic device embodiments described above are merely illustrative. For example, the division of the modules or units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection shown or discussed with each other can be through some interfaces. The indirect coupling or communication connection of the system or unit can be in an electrical, mechanical, or other form. The units described as separate components may or may not be physically separated. The components shown as units may or may not be physical units, that is, they can be located in one place, or they can be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0073] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements for some of the technical features. These modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included in the protection scope of this application.

Claims

1. A configuration method for a payment engine, characterized in that: It includes: Obtain payment instructions, payment protocols, and scripts in the configuration service, and generate executable code objects; Receive payment requests and verify the validity of the payment requests; Initialize local thread variables as the context, and store the generated executable code objects and payment requests in the context; Obtain the payment request from the context, generate corresponding business transaction model objects and payment transaction model objects, and store them in the database; Obtain the payment stage configuration specified in the payment protocol, construct a payment stage executable object, store the payment stage executable object in the database, obtain the payment channel definition and payment channel interface to be requested in the payment stage from the payment transaction model object, send a request to the payment channel, and execute the payment stage.

2. The configuration method for a payment engine according to claim 1, characterized in that: The method further includes: after storing the payment stage executable object in the database, sending a payment stage initialization completion event to subscribers.

3. The configuration method for a payment engine according to claim 2, characterized in that: The method further includes: Read the information of the next payment stage to be executed after the execution of the current payment stage from the payment protocol, generate an executable object, and link it to the current payment stage object; After the execution of the current stage, check the mapping relationship between the execution result of the current payment stage and the status of the entire payment process, confirm whether the entire payment process has been completed. If not, take out the execution information of the next payment stage linked in the current payment stage, execute the next payment stage, and loop this step until all payment stages have been executed or the entire payment process is completed.

4. The configuration method for a payment engine according to claim 1, characterized in that: The method further includes: after the payment channel returns a response, put the payment stage execution result into the payment transaction model object in the context, update the payment stage execution information to the database, and send a payment stage execution completion event to relevant subscribers.

5. The configuration method for a payment engine according to claim 1, characterized in that: The method further includes: after all payment stages are completed or the entire payment process is completed, send a notification event to each subscriber to notify the payment result.

6. The configuration method for a payment engine according to claim 1, characterized in that: The configuration service includes one of the following: Diamond, Apollo.

7. A configuration device for a payment engine, characterized in that: It includes: A configuration initialization module configured to obtain payment instructions, payment protocols, and scripts in the configuration service, and generate executable code objects; A parameter verification module configured to receive payment requests and verify the validity of the payment requests; An initialization context module configured to initialize local thread variables as the context, and store the generated executable code objects and payment requests in the context; An initialization transaction model module configured to obtain the payment request from the context, generate corresponding business transaction model objects and payment transaction model objects, and store them in the database; The stage execution module is configured to obtain the payment stage configuration specified in the payment protocol, construct an executable object for the payment stage, store the executable object for the payment stage in the database, obtain the payment channel definition and payment channel interface to be requested in the payment stage from the payment flow model object, send a request to the payment channel, and execute the payment stage.

8. The configuration device of the payment engine according to claim 7, wherein the stage execution module is further configured to: Read the information of the next payment stage to be executed after the execution of the current payment stage from the payment protocol, generate an executable object, and link it to the current payment stage object; After the execution of the current stage, check the mapping relationship between the execution result of the current payment stage and the status of the entire payment process, confirm whether the entire payment process has been completed. If not, retrieve the execution information of the next payment stage linked in the current payment stage, execute the next payment stage, and repeat this action until all payment stages have been executed or the entire payment process is completed.

9. The configuration device of the payment engine according to claim 7, wherein it further includes: A notification module configured to send at least one of the following to the subscriber: an event indicating the completion of payment stage initialization, an event indicating the completion of payment stage execution, and a notification of the payment result after all payment stages are completed or the entire payment process is completed.

10. An electronic device, wherein it includes: A processor, a memory, and a computer program running on the memory. When the processor executes the computer program, the method described in any one of claims 1-6 is implemented.

11. A computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method described in any one of claims 1-6 is implemented.

Images