Payment method, device, equipment, medium and program product

Abstract

The embodiment of the invention provides a payment method and device, equipment, a medium and a program product. The model context protocol MCP-based payment system comprises a payment agent, a payment MCP integrated server and a payment interface integrated gateway, the method is applied to the payment MCP integrated server, and the method comprises the following steps: receiving a workflow execution instruction from the payment agent and user interaction context information; the workflow execution instruction is generated by the payment agent based on the user interaction context information; inputting the user interaction context information to a payment workflow in response to a workflow execution instruction used for indicating to execute the payment workflow, and obtaining a payment task to be processed; and sending the to-be-processed payment task to a payment interface integrated gateway, so that the payment interface integrated gateway executes payment operation based on the to-be-processed payment task. The method is used for improving payment efficiency and user experience.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of financial payment, and in particular to a payment method, device, equipment, medium and program product. BACKGROUND

[0002] In the field of financial payment, a user can initiate multiple complex transaction requests at the same time, and these transactions need to process multi-source data in real time and generate payment decisions that conform to the context.

[0003] In the prior art, it is difficult to efficiently process the dynamic adaptation of context information and payment logic. Traditional payment systems usually rely on the static rule base of a centralized server, and cannot flexibly cope with changes in context in complex scenarios (such as sudden changes in user behavior patterns, temporary policy adjustments, etc.), resulting in low transaction efficiency, high error rate or poor user experience.

[0004] Therefore, how to realize the intelligentization, dynamicization and high adaptability of the payment process, and significantly improve the payment efficiency and user experience in complex scenarios is a problem to be solved. SUMMARY

[0005] Embodiments of the present application provide a payment method, device, equipment, medium and program product to improve payment efficiency and user experience.

[0006] In a first aspect, embodiments of the present application provide a payment method, a payment system based on a model context protocol (MCP) includes a payment agent, a payment MCP integrated server, and a payment interface integrated gateway. The method is applied to the payment MCP integrated server, and the method includes:

[0007] receiving a workflow execution instruction and user interaction context information from the payment agent; the workflow execution instruction is generated by the payment agent based on the user interaction context information;

[0008] in response to the workflow execution instruction indicating execution of a payment workflow, inputting the user interaction context information into the payment workflow to obtain a to-be-processed payment task;

[0009] sending the to-be-processed payment task to the payment interface integrated gateway to enable the payment interface integrated gateway to perform a payment operation based on the to-be-processed payment task.

[0010] In one possible implementation, the payment MCP integrated server stores workflow information of a plurality of workflows; the plurality of workflows include the payment workflow, and before receiving the workflow execution instruction from the payment agent, the method further includes:

[0011] receiving a workflow information listing request from the payment agent;

[0012] sending workflow information of the plurality of workflows to the payment agent in response to the workflow information listing request; the workflow execution instruction is generated based on the user interaction context information and the workflow information of the plurality of workflows.

[0013] In a possible implementation, the method further includes:

[0014] receiving configuration files of the plurality of workflows, the configuration files including at least one of the following: a unique identifier of the workflow, a name of the workflow, a functional description text of the workflow, a version number of the workflow, a processing node program in the workflow, a format of an input parameter of the workflow, and a format of an output parameter of the workflow;

[0015] storing the configuration files.

[0016] In a possible implementation, the memory data structure of the configuration files of the plurality of workflows is a hash table data structure.

[0017] In a possible implementation, the method further includes:

[0018] interacting with the payment agent based on the MCP protocol in at least one of the following manners:

[0019] receiving a workflow definition acquisition request from the payment agent; the workflow definition acquisition request includes an identifier of a first workflow; in response to the workflow definition acquisition request, feeding back definition information of the first workflow to the payment agent;

[0020] receiving a workflow update request from the payment agent; the workflow update request includes an identifier of a second workflow; in response to the workflow update request, updating the second workflow.

[0021] In a possible implementation, the method further includes:

[0022] interacting with the payment agent based on the MCP protocol in at least one of the following manners:

[0023] receiving a workflow version management request from the payment agent; the workflow version management request includes a timestamp; in response to the workflow version management request, feeding back information of a third workflow that has been changed since the timestamp to the payment agent;

[0024] Receive a workflow execution status and result acquisition request from the payment agent; the workflow execution status and result acquisition request includes the identifier of the fourth workflow; in response to the workflow execution status and result acquisition request, feed back the workflow execution status or result of the fourth workflow to the payment agent;

[0025] Receive a workflow cancellation request from the payment agent; the workflow cancellation request includes an identifier of the fifth workflow; in response to the workflow cancellation request, stop executing the fifth workflow;

[0026] Send a workflow status change notification to the payment agent.

[0027] In one possible implementation, inputting the user interaction context information into the payment workflow to obtain the payment task to be processed includes:

[0028] Based on the user interaction context information, the target payment tool is determined;

[0029] Based on the target payment tool, determine the payment sub-workflow;

[0030] The payment sub-workflow is executed to obtain the payment task to be processed.

[0031] In one possible implementation, determining the target payment tool based on the user interaction context information includes:

[0032] If the user interaction context information includes payment tool information, the target payment tool is determined based on the payment tool information;

[0033] If the payment tool information is not included in the user interaction context information, user intent analysis is performed based on the user interaction context information to obtain user intent analysis results, which are used to characterize the target payment tool.

[0034] In one possible implementation, the payment sub-workflow is a QR code payment sub-workflow, and executing the payment sub-workflow to obtain the payment task to be processed includes:

[0035] Transaction information is obtained based on the user interaction context information;

[0036] Based on the transaction information, a QR code link is generated;

[0037] Based on the QR code link, generate a QR code image;

[0038] The QR code image is output through the payment smart agent;

[0039] obtaining the to-be-processed payment task based on a transaction state after the two-dimensional code picture is output.

[0040] In a possible implementation, the payment sub-workflow is a subscription payment sub-workflow, and the execution of the payment sub-workflow to obtain the to-be-processed payment task comprises:

[0041] determining whether the user has subscribed, and obtaining a user authorization result based on the user interaction context information when the user has not subscribed;

[0042] performing identity verification on the user when the authorization result indicates that the user agrees to authorize;

[0043] obtaining a subscription state of the user after the identity verification on the user is passed;

[0044] initiating a payment request through the payment agent when the subscription state indicates that the subscription is completed;

[0045] obtaining the to-be-processed payment task based on a transaction state after the payment request is initiated.

[0046] In a possible implementation, the payment sub-workflow comprises at least one of a transaction state query sub-workflow, a refund sub-workflow, and a cancellation sub-workflow.

[0047] In a second aspect, an embodiment of the present application provides a payment device, and a payment system based on a model context protocol (MCP) comprises a payment agent, a payment MCP integrated service, and a payment interface integrated gateway. The device is applied to the payment MCP integrated service, and the device comprises:

[0048] a receiving module configured to receive a workflow execution instruction and user interaction context information from the payment agent, wherein the workflow execution instruction is generated by the payment agent based on the user interaction context information;

[0049] an execution module configured to input the user interaction context information into a payment workflow to obtain a to-be-processed payment task in response to the workflow execution instruction indicating that the payment workflow is executed;

[0050] a sending module configured to send the to-be-processed payment task to the payment interface integrated gateway, so that the payment interface integrated gateway performs a payment operation based on the to-be-processed payment task.

[0051] In a third aspect, an embodiment of the present application provides an electronic device, which comprises a memory and a processor.

[0052] The memory stores computer-executable instructions;

[0053] The processor executes the computer-executable instructions stored in the memory, so that the processor executes the method of any one of the first aspect.

[0054] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, the computer-readable storage medium storing computer-executable instructions, the computer-executable instructions being executed by a processor to implement the method of any one of the first aspect.

[0055] In a fifth aspect, an embodiment of the present application provides a computer program product, comprising a computer program, the computer program being executed by a processor to implement the method of any one of the first aspect.

