Payment method, apparatus, device, medium, and program product

Abstract

Embodiments of the present application provide a payment method, device, equipment, medium and program product. 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 includes 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. In response to the workflow execution instruction indicating execution of a payment workflow, the user interaction context information is input to the payment workflow to obtain a to-be-processed payment task. The to-be-processed payment task is sent 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. The method is used to improve payment efficiency and user experience.

Description

Technical Field

[0001] This application relates to the field of financial payments, and more particularly to a payment method, device, equipment, medium, and program product. Background Technology

[0002] In the field of financial payments, users may initiate multiple complex transaction requests simultaneously. These transactions require real-time processing of multi-source data and the generation of payment decisions that conform to the context.

[0003] Existing technologies struggle to efficiently handle the dynamic adaptation of contextual information to payment logic. Traditional payment systems typically rely on a centralized server's static rule base, which cannot flexibly respond to contextual changes in complex scenarios (such as sudden changes in user behavior patterns or temporary policy adjustments), resulting in low transaction efficiency, high error rates, or poor user experience.

[0004] Therefore, how to achieve intelligent, dynamic, and highly adaptable payment processes to significantly improve payment efficiency and user experience in complex scenarios is an urgent problem to be solved. Summary of the Invention

[0005] This application provides a payment method, apparatus, device, medium, and program product to improve payment efficiency and user experience.

[0006] In a first aspect, embodiments of this application provide a payment method. A payment system based on a 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:

[0007] 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.

[0008] 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.

[0009] 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.

[0010] In one possible implementation, the payment MCP integration server stores workflow information for multiple workflows; the multiple workflows include the payment workflow, and before receiving workflow execution instructions from the payment agent, the method further includes:

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

[0012] 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.

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

[0014] 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;

[0015] The configuration file is stored.

[0016] In one possible implementation, the in-memory data structure of the configuration files for the multiple workflows is a hash table data structure.

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

[0018] Based on the MCP protocol, perform at least one of the following interactions with the payment agent:

[0019] 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;

[0020] 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.

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

[0022] Based on the MCP protocol, the payment agent also performs at least one of the following interactions:

[0023] 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;

[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] Based on the transaction status after outputting the QR code image, the payment task to be processed is obtained.

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

[0041] 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.

[0042] When the authorization result is used to indicate that the user agrees to the authorization, the user is authenticated;

[0043] After the user's identity is verified, the user's contract status is obtained;

[0044] The signing status is used to indicate that the signing is complete, and a payment request is initiated through the payment agent.

[0045] The pending payment task is obtained based on the transaction status after the payment request is initiated.

[0046] In one possible implementation, the payment sub-workflow includes at least one of the following: a transaction status query sub-workflow, a refund sub-workflow, and a cancellation sub-workflow.

[0047] Secondly, embodiments of this application provide a payment device. The payment system based on the 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 the device includes:

[0048] 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.

[0049] 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;

[0050] 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.

[0051] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0052] The memory stores computer-executed instructions;

[0053] The processor executes computer execution instructions stored in the memory, causing the processor to perform the method described in any of the first aspects above.

[0054] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described in any of the first aspects above.

[0055] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method described in any of the first aspects above.

[0056] This application provides a payment method, apparatus, device, medium, and program product. The payment MCP integration server can receive workflow execution instructions and user interaction context information generated by the payment agent based on user interaction context information. When the workflow execution instruction indicates the execution of the payment workflow, the user interaction context information is input to obtain the payment task to be processed, which is then sent to the payment interface integration gateway for payment operation. Compared to the problem that traditional payment systems in the prior art cannot flexibly cope with changes in context information in complex scenarios, this application embodiment realizes the interaction between the payment agent and the payment interface integration gateway through the MCP protocol. It integrates user interaction context information using the payment workflow, automatically generates payment tasks to be processed, simplifies the payment process, improves payment processing efficiency, and reduces manual intervention and error rates. Attached Figure Description

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

[0058] Figure 1 A flowchart illustrating a payment method provided in an embodiment of this application;

[0059] Figure 2 A flowchart illustrating a method for obtaining a payment task to be processed, provided as an embodiment of this application;

[0060] Figure 3 This is a schematic diagram illustrating a process for obtaining payment tasks to be processed based on a QR code payment sub-workflow, as provided in an embodiment of this application.

[0061] Figure 4 A schematic diagram illustrating a process for obtaining payment tasks to be processed based on a contract payment sub-workflow, provided as an embodiment of this application;

[0062] Figure 5 A schematic diagram of a payment system provided in an embodiment of this application;

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

[0064] Figure 7 A schematic diagram of the unified data schema management module provided in an embodiment of this application;

[0065] Figure 8 A schematic diagram of the structure of a payment device provided in this application;

[0066] Figure 9 This is a schematic diagram of the structure of an electronic device provided in this application.

[0067] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0068] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.

[0069] In this application, the term "comprising" and its variations may refer to a non-limiting inclusion; the term "or" and its variations may refer to "and / or". The terms "first", "second", etc., in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0070] In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0071] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

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

[0073] The existing Model Context Protocol (MCP) mainly defines the capabilities of resources, tools, and prompt words. When agent developers use external MCP services, there are three options: the first is to write prompt words themselves to call MCP tools; the second is to use the prompt word capabilities within the MCP service; and the third is to arrange the workflow to call MCP tools themselves.

[0074] Traditional MCP protocols are primarily designed for single, atomic tool calls, lacking native support for cross-tool, multi-step business processes. If the agent developers orchestrate the workflow themselves, they need to thoroughly read and understand complex payment product technical documentation, and handle state transfer and error recovery between steps, resulting in significant learning costs and debugging processes.

