Methods, apparatuses, devices, media, and products for payment and information processing

Abstract

Methods, apparatuses, devices, media, and program products for payment and information processing are provided. The method includes: obtaining a plurality of events associated with a payment process of an intelligent agent; generating a plurality of event verification information corresponding to the plurality of events based on event content of the plurality of events; and constructing process verification information corresponding to the payment process based on time sequence information of the plurality of events and the plurality of event verification information. In this way, a plurality of types of objects in the payment process can be uniformly organized as verifiable events, and structured process verification information can be formed based on the time sequence and the causal relationship, thereby supporting subsequent on-demand reconstruction, verification, and provision, and improving traceability efficiency and adoptability.

Description

Technical Field

[0001] The examples in this article generally relate to the field of computers, and in particular to methods, apparatuses, electronic devices, computer-readable storage media, and computer program products for payment and information processing. Background Technology

[0002] In electronic payment scenarios, the payment process may involve multiple types of scattered objects and records, which are usually generated separately by different modules and have different formats. When it is necessary to trace, verify, or provide relevant records on demand, it is often necessary to retrieve and manually concatenate them across multiple modules, which is not only inefficient but also prone to errors.

[0003] Furthermore, the scope of records required may differ for different requesters, and there is room for improvement in how to control the scope of provision as needed and ensure that the provided content can be independently verified. Summary of the Invention

[0004] In a first aspect, a method for payment is provided. The method includes: acquiring multiple events associated with a payment process of an agent; generating multiple event verification information corresponding to the multiple events based on the event content of the multiple events; and constructing process verification information corresponding to the payment process using the multiple event verification information based on the temporal information of the multiple events.

[0005] In a second aspect, a method for information processing is provided. The method includes: in response to receiving a query request associated with a payment process of an agent, obtaining process verification information corresponding to the payment process, the process verification information being obtained based on multiple event verification information corresponding to multiple events associated with the payment process; determining at least one event verification information based on the process verification information, the scope of the at least one event verification information being determined based on the query permissions corresponding to the query request; and providing a response to the query request based on the at least one event verification information.

[0006] In a third aspect, an apparatus for payment is provided. The apparatus includes: an event acquisition module configured to acquire multiple events associated with a payment process of an intelligent agent; a first generation module configured to generate multiple event verification information corresponding to the multiple events based on the event content of the multiple events; and a second generation module configured to construct process verification information corresponding to the payment process based on the timing information of the multiple events and utilizing the multiple event verification information.

[0007] In a fourth aspect, an apparatus for information processing is provided. The apparatus includes: an information acquisition module configured to, in response to receiving a query request associated with a payment process of an intelligent agent, acquire process verification information corresponding to the payment process, the process verification information being obtained based on multiple event verification information corresponding to multiple events associated with the payment process; an information determination module configured to, based on the process verification information, determine at least one event verification piece of information, the scope of which is determined based on the query permissions corresponding to the query request; and a response providing module configured to, based on at least one event verification piece of information, provide a response to the query request.

[0008] In a fifth aspect, an electronic device is provided. The device includes at least one processor; and at least one memory coupled to the at least one processor and storing instructions for execution by the at least one processor. When executed by the at least one processor, the instructions cause the device to perform the methods of the first or second aspect.

[0009] In a sixth aspect, a computer-readable storage medium is provided. The computer-readable storage medium stores computer-executable instructions that can be executed by a processor to implement the methods of the first or second aspect.

[0010] In a seventh aspect, a computer program product is provided, which is tangibly stored in a computer storage medium and includes computer-executable instructions that, when executed by a device, cause the device to perform the method of the first aspect or the second aspect.

[0011] In this way, by organizing various objects in the payment process into events and generating event-level and process-level verification information, the payment process can be uniformly organized, reconstructed on demand, and provided according to permissions at the functional level, reducing manual retrieval and splicing operations across modules. Furthermore, due to the use of structured event and process verification information and the provision scope determined by permissions, compared to exporting full records module by module, the overhead of cross-module retrieval and data transmission can be reduced, the number of storage read and write operations can be reduced, and the exposure of sensitive data and the number of transmissions when providing it externally can be reduced. This improves the efficiency of traceability and processing while reducing system resource consumption and data exposure risks.

[0012] It should be understood that the content described in this section is not intended to limit the key or important features of the examples in this article, nor is it intended to restrict the scope of the solution. Other features will become readily apparent from the following description. Attached Figure Description

[0013] The above and other features, advantages, and aspects of the various examples herein will become more apparent when taken in conjunction with the accompanying drawings and the following detailed description. In the accompanying drawings, the same or similar reference numerals denote the same or similar elements, wherein: Figure 1 A schematic diagram of an example environment that can be implemented therein is shown; Figure 2A A schematic block diagram of an example architecture for payment and information processing is shown, based on several scenarios. Figure 2B A flowchart illustrating an example process for generating a verification report based on certain scenarios is shown; Figure 2C A schematic diagram of example feedback interfaces based on some scenarios is shown; Figure 3 A flowchart illustrating example methods for payment under several scenarios is shown; Figure 4 A flowchart illustrating example methods for information processing based on several scenarios is shown; Figure 5 An exemplary structural block diagram of a payment device is shown according to some scenarios; Figure 6 Exemplary structural block diagrams of apparatuses for information processing according to certain scenarios are shown; and Figure 7 A block diagram of an electronic device capable of implementing multiple illustrative scenarios is shown. Detailed Implementation

[0014] The examples in this document will now be described in more detail with reference to the accompanying drawings. While some examples are shown in the drawings, it should be understood that solutions can be implemented in various forms and should not be construed as limited to the examples presented herein. Rather, these examples are provided to provide a more thorough and complete understanding of the solutions. It should be understood that the drawings and examples in this document are for illustrative purposes only and are not intended to limit the scope of protection of the solutions.

[0015] In the description of the examples in this document, the term "including" and similar terms should be understood as open inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "an example" or "the example" should be understood as "at least one example". The term "some examples" should be understood as "at least some examples". Other explicit and implicit definitions may also be included below. The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0016] It should be noted that, unless explicitly stated otherwise, performing a step in response to A does not mean that the step is performed immediately after A, but may include one or more intermediate steps.

[0017] The examples in this document may involve user data, data acquisition, and / or use. All of these aspects comply with relevant laws, regulations, and rules. In the examples, all data collection, acquisition, processing, manipulation, forwarding, and use are conducted with the user's knowledge and confirmation. Accordingly, when implementing each example, the type, scope of use, and usage scenarios of any data or information that may be involved should be communicated to the user and their authorization obtained through appropriate means, in accordance with relevant laws and regulations. The specific methods of notification and / or authorization can vary depending on the actual situation and application scenario; the scope of the solution is not limited in this regard.

[0018] In this manual and the sample solutions, any processing of personal information will be conducted only under legal grounds (such as obtaining the consent of the data subject or being necessary for the performance of a contract) and will only be carried out within the scope stipulated or agreed upon. A user's refusal to process personal information beyond what is necessary for basic functions will not affect the user's use of basic functions.

[0019] The term "agent" as used in this article refers to a proxy program or application that can accept a user's task delegation and autonomously execute tasks on behalf of the user. It typically includes, but is not limited to, an agent that can select a service provider, compare candidate solutions, and initiate a payment request based on the user's natural language input. This agent may include, but is not limited to, rule-based agents, natural language understanding model-based agents, large language model (LLM)-based agents, or combinations of the above.

[0020] The term “payment process” as used in this article refers to a set of one or more payment-related stages associated with an agent, from triggering to completion, which may include, but are not limited to, at least one of the stages such as task delegation, authentication, adjudication, token processing, payment execution and settlement; in some examples, the payment process may also be referred to as a payment chain.

[0021] The term "event" as used in this document refers to the standardized content obtained from objects or operations in the payment process; an event can also be referred to as an evidentiary event. The term "event content" as used in this document refers to the data carried by the event that describes the corresponding object or operation, and may include, but is not limited to, key fields and their values, or structured summaries of these fields.

[0022] The term “directed acyclic graph” used in this article refers to a graph consisting of nodes and directed edges that does not contain directed cycles. Its full English name is Directed Acyclic Graph, abbreviated as DAG.

[0023] The term “initial event” as used in this article refers to the event that matches the query request in the causal relationship graph and can serve as the starting point for reverse traversal; the term “reverse traversal” refers to the traversal performed in the opposite direction of the causal edge starting from the initial event; and the term “backtracking depth” refers to the maximum number of levels allowed for reverse traversal.

[0024] The term "disclosure content" as used in this article refers to the content that is allowed to be provided to external parties, as determined by the query permissions corresponding to the evidence package and the query request. This may include, but is not limited to, the set of disclosure fields and their values ​​or their anonymized values. The disclosure content may also be referred to as the minimum set of disclosure fields or the disclosure view.

[0025] As used in this document, the term "view type" refers to the type of presentation used to determine the form of the disclosed content, which is associated with the user corresponding to the query request. It may include, but is not limited to, at least one of the following: full view, anonymized view, regulatory view, or merchant view.

[0026] As mentioned above, in autonomous payment scenarios for intelligent agents, the payment process may involve more intermediate objects and judgment processes, such as task delegation credentials, runtime identity, adjudication results, execution tokens, and the write-back of payment and settlement status. In some scenarios, these objects are generated separately by different modules, with different data formats, and the relationships between them are not organized in a structured manner.