[0056] The payment method, device, equipment, medium and program product provided by the embodiments of the present application, the payment MCP integrated server can receive the workflow execution instruction and user interaction context information generated by the payment agent based on the user interaction context information, when the workflow execution instruction indicates to execute the payment workflow, input the user interaction context information into the payment task to be processed, and then send it to the payment interface integrated gateway to execute the payment operation. Compared with the problem that the traditional payment system in the prior art cannot flexibly cope with the change of context information in the complex scene, the embodiments of the present application realize the interaction between the payment agent and the payment interface integrated gateway through the MCP protocol, integrate the user interaction context information by using the payment workflow, automatically generate the payment task to be processed, simplify the payment process, improve the payment processing efficiency, and reduce the manual intervention and error rate. BRIEF DESCRIPTION OF DRAWINGS

[0057] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and serve to explain the principles of the present application together with the specification.

[0058] Figure 1 A flowchart of a payment method provided by an embodiment of the present application;

[0059] Figure 2 A flowchart of a method for obtaining a payment task to be processed provided by an embodiment of the present application;

[0060] Figure 3 A flowchart of a method for obtaining a payment task to be processed based on a two-dimensional code payment sub-workflow provided by an embodiment of the present application;

[0061] Figure 4 A flowchart of a method for obtaining a payment task to be processed based on a signing payment sub-workflow provided by an embodiment of the present application;

[0062] Figure 5 A schematic diagram of a payment system provided for an embodiment of the present application;

[0063] Figure 6 A schematic diagram of a workflow provided for an embodiment of the present application;

[0064] Figure 7 A schematic diagram of a unified data Schema management module provided for an embodiment of the present application;

[0065] Figure 8 A structural schematic diagram of a payment device provided for the present application;

[0066] Figure 9 A structural schematic diagram of an electronic device provided for the present application.

[0067] The specific embodiments of the present application have been shown through the above-described drawings, and will be described in more detail hereinafter. These drawings and the written description are not intended to restrict the scope of the present application concept in any way, but to illustrate the present application concept to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0068] The exemplary embodiments will be described in detail herein with reference to the attached drawings. In the following description, the same numbers are used to indicate the same or similar components. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application.

[0069] In the present application, the term "comprising" and its variants are intended to mean non-limiting inclusion; the term "or" and its variants are intended to mean "and / or". In the present application, the terms "first", "second", and the like are used to distinguish similar objects, and do not necessarily indicate a specific order or sequence.

[0070] In the present application, "a plurality of" means two or more. "And / or", which describes the association relationship between the associated objects, means that there can be three relationships, for example, A and / or B, which can represent the three cases of A alone, A and B together, and B alone. The character " / " generally represents an "or" relationship between the associated objects before and after it.

[0071] It should be noted that the user information (including but not limited to user equipment information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present application are all information and data authorized by the user or authorized by all parties, and the collection, use and processing of related data need to comply with relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation portal for user to choose authorization or refusal.

[0072] In the field of financial payment, users may simultaneously initiate complex transaction requests such as cross-border payment, member benefit redemption, dynamic coupon matching, etc., which require real-time processing of multi-source data (such as user identity, transaction history, geographic location, merchant policy, etc.) and generation of payment decisions that conform to the context.

[0073] The existing Model Context Protocol (MCP) protocol mainly defines the capabilities of resources, tools, and prompt words. When an intelligent agent developer uses an external MCP service, there are three solutions: the first is to compile prompt words to call MCP tools, the second is to use the prompt word capabilities within the MCP service, and the third is to compile workflows to call MCP tools.

[0074] The traditional MCP protocol is mainly designed for single and atomic tool calls, and lacks native support for cross-tool and multi-step business processes. If the intelligent agent developer compiles workflows, the developer needs to read and understand complex payment product technical documents, handle state transmission and error recovery between steps, and has a high learning cost and debugging process.

[0075] If prompt words are not used directly, but are exposed to users in the thinking mode of large reasoning models, the payment experience for users is not friendly, and from practical situations, it is found that large models cannot completely and strictly follow the payment logic in the prompt words to execute, so the effectiveness and consistency of the payment process cannot be guaranteed.

[0076] In summary, the existing technology cannot efficiently handle the dynamic adaptation of context information and payment logic. Traditional payment systems usually rely on the static rule base of centralized servers and cannot flexibly cope with context changes in complex scenarios (such as sudden changes in user behavior patterns, temporary policy adjustments, etc.), resulting in low transaction efficiency, high error rate, or poor user experience.

[0077] Therefore, in order to enable external intelligent agents to access system payment capabilities, compile prompt words with complex payment logic to schedule different payment MCP service tools, and better enable access agent to use payment MCP services, reduce the learning cost of payment products, the MCP protocol is extended, the task flow calling protocol is supplemented, and is actually applied to the construction of payment MCP services.

[0078] The technical solutions of the present application and how the technical solutions of the present application solve the above technical problems will be described in detail below. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of the present application will be described below with reference to the drawings.

[0079] The payment system based on the model context protocol (MCP) can include a payment agent, a payment MCP integrated server, and a payment interface integrated gateway. Optionally, MCP is a specific protocol specification that defines how to interact and communicate between various components in the payment system based on models and context information. By following the MCP protocol, different payment components can exchange data and business collaboration in a unified manner.

[0080] The payment agent can be the front-end interaction entrance of the payment system, providing a convenient payment operation interface and intelligent payment service for users. Optionally, the payment agent can include a large language model (LLM) and a model context protocol client (MCP Client).

[0081] The LLM can be used for natural language dialogue with the user, understand the user's intention and generate responses that meet the context, for example, the LLM can parse the user's vague payment requirements (such as "help me complete this 100 yuan payment"), and extract key information (payment).

[0082] The MCP Client can be used to convert the abstract instructions generated by the LLM (such as "execute the signing payment") into MCP protocol standard requests (such as workflow / call) and send them to the payment MCP integrated server. The MCP Client can also receive data returned by the payment MCP integrated server through the MCP protocol communication and parse it into natural language feedback that the LLM can understand (such as "signing success, payment has been initiated").

[0083] The payment MCP integrated server can be the core server in the payment system responsible for integrating and managing payment services based on the MCP protocol. It receives payment requests from the payment agent, parses and processes the requests according to the MCP protocol, coordinates the payment interface integrated gateway to complete the actual payment operation, and feeds back the payment result to the payment agent. Optionally, the payment MCP integrated server includes any one or more of the MCP service interface module, the payment capability tool module, the payment capability execution module, and the payment capability prompt word module.

[0084] The MCP service interface module can be used as a bridge for communication between the payment MCP integrated server and the payment agent, and can be responsible for protocol parsing, request routing, and response packaging. The payment capability tool module can provide atomic operation interfaces related to payment, such as order creation, payment link generation, refund processing, etc., for other modules to call.

[0085] The payment capability execution module can be used to call specific interfaces of the payment capability tool module, execute business logic (such as processing a user payment request, triggering a refund process), and manage transactions and exceptions. The payment capability prompt word module can define reusable prompt word templates and workflows, standardize the interaction mode of the LLM and the payment capability, and reduce the integration cost of the developer.

[0086] The payment interface integration gateway can be a bridge between the payment system and the bank system, responsible for converting and packaging the payment request initiated by the payment MCP integration server according to the interface format specified by the bank, and then sending it to the bank system for processing, and analyzing and converting the payment result returned by the bank system and returning it to the payment MCP integration server.

[0087] It should be noted that the payment method provided by the embodiments of the present application can be applied to the payment MCP integration server, and the execution subject of the payment MCP integration server can be any electronic device with processing capability, such as a computer.

[0088] Figure 1 A flowchart of a payment method provided by an embodiment of the present application is shown in FIG. 1. As shown in FIG. 1, the method comprises the following steps. Figure 1

[0089] S101, receiving a workflow execution instruction from a payment agent, and user interaction context information; the workflow execution instruction is generated by the payment agent based on the user interaction context information.

[0090] Optionally, the workflow execution instruction can be a command to trigger a workflow, which can include a workflow identifier and input parameters such as payment amount, payment method, etc.

[0091] The user interaction context information can be the full amount of data in the user payment process, which can include device environment information of the payment device used by the user, and payment tool information, etc.

[0092] Optionally, the device environment information of the payment device used by the user can reflect the status of the payment device used by the user and the related information of the environment where it is located, for example, it can include any one or more of the type of the device (mobile phone, tablet, etc.), the operating system version, the network connection state, the geographic location of the device, etc.

[0093] Optionally, the payment tool information can be the related information of the specific tool used by the user for payment, for example, the payment tool information can include any one or more of the bank to which the bank card belongs, the card type, the third-party payment platform account information, etc.

[0094] ​Optionally, the payment MCP integrated server can obtain the device environment information of the payment device used by the user by communicating with the payment device, and obtain the payment tool information by querying the system database.

[0095] Optionally, the payment MCP integrated server can receive the workflow execution instruction and the user interaction context information from the payment agent based on the MCP service interface module through the MCP protocol.

[0096] Optionally, the workflow execution instruction can be generated by analyzing the user interaction context information. For example, the payment agent analyzes the user's intention (such as "pay with a two-dimensional code") through the LLM and generates a structured instruction in combination with the context information (such as the user's risk level). For example, the MCP service interface module is called to send a workflow / call request.