[0075] If prompts are used directly without a workflow, the complex payment capability call prompts will be exposed to the user under the thinking mode of the large inference model, resulting in a less user-friendly payment experience. Furthermore, practical experience has shown that the large model cannot strictly follow the payment logic in the prompts, thus failing to guarantee the effectiveness and consistency of the payment process.

[0076] In summary, existing technologies struggle to efficiently handle the dynamic adaptation of contextual information to payment logic. Traditional payment systems typically rely on a centralized server's static rule base, which cannot flexibly respond to contextual changes in complex scenarios (such as sudden shifts in user behavior patterns or temporary policy adjustments), resulting in low transaction efficiency, high error rates, or poor user experience.

[0077] Therefore, in order to enable external intelligent agents to use payment MCP service tools by combining relatively complex payment logic to compile prompt words when accessing the system's payment capabilities, and to better enable the accessing intelligent agents to use payment MCP services and reduce the learning cost of payment products, this application extends the MCP protocol, supplements the task flow calling protocol, and is actually applied to the construction of payment MCP services.

[0078] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These 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 this application will now be described with reference to the accompanying drawings.

[0079] A payment system based on the Model Context Protocol (MCP) can include: a payment agent, a payment MCP integration server, and a payment interface integration gateway. Optionally, MCP is a specific protocol specification that defines how various components in a payment system interact and communicate based on model and context information. By adhering to the MCP protocol, different payment components can exchange data and collaborate in a unified manner.

[0080] A payment agent can serve as the front-end interactive entry point for a payment system, providing users with a convenient payment interface and intelligent payment services. Optionally, a payment agent may include a Large Language Model (LLM) and a Model Context Protocol Client (MCP Client).

[0081] LLM can be used to engage in natural language dialogue with users, understand user intent, and generate context-appropriate responses. For example, LLM can parse a user's vague payment request (such as "Help me complete this payment of 100 yuan") and extract key information (payment).

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

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

[0084] The MCP service interface module serves as a bridge between the payment MCP integration server and the payment intelligent agent, handling protocol parsing, request routing, and response encapsulation. The payment capability tool module provides atomic operation interfaces related to payment, such as order creation, payment link generation, and refund processing, for use by other modules.

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

[0086] A payment interface integration gateway can act as a bridge between the payment system and the banking system. It is responsible for converting and encapsulating the payment requests initiated by the payment MCP integration server according to the interface format specified by the bank, and then sending them to the banking system for processing. It also parses and converts the payment results returned by the banking system and returns them to the payment MCP integration server.

[0087] It should be noted that the payment method provided in this application embodiment can be applied to a payment MCP integration server. The execution entity of the payment MCP integration server can be any electronic device with processing capabilities, such as a user terminal or a server, for example, a computer.

[0088] Figure 1 This is a flowchart illustrating a payment method provided in an embodiment of this application. Figure 1 As shown, the method includes:

[0089] S101. Receive workflow execution instructions from the payment agent, and user interaction context information; the workflow execution instructions are generated by the payment agent based on the user interaction context information.

[0090] Optionally, the workflow execution instruction can be a command that triggers the workflow, which may include a workflow identifier and input parameters, such as payment amount, payment method, or any one or more of these.

[0091] User interaction context information can be all the data during the user's payment process, which may include device environment information of the payment device used by the user, as well as one or more of the payment tool information.

[0092] Optionally, the device environment information of the payment device used by the user can reflect the status of the payment device itself and related information about its environment. For example, it may include any one or more of the following: device type (mobile phone, tablet, etc.), operating system version, network connection status, device geographical location, etc.

[0093] Optionally, the payment instrument information may be related to the specific instrument used by the user for payment. For example, the payment instrument information may include any one or more of the following: the bank to which the bank card belongs, the card type, and the account information of the third-party payment platform.

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

[0095] Optionally, the payment MCP integration server can receive workflow execution instructions from the payment intelligent agent and user interaction context information through the MCP service interface module and the MCP protocol.

[0096] Optionally, workflow execution instructions can be generated by parsing user interaction context information. For example, the payment agent uses LLM to parse user intent (such as "pay with QR code") and combines it with contextual information (such as user risk level) to generate structured instructions. For instance, it might send a workflow / call request by invoking the MCP service interface module.

[0097] S102. In response to the workflow execution instruction, the user interaction context information is input into the payment workflow to obtain the payment task to be processed.

[0098] Optionally, a payment workflow can be a set of predefined steps and rules for completing a specific payment transaction. It can specify how the payment MCP integration server should handle payment requests under different circumstances, such as first verifying the user's identity, then selecting a payment channel, and finally executing the payment.

[0099] The payment tasks to be processed can be specific operations to be performed in the payment workflow, such as initiating a transfer request to the bank, verifying the user's payment password, deducting funds from the user's account, or any one or more of these. When the payment MCP integration server starts, the payment workflow can be loaded into the server's memory in advance.

[0100] Optionally, the payment task to be processed can be a command generated by the payment MCP integration server based on user interaction context information, used to instruct the execution of subsequent specific payment operations. It can include any one or more key information such as payment method, amount, and payment recipient. The payment MCP integration server can use existing technologies to analyze and process the context information to determine its corresponding payment workflow, thereby obtaining the payment task to be processed.

[0101] S103. Send the pending payment task to the payment interface integration gateway so that the payment interface integration gateway can perform payment operations based on the pending payment task.

[0102] Alternatively, the payment operation can be a specific action required by the payment task to be processed, such as interacting with a banking system to complete the payment process.

[0103] Optionally, the payment MCP integration server can connect and communicate with the payment interface integration gateway via Hyper Text Transfer Protocol Secure (HTTPS) to enable it to perform payment operations corresponding to the pending payment tasks.

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

[0105] Compared to the problem that traditional payment systems in the prior art cannot flexibly cope with changes in context information in complex scenarios, the embodiments of this application realize the interaction between the payment intelligent agent and the payment interface integration gateway through the MCP protocol. By integrating user interaction context information through the payment workflow, the payment tasks to be processed are automatically generated, simplifying the payment process, improving payment processing efficiency, and reducing manual intervention and error rate.