[0027] In some scenarios, when it is necessary to answer questions such as whether a payment process belongs to a certain task, which runtime identity triggered it, whether enhanced confirmation was performed, whether a valid token was used, or whether the authorization boundary was hit, if the above objects exist only as independent records, it may be necessary to retrieve them across multiple modules and manually concatenate the timestamps and relationships. There is room for improvement in processing efficiency and consistency.

[0028] Furthermore, the scope of information to be provided may differ depending on the requesting party (e.g., users, merchants, platform risk control, compliance audits, and arbitration parties). How to control the scope of information provided on demand while ensuring that the content can be independently verified for its consistency and completeness also requires improvement.

[0029] A scheme for payment and information processing is proposed. According to this scheme, on one hand, multiple events associated with the payment process of an intelligent agent are acquired; multiple event verification information corresponding to the events is generated based on the event content; and process verification information corresponding to the payment process is constructed based on the temporal information of the multiple events and the multiple event verification information. On the other hand, in response to receiving a query request associated with the payment process of the intelligent agent, the process verification information corresponding to the payment process is acquired; based on the process verification information, at least one event verification information is determined within a range defined by the query permission corresponding to the query request; and a response to the query request is provided based on at least one event verification information.

[0030] The above solution addresses two key aspects. First, it unifies the various objects involved in the payment process into verifiable events with a standardized format. Based on temporal and causal relationships, it generates structured process verification information, supporting unified organization and traceable representation of the payment process at the functional level, reducing manual retrieval and data splicing across modules. Second, it determines the scope of information provided based on query permissions and provides verifiable responses when responding to query requests, enabling on-demand and tiered information delivery at the functional level. Furthermore, by employing structured event and process verification information and determining the scope of delivery based on permissions, compared to exporting and manually splicing all records module by module, it reduces the computational overhead of cross-module retrieval and traversal, decreases data transmission and storage read / write operations, and reduces the exposure and transmission frequency of sensitive data when providing information externally. This improves traceability and processing efficiency while reducing system resource consumption and data exposure risks.

[0031] The following describes various examples of this scheme in further detail with reference to the accompanying drawings.

[0032] Figure 1 A schematic diagram of an example environment 100 that can be implemented therein is shown. (e.g.) Figure 1 As shown, example environment 100 may include electronic device 110.

[0033] In this example environment 100, electronic device 110 may run an application with payment functionality and may deploy an agent 115. Agent 115 may receive user input from user 140 and, based on that input, initiate a payment request to payment management system 120. In some cases, the application may be any suitable type of application with payment functionality, including but not limited to: travel applications, ticketing applications, purchasing applications, content subscription applications, or other suitable applications. User 140 may interact with agent 115 on electronic device 110 via electronic device 110 and / or its attached devices.

[0034] exist Figure 1In environment 100, electronic device 110 can present interface 140. Interface 140 can be used to present payment-related information. In some examples, electronic device 110 can receive user input via interface 140, for example, via an input box in an interactive window. User input may include natural language text.

[0035] In some cases, electronic device 110 communicates with payment management system 120 to provide payment services. Payment management system 120 can receive and process payment requests from intelligent agent 115.

[0036] Electronic device 110 can be any type of mobile terminal, fixed terminal, or portable terminal, including mobile phones, desktop computers, laptop computers, notebook computers, netbook computers, tablet computers, media computers, multimedia tablets, handheld computers, portable gaming terminals, VR / AR devices, personal communication system (PCS) devices, personal navigation devices, personal digital assistants (PDAs), audio / video players, digital cameras / camcorders, positioning devices, television receivers, radio receivers, e-book devices, gaming devices, or any combination thereof, including accessories and peripherals of these devices or any combination thereof. In some cases, electronic device 110 may also support any type of user-facing interface (such as "wearable" circuitry).

[0037] The payment management system 120 can be deployed on a server or electronic device 110. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and big data and artificial intelligence platforms. The server may include, for example, computing systems / servers such as mainframes, edge computing nodes, computing devices in a cloud environment, etc. The server can provide backend services for payment-supporting applications in the electronic device 110.

[0038] A communication connection can be established between the payment management system 120 and the electronic device 110. This communication connection can be established via wired or wireless means. The communication connection can include, but is not limited to, Bluetooth, mobile network, Universal Serial Bus (USB), and Wireless Fidelity (WiFi) connections. In some cases, the payment management system 120 and the electronic device 110 can exchange signaling information through their communication connection.

[0039] It should be understood that the structure and function of the various elements in environment 100 are described for illustrative purposes only and do not imply any limitation on the scope of the scheme. The example will continue to be described below with reference to the accompanying drawings.

[0040] Figure 2A A schematic block diagram of an example architecture 200A for payment and information processing is shown, based on several scenarios. Architecture 200A can be implemented in a payment management system 120.

[0041] like Figure 2A As shown, architecture 200A may include an evidence chain generation unit 210, a storage unit 220, and an evidence package assembly unit 230. The evidence chain generation unit 210 can be used to implement the following... Figure 3 The described payment process and its various examples, the evidence package assembly unit 230 can be used to implement the following combined Figure 4 The described process for information processing and its examples.

[0042] In some cases, the evidence chain generation unit 210 may include an event determination unit 211, a causal graph construction unit 212, and a hash chain determination unit 213. The event determination unit 211 may acquire events 214 associated with the payment process of an agent (e.g., agent 115). In some cases, during the agent's payment process, the event determination unit 211 may monitor the agent and, in response to detecting that the agent has performed an operation related to the payment process, acquire the operation result of that operation and determine the event corresponding to that operation based on the operation result. In some cases, operations related to the payment process may include, but are not limited to, operations related to task delegation credentials, authentication, execution tokens, payment requests, etc., and operation results may include, but are not limited to, task delegation credential generation, task delegation credential activation, task delegation credential revocation, agent runtime authentication, payment decision output, execution token derivation, execution token use, execution token revocation, payment request initiation, payment execution success, payment execution failure, refund, revocation, settlement completion, and settlement failure, etc.

[0043] In some scenarios, each event may include information such as an event identifier, event type, source module, associated object reference, payment process identifier, task reference, event content summary, event time information, event verification information, and references to preceding events. The event type identifies which category of event the event belongs to: task delegation, authentication, adjudication, token, payment execution, settlement, or dispute resolution. The associated object reference points to the task delegation credential, runtime identity, adjudication result, execution token, payment request, channel receipt, or settlement record. The payment process identifier associates all events within the same payment process. The task reference associates multiple payment or multi-protocol events under the same user task. The event content summary records a structured summary of key fields. The event verification information proves that the event content has not been tampered with. By unifying the various heterogeneous objects in the payment process into events with the same field structure, unified organization of multiple object types and subsequent on-demand retrieval can be supported at the functional level. Furthermore, by adopting a unified event structure rather than heterogeneous records for each module, compared to retrieving and parsing the original records of each module separately, the computational overhead of cross-module retrieval and format conversion can be reduced, and the number of storage read and write operations can be reduced, thereby improving organizational efficiency while reducing resource consumption.

[0044] In some cases, the event determination unit 211 can also perform validation on each of the multiple events based on its fields, with the validation result indicating at least whether the fields of the event are complete. In response to the validation result of the first event indicating that its fields are incomplete, the event determination unit 211 can refuse to store the first event and can send first information to the agent, indicating that the fields of the first event are incomplete. As an example, the event determination unit 211 can perform field integrity, field type, enumeration value, and reference relationship validation on events according to the event pattern definition. If any required field among the event identifier, event type, source module, associated object reference, event content summary, event time information, or event validation information is missing, the event determination unit 211 can determine that the time is incomplete and refuse to write the event. By performing pattern validation on the event fields before writing and rejecting the writing of incomplete events, redundant corrections caused by incomplete events entering subsequent processing can be avoided at the functional level. Furthermore, by intercepting incomplete events at the entry point, compared to discovering and rolling back invalid events during the subsequent reconstruction and verification stages, the overhead of storing and recalculating invalid events can be reduced, thereby reducing system resource consumption.

[0045] In some examples, the event determination unit 211 can also generate multiple event verification information corresponding to multiple events based on the event content of multiple events. In some cases, before generating event verification information, the event determination unit 211 can also perform normalization processing on the event content of multiple events to obtain normalized event content for each event. In some cases, normalization processing may include, but is not limited to, at least one of the following: fixed field order, whitespace character normalization, numerical format normalization, unified time format, and fixed null value handling rules. This can ensure that the same event content generates consistent event verification information in different system environments. The event determination unit 211 can then determine the event verification information corresponding to multiple events based on the normalized event content. Event verification information can also be referred to as event hash.

[0046] In one implementation, the event determination unit 211 can obtain event verification information by calculating the normalized event content based on a cryptographic hash function. Specifically, for the i-th event among multiple events, its corresponding event verification information can be determined according to the following formula:

[0047] in, Let represent the i-th event among multiple events, N represent the operation of performing normalized serialization on the event to obtain the corresponding byte stream, and H represent the cryptographic hash operation that meets the platform's security policy requirements. This represents the event verification information corresponding to the i-th event. In other words, the event determination unit 211 can first perform normalized serialization on the i-th event to obtain a deterministic byte stream, and then perform a cryptographic hash operation on the byte stream to obtain the event verification information for that event. It should be noted that the above formula is only an example, and those skilled in the art can use other operation methods that can meet the platform security policy requirements to determine the event verification information, and are not limited in this regard.