[0097] S102, in response to the workflow execution instruction indicating execution of the payment workflow, inputting the user interaction context information into the payment workflow to obtain a to-be-processed payment task.

[0098] Optionally, the payment workflow can be a set of pre-defined steps and rules for completing a specific payment business, which can specify how the payment MCP integrated server should handle payment requests in different situations, such as steps of verifying user identity first, then selecting a payment channel, and finally executing payment.

[0099] The to-be-processed payment task can be a specific operation to be performed in the payment workflow, such as initiating a transfer request to a bank, verifying a user's payment password, deducting a user's account funds, etc. When the payment MCP integrated server is started, the payment workflow can be loaded into the memory of the payment MCP integrated server in advance.

[0100] Optionally, the to-be-processed payment task can be a command generated by the payment MCP integrated server based on the user interaction context information, which is used to indicate the execution of subsequent specific payment operations. It can include any one or more of the following key information: payment method, amount, payment object, etc. The payment MCP integrated server can analyze and process the context information using existing technologies to determine the corresponding payment workflow, and then obtain the to-be-processed payment task.

[0101] S103, sending the to-be-processed payment task to the payment interface integrated gateway to enable the payment interface integrated gateway to execute payment operations based on the to-be-processed payment task.

[0102] Optionally, the payment operation can be a specific behavior required by the to-be-processed payment task, such as a process of interacting with a bank system to complete payment.

[0103] Optionally, the payment MCP integration server can be connected and communicated with the payment interface integration gateway through Hyper Text Transfer Protocol Secure (HTTPS) to make it execute payment operations corresponding to the payment task to be processed.

[0104] In the embodiments of the present application, the payment MCP integration server can receive the workflow execution instruction and the user interaction context information generated by the payment agent based on the user interaction context information, and when the workflow execution instruction indicates to execute the payment workflow, input the user interaction context information into the payment workflow to obtain the payment task to be processed, and then send it to the payment interface integration gateway to execute the payment operation.

[0105] Compared with the problem that the traditional payment system in the prior art cannot flexibly cope with the change of context information in complex scenarios, the embodiments of the present application realize the interaction between the payment agent and the payment interface integration gateway through the MCP protocol, integrate the user interaction context information by using the payment workflow, automatically generate the payment task to be processed, simplify the payment process, improve the payment processing efficiency, and reduce the manual intervention and error rate.

[0106] In an implementation, the payment MCP integration server can store workflow information of a plurality of workflows. The plurality of workflows can include a payment workflow, and before receiving the workflow execution instruction from the payment agent, the payment MCP integration server can first receive a workflow information listing request from the payment agent.

[0107] Optionally, the workflow information of the plurality of workflows can include any one or more of a payment workflow, a points exchange workflow, a refund workflow, etc. The workflow information listing request can be a payment agent initiated acquisition request for acquiring all the basic information of the workflows stored by the payment MCP integration server.

[0108] In an implementation, the payment MCP integration server can receive a configuration file of a plurality of workflows, the configuration file including at least one of the following: a unique identifier of the workflow, a name of the workflow, a function description text of the workflow, a version number of the workflow, a processing node program in the workflow, a format of an input parameter of the workflow, and a format of an output parameter of the workflow, and store the configuration file.

[0109] Optionally, the unique identifier of the workflow can be a string or a number code used to uniquely identify a workflow. The name of the workflow can be an intuitive, concise and descriptive name of the workflow, which is used to facilitate people to understand and identify the purpose and function of the workflow. The function description text of the workflow can be a detailed description of the specific function of the workflow, which can be presented in the form of text, and can be used to explain the function, processing logic and expected results of the workflow.

[0110] Optionally, the version number of the workflow can be used to identify different versions of the workflow. The workflow can be composed of multiple processing nodes, each representing a specific task or operation, and the processing node program in the workflow can be a specific code or program module that implements these tasks or operations.

[0111] The format of the input parameter of the workflow can define the data format and specification of the input parameter required when the workflow starts to execute. The format of the output parameter of the workflow can define the data format and specification of the output result generated after the execution of the workflow is completed.

[0112] The embodiments of the present application facilitate the unified management and maintenance of the workflow by receiving the configuration files of multiple workflows, facilitate the query, modification and update of the workflow, and better adapt to the changes of the payment system business, improve the scalability and maintainability of the system.

[0113] In an embodiment, the memory data structure of the configuration parameters of the multiple workflows is a hash table data structure. Optionally, the memory data structure can be a way of organizing and storing data in the memory of a computer program.

[0114] The hash table data structure can directly access the data structure of the memory storage location according to the key (Key). It maps the key to an index of an array through a hash function, and then stores the key-value pair at the position corresponding to the index.

[0115] When a value corresponding to a certain key needs to be found, the same hash function is used to calculate the index of the key, and then the value is directly obtained from the position. In the embodiments of the present application, the unique identifier of each workflow can be used as the key, and the configuration parameters of the workflow (which can be encapsulated into an object or a structure) can be used as the value, which are stored in the hash table.

[0116] The memory data structure of the configuration files of the multiple workflows in the embodiments of the present application adopts the hash table data structure with fast search speed, which can obtain the required workflow configuration parameters in a short time, improves the query efficiency of the workflow configuration file, reduces the system waiting time, and improves the overall response speed of the payment system.

[0117] Secondly, the payment MCP integration server can send workflow information of multiple workflows to the payment agent in response to a workflow information listing request; and the workflow execution instruction is generated based on user interaction context information and the workflow information of the multiple workflows.

[0118] Optionally, the payment MCP integration server can send the workflow information of the multiple workflows to the payment agent through a workflow / list method of the MCP protocol, and the workflow information can include metadata of the workflows.

[0119] Optionally, the payment MCP integration server can first parse the user interaction context information to obtain key fields, match the workflow information of the multiple workflows based on the key fields, and then generate the workflow execution instruction.

[0120] Before receiving the workflow execution instruction of the payment agent, the embodiment of the application first receives a workflow information listing request and feeds back multiple workflow information, so that the payment agent generates a workflow execution instruction based on the information. This method enables the payment agent to fully understand the available workflows before initiating workflow execution, and to select a suitable workflow to generate an execution instruction according to actual needs, thereby improving the accuracy and efficiency of workflow execution and reducing workflow execution errors or failures caused by improper selection.