[0106] In one implementation, the payment MCP integration server can store workflow information for multiple workflows. These multiple workflows may include payment workflows, and before receiving workflow execution instructions 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 for multiple workflows may include any one or more of the following: payment workflow, points redemption workflow, refund workflow, etc. The workflow information listing request may be a retrieval request initiated by the payment agent to obtain basic workflow information stored on the payment MCP integration server.

[0108] In one implementation, the payment MCP integration server can receive configuration files for multiple workflows, each configuration file including at least one of the following: a unique identifier for the workflow, the name of the workflow, a functional description text of the workflow, a version number of the workflow, processing node programs in the workflow, the format of the input parameters of the workflow, and the format of the output parameters of the workflow, and store the configuration files.

[0109] Optionally, a workflow's unique identifier can be a string or numeric code used to uniquely identify a workflow. The workflow's name can be a visually intuitive and concise descriptive name, facilitating understanding and identification of its purpose and function. The workflow's functional description text can be a detailed description of the workflow's specific functions; it can be presented in text form and can be used to explain the workflow's role, processing logic, and expected results.

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

[0111] The format of workflow input parameters defines the data format and specifications of the input parameters required when the workflow starts executing. The format of workflow output parameters defines the data format and specifications of the output results generated after the workflow is completed.

[0112] This application embodiment, by receiving configuration files for multiple workflows, facilitates unified management and maintenance of workflows, makes it convenient to query, modify, and update workflows, better adapts to changes in payment system business, and improves the system's scalability and maintainability.

[0113] In one implementation, the in-memory data structure for the configuration parameters of multiple workflows is a hash table data structure. Alternatively, the in-memory data structure can be a way in which a computer program organizes and stores data in memory.

[0114] A hash table is a data structure that allows direct access to memory storage locations based on keys. It uses a hash function to map keys to indices in an array, then stores key-value pairs at the corresponding indexes.

[0115] When it is necessary to find the value corresponding to a certain key, the same hash function is used again to calculate the index of the key, and then the value is retrieved directly from that position. In this embodiment, the unique identifier of each workflow can be used as the key, and the configuration parameters of the workflow (which can be encapsulated as an object or structure) can be used as the value, stored in a hash table.

[0116] The memory data structure of the configuration files for multiple workflows in this embodiment adopts a hash table data structure with fast lookup speed, which can obtain the required workflow configuration parameters in a short time, improve the query efficiency of workflow configuration files, reduce system waiting time, and improve the overall response speed of the payment system.

[0117] Secondly, the payment MCP integration server can respond to workflow information listing requests and send workflow information of multiple workflows to the payment agent; the workflow execution instructions are generated by the payment agent based on user interaction context information and workflow information of multiple workflows.

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

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

[0120] In this embodiment, before receiving workflow execution instructions from the payment agent, the system first receives a list of workflow requests and provides feedback on multiple workflow information. This allows the payment agent to generate workflow execution instructions based on this information. This method enables the payment agent to fully understand available workflows before initiating workflow execution, and to select the appropriate workflow to generate execution instructions according to actual needs. This improves the accuracy and efficiency of workflow execution and reduces errors or failures caused by improper selection.

[0121] The following provides a detailed explanation of the interaction between the payment MCP integration server and the payment smart agent based on the MCP protocol.

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

[0123] Optionally, a workflow definition retrieval request can be used when a payment agent needs to know the definition of a specific workflow in detail to request the server to obtain the complete definition information of that workflow.

[0124] A workflow definition can include a flowchart, processing node information, and input / output parameter formats. The workflow identifier can be a unique string that identifies a specific workflow, used for precise workflow location. For example, the workflow definition retrieval request can be the 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 it back to the payment agent.

[0126] Similarly, the payment MCP integration server can first receive a workflow update request from the payment agent, which includes the identifier of the second workflow. The payment MCP integration server can then respond to the workflow update request and update the second workflow.

[0127] Optionally, a workflow update request can be a modification command initiated by a payment agent to update the configuration of a workflow (such as adding a node or modifying conditional logic). For example, the workflow update request can be the workflow / update method.

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

[0129] This application embodiment realizes the interaction between the payment MCP integration server and the payment intelligent agent regarding workflow definition and update through the MCP protocol, enabling the payment intelligent agent to obtain and update workflow information in a timely manner, ensuring that both parties have a consistent understanding of the workflow, improving the flexibility and timeliness of workflow management, and facilitating the adjustment and optimization of the workflow according to business needs.

[0130] The payment MCP integration server can also receive workflow version management requests from the payment agent; the workflow version management request includes a timestamp; in response to the workflow version management request, it feeds back to the payment agent information on third workflows that have changed since the timestamp.

[0131] Optionally, a workflow version management request can be used to manage workflow versions, including querying the workflow's version history, upgrading the workflow version, rolling back to a specified version, or any one or more of these operations. For example, this workflow version management request can be implemented using workflow / list_changed.

[0132] Optionally, the payment MCP integration server can use version queries to provide the payment agent with information on third workflows that have changed since the timestamp.

[0133] The payment MCP integration server can also receive workflow execution status and result retrieval requests from the payment agent; the workflow execution status and result retrieval requests include the identifier of the fourth workflow; in response to the workflow execution status and result retrieval requests, it feeds back the workflow execution status or result of the fourth workflow to the payment agent.

[0134] Optionally, the workflow execution status and result retrieval request can be a query command initiated by the payment agent to obtain the real-time execution status (e.g., running, completed) or final result (e.g., payment successful / failed) of a specified workflow. For example, the workflow execution status and result retrieval request can be implemented via workflow / status.