[0048] In some cases, each of the multiple events acquired by the event determination unit 211 may include first event verification information for that event. The event determination unit 211 may calculate second event verification information for each of the multiple events based on the normalized event content of the multiple events, and compare the first and second event verification information for each of the multiple events. In response to a discrepancy between the first and second event verification information of a second event among the multiple events, the event determination unit 211 may refuse to store the second event and send second information to the agent, indicating that the event verification information of the second event is inconsistent. As an example, the first event verification information may be a first event hash included in the event, and the second event verification information may be a second event hash of the event calculated by the event determination unit 211 based on the normalized event content of the event. The event determination unit 211 may compare the first and second event hashes of the same event.

[0049] In some scenarios, the event determination unit 211 can also store events other than the first and / or second events among multiple events, where the stored events remain unchanged. Users, electronic devices 110, payment management systems 120, and intelligent agents 115 cannot modify the stored events. In some examples, if a change to a stored event is required, the event determination unit 211 can only append or revoke the event, associating it with the original event through causal relationships. By writing events to append-only storage and prohibiting in-place modification or deletion, the immutability of written events can be maintained at the functional level. Furthermore, due to the append-only approach and the elimination of rewriting of written events, compared to in-place updates, the overhead of random writes to existing records and index rebuilding is reduced, and the number of storage read / write operations is decreased, thereby reducing system resource consumption while ensuring the credibility of evidence.

[0050] In some cases, the event determination unit 211 can also determine whether each of the multiple events is abnormal. Abnormalities include incomplete fields, inconsistent event validation information, untrusted event sources, and inability to locate associated objects, etc. In response to the existence of an abnormality in a third of the multiple events, the event determination unit 211 can generate an exception record corresponding to that event. This exception record may include, for example, an exception event identifier, a reference to the original event, an exception cause code, the source module, the processing time, and the processing result.

[0051] In some scenarios, in response to the payment process meeting a first predetermined condition, the event determination unit 211 can obtain the user's review information regarding the third event corresponding to the agent. The first predetermined condition may, for example, indicate that the risk level of the payment process has reached a threshold (e.g., indicating that the payment process is a high-risk payment process). The review information may indicate a normal processing event, a rejected processing event, or other information. By identifying abnormal events on the write side and introducing review for high-risk payment processes, potential untrustworthy events can be intercepted at an early stage at the functional level. Furthermore, since abnormal handling is completed at the event entry point, compared to carrying the abnormality into the subsequent reconstruction and verification stages for further processing, the additional computation and transmission overhead generated by abnormal events during cross-module flow can be reduced.

[0052] The evidence chain generation unit 210 can construct process verification information corresponding to the payment process based on the temporal information of multiple events and using multiple event verification information. The process verification information may include a causal relationship graph 215 and a hash chain 216 corresponding to the payment process. Specifically, the causal graph construction unit 212 can construct the causal relationship graph 215 based on the causal relationship between events 214, and the hash chain determination unit 213 can construct the hash chain 216 based on the temporal information of events 214.

[0053] In some scenarios, the causal graph construction unit 212 can determine the causal relationships between multiple events based on predetermined causal identification rules. The causal graph construction unit 212 can acquire at least one causal identification rule, each rule including, for example, information such as upstream event type, downstream event type, matching conditions, and relationship type. Relationship types can include causal relationships, triggering relationships, derived relationships, substitution relationships, revocation relationships, and referencing relationships, etc. As an example only, the causal graph construction unit 212 can, based on predetermined causal identification rules, determine that there is a causal relationship between the task delegation certificate generation event and the payment adjudication event, a triggering relationship between the payment adjudication event and the execution token derived event, a derived relationship between the execution token derived event and the payment execution event, a causal relationship between the payment execution event and the settlement event, etc.

[0054] The causal graph construction unit 212 can determine causal edges based on causal relationships, with the direction of the causal edges pointing from upstream cause events to downstream result events. The causal graph construction unit 212 can then construct a causal relationship graph based on these causal edges. The causal relationship graph can be, for example, a directed acyclic graph, and the causal edges can include information such as upstream event identifiers, downstream event identifiers, and relationship types. In one implementation, the causal graph construction unit 212 can establish a causal edge between the corresponding upstream and downstream events if and only if the upstream event types match, the downstream event types match, and the associated object references match. This causal edge establishment condition can be expressed as:

[0055] Where e_i represents an upstream event, e_j represents a downstream event, o represents the operation of taking the reference of the associated object of the event, and Match represents the matching operation based on object reference, payment process identifier, task reference or associated object reference. When the result of the above matching operation is true and the event type satisfies the upstream and downstream constraints, the causal graph construction unit 212 can establish a causal edge from e_i to e_j.

[0056] In some cases, the causal graph construction unit 212 can also establish forward and reverse indexes based on causal edges. The forward index is used to trace the impact of events on downstream processes, while the reverse index is used to trace back upstream events from the results of the payment process. By using a directed acyclic graph to structurally represent the causal relationships between events and establishing bidirectional indexes, on-demand reconstruction and traversal of the complete causal path of the payment process can be supported at the functional level. Furthermore, due to the use of structured causal edges and pre-built indexes, compared to manually reasoning causal relationships based on original records during dispute resolution, the computational overhead of retrieval and comparison during reconstruction and the number of repeated reads and storage operations can be reduced.

[0057] In some examples, the causal graph construction unit 212 can also construct causal edge records. These records may include, for example, information such as causal edge identifiers, upstream event identifiers, downstream event identifiers, relationship types, relationship establishment times, matching rule identifiers, and causal edge hashes. The causal graph construction unit 212 can also use upstream event identifiers, downstream event identifiers, and relationship types to form unique constraints and detect duplicate causal edges. If a causal edge of the same direction and type already exists between the same pair of events, the causal graph construction unit 212 can avoid writing it again and return the existing causal edge identifier. The causal graph construction unit 212 can provide the causal graph (e.g., which may also include causal edges) to the storage unit 220 to store the causal graph 215 (and the causal edges).

[0058] In some examples, when writing a causal edge, the causal graph construction unit 212 can traverse along the forward edges starting from the downstream event. If it can return to the upstream event, a causal loop is determined to be formed. In this case, the causal graph construction unit 212 can also refuse to write the causal edge and return a causal loop error. In some examples, when each causal edge is written, the causal graph construction unit 212 can also record its corresponding payment link identifier and task reference. If there are multiple payments, multiple protocols, or multiple execution tokens under the same task, the causal graph construction unit 212 can also include them in the same task-level causal view through task references and distinguish different payment links through payment link identifiers.

[0059] In some cases, the hash chain determination unit 213 can sort multiple events based on their respective time sequence information. For example, the earlier the corresponding time information, the higher the sorting result. The hash chain determination unit 213 can determine the chain verification information corresponding to multiple events based on the sorting result, and this chain verification information can form a hash chain. In some cases, for each of the multiple events, the hash chain determination unit 213 can determine the chain verification information of the event based on the event verification information of that event, the chain verification information corresponding to the previous event in the sorting result, and the chain sequence number of the event in the payment process. In one embodiment, the chain verification information can be determined according to the following formula:

[0060] in, This represents the chained verification information corresponding to the i-th event. This represents the chained verification information corresponding to the previous event of the i-th event in the sorting result. This represents the event verification information for the i-th event. This indicates the chain number of the event within the payment process, H represents the cryptographic hash operation, and the symbol " "" indicates field concatenation. In some cases, the chain number is a strictly increasing and gapless sequence number within the payment process.

[0061] In some scenarios, during the storage of the hash chain, the hash chain determination unit 213 may send a third message to the agent in response to a non-continuously increasing chain sequence number in the hash chain 216. This third message indicates a break in the chain sequence number. In some scenarios, the hash chain determination unit 213 may also re-determine the chain verification information starting from the first position in the hash chain 216, where the first position is located at the head of the hash chain or the anchor point of the hash chain. In some examples, the hash chain determination unit 213 may generate an anchor point in response to the number of stored events reaching a preset number and / or the payment process meeting a preset state. The anchor point may include, for example, an anchor point identifier, a payment link identifier, an anchor sequence number, a corresponding event identifier, a chain hash, a generation time, and an anchor signature. The anchor point can be used to accelerate subsequent chain verification. The hash chain determination unit 213 may then generate a chain break event in response to a discrepancy between the re-determined chain verification information and the original chain verification information. By constructing chain verification information for events based on time sequence and setting anchor points, self-verification of the continuity and integrity of the event sequence can be supported at the functional level. Furthermore, due to the use of a chained recursive structure and anchor points, compared to recalculating all events independently one by one, it can recalculate from the nearest anchor point when performing partial chain verification, reducing the hash calculation overhead and storage read count during verification.

[0062] Event 214, causal relationship graph 215, and hash chain 216 can be stored via storage unit 220, which in some examples can be implemented using an append-only storage engine. Evidence package assembly unit 230 may include query identification unit 231, policy determination unit 232, causal chain reconstruction unit 233, event verification unit 234, and evidence package generation unit 235.

[0063] The evidence package assembly unit 230 can, in response to receiving a query request 201 associated with the payment process of the smart agent, obtain process verification information corresponding to the payment process. This process verification information is obtained based on multiple event verification information corresponding to multiple events, which are associated with the payment process. As mentioned above, and for illustrative purposes only, the process verification information may include the aforementioned causal relationship graph 215 and hash chain 216 corresponding to the payment process. Based on the process verification information, the evidence package assembly unit 230 can determine at least one event verification piece of information. The scope of this at least one event verification piece of information is determined based on the query permissions corresponding to the query request. Based on at least one event verification piece of information, the evidence package assembly unit 230 can provide a response to the query request.