[0121] The interaction between the payment MCP integration server and the payment agent based on the MCP protocol is described in detail below.

[0122] The payment MCP integration server can first receive a workflow definition acquisition request from the payment agent based on the MCP protocol, and the workflow definition acquisition request can include an identifier of a first workflow. Secondly, the payment MCP integration server can feed back definition information of the first workflow to the payment agent in response to the workflow definition acquisition request.

[0123] Optionally, the workflow definition acquisition request can be used to request the server to acquire complete definition information of a specific workflow when the payment agent needs to understand the definition of the specific workflow in detail.

[0124] The workflow definition can include a flowchart of the workflow, processing node information, input and output parameter formats, etc. The identifier of the workflow can be a string uniquely identifying a specific workflow, which is used to accurately locate the workflow. For example, the workflow definition acquisition request can be a workflow / get method.

[0125] Optionally, the payment MCP integration server can encapsulate the definition information of the first workflow into a response format of the MCP protocol standard and feed back to the payment agent.

[0126] Similarly, the payment MCP integration server can first receive a workflow update request from the payment agent, the workflow update request including an identification of a second workflow. The payment MCP integration server can update the second workflow in response to the workflow update request.

[0127] Optionally, the workflow update request can be a modification command initiated by the payment agent to update the configuration of a certain workflow (e.g., adding a node, modifying a conditional logic). Exemplarily, the workflow update request can be a workflow / update method.

[0128] Optionally, the payment MCP integration server can replace part or all of the content in the second workflow definition with a new configuration and store it to update the second workflow.

[0129] The embodiments of the present application realize the interaction between the payment MCP integration server and the payment agent regarding the workflow definition and update through the MCP protocol, so that the payment agent can obtain and update the workflow information in time, ensure the consistency of the understanding of the workflow between the two parties, improve the flexibility and timeliness of the workflow management, and facilitate the adjustment and optimization of the workflow according to the business requirements.

[0130] The payment MCP integration server can also receive a workflow version management request from the payment agent; the workflow version management request including a timestamp; in response to the workflow version management request, feedback to the payment agent the information of a third workflow that has changed since the timestamp.

[0131] Optionally, the workflow version management request can be used to perform management operations on the version of the workflow, including any one or more of querying the version history of the workflow, upgrading the version of the workflow, rolling back to a specified version, etc. Exemplarily, the workflow version management request can be implemented through workflow / list_changed.

[0132] Optionally, the payment MCP integration server can feedback to the payment agent the information of the third workflow that has changed since the timestamp through version query.

[0133] The payment MCP integration server can also receive a workflow execution status and result acquisition request from the payment agent; the workflow execution status and result acquisition request including an identification of a fourth workflow; in response to the workflow execution status and result acquisition request, feedback to the payment agent the workflow execution status or result of the fourth workflow.

[0134] Optionally, the workflow execution status and result acquisition request can be a query command initiated by the payment agent to acquire the real-time execution status (e.g., running, completed) or final result (e.g., payment success / failure) of a specified workflow. Exemplarily, the workflow execution status and result acquisition request can be implemented through workflow / status.

[0135] The payment MCP integration server can also receive a workflow cancellation execution request from the payment agent; the workflow cancellation execution request comprises an identification of the fifth workflow; and in response to the workflow cancellation execution request, the execution of the fifth workflow is stopped.

[0136] Optionally, the workflow cancellation execution request can be a termination command initiated by the payment agent to interrupt a running workflow instance (e.g., user-initiated cancellation of payment). Exemplarily, the workflow cancellation execution request can be implemented through workflow / cancel.

[0137] The payment MCP integration server can also send a workflow status change notification to the payment agent.

[0138] Optionally, the workflow status change notification can be a message actively pushed by the payment MCP integration server to inform the payment agent of the status change (e.g., from "running" to "completed") of a certain workflow in real time. Exemplarily, the workflow status change notification can be implemented through workflow / notifications.

[0139] The embodiments of the present application realize comprehensive workflow management interaction through the MCP protocol, enabling the payment agent to grasp the version, execution status, etc. of the workflow in real time and to cancel the workflow, while the payment MCP integration server can timely notify the payment agent of the workflow status change, improving the real-time performance and controllability of workflow management.

[0140] The payment MCP integration server inputs the user interaction context information into the payment workflow to obtain a to-be-processed payment task, which is described in detail as follows. Figure 2 A flowchart of a method for obtaining a to-be-processed payment task provided by the embodiments of the present application is shown in FIG. 1. Figure 2 As shown in FIG. 1, the flow of obtaining a to-be-processed payment task comprises the following steps.

[0141] S201, determining a target payment tool based on the user interaction context information.

[0142] Optionally, the user interaction context information can be a set of interaction data generated in a payment scenario, and can include any one or more of user attributes, payment request parameters, behavior data, and environment information.

[0143] Optionally, the payment MCP integrated server can match the target payment tool from the user interaction context information through a rule engine. The payment MCP integrated server can also analyze the user interaction context information (such as geographic location, historical payment habits) to determine the target payment tool through a decision tree or a machine learning model.

[0144] In the case where the payment tool information is included in the user interaction context information, the payment MCP integrated server can determine the target payment tool based on the payment tool information.

[0145] Optionally, the payment MCP integrated server can directly extract the payment tool information from the user interaction context information to determine the target payment tool.

[0146] In the case where the payment tool information is not included in the user interaction context information, the payment MCP integrated server can perform user intent analysis based on the user interaction context information to obtain a user intent analysis result, and the user intent analysis result is used to represent the target payment tool.

[0147] Optionally, the payment MCP integrated server can extract key information based on the user interaction context information, map the user interaction context information to a predetermined user intent analysis using a rule engine or a machine learning model, sort the user intent analysis result according to a confidence level, and then determine the target payment tool.

[0148] According to different situations of the user interaction context information, the embodiments of the present application determine the target payment tool in different ways, which can quickly and accurately determine the payment tool using explicit information, and can also mine user demand from implicit information through intent analysis, improve the accuracy and flexibility of determining the target payment tool, and meet the payment demand in different scenarios.

[0149] S202, determining a payment sub-workflow based on the target payment tool.

[0150] Optionally, the payment sub-workflow can be an executable process fragment designed for a specific payment tool, and can include a series of atomic operations (such as generating a two-dimensional code, calling a payment gateway, verifying a signature, or any one or more of them).

[0151] Optionally, the payment MCP integration server can determine the payment sub-workflow based on a mapping relationship between the target payment tool and the payment sub-workflow. The mapping relationship can be pre-stored in the payment MCP integration server.

[0152] S203, execute the payment sub-workflow to obtain a to-be-processed payment task.

[0153] Optionally, the to-be-processed payment task can be a task object generated after execution of the payment sub-workflow and needing to be processed by the payment system or the third-party service, and includes a unique identifier and an execution instruction.

[0154] Optionally, the payment MCP integration server can instantiate the generated payment sub-workflow and submit it to a distributed task queue to obtain the to-be-processed payment task.

[0155] Embodiments of the present application accurately determine the target payment tool and the corresponding payment sub-workflow by gradually analyzing and processing user interaction context information, ensure that the generated to-be-processed payment task meets user needs and actual business scenarios, improve the accuracy and pertinence of the payment task, and reduce payment errors caused by improper selection of payment tools or sub-workflows.

[0156] On the basis of the above-mentioned embodiments, the payment sub-workflow is a subdivided part of the entire payment workflow, which can define a series of specific steps and operations for a specific payment scenario and user payment intention, and is used to complete a specific link or stage in the payment process.

[0157] In one implementation, the payment sub-workflow can include any one or more of a two-dimensional code payment sub-workflow, a signing payment sub-workflow, a transaction status query sub-workflow, a refund sub-workflow, and a cancellation sub-workflow.