[0135] The payment MCP integration server can also receive workflow cancellation requests from payment agents; the workflow cancellation request includes the identifier of the fifth workflow; in response to the workflow cancellation request, the execution of the fifth workflow is stopped.

[0136] Optionally, a workflow cancellation request can be a termination command initiated by the payment agent to interrupt a running workflow instance (e.g., a user actively cancels a payment). For example, a workflow cancellation request can be implemented using the workflow / cancel function.

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

[0138] Optionally, workflow status change notifications can be messages proactively pushed by the payment MCP integration server to inform the payment agent in real time of changes in the status of a workflow (such as changing from "running" to "completed"). For example, workflow status change notifications can be implemented through workflow / notifications.

[0139] This application embodiment achieves comprehensive workflow management interaction through the MCP protocol, enabling the payment agent to grasp information such as workflow version and execution status in real time, and to cancel workflows. At the same time, the payment MCP integration server can promptly notify the payment agent of workflow status changes, improving the real-time performance and controllability of workflow management.

[0140] The following section provides a detailed explanation of how the payment MCP integration server inputs user interaction context information into the payment workflow to obtain payment tasks to be processed. Figure 2 This application provides a flowchart illustrating a method for obtaining payment tasks to be processed, as shown in the embodiments of this application. Figure 2 As shown, the process for obtaining payment tasks to be processed includes:

[0141] S201. Determine the target payment tool based on user interaction context information.

[0142] Optionally, the user interaction context information can be a set of interaction data generated in the payment scenario, which may include any one or more of the following: user attributes, payment request parameters, behavioral data, and environmental information. The target payment tool can be a payment channel selected by the user or recommended by the payment MCP integration server, and must match the payment methods supported by the merchant.

[0143] Optionally, the payment MCP integration server can match the target payment tool from user interaction context information using a rules engine. Alternatively, the payment MCP integration server can analyze user interaction context information (such as geographical location and historical payment habits) using decision trees or machine learning models to determine the target payment tool.

[0144] When the user interaction context includes payment tool information, the payment MCP integration server can determine the target payment tool based on the payment tool information.

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

[0146] If the user interaction context does not include payment tool information, the payment MCP integration server can perform user intent analysis based on the user interaction context to obtain user intent analysis results, which are used to characterize the target payment tool.

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

[0148] This application embodiment uses different methods to determine the target payment tool based on different user interaction context information. It can quickly and accurately determine the payment tool using explicit information, and can also mine user needs from implicit information through intent analysis, thereby improving the accuracy and flexibility of target payment tool determination and meeting payment needs in different scenarios.

[0149] S202. Based on the target payment tool, determine the payment sub-workflow.

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

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

[0152] S203. Execute the payment sub-workflow to obtain the payment tasks to be processed.

[0153] Optionally, the payment task to be processed can be a task object generated after the execution of the payment sub-workflow, which needs to be processed by the payment system or a third-party service, and contains a unique identifier and execution instructions.

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

[0155] This application embodiment accurately determines the target payment tool and corresponding payment sub-workflow by stepwise analyzing and processing user interaction context information, ensuring that the generated payment tasks to be processed meet user needs and actual business scenarios, improving the accuracy and relevance of payment tasks, and reducing payment errors caused by improper selection of payment tools or sub-workflows.

[0156] Based on the above embodiments, the payment sub-workflow is a subdivision of the entire payment workflow. It can define a series of specific steps and operations for specific payment scenarios and user payment intentions, in order to complete a specific link or stage in the payment process.

[0157] In one implementation, the payment sub-workflow may include any one or more of the following: QR code payment sub-workflow, contract payment sub-workflow, transaction status query sub-workflow, refund sub-workflow, and contract cancellation sub-workflow.

[0158] The QR code payment sub-workflow can be a payment process that uses QR codes as information carriers to realize the transfer of funds between users and merchants. The contract payment sub-workflow can be a payment process that takes place after a user and a payment service provider or merchant reach a specific payment agreement and establish a long-term payment relationship.

[0159] The transaction status query sub-workflow is a process module used to query the current status of payment transactions. Users or merchants can use this sub-workflow to understand the processing progress and results of transactions in real time, so as to take appropriate measures in a timely manner.

[0160] The refund sub-workflow can be used to execute a series of refund operations when there is a need to refund payments already made by a user. The termination sub-workflow can be the process by which a user terminates a previously signed payment agreement with a payment service provider or merchant, ending a long-term payment relationship.

[0161] The embodiments of this application may include multiple payment sub-workflows, which can enrich the functions of the payment system and meet diverse payment needs.

[0162] Taking the payment sub-workflow as an example, which may include a QR code payment sub-workflow, Figure 3 This application provides a schematic diagram of a process for obtaining payment tasks to be processed based on a QR code payment sub-workflow, as shown in the embodiments of this application. Figure 3 As shown, the process may include:

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

[0164] In one implementation, the user interaction context information can be dynamic data from the user's device. For example, the payment MCP integration server can obtain transaction information based on the user's interaction context on a registration website.

[0165] The transaction information may include one or more of the following: transaction order number, transaction amount, and transaction time. The transaction order number serves as a unique identifier for the transaction, distinguishing different transactions; the transaction amount represents the amount of funds involved in the transaction; and the transaction time records the specific moment the transaction occurred.

[0166] In another implementation, the user interaction context information can be static payment parameters pre-configured by the merchant. For example, the user interaction context information can be any one or more of the following: store name, receiving account, etc. The payment MCP integration server can obtain the corresponding transaction information based on this user interaction context information.

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

[0168] S302. Generate a QR code link based on transaction information.

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

[0170] S303. Generate a QR code image based on the QR code link.

[0171] Alternatively, the QR code image can be a graphic generated from a QR code link, presented as a black and white checkered pattern. It is a form of encoding that can be recognized by the camera of a mobile device (such as a mobile phone). By scanning the QR code image, users can quickly obtain the transaction information contained therein and complete the payment operation.