[0064] Specifically, the query identification unit 231 can parse the query request 201 to at least determine the associated payment object and query type 241 corresponding to the query request 201. In some examples, the query identification unit 231 can also query information such as the requester's role, query reason, query time, and attachment references corresponding to the request 201. In some examples, the query identification unit 231 can send a fourth piece of information to the agent in response to a query type that does not belong to the specified range. This fourth piece of information can indicate that the query type of the query request is incorrect. In some cases, the query type may include, but is not limited to, at least one of unauthorized payment, amount dispute, service non-delivery, token misuse, authorization scope dispute, duplicate deduction, refund failure, and status dispute.

[0065] In some scenarios, the query identification unit 231 can determine whether a payment record corresponding to the payment process is stored based on the associated payment object. For example, it can determine whether the corresponding payment record is stored in the storage unit 220. In response to the existence of a payment record, the query identification unit 231 can obtain the link identifier of the payment process based on the payment record and obtain process verification information based on the link identifier. In some scenarios, the query identification unit 231 can extract information such as the link identifier, task reference, task delegation certificate reference, execution token reference, adjudication result reference, and channel receipt reference of the payment process from the payment record as the starting point for subsequent reconstruction. In some scenarios, in response to the absence of a payment record, the query identification unit 231 can send a fifth piece of information to the agent, which can indicate that there is an error in the associated payment object of the query request. By first determining the dispute type and associated payment object, and then locating the payment record and process verification information accordingly, precise location of the required process verification information can be supported at the functional level. Furthermore, due to the direct location processing based on the link identifier, compared to the processing of retrieving the original logs subsystem by subsystem, the computational overhead of cross-subsystem retrieval and the bandwidth occupation of end-to-cloud communication can be reduced, and the number of storage read / write operations can be decreased.

[0066] In some examples, the evidence package assembly unit 230 can create a query acceptance record based on the acquired information. This record may include information such as query identifier, query type, associated payment object, payment link identifier, task reference, query status, creation time, processing deadline, and dispute strategy version. In some examples, the initial status of the query acceptance record is "accepted."

[0067] The strategy determination unit 232 can determine the query strategy 242 based on the query type. The query strategy 242 may include information such as a strategy identifier, query type, required evidence event types, optional evidence event types, backtracking depth, verification level, disclosure configuration, and missing evidence handling methods. Backtracking depth limits the number of layers in the reverse reconstruction of the causal chain. A greater backtracking depth results in more complete evidence collection, but also higher traversal overhead. For example, for a query request regarding unauthorized payments, the backtracking depth can be configured to a relatively large number of layers to trace back from settlement to task delegation; for a query request regarding a disputed amount, the backtracking depth can be configured to a relatively small number of layers to trace back from settlement to adjudication, thereby controlling traversal overhead while meeting the scope of evidence collection. It should be understood that the above-mentioned number of layers is merely an example and can be configured according to the dispute type and business needs without restriction.

[0068] In some examples, the strategy determination unit 232 can obtain the query strategy 242 corresponding to query request 201 from multiple query strategies based on query request 201. In some cases, the strategy determination unit 232 can obtain the query strategy 242 corresponding to query request 201 from the query strategy table using query type as the key. In some examples, if no query strategy is found, the strategy determination unit 232 can determine that the default query strategy corresponds to query request 201. The evidence package assembly unit 230 can determine at least one event verification information based on query strategy 242 and process verification information. In some examples, the evidence event types are different for different query types. For example, for unauthorized payments, the evidence event types that must be collected include at least task delegation certificate generation, runtime authentication, payment adjudication completion, execution token derivation, execution token verification, and payment execution events. For amount disputes, the evidence event types that must be collected include at least task delegation certificate generation, payment adjudication completion, execution token derivation, payment request, payment execution, and settlement completion events. For token misuse, the required evidence event types to be collected must include at least the following: execution token derivation, execution token verification, token execution result recording, token revocation, and revocation propagation events. For authorization scope disputes, the required evidence event types to be collected must include at least the following: task delegation credential generation, scenario wallet usage relationship generation, payment adjudication completion, execution token derivation, execution token verification, and payment execution events. Of course, these are just examples; in practice, other query types and task event types corresponding to other query requests may also be included.

[0069] In some examples, the evidence package assembly unit 230 can generate a backtracking depth counter based on the backtracking depth. The evidence package assembly unit 230 can also generate an event type filter based on the types of evidence events that must be collected and those that can be optionally collected, retaining only the event types specified by the strategy during the backtracking process, and retaining bridging events related to the integrity of the causal path when necessary. In some examples, the evidence package assembly unit 230 can generate a set of verification rules based on the verification level. For example, the basic level performs event hash verification and required field integrity verification; the standard level adds hash chain continuity verification on top of the basic level; and the strict level further adds timestamp causal order verification, content normalization recalculation verification, and anchor point verification.

[0070] In some examples, the causal chain reconstruction unit 233 can read the process verification information corresponding to the query request 201 from the storage unit 220 based on information such as the associated payment object and payment link identifier. For example, it can read the causal relationship graph 215 corresponding to the query request 201. In some cases, the causal chain reconstruction unit 233 can determine the initial event matching the query request 201 from the causal relationship graph 215. In the causal relationship graph, the causal chain reconstruction unit 233 can perform a reverse traversal of the causal edges where the initial event is located, starting from the initial event, to obtain at least one event located upstream of the initial event in the causal relationship graph (this at least one event can be referred to as the causal chain 243 obtained by reverse traversal), and then obtain at least one event verification information corresponding to at least one event.

[0071] As an example only, the causal chain reconstruction unit 233 can add the initial event to the queue to be traversed and retrieve events sequentially from the queue using a breadth-first approach, querying their upstream events through a reverse index. In some examples, if an upstream event has not been visited and has not exceeded the backtracking depth, the causal chain reconstruction unit 233 can add it to the queue to be traversed and write the corresponding causal edge into the causal path set. When traversing to an event without an upstream causal edge, or when the event type is a root event such as task delegation certificate generation, original expression reception, or real-name subject authorization, the causal chain reconstruction unit 233 can mark it as a root evidence event.

[0072] In some examples, the causal chain reconstruction unit 233 can filter events in the traversed event set according to the query strategy 242. For bridging events that do not belong to the mandatory event type but connect two necessary evidence events, the causal chain reconstruction unit 233 can retain their summaries according to the strategy to ensure the continuity of the causal path. In some examples, after traversal is completed, the causal chain reconstruction unit 233 can batch load complete event records to form an evidence event set. This set, together with the causal path set, root evidence events, payment link identifiers, and dispute identifiers, constitutes the input for generating subsequent evidence packages. In some cases, the causal chain reconstruction unit 233 can sort the evidence event set according to causal relationship and event time to form an evidence timeline, with causal order taking precedence over pure chronological order. When the causal relationship cannot be determined, event time information and chain number are used for sorting.

[0073] By reconstructing the causal relationship graph in reverse order according to the backtracking depth and determining the scope of event verification information accordingly, the system can support the automatic reconstruction and on-demand collection of dispute-related evidence at the functional level. Furthermore, due to the use of reverse indexing and backtracking depth constraints, compared to manually retrieving and splicing all records, the computational overhead of traversal and retrieval can be reduced, as can the number of storage read / write operations and the amount of cross-module data transfer.

[0074] Event verification unit 234 can perform verification on at least one event, and the verification result indicates the integrity, continuity, and causal order of at least one event. In some cases, event verification unit 234 can re-perform deterministic serialization and hash calculation for each event in the evidence event set and compare it with the event hash in the event record. If they are inconsistent, event verification unit 234 can mark it as an event hash anomaly. In some examples, event verification unit 234 can sort events under the same payment chain according to the chain sequence number and recalculate the chain hash starting from the chain head or the most recent anchor point. If the recalculation result is inconsistent with the recorded value, it is marked as a chain break, and the first break position is recorded. In some examples, event verification unit 234 can check whether each event's required fields exist and are not empty according to the event pattern definition. Missing fields are recorded in the missing field list. In some examples, event verification unit 234 verifies for each causal edge in the causal path set whether the event timestamp of the upstream event is no later than the event timestamp of the downstream event plus an allowed clock deviation threshold. If it violates this, it is marked as a time order anomaly. In some examples, for strict-level verification, event verification unit 234 further verifies the chain hash, anchor sequence number, and anchor signature in the anchor point. If the anchor point signature is invalid, it is marked as an anchor point exception. Event verification unit 234 can generate a verification report based on the above verification results 244.

[0075] Figure 2B A flowchart of an example process 200B for generating a verification report based on certain scenarios is shown. Process 200B can be implemented at the evidence package assembly unit 230.

[0076] like Figure 2BAs shown, in box 251, the evidence package assembly unit 230 determines the associated payment object, that is, determines the payment-related object associated with the query request. In box 252, the evidence package assembly unit 230 queries the causal relationship graph corresponding to the associated payment object. In box 253, the evidence package assembly unit 230 traverses the causal edges in reverse in the causal relationship graph to backtrack from the result event upstream. In box 254, the evidence package assembly unit 230 determines whether the backtracking depth has reached the upper limit. In box 255, in response to the backtracking depth not reaching the upper limit, the traversal of causal edges continues. The evidence package assembly unit 230 may, for example, return to execute box 253. In box 256, in response to the backtracking depth reaching the upper limit, the evidence package assembly unit 230 obtains at least one event obtained from the backtracking. In box 257, the evidence package assembly unit 230 verifies the hash chain corresponding to the at least one event. In box 258, the evidence package assembly unit 230 determines whether the hash chain is continuous. If it is not continuous, the evidence package assembly unit 230 can directly execute box 260 to generate a verification report. If the events are consecutive, the evidence package assembly unit 230 can execute block 259. In block 259, the evidence package assembly unit 230 can determine whether the at least one event is complete. In block 260, the electronic device 110 generates a verification report based on the results of the above verifications.