[0158] The two-dimensional code payment sub-workflow can be a payment process that uses a two-dimensional code as an information carrier to realize fund transfer between a user and a merchant. The signing payment sub-workflow can be a payment process performed after a user and a payment service provider or a merchant reach a specific payment agreement and establish a long-term payment relationship.

[0159] The transaction status query sub-workflow can be a process module for querying the current state of a payment transaction. A user or a merchant can use the sub-workflow to learn about the processing progress and results of the transaction in real time, so as to take corresponding measures in a timely manner.

[0160] The refund sub-workflow can be a series of refund operation processes performed when it is necessary to refund the user's paid amount. The cancellation sub-workflow can be a process of canceling a payment agreement previously signed by a user and a payment service provider or a merchant, and terminating a long-term payment relationship.

[0161] The embodiments of the present application can include a plurality of payment sub-workflows, can enrich the functions of the payment system, and meet diversified payment requirements.

[0162] Taking that the payment sub-workflow can include a two-dimensional code payment sub-workflow as an example, Figure 3 A flowchart for obtaining a to-be-processed payment task based on a two-dimensional code payment sub-workflow provided by the embodiments of the present application is shown in FIG. 3. Figure 3 The flowchart can include the following steps:

[0163] S301, obtaining transaction information based on user interaction context information.

[0164] In an implementation manner, the user interaction context information can be dynamic data of a user terminal. For example, the payment MCP integrated server can obtain transaction information based on the interaction context information of the user terminal on a certain registration website.

[0165] The transaction information can include any one or more of a transaction order number, a transaction amount, and a transaction time. The transaction order number can represent a unique identifier of a transaction, and is used to distinguish different transactions. The transaction amount can represent the amount of funds involved in the transaction. The transaction time can record the specific time when the transaction occurs.

[0166] In another implementation manner, the user interaction context information can be static payment parameters pre-configured by a merchant. For example, the user interaction context information can be any one or more of a store name, a payment account, and the like. The payment MCP integrated server can obtain corresponding transaction information based on the user interaction context information.

[0167] Similarly, the payment MCP integrated server can obtain transaction information by analyzing the user interaction context information.

[0168] S302, generating a two-dimensional code link based on the transaction information.

[0169] Optionally, the two-dimensional code link can be a network link address formed by encoding transaction-related information in a specific format. The payment MCP integrated server can integrate and convert the information into the form of a two-dimensional code link according to the obtained transaction information, specific encoding rules, and algorithms.

[0170] S303, generating a two-dimensional code picture based on the two-dimensional code link.

[0171] Optionally, the two-dimensional code picture can be a graph presented in a black-and-white square pattern generated from the two-dimensional code link. It is a coding form that can be recognized by a camera of a mobile device (such as a mobile phone). A user can quickly obtain transaction information contained in the two-dimensional code picture by scanning the two-dimensional code picture, and then complete a payment operation.

[0172] Optionally, the payment MCP integrated server can use a two-dimensional code generation tool or algorithm, take the two-dimensional code link as input, and generate a visual two-dimensional code picture through a series of encoding and graphical processing.

[0173] S304, output the two-dimensional code picture through the payment agent.

[0174] Optionally, the payment MCP integrated server can transmit the two-dimensional code picture to the payment agent through the MCP service interface module. The payment agent can display the two-dimensional code picture on a display device (such as a mobile phone screen, a smart terminal display screen, etc.) associated with the payment agent, or send the two-dimensional code picture to a device specified by the user, so that the user can conveniently scan the two-dimensional code to perform a payment operation.

[0175] S305, obtain a to-be-processed payment task based on a transaction state after the two-dimensional code picture is output.

[0176] Optionally, the transaction state can be a current situation and stage of the transaction in the payment process. For example, the transaction state can include any one of the states of paid or unpaid. Correspondingly, if the transaction state is paid, a to-be-processed payment task that has been paid can be obtained; if the transaction state is unpaid, a to-be-processed payment task that has not been paid can be obtained.

[0177] Optionally, the payment MCP integrated server can monitor the transaction state in real time, and when the transaction state meets the condition for generating a to-be-processed payment task (for example, the user scans the two-dimensional code and completes payment confirmation), the payment MCP integrated server can generate a corresponding to-be-processed payment task according to a preset rule and process.

[0178] The embodiments of the present application can accurately obtain transaction information to generate a two-dimensional code, quickly provide a payment method for a user, output through a payment agent, facilitate user operation, obtain a to-be-processed payment task based on a transaction state, and timely complete a payment process to improve payment efficiency.

[0179] For example, a payment sub-workflow can include a signing payment sub-workflow, Figure 4 A process diagram for obtaining a to-be-processed payment task based on a signing payment sub-workflow is provided for the embodiments of the present application, as shown in Figure 4 The process can include:

[0180] S401, determine whether a user has signed up, and when the user has not signed up, obtain a user authorization result based on context information.

[0181] Optionally, the user subscription can be an agreement between the user and a payment service provider or other related institution, which specifies the rights and obligations of both parties in payment business. For example, the user subscribes to a certain payment method (such as fast payment, automatic deduction, etc.), which means that the user agrees to use the payment service in the manner and conditions specified in the agreement, and the payment service provider provides the corresponding payment function and service guarantee for the user according to the agreement.

[0182] Optionally, the context information can be similar to the above, and can include device environment information of the payment device used by the user, and payment tool information. The user authorization result can be a response of the user to an authorization request made by the payment MCP integrated server. The authorization result usually has two cases: agreeing to authorize or refusing to authorize.

[0183] Agreeing to authorize means that the user allows the payment MCP integrated server to use its related information or perform specific operations (such as obtaining user bank card information, making payment deduction, etc.) within a certain scope and conditions; refusing to authorize means that the user does not agree to the related request of the payment system, and the payment MCP integrated server will not be able to proceed with the subsequent operation as originally planned.

[0184] Optionally, the payment MCP integrated server can check whether the user has established a subscription relationship with the payment service provider by querying the internal database, interacting with the related business system, etc. When it is determined that the user has not subscribed, the payment MCP integrated server can initiate an authorization request to the user according to the context information through a suitable manner, and collect the response of the user to the request, so as to obtain the user authorization result. The way to obtain the authorization result can include popping up an authorization prompt window for the user to click to confirm or refuse, sending a short message verification code for the user to reply, etc.

[0185] S402, when the authorization result is used to represent that the user agrees to authorize, performing identity verification on the user.

[0186] Optionally, the identity verification can be to prevent others from using the user's identity to perform sensitive operations such as payment, and to protect the user's fund safety and transaction safety. The identity verification method can include any one or more of password verification, short message verification code verification, fingerprint recognition, face recognition, etc.

[0187] Optionally, the payment MCP integrated server can perform identity verification operation on the user according to the preset identity verification process and rules. For example, sending a short message verification code to the user's mobile phone, requiring the user to input the correct verification code, or calling the fingerprint recognition function of the device to let the user perform fingerprint scanning, etc.

[0188] S403, after the identity verification of the user is passed, obtaining the subscription state of the user.

[0189] Optionally, the subscription status can reflect the current situation of the subscription relationship between the user and the payment service provider. The subscription status can include any one of the following: unsubscribed, in subscription, subscription completed, subscription canceled, etc.

[0190] Optionally, when the user's identity verification operation meets the standard set by the payment MCP integrated service end, i.e., the identity information provided by the user is consistent with the information recorded by the payment MCP integrated service end, it can be considered that the user's identity verification is passed. At this time, the payment MCP integrated service end can query the internal database or interact with the related business system to obtain the latest subscription status information of the user.

[0191] S404, when the subscription status is used to represent that the subscription is completed, a payment request is initiated by the payment agent.

[0192] Optionally, the payment MCP integrated service end can initiate a payment request to the user according to the preset rules and processes through the payment agent. The payment request can include transaction amount, payee information, payer information, transaction type and other key information.