[0172] Optionally, the payment MCP integration server can use QR code generation tools or algorithms to take the QR code link as input and generate a visual QR code image through a series of encoding and graphical processing.

[0173] S304. Output a QR code image through the payment smart agent.

[0174] Optionally, the payment MCP integration server can transmit the QR code image to the payment agent via the MCP service interface module. The payment agent can then display the QR code image on a display device associated with it (such as a mobile phone screen, smart terminal display, etc.), or send the QR code image to a user-specified device, allowing the user to conveniently scan the QR code for payment.

[0175] S305. Based on the transaction status after outputting the QR code image, obtain the payment task to be processed.

[0176] Optionally, the transaction status can be the current state and stage of the transaction during the payment process. For example, the transaction status can include any status such as paid or unpaid. Accordingly, if the transaction status is paid, a paid pending payment task can be obtained; if the transaction status is unpaid, an unpaid pending payment task can be obtained.

[0177] Optionally, the payment MCP integration server can monitor the transaction status in real time. When the transaction status meets the conditions for generating a pending payment task (such as a user scanning a QR code and completing payment confirmation), the payment MCP integration server will generate the corresponding pending payment task according to preset rules and processes.

[0178] The embodiments of this application can accurately obtain transaction information to generate QR codes, quickly provide users with payment methods, output through a payment intelligent agent to facilitate user operation, obtain pending payment tasks based on transaction status, complete the payment process in a timely manner, and improve payment efficiency.

[0179] Taking the payment sub-workflow as an example, which may include a contract payment sub-workflow, Figure 4 This application provides a schematic diagram of a process for obtaining payment tasks to be processed based on a contract payment sub-workflow, as shown in the embodiments of this application. Figure 4 As shown, the process may include:

[0180] S401. Determine whether the user has signed a contract. If the user has not signed a contract, obtain the user's authorization result based on the context information.

[0181] Optionally, a user agreement can be an agreement between a user and a payment service provider or other relevant institution, which clarifies the rights and obligations of both parties regarding payment services. For example, when a user signs up to activate a certain payment method (such as quick payment, automatic deduction, etc.), it means that the user agrees to use the payment service in accordance with the methods and conditions stipulated in the agreement, and the payment service provider provides the user with the corresponding payment functions and service guarantees as agreed.

[0182] Optionally, the context information, similar to that described above, may include device environment information of the payment device used by the user, as well as payment instrument information. The user authorization result can be the user's response to the authorization request submitted by the payment MCP integration server. The authorization result typically falls into two categories: granting authorization or denying authorization.

[0183] Agreeing to authorization means that the user allows the payment MCP integration server to use its relevant information or perform specific operations (such as obtaining the user's bank card information, making payment deductions, etc.) within a certain scope and under certain conditions; refusing authorization means that the user does not agree to the relevant requests of the payment system, and the payment MCP integration server will be unable to perform subsequent operations as originally planned.

[0184] Optionally, the payment MCP integration server can check whether a user has established a contractual relationship with the payment service provider by querying the internal database and interacting with relevant business systems. If it is determined that the user has not signed a contract, the payment MCP integration server can, based on contextual information, initiate an authorization request to the user in an appropriate manner and collect the user's response to the request, thereby obtaining the user's authorization result. Methods for obtaining the authorization result may include displaying an authorization prompt window for the user to confirm or refuse, or sending an SMS verification code for the user to reply with.

[0185] S402. When the authorization result is used to represent that the user agrees to the authorization, the user is authenticated.

[0186] Optionally, identity verification can prevent unauthorized individuals from impersonating a user to perform sensitive operations such as payments, thereby ensuring the user's financial and transaction security. Identity verification methods may include any one or more of the following: password verification, SMS verification code verification, fingerprint recognition, facial recognition, etc.

[0187] Optionally, the payment MCP integration server can perform identity verification operations on users according to preset identity verification processes and rules. For example, it can send an SMS verification code to the user's mobile phone and require the user to enter the correct verification code; or it can call the device's fingerprint recognition function to allow the user to perform fingerprint scanning, or any one or more of these methods.

[0188] S403. After the user's identity is verified, obtain the user's contract status.

[0189] Optionally, the contract status can reflect the current status of the contractual relationship between the user and the payment service provider. The contract status may include any of the following: not signed, signing in progress, contract completed, or contract terminated.

[0190] Optionally, if the user's identity verification process meets the standards set by the payment MCP integration server—that is, the identity information provided by the user matches the information recorded by the payment MCP integration server—it can be considered that the user's identity verification has been successful. At this point, the payment MCP integration server can query its internal database or interact with relevant business systems to obtain the user's latest contract status information.

[0191] S404. In the signing status, the signing is indicated to be completed, and a payment request is initiated through the payment agent.

[0192] Optionally, the payment MCP integration server can initiate payment requests to users through payment smart agents according to preset rules and processes. These payment requests may include key information such as transaction amount, payee information, payer information, and transaction type.

[0193] S405. Based on the transaction status after initiating the payment request, obtain the payment tasks to be processed.

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

[0195] This application embodiment uses multi-step verification and confirmation to ensure that only authorized and verified users can make payment contracts, thus preventing illegal operations. After initiating a payment request, instructions are received based on the transaction status to accurately complete the payment process and ensure payment security.

[0196] Figure 5 A schematic diagram of a payment system provided in this application embodiment, such as... Figure 5 As shown, the payment system can consist of three parts. The first part is the payment MCP integration service (i.e., the aforementioned payment MCP integration server), 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 aforementioned data management module).

[0197] The second part is the payment intelligent agent, which includes an LLM (Limited Least Mechanism) and an MCP Client, serving as the entry point for direct interaction with the user. The LLM is used to understand user intent and generate a call plan. The MCP Client connects to the MCP service interface module via the MCP protocol.