[0077] The above method enables the automatic collection and hierarchical verification of events related to query requests along the causal relationship graph at a controlled backtracking depth. This reduces the manual step of item-by-item verification and splicing at the functional level. Furthermore, since the backtracking depth is constrained by an upper limit and the verification is performed along the constructed hash chain and causal edges, compared to performing indiscriminate traversal and comparison of all records, it can reduce the computational overhead of reverse traversal and the number of traversed nodes, and reduce the number of reads from storage unit 220, thereby reducing the computational resource consumption and storage read / write overhead of a single evidence collection.

[0078] In some cases, verification reports may include, but are not limited to, verification conclusions, lists of anomalous events, lists of missing fields, lists of chronological anomalies, chain break locations, anchor point verification results, and verification rule versions. Therefore, by performing hierarchical integrity verification on the reconstructed events according to levels and generating verification reports, standardized judgments on the integrity, continuity, and causal order of evidence can be supported at the functional level. Furthermore, since the verification level can be selected as needed, compared to performing the highest-strength verification on all evidence, the hash calculation overhead and storage read counts during verification can be reduced while still meeting trust requirements.

[0079] In some examples, the evidence package generation unit 235 can generate an evidence package 245 corresponding to the query request based on at least one event verification information. The evidence package assembly unit 230 can sort the evidence event set according to causal relationship and event time to form an evidence timeline, with causal order taking precedence over pure chronological order, and using event time information and chain number for sorting when the causal relationship cannot be determined. The evidence package may include, for example, information such as evidence package identifier, dispute identifier, dispute type, payment link identifier, task reference, evidence timeline, evidence event list, causal path set, root evidence event, verification report, evidence package hash, evidence package signature, and generation time. In some examples, the evidence package assembly unit 230 can generate an evidence fragment index for the events, fields, and supporting materials within the evidence package, which can be used for subsequent minimal disclosure by field, event type, and query role. In some examples, the evidence package assembly unit 230 can perform deterministic serialization on the evidence package content, calculate evidence package verification information (e.g., evidence package hash), and have the evidence package generation module sign it to form an evidence package signature. For example, the evidence package hash can be determined based on the following:

[0080] Where 'a' represents the dispute identifier, 'l' represents the link identifier of the payment process, 'V' represents the event verification information list of evidence events within the evidence package, 'E' represents the verification information list of causal edges within the evidence package, 'r' represents the verification information corresponding to the integrity verification report, 'H' represents cryptographic hash operation, and the symbol " "" indicates field concatenation, and P indicates the evidence package verification information corresponding to the evidence package. In other words, the evidence package assembly unit 230 concatenates the dispute identifier, link identifier, event verification information list, causal edge verification information list, and verification report verification information in sequence and then performs a cryptographic hash operation to obtain the evidence package verification information, thereby binding the entire evidence package into a verifiable whole.

[0081] In some examples, the evidence package assembly unit 230 can determine the disclosure content based on the evidence package and the query permissions corresponding to the query request, and generate a response to the query request based on the disclosure content. In some cases, the query permissions can be determined based on the requester role and query purpose corresponding to the query request. The evidence package assembly unit 230 can determine the query purpose of the query request and can refuse to provide a response to the query request if the query purpose does not match the payment process and / or the user corresponding to the query request. In some cases, in response to the disclosure content including a first field that does not meet predetermined requirements, the evidence package assembly unit 230 can process the first field and determine the updated disclosure content based on the processed first field. In some cases, the processing may include, but is not limited to, at least one of desensitization, hashing, scoping, or referencing. For example, for fields that are not allowed to be disclosed directly in plaintext, such as the user's original expression, device proof, complete intelligent agent operating environment, real-name entity account, and internal risk control policies, the evidence package assembly unit 230 may only output its mask value, check value, range value, or reference value, instead of directly outputting its field content.

[0082] In some scenarios, the evidence assembly unit 230 can determine the view type corresponding to the disclosed content based on the user corresponding to the query request, and generate a response to the query request based on the disclosed content and the view type. In some scenarios, the view type may include, but is not limited to, at least one of the following: complete evidence view, anonymized evidence view, regulatory evidence view, and payee evidence view, which are respectively used by a dispute resolution party with full permissions, a regular user or payee, a regulatory query party, and a payee dispute resolution party.

[0083] In some cases, the evidence package assembly unit 230 can perform normalization processing on the field names, field values, de-identification tags, and fragment contexts in the disclosed content before calculating fragment verification information. In one embodiment, the fragment verification information can be determined according to the following formula:

[0084] Where d represents the disclosed evidence fragment, N represents the operation of performing normalized serialization processing on the evidence fragment to obtain the corresponding byte stream, H represents the cryptographic hash operation, and f represents the fragment verification information corresponding to the evidence fragment.

[0085] In some cases, the evidence package assembly unit 230 can generate a containment path from fragment verification information to evidence package verification information based on the fragment index. This containment path is used to prove that the disclosed fragment belongs to the original evidence package. In one implementation, the querying party initiating the query request can verify the disclosed fragment in the following manner:

[0086] Where f represents fragment verification information, π represents the inclusion path from fragment verification information to evidence package verification information, P represents evidence package verification information, and Verify represents the operation of verifying the fragment verification information and evidence package verification information based on the inclusion path. When the above verification result is true, the querying party does not need to obtain the complete evidence package to verify that the disclosed fragment originates from the original evidence package and has not been tampered with. By determining the minimum disclosure scope according to role and purpose and providing fragment verification information and inclusion paths for the disclosed fragments, the functional level can support the hierarchical opening and verifiable disclosure of disputed evidence according to permissions. In addition, since only the minimum disclosure content determined by permissions is provided to the outside world instead of the complete chain of evidence, compared with the processing of exporting the full record party by party, the number of external data transmissions and bandwidth consumption can be reduced, and the sensitive data exposure surface can be reduced, thereby reducing the risk of data exposure and system resource consumption while ensuring verifiability.

[0087] In some scenarios, the evidence package assembly unit 230 can also generate and store query receipts corresponding to the response. Stored query receipts remain unchanged and cannot be altered. The query receipts can record the requester's role, query purpose, actual set of disclosed fields, integrity proof summary, and policy version for post-event verification and to prevent expansion of the disclosure scope or replacement of disclosure results. By generating evidence packages and binding them as a signed, verifiable whole, and writing the query receipts corresponding to each disclosure to an immutable log, automatic assembly and non-repudiation of disputed evidence can be supported at the functional level. Furthermore, since the evidence package is bound as a whole and query receipts are not rewritten, compared to maintaining them separately for each event and multiple repeated signatures, the computational overhead of signing and storage writing can be reduced, and the number of storage read / write operations can be decreased.

[0088] In some cases, the payment management system 120 may also provide a feedback interface, which includes at least a response to the query request. For example, the payment management system 120 may provide the information flow of this feedback interface to the electronic device of the party initiating the query, so that the electronic device displays the feedback interface via a screen. In some cases, the feedback interface may also include at least one of the following: evidence package, at least one event verification information, disclosure content, or process verification information. (Reference) Figure 2C , Figure 2C A schematic diagram of an example feedback interface 200C according to some scenarios is shown. The feedback interface 200C may be provided by an electronic device 110 via an interface 140 for presenting a response to a query request.

[0089] like Figure 2CAs shown, on the feedback interface 200C, the electronic device 110 can display a download control 271, a view control 272, and a scroll control 273. The electronic device 110 can download the evidence package in response to triggering the download control 271. The electronic device 110 can display a causal relationship graph corresponding to the query request in response to triggering the view control 272. The electronic device 110 can scroll the content displayed on the feedback interface 200C in response to a sliding operation on the scroll control 273, or in response to a sliding operation on the interface, to display other content. In addition, the feedback interface 200C can also display information such as the dispute type, creation time, and an overview of the payment process presented in the form of process nodes (e.g., task delegation, agent identity, decision-making process, payment execution and collection results nodes), a causal chain graph presented in the form of nodes and connecting edges, and an evidence list.

[0090] In some scenarios, in response to receiving an operation on the download control 271, electronic device 110 requests an evidence package corresponding to the current response from payment management system 120, and saves the evidence package locally upon receipt. This switches the download status from incomplete to complete in the corresponding area of ​​feedback interface 200C. In this way, users can directly obtain the response and evidence package corresponding to the query request on the same feedback interface 200C, reducing the number of jumps between different interfaces. Since the disclosure content corresponding to the response has been determined on the service side according to permissions, electronic device 110 does not need to repeatedly request the payment management system 120 to obtain a complete evidence chain. This reduces the number of edge-cloud interaction rounds, lowers client-side page rendering overhead and cache usage, and reduces the query load and edge-cloud communication bandwidth usage of payment management system 120.