[0193] S405, based on the transaction state after initiating the payment request, a to-be-processed payment task is obtained.

[0194] Optionally, this step is similar to S305 described above, and will not be described here.

[0195] The embodiments of the present application can ensure that only authorized and identity-verified users can make subscription payments through multi-step verification and confirmation, avoid illegal operations, and obtain instructions based on the transaction state after initiating the payment request, thereby accurately completing the payment process and ensuring payment security.

[0196] Figure 5 A schematic diagram of a payment system provided by the embodiments of the present application is shown in FIG. 1. Figure 5 As shown in FIG. 1, the payment system can include three parts. The first part is a payment MCP integrated service (i.e., the payment MCP integrated service end described above), which can include an MCP service interface module, a payment capability workflow module, a payment capability tool module, a payment capability execution module, a payment capability prompt word module, and a unified data schema (a data structure) management module (i.e., the data management module described above).

[0197] The second part is a payment agent, which includes LLM and MCP Client and is an entrance for directly interacting with the user. The LLM can be used to understand the user's intention and generate a call plan. The MCP Client can be connected with the MCP service interface module through the MCP protocol.

[0198] The third part is the payment interface integration gateway, which is an Application Programming Interface (API) integration gateway of bank-related payment capabilities.

[0199] The connection relationship between the modules in the system is described in detail below. Figure 5

[0200] M1: MCP service interface module

[0201] M2: Payment capability module

[0202] M3: Payment capability prompt word module

[0203] M4: Payment capability execution module

[0204] M5: Unified data schema management module

[0205] M6: Payment capability workflow module

[0206] M1 can be connected to M2, M3, and M6. M2 can be connected to M4 and M5 for querying tool definitions. M4 can be connected to the payment interface integration gateway through HTTPS, M3 for routing decision consultation, and M5 for querying adapter configurations. M3 can be connected to M5 for querying prompt word definitions. M6 can be connected to M5 for obtaining workflow definitions. It should be noted that the above connection relationship can adopt the existing payment MCP integration service connection relationship.

[0207] The payment capability workflow module is described in detail below.

[0208] (1) Function description

[0209] This module is the business process arrangement and execution engine of the payment MCP integration service. It innovatively extends the MCP protocol and introduces workflow arrangement capabilities. This module is responsible for workflow registration, management, execution, and state tracking, and combines atomic payment tools into complete business processes, providing higher-level business abstraction and automation capabilities for Artificial Intelligence (AI) agents.

[0210] (2) Transmission method

[0211] Internal module interaction: the interaction between this module and other modules in the system is completed through programming language function calls.

[0212] Interaction with the unified data schema management module to read the configuration information of the extended API to generate extended tools; ​

[0213] With the payment capability tool module, the parameters in the workflow / call (a method) request are passed to the payment capability tool module by invocation, and the returned results thereof are received.

[0214] External exposure mode: The module itself does not directly process network requests. It communicates with the outside world through the MCP service interface module. The tool list and tool invocation results managed by it are encapsulated into standard JSON-RPC (a data format) messages by the MCP service interface module, and are transmitted to the MCP Client through server-sent events (SSE) or standard input / output (stdio).

[0215] (3) MCP protocol layer extension

[0216] A complete set of workflow management methods are added on the basis of the MCP protocol, as shown in Table 1:

[0217] Table 1

[0218]

[0219] (3) Processing logic

[0220] A. Capability declaration: Declare support for the workflow capability at server initialization, including supported methods and features. In the above methods, list, get, call, and status are basic methods, and only listChanged, update, cancel, and notifications are advanced features for workflow management, which need to be declared to support.

[0221] B. Workflow registration and storage: The workflow definition is in JSON (a data format) format, stored in the unified data Schema management module, and the payment capability workflow module loads the defined workflow at initialization. A complete workflow definition format is designed, including the following key fields, as shown in Table 2:

[0222] Table 2

[0223]

[0224] According to the execution process of the bank payment capability, a set of workflows can be designed.

[0225] Figure 6 A schematic diagram of a workflow provided for the embodiments of the present application is shown in FIG. 1. Figure 6 The detailed description is as follows:

[0226] 1. Main workflow main_payment_workflow, as shown in Table 3:

[0227] Table 3

[0228]

[0229] 2. Two-dimensional code payment subflow qr_code_payment_subflow, as shown in Table 4:

[0230] Table 4

[0231]

[0232] 3. Contract payment subflow contract_payment_subflow, as shown in Table 5:

[0233] Table 5

[0234]

[0235] 4. Query subflow query_payment_subflow, as shown in Table 6:

[0236] Table 6

[0237]

[0238] 5. Refund subflow refund_payment_subflow, as shown in Table 7:

[0239] Table 7

[0240]

[0241] 6. Unsign subflow unsign_payment_subflow, as shown in Table 8:

[0242] Table 8

[0243]

[0244] C. Tool binding: After obtaining the workflow declaration, each workflow step is automatically bound to the corresponding MCP tool. The actual input parameters of each workflow will be generated according to the collection of workflow definition parameters and definition parameters of the called tool, so that AI can automatically call various tools by triggering the workflow, realizing perfect separation of declarative programming and specific implementation.

[0245] D.Workflow Call: The client sends a workflow / call request to the MCP server to invoke a certain workflow. The MCP service provides a main workflow to simplify the access of the agent and also supports the agent to invoke a certain sub-process to implement the business logic. The agent can also actively cancel the execution of the workflow by invoking workflow / cancel.

[0246] The unified data Schema management module is described below in detail.

[0247] (1) Function description

[0248] The module is the metadata and configuration management center of the payment MCP integrated service and is a core component for realizing the standardization and automatic encapsulation of payment capabilities.

[0249] The module stores and manages global environment variable configurations and request / response data structures of extended payment tools through a set of predefined, machine-readable metadata configuration schemes (JSON Schema specification) and contains all information required for converting traditional payment APIs into MCP tools (including original interface definitions, parameter mapping rules, and prompt word templates).

[0250] The function of the module is to provide a unified interface and parameter specification definition for other modules, so that heterogeneous payment capabilities in the enterprise can be automatically and standardized encapsulated into MCP services that can be directly invoked by the agent, improving the extensibility and maintainability of the payment MCP integrated service.

[0251] (2) Transmission mode

[0252] Only internal module interaction is supported, and the interaction between the module and other modules in the system is completed through programming language function call.

[0253] (3) Processing logic

[0254] The core of the processing logic of the module is the loading, parsing, and providing of metadata, and the module internally has a high-efficiency Schema cache query center.

[0255] Figure 7 A schematic diagram of the unified data Schema management module provided by the embodiments of the present application is shown in FIG. 1. Figure 7 As shown in FIG. 1, the unified data Schema management module can include:

[0256] (1) Initialization and loading

[0257] At system startup, the module automatically loads and parses all the configuration files from predefined paths (e.g. the config / schemas directory) that define the complete metadata in a standard structure, which the module parses into internal in-memory data structures (e.g. hash tables) for fast querying.

[0258] (2) Query processing

[0259] The module provides a series of read-only query functions for other modules, when other modules initiate a query through function calls, the module performs a fast lookup in the in-memory metadata cache according to the query primary key.

[0260] If there is a query result, the corresponding JSON Schema (a data object) object or configuration information is directly returned to the caller, if there is no query result, an error message is returned.

[0261] For example, the payment capability workflow module obtains workflow information through the unified data Schema management module, and the unified data Schema management module feeds back the workflow information to the payment capability workflow module.

[0262] It should be noted that the interaction between other modules and the unified data Schema management module is consistent with this process, and will not be described here.

[0263] For example, an example of a basic toolset is provided as shown in Table 9:

[0264] Table 9

[0265]

[0266]

[0267]

[0268]

[0269]