[0198] The third part is the payment interface integration gateway, which is an application programming interface (API) integration gateway for bank-related payment capabilities.

[0199] The following is about Figure 5 The connections between the various modules are explained in detail.

[0200] M1: MCP service interface module

[0201] M2: Payment Capacity Module

[0202] M3: Payment Ability Prompt Module

[0203] M4: Payment Capability Execution Module

[0204] M5: Unified Data Schema Management Module

[0205] M6: Payment Capability Workflow Module

[0206] M1 can connect to M2, M3, and M6. M2 can connect to M4 and M5 for querying tool definitions. M4 can connect to the payment interface integration gateway via HTTPS, connect to M3 for routing decision consultation, and connect to M5 for querying adapter configurations. M3 can connect to M5 for querying prompt word definitions. M6 can connect to M5 to obtain workflow definitions. It should be noted that the above connection relationships can utilize existing connection relationships from the payment MCP integration service.

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

[0208] (1) Functional description

[0209] This module serves as the business process orchestration and execution engine for the payment MCP integration service. Through innovative extensions to the MCP protocol, it introduces workflow orchestration capabilities. This module is responsible for workflow registration, management, execution, and status tracking, combining atomic payment tools into complete business processes and providing a higher level of business abstraction and automation capabilities for artificial intelligence (AI) agents.

[0210] (2) Transmission method

[0211] Internal module interaction: This module interacts with other modules in the system through function calls in the programming language.

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

[0213] The payment capability tool module passes the parameters from the workflow / call (a method) request to the payment capability tool module via a call and receives the returned results.

[0214] External Exposure Method: This module itself does not directly handle network requests. It communicates with the outside world through the MCP service interface module. The list of tools it manages and the results of tool calls are encapsulated into standard JSON-RPC (a data format) messages by the MCP service interface module, and 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 has been added based on the MCP protocol, as shown in Table 1:

[0217] Table 1

[0218]

[0219] (3) Processing logic

[0220] A. Capability Declaration: Declare support for workflow capabilities during server initialization, including supported methods and features. Among the above methods, list, get, call, and status are basic methods, while only listChanged, update, cancel, and notifications are advanced effects for workflow management and need to be declared for support.

[0221] B. Workflow Registration and Storage: Workflow definitions are in JSON format and stored in the unified data schema management module. The payment capability workflow module loads the defined workflows during initialization. A complete workflow definition format has been designed, including the following key fields, as shown in Table 2:

[0222] Table 2

[0223]

[0224] Based on the execution process of bank payment capabilities, a workflow can be designed.

[0225] Figure 6 This is a schematic diagram of a workflow provided in an embodiment of this application. Figure 6 Detailed explanation is as follows:

[0226] 1. The main workflow, main_payment_workflow, is shown in Table 3:

[0227] Table 3

[0228]

[0229] 2. The QR code payment subflow (qr_code_payment_subflow) is shown in Table 4:

[0230] Table 4

[0231]

[0232] 3. The contract payment subflow is shown in Table 5:

[0233] Table 5

[0234]

[0235] 4. The query subflow, query_payment_subflow, is shown in Table 6:

[0236] Table 6

[0237]

[0238] 5. The refund subflow is shown in Table 7:

[0239] Table 7

[0240]

[0241] 6. The contract termination subflow, unsign_payment_subflow, is 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 based on the combination of the workflow definition parameters and the definition parameters of the called tool. In this way, AI can automatically call various tools by triggering the workflow, achieving a perfect separation between declarative programming and specific implementation.

[0245] D. Workflow Invocation: The client sends a workflow / call request to the MCP server to invoke a specific workflow. This MCP service provides the main workflow, simplifying agent access, and also supports agents calling individual sub-processes to implement business logic. Agents can also actively cancel workflow execution by calling workflow / cancel.

[0246] The Unified Data Schema Management module will be described in detail below.

[0247] (1) Functional description

[0248] This module serves as the metadata and configuration management center for the "Payment MCP Integration Service," and is a core component for achieving standardized and automated encapsulation of payment capabilities.

[0249] This module uses a predefined, machine-readable metadata configuration scheme (using the JSON Schema specification) to uniformly store and manage global environment variable configurations and extend the request / response data structure of payment tools. It contains all the information needed to convert traditional payment APIs into MCP tools (including original interface definitions, parameter mapping rules, and prompt word templates).

[0250] Its function is to provide a unified interface and parameter specification definition for other modules, so that heterogeneous payment capabilities within an enterprise can be automatically and standardizedly encapsulated into MCP services that can be directly called by intelligent agents, thereby improving the scalability and maintainability of payment MCP integration services.

[0251] (2) Transmission method

[0252] It only supports internal module interaction. The interaction between this module and other modules in the system is accomplished through function calls in the programming language.

[0253] (3) Processing logic

[0254] The core processing logic of this module is the loading, parsing and provision of metadata, and internally it is a high-efficiency schema cache query center.

[0255] Figure 7 This is a schematic diagram of the unified data schema management module provided in an embodiment of this application. Figure 7 As shown, the unified data schema management module may include:

[0256] (1) Initialization and loading

[0257] When the system starts, the module automatically loads and parses all configuration files from predefined paths (such as the config / schemas directory). These configuration files define complete metadata in a standard structure. The module parses these files into internal in-memory data structures (such as hash tables) for fast lookups.

[0258] (2) Query processing

[0259] This module provides a series of read-only query functions for other modules. When other modules initiate a query through function calls, this module quickly looks up the query primary key in the metadata cache in memory.

[0260] If there are query results, the corresponding JSON Schema (a type of data object) or configuration information will be returned directly to the caller; if there are no query results, an error message will be 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 the same as this process, and will not be elaborated here.

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