[0091] It should be understood that the above implementation methods are merely examples, and other alternative methods can be used to achieve the same or similar functions. For example, events can be stored in relational databases, graph databases, or event flow systems, and causal relationship graphs can be represented using adjacency lists, adjacency matrices, or native edges of graph databases. Furthermore, causal relationships can be determined using rule matching based on reference relationships, statistical inference based on time windows and object co-occurrence, or by each source module explicitly declaring upstream event identifiers when generating events. For example, chain integrity verification in process verification information can be implemented using chained hashing, Merkle tree verification, or independent signature verification for each event, and the corresponding verification level division can be adjusted according to business needs. For example, query strategies can be implemented using static configuration or dynamic strategy engines, and the granularity of disclosed content can be controlled at the field level, event level, or view level. These alternative methods can all achieve the same or similar functions, and those skilled in the art can choose according to actual needs without limitation.

[0092] For ease of understanding, several exemplary application scenarios are given below. In the first example scenario, for a query request regarding unauthorized payments, the payment management system 120 receives the query request and parses out the query type and associated payment object. Based on the query strategy, it determines the types of events to be collected and configures the backtracking depth to a relatively large number of layers. The payment management system 120 can start from the payment execution event of the payment object and reconstruct the causal relationship graph backwards to the token derivation event, adjudication event, authentication event, and authorization credential event. After completing the integrity verification, it generates an evidence package. The payment management system 120 can provide responses according to role permissions.

[0093] In the second example scenario, during the reconstruction and verification process, the payment management system 120 can respond to inconsistencies between the chain verification information and recalculation results between the token derivation event and the adjudication event, marking the verification conclusion as suspicious and recording the break point. The payment management system 120 can retain this event in the evidence package but mark it as suspicious, and trigger the corresponding background investigation process.

[0094] In the third example scenario, for a query request regarding a disputed amount, the payment management system 120 can configure the backtracking depth to a relatively small number of layers, with the causal chain only tracing back to the adjudication event and the payment execution event. The evidence package provides disclosures related to the payment request and settlement according to the payee role, without including details of task delegation and identity verification.

[0095] In the fourth example scenario, for the verifiable minimal disclosure query by the arbitrator, the payment management system 120 can parse the query purpose and match the disclosure strategy based on the arbitrator's role and dispute type, outputting only necessary fields such as the summary of the authorization document, the award conclusion, the scope of the execution token, the payment execution result, and the summary of the integrity certificate, while omitting user real-name information, device fingerprint plaintext, and internal risk control parameters. It should be understood that the above example scenarios are for illustrative purposes only and are not intended to limit the scope of the solution.

[0096] Figure 3 A flowchart of an example method 300 for payment under certain scenarios is shown. Method 300 can be implemented in a payment management system 120. For ease of discussion, the following is combined with... Figure 1 The environment 100 described herein describes method 300.

[0097] In box 310, the payment management system 120 acquires multiple events associated with the payment process of the smart agent.

[0098] In box 320, the payment management system 120 generates multiple event verification information corresponding to multiple events based on the event content of multiple events.

[0099] In box 330, the payment management system 120 constructs process verification information corresponding to the payment process based on the timing information of multiple events and the verification information of multiple events.

[0100] Therefore, it is possible to unify the various objects associated with the payment process of the intelligent agent into verifiable events, generate event-level event verification information, and construct process-level process verification information based on time sequence and causal relationships. This enables unified organization, on-demand reconstruction, and permission-based provision of the payment process at the functional level. Furthermore, by using structured events, causal relationship graphs, and hash chains as process verification information, compared to maintaining heterogeneous records module by module and manually splicing them when needed, it can reduce the computational overhead of cross-module retrieval, parsing, and reconstruction, and reduce the number of storage read and write operations. This improves traceability efficiency and reliability while reducing system resource consumption.

[0101] In some cases, acquiring multiple events associated with the agent's payment process includes: during the agent's payment process, in response to detecting that the agent has performed an operation related to the payment process, acquiring the operation result of the operation; and determining the event corresponding to the operation based on the operation result.

[0102] In some cases, method 300 further includes: for each of the plurality of events, validating the event based on the fields of the event, the validation result indicating at least whether the fields of the event are complete; in response to the validation result of the first event indicating that the fields of the first event are incomplete, refusing to store the first event; and sending a first message to the agent indicating that the fields of the first event are incomplete.

[0103] In some cases, generating multiple event verification information corresponding to multiple events includes: performing normalization processing on the event content of multiple events to obtain normalized event content of multiple events; and determining the event verification information corresponding to multiple events based on the normalized event content.

[0104] In some cases, each of the multiple events includes a first event hash of that event, and method 300 further includes: calculating a second event hash for each of the multiple events based on the normalized event content of the multiple events; comparing the first event hash and the second event hash for each of the multiple events; refusing to store the second event in response to a discrepancy between the first event hash and the second event hash of the second event among the multiple events; and sending a second message to the agent indicating that the event hash of the second event is inconsistent.

[0105] In some cases, method 300 further includes storing events other than the first and / or second events among a plurality of events, wherein the other stored events remain unchanged.

[0106] In some cases, method 300 further includes: in response to an exception occurring in a third of multiple events, generating an exception record corresponding to the event, wherein the exception includes at least one of the following: incomplete field, inconsistent event hash, untrusted event source, or inability to locate the associated object.

[0107] In some cases, method 300 further includes: in response to the payment process meeting a first predetermined condition, obtaining the user's review information on the third event corresponding to the smart agent, wherein the first predetermined condition indicates that the risk level of the payment process has reached a threshold.

[0108] In some cases, process verification information includes a causal relationship graph corresponding to the payment process. Constructing the causal relationship graph includes: determining the causal relationship between multiple events based on predetermined causal identification rules; determining causal edges based on the causal relationship, with the direction of the causal edges pointing from upstream cause events to downstream result events; and constructing the causal relationship graph based on the causal edges.

[0109] In some cases, method 300 also includes: establishing forward and reverse indexes based on causal edges, whereby the forward index is used to trace the impact of events on downstream events, and the reverse index is used to trace back upstream events from the results of the payment process.

[0110] In some cases, the process verification information includes a hash chain corresponding to the payment process. Constructing the hash chain includes: sorting multiple events based on their respective time sequence information; and determining chained verification information corresponding to multiple events based on the sorting results. The chained verification information constitutes the hash chain.

[0111] In some cases, the chain verification information corresponding to each event in multiple events is determined based on the event verification information of that event, the chain verification information corresponding to the previous event in the sorting results, and the chain sequence number of that event in the payment process.

[0112] In some cases, method 300 further includes: during the storage of the hash chain, in response to the chain number in the hash chain not satisfying continuous increment, sending a third message to the agent, the third message indicating a discontinuity in the chain number.

[0113] In some cases, method 300 further includes: re-determining the chain check information from a first position in the hash chain, the first position being the head of the hash chain or the anchor point of the hash chain; and generating a chain break event in response to a discrepancy between the re-determined chain check information and the chain check information.

[0114] In some cases, anchor points are determined based on the following: an anchor point is generated in response to the number of stored events reaching a preset number and / or the payment process meeting a preset state.

[0115] Figure 4A flowchart of an example method 400 for information processing based on certain scenarios is shown. Method 400 can be implemented in a payment management system 120. For ease of discussion, the following is combined with... Figure 1 The described environment 100 describes method 400. Method 400 can be considered as a combination of... Figure 3 The corresponding process of the described method 300 on the query processing side can be executed by the same system at different stages.

[0116] In box 410, the payment management system 120 responds to receiving a query request associated with the payment process of the smart agent by obtaining process verification information corresponding to the payment process. The process verification information is obtained based on multiple event verification information corresponding to multiple events, which are associated with the payment process.

[0117] In box 420, the payment management system 120 determines at least one event verification information based on the process verification information, and the scope of the at least one event verification information is determined based on the query permission corresponding to the query request.

[0118] In box 430, the payment management system 120 provides a response to the query request based on at least one event verification information.

[0119] In some cases, obtaining process verification information corresponding to the payment process includes: determining the query type corresponding to the query request; and in response to the query type not falling within the specified range, sending a fourth message to the agent, the fourth message indicating that the query type of the query request is incorrect.

[0120] In some cases, obtaining process verification information corresponding to the payment process includes: determining the associated payment object corresponding to the query request; determining whether a payment record corresponding to the payment process is stored based on the associated payment object; and in response to the existence of a payment record, obtaining the link identifier of the payment process based on the payment record, and obtaining process verification information based on the link identifier.

[0121] In some cases, method 400 further includes: in response to the absence of a payment record, sending a fifth message to the agent, the fifth message indicating that there is an error in the associated payment object of the query request.

[0122] In some cases, determining at least one event verification information includes: obtaining the query strategy corresponding to the query request from multiple query strategies based on the query request; and determining at least one event verification information based on the query strategy and process verification information.

[0123] In some cases, the process verification information includes a causal graph corresponding to the payment process, and determining at least one event verification information includes: identifying an initial event matching the query request from the causal graph; performing a reverse traversal of the causal edges of the initial event in the causal graph to obtain at least one event upstream of the initial event time in the causal graph; and obtaining at least one event verification information corresponding to at least one event.

[0124] In some cases, method 400 further includes: performing a verification on at least one event, the verification result indicating the integrity, continuity and causal order of at least one event; and generating a verification report based on the verification result.

[0125] In some cases, providing a response to a query request includes: generating an evidence package corresponding to the query request based on at least one event verification information; determining the disclosure content based on the evidence package and the query permissions corresponding to the query request; and generating a response to the query request based on the disclosure content.

[0126] In some cases, method 400 further includes: processing the first field in response to the disclosure including a first field that does not meet predetermined requirements; and determining the updated disclosure based on the processed first field.