[0270] In summary, the embodiment of the application extends the workflow capability on the basis of the MCP protocol. The MCP protocol is innovatively extended, and the workflow / list, workflow / get, workflow / call and other methods are newly added, the declarative arrangement and synchronous execution of the payment process are supported, and compatibility with the existing MCP protocol is maintained by dynamically generating tools for each workflow. In the bank payment MCP service, a verified workflow template is defined, the intelligent payment routing decision workflow and the workflow for executing multiple payment capabilities are standardized and encapsulated, the calling mode of the intelligent agent is simplified, and the quality of the payment service is improved.

[0271] On the other hand, the embodiment of the application implements the conversion specification and mechanism of the automatic API to the MCP service. The financial payment capability is encapsulated as an MCP service, an intelligent payment service hub between the multi-payment channel and the AI intelligent agent is constructed, the standardized and declarative MCP interface is provided to the intelligent agent, and various heterogeneous payment APIs are aggregated and adapted. By abstracting the request / response parameters of the multiple payment APIs, a descriptive data structure specification (a metadata configuration scheme) that can be stably understood by the large model is refined. The developers in the enterprise only need to describe and supplement the input / output parameters of the API according to the specification, and the conversion tool of the MCP service can automatically encapsulate the API as a standard MCP tool that can be directly called by the intelligent agent.

[0272] Therefore, the embodiment of the application has the following technical effects:

[0273] 1. The limitations of the existing MCP protocol in complex business process processing are solved.

[0274] From the perspective of the workflow capability extended based on the MCP protocol, firstly, the compatibility is high, and the existing functions are not affected by the extension based on the existing MCP protocol; secondly, the flexibility is high, the workflow supports dynamic selection of the execution path based on the context, parameterized configuration and dynamic adjustment, and meets the individual needs of different business scenarios. The intelligent agent developer can simply call the MCP service workflow template to complete the payment process, or customize the workflow template combined with the own business logic, thereby reserving the development freedom while reducing the development cost and maintenance complexity of the intelligent agent payment process.

[0275] From the perspective of the overall payment MCP service construction, a unified abstraction layer supporting multiple payment capabilities is constructed, the complex adaptation problem is solved by a single integration point, and the intelligent agent is integrated once to seamlessly call all the integrated payment capabilities.

[0276] 2. The user payment experience is improved.

[0277] Change the rigid mode of pre-configuration of payment process by merchants in the prior art, solve the problem that the payment process cannot be dynamically adjusted according to real-time scenes, realize the intelligentization and personalization of payment decision, and improve the terminal user experience.

[0278] 3. Quickly seal the MCP service.

[0279] The technical threshold, workload and time cost of modifying and accessing the existing traditional API to the agent ecology are reduced, the traditional payment capability is realized, the MCP is promoted, and the ecology is prosperous.

[0280] The above is the method embodiment provided by the present application, and the device provided by the present application will be described below.

[0281] Figure 8 The structure diagram of the payment device provided by the present application, the payment system based on the model context protocol MCP includes: a payment agent, a payment MCP integrated service end, and a payment interface integrated gateway, and the device is applied to the payment MCP integrated service end, as shown in Figure 8 The payment device 500 provided by the present embodiment includes: a receiving module 501, an executing module 502, and a sending module 503. Optionally, the payment device 500 can further include a processing module 504.

[0282] The receiving module 501 is configured to receive a workflow execution instruction and user interaction context information from the payment agent, and the workflow execution instruction is generated by the payment agent based on the user interaction context information.

[0283] The executing module 502 is configured to input the user interaction context information into the payment workflow in response to the workflow execution instruction for instructing to execute the payment workflow, and obtain a to-be-processed payment task.

[0284] The sending module 503 is configured to send the to-be-processed payment task to the payment interface integrated gateway, so that the payment interface integrated gateway performs a payment operation based on the to-be-processed payment task.

[0285] Optionally, the payment MCP integrated service end stores: workflow information of a plurality of workflows; the plurality of workflows include: a payment workflow, before the receiving module 501 is configured to receive the workflow execution instruction from the payment agent, the processing module 504 is configured to receive a workflow information listing request from the payment agent. In response to the workflow information listing request, the workflow information of the plurality of workflows is sent to the payment agent; the workflow execution instruction is generated by the payment agent based on the user interaction context information and the workflow information of the plurality of workflows.

[0286] Optionally, the processing module 504 is further configured to receive configuration files of a plurality of work flows, the configuration files comprising at least one of: a unique identifier of the work flow, a name of the work flow, a functional description text of the work flow, a version number of the work flow, a processing node program in the work flow, a format of an input parameter of the work flow, and a format of an output parameter of the work flow. The configuration files are stored.

[0287] Optionally, the memory data structure of the configuration files of the plurality of work flows is a hash table data structure.

[0288] Optionally, the processing module 504 is further configured to interact with the payment agent based on the MCP protocol in at least one of: receiving a work flow definition acquisition request from the payment agent, the work flow definition acquisition request comprising an identifier of a first work flow; in response to the work flow definition acquisition request, feeding back definition information of the first work flow to the payment agent; receiving a work flow update request from the payment agent, the work flow update request comprising an identifier of a second work flow; in response to the work flow update request, updating the second work flow.

[0289] Optionally, the processing module 504 is further configured to interact with the payment agent based on the MCP protocol in at least one of: receiving a work flow version management request from the payment agent, the work flow version management request comprising a time stamp; in response to the work flow version management request, feeding back information of a third work flow that has been changed since the time stamp to the payment agent; receiving a work flow execution state and result acquisition request from the payment agent, the work flow execution state and result acquisition request comprising an identifier of a fourth work flow; in response to the work flow execution state and result acquisition request, feeding back a work flow execution state or result of the fourth work flow to the payment agent; receiving a work flow cancellation execution request from the payment agent, the work flow cancellation execution request comprising an identifier of a fifth work flow; in response to the work flow cancellation execution request, stopping execution of the fifth work flow; and sending a work flow state change notification to the payment agent.

[0290] In an embodiment, the execution module 502 is specifically configured to determine a target payment tool based on the user interaction context information. Based on the target payment tool, a payment sub-work flow is determined. The payment sub-work flow is executed to obtain a to-be-processed payment task.

[0291] For example, the execution module 502 is specifically configured to, in a case where the user interaction context information comprises payment tool information, determine the target payment tool based on the payment tool information. In a case where the user interaction context information does not comprise the payment tool information, perform user intention analysis based on the user interaction context information to obtain a user intention analysis result, the user intention analysis result being used to represent the target payment tool.

[0292] Exemplarily, the payment sub-workflow is a two-dimensional code payment sub-workflow, and the execution module 502 is specifically configured to acquire transaction information based on the user interaction context information. Based on the transaction information, a two-dimensional code link is generated. Based on the two-dimensional code link, a two-dimensional code picture is generated. The two-dimensional code picture is output through the payment agent. Based on the transaction state after the two-dimensional code picture is output, the to-be-processed payment task is obtained.

[0293] Exemplarily, the payment sub-workflow is a signing payment sub-workflow, and the execution module 502 is specifically configured to determine whether the user has signed up, and determine the user authorization result based on the user interaction context information when the user has not signed up. When the authorization result is used to represent that the user agrees to authorize, the identity of the user is verified. After the identity of the user is verified, the signing state of the user is acquired. When the signing state is used to represent that the signing is completed, the payment request is initiated through the payment agent. Based on the transaction state after the payment request is initiated, the to-be-processed payment task is obtained.

[0294] Exemplarily, the payment sub-workflow includes at least one of the following: a transaction state query sub-workflow, a refund sub-workflow, and a cancellation sub-workflow.

[0295] The payment device provided in the embodiment can execute the method provided in any of the above method embodiments, and has similar implementation principles and technical effects, which will not be described here in detail.

[0296] Figure 9 A structural schematic diagram of an electronic device provided in the present application is shown in FIG. 6. Figure 9 As shown in FIG. 6, the electronic device 600 provided in the embodiment includes at least one processor 601 and a memory 602. Optionally, the device 600 further includes a communication component 603. The processor 601, the memory 602, and the communication component 603 are connected through a bus 604.