[0264] Table 9

[0265]

[0266]

[0267]

[0268]

[0269]

[0270] In summary, on the one hand, the embodiments of this application extend and define the workflow capabilities based on the MCP protocol. It innovatively extends the MCP protocol, adds the workflow capability, defines methods such as workflow / list, workflow / get, and workflow / call, supports the declarative orchestration and synchronous execution of the payment process, and maintains compatibility with the existing MCP protocol by dynamically generating tools for each workflow. In the bank payment MCP service, verified workflow templates are defined, standardizing and encapsulating the intelligent payment routing decision-making workflow and the workflows for executing various payment capabilities, simplifying the agent call method and improving the payment service quality.

[0271] On the other hand, the embodiments of this application implement the conversion specification and mechanism from automated APIs to MCP services. The financial payment capabilities are encapsulated as MCP services, constructing an intelligent payment service hub between diverse payment channels and AI agents. It provides a standardized and declarative MCP interface to agents upward, and aggregates and adapts various heterogeneous payment APIs downward. By abstracting the request / response parameters of multiple payment APIs, a descriptive data structure specification (a metadata configuration scheme) that can be stably understood by large models is refined. Developers within the enterprise only need to describe the input and output parameters of the API and supplement the metadata according to this specification, and then they can be automatically encapsulated as standard MCP tools that can be directly called by agents through the conversion tools supporting the MCP services.

[0272] Therefore, the embodiments of this application have the following technical effects: <00005S86><0000S87>1. It solves the limitations of the existing MCP protocol in handling complex business processes.

[0274] From the perspective of the workflow capabilities extended based on the MCP protocol, first, it has high compatibility, which is completely extended based on the existing MCP protocol without affecting existing functions. Second, it has high flexibility. The workflow supports dynamically selecting the execution path based on the context, parametric configuration, and dynamic adjustment to meet the personalized needs of different business scenarios. The agent development party can either simply call the MCP service workflow template to complete the payment process or customize the workflow template in combination with its own business logic, reducing the development cost and maintenance complexity of the agent payment process while retaining the development freedom.

[0275] From the overall construction of the payment MCP service, by constructing a unified abstraction layer that supports multi-terminal payment capabilities, complex adaptation problems are solved with a single integration point, enabling agents to seamlessly call all the connected payment capabilities with just one integration.

[0276] 2. It improves the user payment experience.

[0277] It changes the rigid model of payment process pre-configured statically by merchants in existing technologies, solves the problem that the payment process cannot be dynamically adjusted according to real-time scenarios, realizes intelligent and personalized payment decisions, and improves the end-user experience.

[0278] 3. Fast sealing and conversion to MCP service.

[0279] It lowers the technical barriers, workload, and time costs of transforming existing traditional APIs and integrating them into the intelligent agent ecosystem, realizing the "MCP-ization" of traditional payment capabilities and promoting the prosperity of the ecosystem.

[0280] The above are the method embodiments provided in this application. The apparatus provided in this application will be described below.

[0281] Figure 8 This application provides a schematic diagram of the structure of a payment device. The payment system based on the 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, such as... Figure 8 As shown, the payment device 500 provided in this embodiment includes: a receiving module 501, an execution module 502, and a sending module 503. Optionally, the payment device 500 may further include a processing module 504.

[0282] The receiving module 501 is used 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.

[0283] The execution module 502 is used to respond to the workflow execution instruction to instruct the execution of the payment workflow, input user interaction context information into the payment workflow, and obtain the payment task to be processed.

[0284] The sending module 503 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 payment operation based on the payment task to be processed.

[0285] Optionally, the payment MCP integration server stores workflow information for multiple workflows; these workflows include a payment workflow. Before the receiving module 501 receives workflow execution instructions from the payment agent, the processing module 504 receives a workflow information listing request from the payment agent. In response to the workflow information listing request, the processing module sends the workflow information for multiple workflows to the payment agent. The workflow execution instructions are generated by the payment agent based on user interaction context information and the workflow information for the multiple workflows.

[0286] Optionally, the processing module 504 is further configured to receive configuration files for multiple workflows, each configuration file including at least one of the following: a unique identifier for the workflow, the name of the workflow, a functional description text of the workflow, a version number of the workflow, processing node programs in the workflow, the format of the workflow's input parameters, and the format of the workflow's output parameters. The configuration files are then stored.

[0287] For example, the in-memory data structure of the configuration files for multiple workflows 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 the following ways: 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 the definition information of the first workflow to the payment agent; 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.

[0289] Optionally, the processing module 504 is further configured to interact with the payment agent based on the MCP protocol and perform at least one of the following interactions: 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, providing the payment agent with information about a third workflow that has changed since the timestamp; receiving a workflow execution status and result retrieval request from the payment agent; the workflow execution status and result retrieval request includes an identifier of a fourth workflow; in response to the workflow execution status and result retrieval request, providing the payment agent with information about the workflow execution status or result of the fourth workflow; receiving a workflow cancellation request from the payment agent; the workflow cancellation request includes an identifier of a fifth workflow; in response to the workflow cancellation request, stopping the execution of the fifth workflow; and sending a workflow status change notification to the payment agent.

[0290] In one implementation, the execution module 502 is specifically used to determine the target payment tool based on user interaction context information. Based on the target payment tool, a payment sub-workflow is determined. The payment sub-workflow is executed to obtain the payment tasks to be processed.

[0291] For example, execution module 502 is specifically used to determine the target payment tool based on the payment tool information when the user interaction context information includes payment tool information. When the user interaction context information does not include payment tool 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.

[0292] For example, the payment sub-workflow is a QR code payment sub-workflow. Execution module 502 is specifically used to obtain transaction information based on user interaction context information; generate a QR code link based on the transaction information; generate a QR code image based on the QR code link; output the QR code image through the payment agent; and obtain the payment task to be processed based on the transaction status after outputting the QR code image.