[0127] In some cases, method 400 further includes: generating a query receipt corresponding to the response, storing the query receipt, and keeping the stored query receipt unchanged.

[0128] In some cases, generating a response to a query request based on the disclosed content includes: determining the view type corresponding to the disclosed content based on the user corresponding to the query request; and generating a response to the query request based on the disclosed content and the view type.

[0129] In some cases, method 400 further includes: determining the purpose of the query request; and refusing to provide a response to the query request in response to a mismatch between the purpose of the query and the user corresponding to the payment process and / or the query request.

[0130] In some cases, method 400 also includes providing a feedback interface, which includes at least a response.

[0131] A corresponding apparatus for implementing the above methods or processes is also provided.

[0132] Figure 5 An exemplary structural block diagram of a payment device 500 is shown according to some scenarios. The device 500 may be implemented as or included in a payment management system 120. The various modules / components in the device 500 may be implemented by hardware, software, firmware, or any combination thereof.

[0133] like Figure 5 As shown, the device 500 includes an event acquisition module 510, configured to acquire multiple events associated with the payment process of the smart agent; a first generation module 520, configured to generate multiple event verification information corresponding to the multiple events based on the event content of the multiple events; and a second generation module 530, configured to construct process verification information corresponding to the payment process based on the timing information of the multiple events and using the multiple event verification information.

[0134] In some cases, the event acquisition module 510 can also be configured to: during the payment process of the agent, in response to detecting that the agent has performed an operation related to the payment process, acquire the operation result of the operation; and determine the event corresponding to the operation based on the operation result.

[0135] In some cases, the device 500 may also be configured to: for each of a plurality of events, validate the event based on the fields of the event, and refuse to store the first event and send the first information to the agent in response to the incompleteness of the fields of the first event.

[0136] In some cases, the first generation module 520 can also be configured to: perform normalization processing on the event content of multiple events to obtain normalized event content; and determine the event verification information corresponding to the multiple events based on the normalized event content.

[0137] In some cases, the device 500 may also be configured to: calculate second event verification information for each of the multiple events based on the normalized event content, and refuse to store the second event and send the second information to the agent when the first event verification information of the second event is inconsistent with the second event verification information; and store other events other than the first event and / or the second event, while the other stored events remain unchanged.

[0138] In some cases, device 500 may also be configured to: generate a corresponding exception record in response to an anomaly in a third event; and obtain user review information on the third event corresponding to the smart agent in response to the payment process meeting a first predetermined condition.

[0139] In some cases, the process verification information includes a causal relationship graph corresponding to the payment process. The second generation module 530 can also be configured to: determine the causal relationship between multiple events based on a predetermined causal identification rule; determine causal edges based on the causal relationship, with the direction of the causal edges pointing from the upstream cause event to the downstream result event; and construct a causal relationship graph based on the causal edges.

[0140] In some cases, the second generation module 530 can also be configured to: establish a forward index and a reverse index based on causal edges, whereby the forward index is used to trace the impact of events on downstream events, and the reverse index is used to trace back upstream events from the results of the payment process.

[0141] In some cases, the process verification information includes a hash chain corresponding to the payment process. The second generation module 530 can also be configured to: sort multiple events based on their respective time sequence information; and determine chained verification information corresponding to multiple events based on the sorting results, wherein the chained verification information constitutes a hash chain.

[0142] In some cases, the chain verification information corresponding to each event in multiple events is determined based on the event verification information of that event, the chain verification information corresponding to the previous event in the sorting results, and the chain sequence number of that event in the payment process.

[0143] In some examples, device 500 can also be configured to: during the storage of the hash chain, in response to the chain number in the hash chain not satisfying continuous increment, send a third message to the agent, the third message indicating a discontinuity in the chain number.

[0144] In some examples, device 500 may also be configured to: redetermine chain verification information from a first position in the hash chain, the first position being the head of the hash chain or the anchor point of the hash chain; and generate a chain break event in response to a discrepancy between the redetermined chain verification information and the chain verification information.

[0145] In some examples, anchor points are determined based on the following: an anchor point is generated in response to the number of stored events reaching a preset number and / or the payment process meeting a preset state.

[0146] Figure 6 A block diagram of an apparatus 600 for information processing is shown, depending on certain scenarios. Apparatus 600 may be implemented as or included in electronic device 110, or may be implemented as or included in payment management system 120. The various modules / components in apparatus 600 may be implemented by hardware, software, firmware, or any combination thereof.

[0147] like Figure 6As shown, the device 600 includes an information acquisition module 610, configured to acquire process verification information corresponding to the payment process in response to receiving a query request associated with the payment process of the smart agent. The process verification information is obtained based on multiple event verification information corresponding to multiple events associated with the payment process. The multiple events are associated with the payment process. An information determination module 620 is configured to determine at least one event verification information based on the process verification information. The scope of the at least one event verification information is determined based on the query permission corresponding to the query request. A response providing module 630 is configured to provide a response to the query request based on at least one event verification information.

[0148] In some cases, the information acquisition module 610 can also be configured to: determine the query type corresponding to the query request, and send fourth information to the agent when the query type does not fall within the specified range; and / or determine the associated payment object corresponding to the query request, determine whether a payment record corresponding to the payment process is stored based on the associated payment object, obtain the link identifier of the payment process based on the payment record and obtain the process verification information accordingly when a payment record exists, and send fifth information to the agent when no payment record exists.

[0149] In some cases, the information determination module 620 may also be configured to: obtain the corresponding query strategy from multiple query strategies based on the query request, and determine at least one event verification information based on the query strategy and process verification information; and / or determine the initial event matching the query request from the causal relationship graph, perform reverse traversal of the causal edge where the initial event is located from the initial event to obtain at least one event located upstream of the initial event in the time sequence, and obtain at least one event verification information corresponding to at least one event.

[0150] In some cases, the device 600 may also be configured to: perform a verification on at least one event, the verification result indicating the integrity, continuity and causal order of at least one event, and generate a verification report based on the verification result.

[0151] In some cases, the response providing module 630 can also be configured to: generate an evidence package corresponding to the query request based on at least one event verification information, determine the disclosure content based on the evidence package and the query permission corresponding to the query request, and generate a response to the query request based on the disclosure content.

[0152] In some cases, device 600 may also be configured to: generate and store a query receipt corresponding to the response, with the stored query receipt remaining unchanged; process the first field in response to the disclosure content including a first field that does not meet predetermined requirements and thereby determine the updated disclosure content; determine the view type corresponding to the disclosure content based on the user corresponding to the query request and thereby generate a response; determine the query purpose of the query request and refuse to provide a response if the query purpose does not match the payment process and / or the corresponding user; and provide a feedback interface that includes at least the response.

[0153] Figure 7 A block diagram of an electronic device 700 capable of implementing multiple illustrative scenarios is shown. The electronic device 700 can be used to implement... Figure 1 The payment management system 120 described. It should be understood that... Figure 7 The electronic device 700 shown is merely an example and should not be construed as limiting the functionality and scope of the example described herein.

[0154] like Figure 7 As shown, electronic device 700 is in the form of a general-purpose computing device. Components of electronic device 700 may include, but are not limited to, one or more processors or processing units 710, memory 720, storage device 730, one or more communication units 740, one or more input devices 750, and one or more output devices 760. Processing unit 710 may be a physical or virtual processor and is capable of performing various processes according to programs stored in memory 720. In a multiprocessor system, multiple processing units execute computer-executable instructions in parallel to improve the parallel processing capability of electronic device 700.

[0155] Electronic device 700 typically includes multiple computer storage media. Such media can be any available media accessible to electronic device 700, including but not limited to volatile and non-volatile media, removable and non-removable media. Memory 720 can be volatile memory (e.g., registers, cache, random access memory (RAM)), non-volatile memory (e.g., read-only memory (ROM), flash memory), or some combination thereof). Storage device 730 can be removable or non-removable media and can include machine-readable media, such as flash drives, disks, or any other media capable of storing information and / or data and accessible within electronic device 700.

[0156] Electronic device 700 may further include additional removable / non-removable, volatile / non-volatile storage media. Although not explicitly stated... Figure 7As shown, disk drives for reading from or writing to removable, non-volatile disks and optical disk drives for reading from or writing to removable, non-volatile optical disks can be provided. In these cases, each drive can be connected to a bus via one or more data media interfaces. Memory 720 may include program product 725 having one or more program modules configured to perform the methods or actions of the various examples described herein.

[0157] The communication unit 740 enables communication with other computing devices via a communication medium. Additionally, the functionality of the components of the electronic device 700 can be implemented as a single computing cluster or multiple computing machines capable of communicating via communication connections. Therefore, the electronic device 700 can operate in a networked environment using logical connections to one or more other servers, network personal computers (PCs), or another network node.

[0158] Input device 750 can be one or more input devices, such as a mouse, keyboard, trackball, etc. Output device 760 can be one or more output devices, such as a monitor, speaker, printer, etc. Electronic device 700 can also communicate with one or more external devices (not shown) via communication unit 740 as needed. These external devices include storage devices, display devices, etc., and can communicate with one or more devices that enable user interaction with electronic device 700, or with any device that enables electronic device 700 to communicate with one or more other computing devices (e.g., network card, modem, etc.). Such communication can be performed via input / output (I / O) interface (not shown).

[0159] According to examples herein, a computer-readable storage medium is provided that stores computer-executable instructions thereon, wherein the computer-executable instructions are executed by a processor to implement the methods described above. According to examples herein, a computer program product is also provided that is tangibly stored on a non-transitory computer-readable medium and includes computer-executable instructions, which are executed by a processor to implement the methods described above.