[0297] In the specific implementation process, the at least one processor 601 executes the computer execution instructions stored in the memory 602, so that the at least one processor 601 executes the above method.

[0298] The specific implementation process of the processor 601 can refer to the above method embodiments, and has similar implementation principles and technical effects, which will not be described here in detail.

[0299] In the above embodiments, it should be understood that the processor can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor. The steps of the method disclosed in combination with the application can be directly embodied as hardware processor execution, or executed by a combination of hardware and software modules in the processor.

[0300] The memory can include a random access memory (RAM), and can also include a non-volatile memory (NVM), such as at least one disk memory.

[0301] The bus can be an industry standard architecture (ISA) bus, a peripheral component (PCI) bus, or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the bus in the drawings of the present application does not limit to only one bus or one type of bus.

[0302] The present application also provides a computer program product, comprising a computer program, which is executed by a processor to implement the above method.

[0303] The present application also provides a computer readable storage medium, which stores computer execution instructions, and when a processor executes the computer execution instructions, the above method is implemented.

[0304] The above readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0305] An example readable storage medium is coupled to the processor such that the processor can read information from the readable storage medium and can write information to the readable storage medium. Of course, the readable storage medium can also be a part of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (ASIC). Of course, the processor and the readable storage medium can also exist as discrete components in the device.

[0306] The division of units is only a logical functional division, and in actual implementation, there can be another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units shown or discussed can be indirect coupling or communication connection through some interfaces, devices or units, and can be electrical, mechanical or other forms.

[0307] The units described as separate components can or can not be physically separated, and the components shown as units can or can not be physical units, that is, can be located in one place, or can be distributed on a plurality of network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiment scheme.

[0308] In addition, the functional units in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit.

[0309] If the functions are realized in the form of software function units and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application or the essential part or part of the technical solutions that make contributions to the prior art can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the embodiments of the present application. The foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various program code storage media.

[0310] Those skilled in the art can understand that all or part of the steps of the foregoing method embodiments can be completed by program instruction related hardware. The foregoing program can be stored in a computer readable storage medium. The program executes to perform the steps of the foregoing method embodiments; and the foregoing storage medium includes various storage media that can store program codes, such as ROM, RAM, magnetic disk, or optical disk.

[0311] Finally, it should be noted that other embodiments of the present application will become readily apparent to those skilled in the art from the disclosure herein, wherein the present application is intended to be limited only by the scope of the appended claims, and the reasonable interpretation of equivalency thereof.

Claims

1. A payment method, characterized in that, A payment system based on Model Context Protocol (MCP) includes: a payment agent, a payment MCP integration server, and a payment interface integration gateway. The method is applied to the payment MCP integration server, and the method includes: The system receives workflow execution instructions from the payment agent, as well as user interaction context information; the workflow execution instructions are generated by the payment agent based on the user interaction context information. In response to a workflow execution instruction to instruct the execution of a payment workflow, the user interaction context information is input into the payment workflow to obtain a payment task to be processed. The pending payment task is sent to the payment interface integration gateway so that the payment interface integration gateway can perform a payment operation based on the pending payment task.

2. The method according to claim 1, characterized in that, The payment MCP integration server stores workflow information for multiple workflows. The plurality of workflows includes: the payment workflow, wherein, prior to receiving the workflow execution instruction from the payment agent, the method further includes: Receive workflow information listing request from the payment agent; In response to the workflow information listing request, the workflow information of the multiple workflows is sent to the payment agent; the workflow execution instructions are generated by the payment agent based on the user interaction context information and the workflow information of the multiple workflows.

3. The method according to claim 2, characterized in that, The method further includes: The configuration file of the plurality of workflows is received, the configuration file including at least one of the following: a unique identifier of the workflow, a name of the workflow, a functional description text of the workflow, a version number of the workflow, a processing node program in the workflow, a format of the input parameters of the workflow, and a format of the output parameters of the workflow; The configuration file is stored.

4. The method according to claim 3, characterized in that, The memory data structure of the configuration files for the multiple workflows is a hash table data structure.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: Based on the MCP protocol, perform at least one of the following interactions with the payment agent: Receive a workflow definition acquisition request from the payment agent; the workflow definition acquisition request includes an identifier of a first workflow; in response to the workflow definition acquisition request, feed back the definition information of the first workflow to the payment agent; Receive a workflow update request from the payment agent; the workflow update request includes an identifier of the second workflow; in response to the workflow update request, update the second workflow.

6. The method according to claim 5, characterized in that, The method further includes: Based on the MCP protocol, the payment agent also performs at least one of the following interactions: Receive a workflow version management request from the payment agent; the workflow version management request includes a timestamp; in response to the workflow version management request, provide the payment agent with information on a third workflow that has changed since the timestamp; Receive a workflow execution status and result acquisition request from the payment agent; the workflow execution status and result acquisition request includes the identifier of the fourth workflow; in response to the workflow execution status and result acquisition request, feed back the workflow execution status or result of the fourth workflow to the payment agent; Receive a workflow cancellation request from the payment agent; the workflow cancellation request includes an identifier of the fifth workflow; in response to the workflow cancellation request, stop executing the fifth workflow; Send a workflow status change notification to the payment agent.

7. The method according to any one of claims 1-4, characterized in that, The step of inputting the user interaction context information into the payment workflow to obtain the payment task to be processed includes: Based on the user interaction context information, the target payment tool is determined; Based on the target payment tool, determine the payment sub-workflow; The payment sub-workflow is executed to obtain the payment task to be processed.

8. The method according to claim 7, characterized in that, The step of determining the target payment tool based on the user interaction context information includes: If the user interaction context information includes payment tool information, the target payment tool is determined based on the payment tool information; If the payment tool information is not included in the user interaction context information, user intent analysis is performed based on the user interaction context information to obtain user intent analysis results, which are used to characterize the target payment tool.

9. The method according to claim 7, characterized in that, The payment sub-workflow is a QR code payment sub-workflow. Executing the payment sub-workflow to obtain the payment task to be processed includes: Transaction information is obtained based on the user interaction context information; Based on the transaction information, a QR code link is generated; Based on the QR code link, generate a QR code image; The QR code image is output through the payment smart agent; Based on the transaction status after outputting the QR code image, the payment task to be processed is obtained.

10. The method according to claim 7, characterized in that, The payment sub-workflow is a contract payment sub-workflow. Executing the payment sub-workflow to obtain the payment task to be processed includes: If the user has signed a contract, and if the user has not signed a contract, the user authorization result is obtained based on the user interaction context information. When the authorization result is used to indicate that the user agrees to the authorization, the user is authenticated; After the user's identity is verified, the user's contract status is obtained; The signing status is used to indicate that the signing is complete, and a payment request is initiated through the payment agent. The pending payment task is obtained based on the transaction status after the payment request is initiated.

11. The method according to claim 7, characterized in that, The payment sub-workflow includes at least one of the following: transaction status query sub-workflow, refund sub-workflow, and contract cancellation sub-workflow.

12. A payment device, characterized in that, A payment system based on Model Context Protocol (MCP) includes: a payment agent, a payment MCP integration server, and a payment interface integration gateway. The device is applied to the payment MCP integration server and includes: The receiving module is configured to receive workflow execution instructions from the payment agent, as well as user interaction context information; the workflow execution instructions are generated by the payment agent based on the user interaction context information. The execution module is used to respond to the workflow execution instruction to instruct the execution of the payment workflow, input the user interaction context information into the payment workflow, and obtain the payment task to be processed; The sending module is used to send the payment task to be processed to the payment interface integration gateway, so that the payment interface integration gateway can perform a payment operation based on the payment task to be processed.

13. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-11.

15. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-11.

Images