[0293] For example, the payment sub-workflow is a contract payment sub-workflow. Execution module 502 is specifically used to determine whether the user has signed a contract. If the user has not signed a contract, it obtains the user's authorization result based on the user's interaction context information. When the authorization result indicates that the user agrees to the authorization, the user is authenticated. After successful user authentication, the user's contract status is obtained. When the contract status indicates that the contract is complete, a payment request is initiated through the payment agent. Based on the transaction status after initiating the payment request, the pending payment task is obtained.

[0294] For example, the payment sub-workflow includes at least one of the following: transaction status query sub-workflow, refund sub-workflow, and cancellation sub-workflow.

[0295] The payment device provided in this embodiment can execute the methods provided in any of the above method embodiments. The implementation principle and technical effect are similar, and will not be described in detail here.

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

[0297] In a specific implementation, at least one processor 601 executes computer execution instructions stored in memory 602, causing at least one processor 601 to perform the above-described method.

[0298] The specific implementation process of processor 601 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0299] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

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

[0301] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0302] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0303] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0304] The aforementioned 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 storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0305] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0306] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0307] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0308] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0309] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0310] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0311] Finally, it should be noted that other embodiments of this application will readily conceive of by those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes may be made without departing from its scope.

Claims

1. A payment method, characterized in that, The payment system based on Model Context Protocol (MCP) includes: a payment agent, a payment MCP integration server, and a payment interface integration gateway. The payment MCP integration server stores workflow information for multiple workflows; the workflow information for multiple workflows includes any one or more of the following: payment workflow, points redemption workflow, and refund workflow. The method is applied to the payment MCP integration server, and the method includes: Receive workflow information listing request from the payment agent; In response to a workflow information listing request, workflow information for multiple workflows is sent to the payment agent via the workflow / list method of the MCP protocol. The workflow consists of multiple processing nodes, each representing a specific task or operation. The processing node programs in the workflow are the specific code or program modules that implement these tasks or operations. Furthermore, after obtaining the workflow declaration, each workflow step is automatically bound to the corresponding MCP tool. 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 used to instruct the execution of a payment workflow, wherein the payment workflow is a set of predefined steps and rules for completing a specific payment transaction; the user interaction context information is input into the payment workflow to obtain a payment task to be processed; the payment task to be processed is sent to the payment interface integration gateway so that the payment interface integration gateway performs a payment operation based on the payment task to be processed; 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 retrieval request from the payment agent; the workflow definition retrieval request includes an identifier of a first workflow; in response to the workflow definition retrieval request, feed back the definition information of the first workflow to the payment agent; the workflow definition retrieval request is a workflow / get method; 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; the workflow update request is a workflow / update method; 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; the workflow version management request is implemented through workflow / list_changed; Receive a workflow execution status and result retrieval request from the payment agent; the workflow execution status and result retrieval request includes the identifier of the fourth workflow; in response to the workflow execution status and result retrieval request, provide feedback on the workflow execution status or result of the fourth workflow to the payment agent; the workflow execution status and result retrieval request is implemented through workflow / status; Receive a workflow cancellation request from the payment agent; the workflow cancellation request includes the identifier of the fifth workflow; in response to the workflow cancellation request, stop executing the fifth workflow; the workflow cancellation request is implemented via workflow / cancel; Send a workflow status change notification to the payment agent.

2. The method according to claim 1, 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.

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

4. The method according to any one of claims 1-3, 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.

5. The method according to claim 4, 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.

6. The method according to claim 4, 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.

7. The method according to claim 4, 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.

8. The method according to claim 4, 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.

9. A payment device, characterized in that, The payment system based on Model Context Protocol (MCP) includes: a payment agent, a payment MCP integration server, and a payment interface integration gateway. The payment MCP integration server stores workflow information for multiple workflows; the workflow information for these multiple workflows includes any one or more of the following: payment workflow, points redemption workflow, and refund workflow. The device is applied to the payment MCP integration server and includes: The receiving module is used to receive workflow information listing requests from the payment agent; In response to a workflow information listing request, workflow information for multiple workflows is sent to the payment agent via the workflow / list method of the MCP protocol. The workflow consists of multiple processing nodes, each representing a specific task or operation. The processing node programs in the workflow are the specific code or program modules that implement these tasks or operations. Furthermore, after obtaining the workflow declaration, each workflow step is automatically bound to the corresponding MCP tool. 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. An execution module is used to respond to the workflow execution instruction to instruct the execution of a payment workflow, which is a set of predefined steps and rules for completing a specific payment transaction; the user interaction context information is input into the payment workflow to 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 performs a payment operation based on the payment task to be processed. The processing module is used for: Based on the MCP protocol, perform at least one of the following interactions with the payment agent: Receive a workflow definition retrieval request from the payment agent; the workflow definition retrieval request includes an identifier of a first workflow; in response to the workflow definition retrieval request, feed back the definition information of the first workflow to the payment agent; the workflow definition retrieval request is a workflow / get method; 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; the workflow update request is a workflow / update method; 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; the workflow version management request is implemented through workflow / list_changed; Receive a workflow execution status and result retrieval request from the payment agent; the workflow execution status and result retrieval request includes the identifier of the fourth workflow; in response to the workflow execution status and result retrieval request, provide feedback on the workflow execution status or result of the fourth workflow to the payment agent; the workflow execution status and result retrieval request is implemented through workflow / status; Receive a workflow cancellation request from the payment agent; the workflow cancellation request includes the identifier of the fifth workflow; in response to the workflow cancellation request, stop executing the fifth workflow; the workflow cancellation request is implemented via workflow / cancel; Send a workflow status change notification to the payment agent.

10. 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-8.

11. 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-8.

12. 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-8.

Images