[0160] Various aspects are described herein with reference to flowchart illustrations and / or block diagrams of the methods, apparatuses, devices, and computer program products implemented according to this document. It should be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0161] These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processing unit of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of a flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, causing a computer, programmable data processing apparatus, and / or other device to operate in a particular manner.

[0162] The flowcharts and block diagrams in the accompanying figures illustrate the architecture, functionality, and operation of possible implementations of the systems, methods, and computer program products according to various embodiments of this document. In this regard, each box in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions indicated in the boxes may occur in a different order than those indicated in the figures.

[0163] The various implementations described herein have been illustrated above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed implementations. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the described implementations. The terminology used herein is chosen to best explain the principles, practical applications, or improvements to technology in the market, or to enable others skilled in the art to understand the implementations disclosed herein.

Claims

1. A method for making a payment, comprising: Acquire multiple events associated with the agent's payment process; Based on the event content of the multiple events, generate multiple event verification information corresponding to the multiple events; as well as Based on the timing information of the multiple events, and using the verification information of the multiple events, process verification information corresponding to the payment process is constructed.

2. The method of claim 1, wherein acquiring multiple events associated with the payment process of the smart agent includes: During the payment process of the intelligent agent, in response to detecting that the intelligent agent has performed an operation related to the payment process, the operation result of the operation is obtained; as well as The event corresponding to the operation is determined based on the operation result.

3. The method according to claim 1, further comprising: For each of the plurality of events, the event is validated based on its fields, and the validation result indicates at least whether the fields of the event are complete; If the validation result of the first event among the plurality of events indicates that the field of the first event is incomplete, the first event is refused to be stored; as well as Send a first message to the agent, the first message indicating that the fields of the first event are incomplete.

4. The method according to claim 1, wherein generating the multiple event verification information corresponding to the multiple events includes: The event content of the multiple events is normalized to obtain the normalized event content of the multiple events; as well as Based on the standardized event content, the event verification information corresponding to the multiple events is determined.

5. The method of claim 4, wherein each of the plurality of events includes a first event hash of that event, the method further comprising: Calculate the second event hash of each of the multiple events based on the normalized event content; Compare the first event hash and the second event hash of each of the plurality of events; as well as If the hash of the first event and the hash of the second event in the plurality of events are inconsistent, the second event is refused to be stored; as well as A second message is sent to the agent, indicating that the event hash of the second event is inconsistent.

6. The method according to claim 3 or 5, further comprising: Store other events besides the first event and / or the second event among the plurality of events, wherein the other events that have been stored remain unchanged.

7. The method according to claim 1, further comprising: In response to an anomaly in a third of the plurality of events, an anomaly record corresponding to the event is generated, wherein the anomaly includes at least one of the following: incomplete fields, inconsistent event hashes, untrustworthy event source, or inability to locate the associated object.

8. The method of claim 7, further comprising: In response to the payment process meeting a first predetermined condition, the system obtains the user's review information on the third event corresponding to the smart agent, wherein the first predetermined condition indicates that the risk level of the payment process has reached a threshold.

9. The method according to claim 1, wherein the process verification information includes a causal relationship graph corresponding to the payment process, and constructing the causal relationship graph includes: Based on predetermined causal identification rules, the causal relationships between the multiple events are determined; Based on the causal relationship, a causal edge is determined, and the direction of the causal edge is from the upstream cause event to the downstream result event; The causal relationship graph is constructed based on the causal edges.

10. The method of claim 9, further comprising: Based on the causal edge, a forward index and a reverse index are established. The forward index is used to trace the impact of an event on the downstream, and the reverse index is used to trace back upstream events from the result of the payment process.

11. The method of claim 1, wherein the process verification information includes a hash chain corresponding to the payment process, wherein constructing the hash chain includes: The events are sorted based on their respective time sequence information; as well as Based on the sorting result, chained verification information corresponding to the multiple events is determined, and the chained verification information constitutes the hash chain.

12. The method according to claim 11, wherein the chain verification information corresponding to each of the plurality of events is determined based on the event verification information of the event, the chain verification information corresponding to the previous event of the event in the sorting result, and the chain sequence number of the event in the payment process.

13. The method of claim 11, further comprising: During the storage of the hash chain, in response to the chain number in the hash chain not satisfying continuous increment, a third message is sent to the agent, the third message indicating that the chain number is discontinuous.

14. The method of claim 11, further comprising: The chain verification information is re-determined starting from the first position of the hash chain, where the first position is located at the head of the hash chain or the anchor point of the hash chain; as well as In response to a discrepancy between the re-determined chain verification information and the original chain verification information, a chain break event is generated.

15. The method of claim 14, wherein the anchor point is determined based on: An anchor point is generated in response to the number of stored events reaching a preset number and / or the payment process meeting a preset state.

16. A method for information processing, comprising: In response to receiving a query request associated with the payment process of the smart agent, process verification information corresponding to the payment process is obtained, the process verification information is obtained based on multiple event verification information corresponding to multiple events, the multiple events being associated with the payment process; Based on the process verification information, at least one event verification information is determined, and the scope of the at least one event verification information is determined based on the query permission corresponding to the query request; as well as Based on the at least one event verification information, a response is provided for the query request.

17. The method according to claim 16, wherein obtaining the process verification information corresponding to the payment process includes: Determine the query type corresponding to the query request; as well as In response to the query type not falling within the specified range, a fourth message is sent to the agent, indicating that the query type of the query request is incorrect.

18. The method according to claim 16, wherein obtaining the process verification information corresponding to the payment process includes: Determine the associated payment object corresponding to the query request; Based on the associated payment object, determine whether a payment record corresponding to the payment process is stored; as well as In response to the existence of the payment record, the link identifier of the payment process is obtained based on the payment record, and the process verification information is obtained based on the link identifier.

19. The method of claim 18, further comprising: In response to the absence of the payment record, a fifth message is sent to the agent, indicating that there is an error in the associated payment object of the query request.

20. The method of claim 16, wherein determining at least one event verification information comprises: Based on the query request, obtain the query strategy corresponding to the query request from multiple query strategies; Based on the query strategy and the process verification information, the at least one event verification information is determined.

21. The method of claim 16, wherein the process verification information includes a causal relationship graph corresponding to the payment process, and determining the at least one event verification information includes: Identify the initial event that matches the query request from the causal relationship graph; In the causal relationship graph, starting from the initial event, the causal edges where the initial event is located are traversed in reverse order to obtain at least one event in the causal relationship graph that is upstream of the initial event time. as well as Obtain the verification information corresponding to the at least one event.

22. The method of claim 21, further comprising: A verification is performed on the at least one event, and the verification result indicates the integrity, continuity, and causal order of the at least one event; as well as A verification report is generated based on the verification results.

23. The method of claim 16, wherein providing a response to the query request comprises: Based on the at least one event verification information, generate the evidence package corresponding to the query request; Based on the evidence package and the query permissions corresponding to the query request, the content to be disclosed is determined; as well as Based on the disclosed information, a response is generated for the query request.

24. The method of claim 23, further comprising: In response to the disclosure including a first field that does not meet predetermined requirements, the first field is processed; as well as The updated disclosure content is determined based on the processed first field.

25. The method of claim 23, further comprising: Generate a query receipt corresponding to the response, store the query receipt, and keep the stored query receipt unchanged.

26. The method of claim 23, wherein generating a response to the query request based on the disclosed content comprises: Based on the user corresponding to the query request, determine the view type corresponding to the disclosed content; as well as Based on the disclosed content and the view type, a response is generated for the query request.

27. The method of claim 16, further comprising: Determine the purpose of the query request; In response to the fact that the purpose of the query does not match the payment process and / or the user corresponding to the query request, a response to the query request is refused.

28. The method of claim 16, further comprising: A feedback interface is provided, which includes at least the response.

29. A device for making payments, comprising: The event acquisition module is configured to acquire multiple events associated with the agent's payment process; The first generation module is configured to generate multiple event verification information corresponding to the multiple events based on the event content of the multiple events; as well as The second generation module is configured to construct process verification information corresponding to the payment process based on the timing information of the multiple events and the verification information of the multiple events.

30. An apparatus for information processing, comprising: The information acquisition module is configured to, in response to receiving a query request associated with the payment process of the smart agent, acquire process verification information corresponding to the payment process, wherein the process verification information is obtained based on multiple event verification information corresponding to multiple events, and the multiple events are associated with the payment process; The information determination module is configured to determine at least one event verification information based on the process verification information, wherein the scope of the at least one event verification information is determined based on the query permission corresponding to the query request; as well as A response providing module is configured to provide a response to the query request based on the at least one event verification information.

31. An electronic device, characterized in that, include: At least one processor; as well as At least one memory, the at least one memory being coupled to the at least one processor and storing instructions for execution by the at least one processor, characterized in that, when executed by the at least one processor, the instructions cause the electronic device to perform the method according to any one of claims 1 to 15, or, according to any one of claims 16 to 28.

32. A computer-readable storage medium having computer-executable instructions stored thereon, characterized in that, The computer-executable instructions can be executed by a processor to implement the method according to any one of claims 1 to 15, or the method according to any one of claims 16 to 28.

33. A computer program product, said computer program product being tangibly stored in a computer storage medium and comprising computer-executable instructions, characterized in that, The computer-executable instructions, when executed by the device, cause the device to perform the method according to any one of claims 1 to 15, or the method according to any one of claims 16 to 28.

Images