Methods, apparatuses, devices, media, and program products for payment

Abstract

A method, apparatus, device, medium and program product for payment are provided. The method comprises: in response to receiving a payment request from an intelligent agent, obtaining a plurality of credentials associated with the payment request, the plurality of credentials comprising at least a first credential and a second credential, the first credential being used to verify payment authority of the intelligent agent, and the second credential being used to verify a payment subject of the payment request; based on the plurality of credentials, performing a verification process on the payment request; and based on a verification result of the verification process, processing the payment request. In this way, the payment reliability associated with the intelligent agent can be guaranteed.

Description

Technical Field

[0001] The examples in this article generally relate to the field of computers, and in particular to methods, apparatus, devices, computer storage media, and computer program products used for payment. Background Technology

[0002] With the development of autonomous payment by intelligent agents, payment requests may be automatically generated by authorized intelligent agents based on user tasks, scenario constraints, and runtime adjudication results, rather than always being initiated directly by the paying entity for each transaction. In such a scenario, how to clearly express the attribution of funds and responsibilities, the scope of authorized agents, and whether a single payment is executable at the credential level, while maintaining consistency among the credentials when authorization relationships change, are problems that need to be solved. Summary of the Invention

[0003] In a first aspect of this document, a method for payment is provided. The method includes: in response to receiving a payment request from an agent, obtaining multiple credentials associated with the payment request, the multiple credentials including at least a first credential and a second credential, the first credential being used to verify the payment authority of the agent, and the second credential being used to verify the payment subject of the payment request; performing a verification process for the payment request based on the multiple credentials; and processing the payment request based on the verification result of the verification process.

[0004] In a second aspect of this paper, a method for generating payment credentials is provided. The method includes: acquiring a second credential for verifying a payment subject; generating a first credential based on the second credential for verifying a smart agent's payment permissions; and, in response to receiving a payment request from the smart agent, generating a third credential based on the first credential for verifying payment parameters of a payment token.

[0005] In a third aspect of this document, an apparatus for payment is provided. The apparatus includes: a first acquisition module configured to, in response to receiving a payment request from an agent, acquire multiple credentials associated with the payment request, the multiple credentials including at least a first credential and a second credential, the first credential being used to verify the payment authority of the agent, and the second credential being used to verify the payment subject of the payment request; a first verification module configured to perform a verification process on the payment request based on the multiple credentials; and a processing module configured to process the payment request based on the verification result of the verification process.

[0006] In a fourth aspect of this document, an apparatus for generating payment credentials is provided. The apparatus includes: a second acquisition module configured to acquire a second credential for verifying a payment subject; a first generation module configured to generate a first credential based on the second credential for verifying a smart agent's payment permissions; and a second generation module configured to generate a third credential based on the first credential in response to receiving a payment request from a smart agent, the third credential for verifying payment parameters of a payment token.

[0007] In a fifth aspect of this document, an electronic device is provided. The electronic device includes: at least one processing unit; and at least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions causing the electronic device to perform a method according to the first or second aspect when executed by the at least one processing unit.

[0008] In a sixth aspect of this document, a computer-readable storage medium is provided. A computer program is stored on the computer-readable storage medium, and the computer program can be executed by a processor to implement the method according to the first or second aspect.

[0009] In a seventh aspect of this document, a computer program product is provided. The computer program product 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 according to the first or second aspect.

[0010] In this way, the identity of the payment subject, the agent's agency authority, and the single payment execution authority in the intelligent agent autonomous payment scenario can be separated into multiple mutually referencing credentials. Based on these multiple credentials, the payment request initiated by the intelligent agent is verified and then processed. This clearly expresses the attribution of funds and responsibilities, the scope of the agent's allowed agency, and whether a single payment can be executed at the credential level. It realizes hierarchical authorization and restricted execution in the intelligent agent payment scenario, improves the security and traceability of intelligent agent autonomous payments, and reduces the financial risks caused by the break of authorization relationships or the replacement of credentials.

[0011] 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

[0012] 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 1A schematic diagram of an example environment based on some examples in this article is shown; Figure 2 A schematic block diagram illustrating the overall architecture of a three-tier payment credential chain based on some examples in this paper is shown; Figure 3 A schematic diagram illustrating the convergence of hierarchical permissions during credential generation, based on some examples in this article, is shown. Figure 4 A flowchart is shown illustrating an example process of layer-by-layer verification during payment execution, based on some examples in this article; Figure 5 A timing diagram of an example process for generating a second credential is shown, based on some examples in this paper; Figure 6 A timing diagram of an example process for generating a first credential is shown, based on some examples in this paper; Figure 7 A timing diagram of an example process for first-level permission convergence verification based on some examples in this paper is shown; Figure 8 A timing diagram of an example process for Level 2 permission convergence verification based on some examples in this paper is shown; Figure 9 A schematic diagram illustrating the division of responsibilities and referencing relationships among three levels of credentials, based on some examples in this paper, is shown. Figure 10 A flowchart illustrating a payment method based on some examples from this article is shown; Figure 11 A flowchart illustrating a method for generating payment vouchers, based on some examples in this paper, is shown; Figure 12 Block diagrams of payment devices for several scenarios are shown; Figure 13 Block diagrams of apparatuses for generating payment vouchers in various scenarios are shown; and Figure 14 A block diagram of an electronic device capable of implementing multiple illustrative scenarios is shown. Detailed Implementation

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

[0014] It should be noted that the headings of any section / subsection provided herein are not restrictive. Various examples are described throughout this document, and examples of any type may be included under any section / subsection. Furthermore, examples described in any section / subsection may be combined in any way with any other examples described in the same section / subsection and / or different sections / subsections.

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

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

[0018] As used in this article, the term "agent" refers to a software or program entity capable of perceiving tasks, making decisions, and initiating or executing operations on behalf of a payment subject. This typically includes, but is not limited to, rule-based programs, agent programs built based on machine learning models, and any combination of the foregoing. In some examples, an agent can automatically initiate payment requests on behalf of the payment subject based on user tasks, scenario constraints, and operating environment.

[0019] The term "autonomous payment by intelligent agent" as used in this article refers to a payment method in which an authorized intelligent agent initiates or executes a payment on behalf of the payment subject based on user tasks, scenario constraints, proxy capabilities, and runtime adjudication results, without requiring the payment subject to initiate each payment directly.

[0020] The term “payment request” as used in this document refers to a message or data requesting the execution of a payment, which may include, but is not limited to, at least one of the following: agent identity information, credential reference, payment amount, payee information, merchant category code, scene information, and time information.

[0021] The term "payment entity" as used in this article refers to the entity that ultimately bears the funds and responsibilities involved in the payment, which may include, but is not limited to, natural persons or enterprises that have undergone real-name authentication. The payment entity may also be referred to as a real-name entity in this article.

[0022] The term "credential" as used in this document refers to a data structure or data record that is used to prove a fact or a right and can be verified. It typically includes, but is not limited to, at least one of the following: credential identifier, constraint fields, status information, and reference information to other credentials.

[0023] The term "secondary credential" as used in this document refers to a credential used to verify the payer's identity in a payment request. It may also be referred to as a real-name credential or a first-level credential, and is typically used to prove the ultimate attribution of funds and liability. A secondary credential may indicate at least one of the following: the type of payer, authentication information, account information, the intelligent agent associated with the payer, and payment configuration information associated with the payer.

[0024] As used herein, the term "first credential" refers to a credential used to verify an agent's payment authority. It may also be referred to herein as an agent proxy credential or a second-level credential, typically used to prove that an agent is authorized to act on behalf of a payment entity within a defined scope. A first credential may indicate at least one of the following: the agent's identity information, authentication information, capability information, payment configuration information associated with the agent, and a validity period associated with the agent. The scope of authority of a first credential generally does not exceed the scope of authorization of the second credential it references.

[0025] The term "third credential" as used in this document refers to a credential used to verify the payment parameters of a payment token. It may also be referred to as a payment execution token or third-level credential, and is typically used to prove that a payment request has been adjudicated and can be executed. A third credential may indicate at least one of the following: payment amount, business party information, scenario information, validity period, and number of uses. The scope of authority of a third credential generally does not exceed the scope of authority of the first credential it references.

[0026] The term “payment authority” as used in this article refers to the scope within which an intelligent agent is permitted to make payments on behalf of a payment entity, which typically includes, but is not limited to, at least one of the following: permitted scenarios, permitted merchant categories, single transaction limits, cumulative limits, and validity periods.

[0027] As used in this document, the term "payment token" refers to data used to carry and express the information required for a single payment, whose payment parameters may include, but are not limited to, at least one of the following: payment amount, business information, scenario information, and validity period. In some examples, the payment token may be carried by or correspond to a third-party credential.

[0028] The term "verification process" as used in this document refers to the process of verifying a payment request based on one or more vouchers, which may include, but is not limited to, at least one of the following: verification of voucher status, verification of voucher validity, verification of reference relationships between vouchers, verification of authorization scope, and verification of voucher integrity.

[0029] As used in this document, "reference information" refers to information in one document that points to another document, which may include, but is not limited to, the identifier of the referenced document. Lower-level documents reference higher-level documents through reference information, thereby establishing a verifiable association between documents.

[0030] The term "first checksum" as used in this document refers to the integrity digest calculated based on multiple vouchers and stored in the vouchers; it may also be referred to as the voucher chain hash. The term "second checksum" refers to the integrity digest recalculated based on multiple vouchers during the verification process, used to compare with the first checksum to detect whether the reference relationships or constraint fields of the multiple vouchers have been replaced, tampered with, or misreferenced.

[0031] The term "constraint field" as used in this document refers to a field that participates in the calculation of the verification value and is used to characterize the key attributes of the voucher. It may include, but is not limited to, at least one of the version information, status information and summary information of the corresponding voucher.

[0032] As used in this document, the term "permission set" refers to the executable scope indicated by a credential, which may include, but is not limited to, at least one of the following: a set of permitted smart agents, a set of permitted scenarios, a set of permitted merchant category codes, a set of capability codes, a set of scenario wallets, a single transaction limit, a daily limit, a monthly limit, and a validity period. The first permission set typically refers to the permission set indicated by the second credential, and the second permission set typically refers to the permission set indicated by the first credential.

[0033] The term "configuration information" as used in this document refers to information that is used as input when generating a credential and describes the permissions or attributes declared by the credential to be generated. This information may include, but is not limited to, at least one of the following: the capabilities to be declared, the scenario, the merchant category, the limit, and the validity period.

[0034] As used in this document, the term "documentation record" refers to data written into a documentation chain or auditing system to record events related to documents, which can indicate at least one of the generation and modification information of multiple documents. The term "documentation chain" refers to a data base used to store documentation records in a traceable manner, which typically records events by appending them to the data.

[0035] The term "fourth credential" as used in this article refers to a credential used to verify the scope of an agent's task execution. It can be introduced between the first and third credentials to suit multi-level delegation scenarios.

[0036] The term “three-tier payment voucher chain” used in this article refers to a hierarchical voucher structure consisting of a second voucher, a first voucher, and a third voucher. The vouchers at each level are linked to each other through reference information, and the scope of authority of a lower-level voucher usually does not exceed that of an upper-level voucher.

[0037] The term "permission convergence" used in this article refers to the principle that the permission scope of a lower-level credential does not exceed the permission scope of an upper-level credential, which is usually achieved by comparing multiple permission dimensions one by one.

[0038] The term "linkage failure" as used in this article refers to the mechanism by which, when the state of an upper-level document changes, the change is propagated to one or more lower-level documents that reference the upper-level document, and the state of the lower-level documents is adjusted accordingly.

[0039] As used in this article, the term "hash function" refers to a function that maps an input of arbitrary length to an output of fixed length, which may include, but is not limited to, cryptographic hash functions (e.g., SHA-256). In some examples, hash functions can be used to compute a first checksum and a second checksum.

[0040] The term "real-name authentication level" as used in this article refers to a measure of the degree of identity verification for a payment entity, which may include, but is not limited to, different levels of authentication strength. The term "KYC" (Know Your Customer) refers to the identity verification of a payment entity, and in this article, it may correspond to the authentication information of the second credential.

[0041] The term "agent authentication level" as used in this paper refers to a measure of the degree to which an agent's identity and capabilities are authenticated. The term "KYA" (Know Your Agent) refers to the authentication of an agent's identity and capabilities, and in this paper, it can correspond to the authentication information of the first credential.

[0042] The term “Merchant Category Code” (MCC) used in this article refers to a code used to identify a merchant’s business category, which can be used as a dimension of payment authorization.

[0043] The term "scenario code" as used in this article refers to a code used to identify a payment scenario, which can be used as a dimension of payment authorization. Exemplary scenarios may include, but are not limited to, air travel, hotel accommodation, purchasing, and transactions.

[0044] The term "scenario wallet" as used in this article refers to a financial vehicle associated with a specific scenario, which can be linked to a first credential to limit the scope of funds that an agent can use in the corresponding scenario.

[0045] As used herein, the term "ruling result" refers to the conclusion reached after determining a payment request, which may include, but is not limited to, at least one of approval, rejection, and enhanced confirmation. The term "enhanced confirmation" refers to a processing method that provides the paying entity with information to determine whether to proceed with the payment when the ruling result indicates that further confirmation is required.

[0046] As mentioned above, in intelligent agent autonomous payment scenarios, payment requests are not necessarily initiated directly by the paying entity for each transaction. Instead, they may be automatically generated by an authorized intelligent agent based on user tasks, scenario limitations, proxy capabilities, and runtime adjudication results. In some solutions, payment authentication and authorization verification are flat, single-layer structures that only verify the payment account, user identity, payment password, device status, or transaction risk. This makes it difficult to clearly express, at the credential level, the three different facts of "who ultimately owns the funds, which intelligent agent is allowed to act as an agent, and whether this payment has been adjudicated and allowed to be executed."

[0047] Specifically, in the scenario of autonomous payment by intelligent agents, the following issues are expected to be addressed. First, it is desirable to separate the identity of the payment subject, the agent's proxy authority, and the single payment execution authority into multiple clearly defined credentials. This means that the credential used to verify the payment subject proves the attribution of funds and responsibility; the credential used to verify the agent's payment authority proves that the agent can act on behalf of the payment subject within a limited scope; and the credential used to verify the payment token's payment parameters proves that a payment has been adjudicated and can be executed. If these three types of facts are mixed in the same credential, the boundaries of the credential's responsibilities are unclear, making it difficult to limit the agent's long-term proxy capabilities and to prove whether a single payment has been adjudicated. Second, it is desirable to establish a strong reference relationship between lower-level credentials and upper-level credentials. This means that the credential used to verify the agent's payment authority references the credential used to verify the payment subject, and the credential used to verify the payment token's payment parameters references both of these, thus preventing the payment token from being used independently without the authorization context of the upper layer. Third, it is desirable to perform layer-by-layer permission convergence verification during the credential generation stage and the payment execution stage, ensuring that the permissions declared by the lower-level credential do not exceed the scope allowed by the upper-level credential. Fourth, it is expected that the referencing relationships, version status, and key permission fields of each layer of vouchers will be calculated into a unified integrity digest to detect whether any layer of vouchers has been replaced, tampered with, misreferenced, or used with an expired version. Fifth, it is expected that when an upper-level voucher is frozen, revoked, suspended, or expired, the status change will be propagated to the lower-level vouchers that reference that upper-level voucher, preventing the execution of payment tokens derived from an unavailable upper-level authorization. Sixth, it is expected that during payment execution, each voucher will be verified layer by layer in a certain order, combined with integrity verification, permission convergence verification, status verification, validity period verification, and fund account availability verification. Only when all verifications pass will actual payment be allowed. Seventh, it is expected that the voucher generation, permission convergence verification, integrity digest calculation, layer-by-layer verification, linkage failure, and voucher chain query backtracking process will be written into the evidence storage chain or audit system to support subsequent dispute resolution, risk control review, and compliance inquiries.

[0048] To at least partially address one or more of the aforementioned problems, as well as other potential issues, this paper presents an example of a scheme for processing payment credentials. According to this scheme, payment-related credentials are organized into multiple mutually referencing credentials: a second credential for verifying the payment subject, a first credential for verifying the agent's payment permissions, and a third credential for verifying the payment token's payment parameters. The first credential references the second credential, the third credential references the first and second credentials, and the permission scope of a lower-level credential does not exceed that of an upper-level credential. On the generation side, the second credential is first obtained, then the first credential is generated based on the second credential. In response to receiving a payment request from the agent, the third credential is generated based on the first credential. A hierarchical permission convergence check is performed each time a lower-level credential is generated; if any dimension exceeds its limit, the generation of the lower-level credential is rejected. On the verification side, in response to receiving a payment request from the agent, multiple credentials associated with the payment request are obtained. The third credential, the first credential, and the second credential are verified in a bottom-up order. The consistency between the first verification value calculated based on the multiple credentials and the recalculated second verification value is checked, and the payment request is then processed based on the verification result.

[0049] The above scheme addresses three key aspects: the attribution of funds and responsibilities, the scope of the agent's agency, and whether a single payment can be executed. These are all encapsulated in different vouchers and linked together through referencing relationships, thus clarifying the boundaries of the vouchers' responsibilities. Furthermore, by implementing hierarchical permission convergence verification, unauthorized access is intercepted during voucher generation. By using verification values ​​calculated based on multiple vouchers, the scheme detects whether vouchers have been replaced or tampered with during payment execution. This enhances the security of autonomous payments by the agent and reduces the financial risks associated with broken authorization relationships, unauthorized access, or voucher replacement.

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

[0051] Figure 1 A schematic diagram of an example environment 100 based on some examples in this article is shown. For example... Figure 1 As shown, example environment 100 includes electronic device 110.

[0052] In example environment 100, electronic device 110 runs application 120 that supports payment. Application 120 can be any application capable of initiating or carrying autonomous payment interactions by an intelligent agent. In some examples, an intelligent agent representing the payment subject can initiate a payment request via application 120.

[0053] User 140 can interact with application 120 through electronic device 110. In some examples, user 140 corresponds to the payer of a payment request, that is, the entity that ultimately assumes the funds and responsibilities.

[0054] Electronic device 110 can present interface 150 to user 140 through application 120. Interface 150 can be used for interactions such as configuring authorization, configuring allowed scenarios and limits, and presenting enhanced confirmation prompts when needed.

[0055] Electronic device 110 can communicate with server 130. In some examples, the payment request of the smart agent is received by server 130, and the generation of credentials, hierarchical permission convergence verification, calculation of the first verification value, bottom-up hierarchical verification, linkage failure, and evidence storage writing can be handled by server 130.

[0056] 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).

[0057] Server 130 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. Server 130 may include, for example, computing systems / servers such as mainframes, edge computing nodes, computing devices in a cloud environment, etc. Server 130 can provide backend services for application 120 in electronic device 110 that supports payment credential processing.

[0058] A communication connection can be established between server 130 and 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, server 130 and electronic device 110 can exchange signaling information through their communication connection.

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

[0060] Figure 2 A schematic block diagram 200 illustrates the overall architecture of a three-tier payment credential chain based on some examples in this paper. Figure 2 In the example, the three-tier payment credentials include mutually referencing second credential 205, first credential 210, and third credential 220. For ease of understanding, the second credential 205 is also referred to as the first-tier credential or real-name subject credential, the first credential 210 as the second-tier credential or smart agent proxy credential, and the third credential 220 as the third-tier credential or payment execution token.

[0061] The second credential 205 is used to verify the paying entity of the payment request. The second credential 205 is used to prove the ultimate attribution of funds and responsibility. For example, the second credential 205 may indicate the paying entity's authentication information (e.g., KYC), account information, and authorization boundaries. The first credential 210 is used to verify the payment authority of the intelligent agent, proving the agent's agency authority within a defined scope. For example, the first credential 210 may indicate the intelligent agent's authentication information (e.g., KYA), capability code, permitted scenarios (e.g., permitted payment scenario types), permitted merchant category codes, and limits. The third credential 220 is used to verify the payment parameters of the payment token, proving that the payment has been approved. For example, the third credential 220 may indicate the payment amount, payee, scenario (e.g., the scenario type used for payment), validity period (e.g., the validity period of the payment request), and number of uses.

[0062] like Figure 2 As shown, the "upper-level reference and upper limit of permissions" between the second credential 205 and the first credential 210 can indicate that the first credential 210 may include reference information of the second credential 205 (e.g., also referred to as third reference information) and that the permission range indicated by the first credential 210 is no greater than the permission range indicated by the second credential 205. For example, the "upper-level reference and upper limit of permissions" between the first credential 210 and the third credential 220 can indicate that the third credential 220 may include reference information of the first credential 210 (e.g., also referred to as second reference information) and that the permission range indicated by the third credential 220 is no greater than the permission range indicated by the first credential 210.

[0063] As an example, second credential 205, first credential 210, and third credential 220 can be used to calculate the credential chain hash. For example, credential chain hash 225 can be calculated based on second credential 205, first credential 210, and third credential 220. For example, credential chain hash 225 can indicate the reference information of the three-layer credentials (e.g., the identifiers of the three credentials) and constraint fields such as version, status (e.g., indicating whether the corresponding credential is valid), and permission digest. As an example, credential chain hash 225 also corresponds to the first check value in this document, used to protect cross-layer integrity. In box 230, payment execution can be performed layer by layer verification. For example, after receiving a payment request, it can be verified layer by layer from the third layer to the second layer and then to the first layer (i.e., third credential 220, first credential 210, second credential 205) from bottom to top. Cross-layer linkage failure 215 means that when the upper-layer credential is frozen or revoked, the lower-layer credential is also suspended or revoked in a linked manner. The evidence storage chain (also known as the audit chain) 235 can be used to record events such as the generation, verification, hashing, invalidation, and payment execution of relevant vouchers.

[0064] Through the overall architecture of the three-layer certificate chain described above, the three types of facts—the attribution of funds and responsibilities, the scope of agency of the intelligent agent, and whether a single payment can be executed—are respectively carried in the second certificate 205, the first certificate 210, and the third certificate 220. They are interconnected through reference relationships, certificate chain hash 225, layer-by-layer verification 230, and linkage failure 215, so that the responsibility boundaries of each layer of certificates are clear and the whole can be verified and traced.

[0065] Figure 3 A schematic block diagram 300 illustrates the hierarchical permission convergence during credential generation, based on some examples in this paper. For example... Figure 3As shown, in box 305, a second credential (e.g., a real-name entity credential) can be indicated. As an example, the second credential can indicate the permitted scenario (e.g., the type of scenario for which transactions are permitted), the authorized agent (e.g., one or more agents authorized by the paying entity to perform payment operations), the merchant scope, and the total limit (e.g., the total amount of permitted transactions). For example, in box 310, first-level permission convergence can be performed to determine whether a first credential (e.g., an agent proxy credential) should be generated. For example, in box 315, a first credential (a agent proxy credential) can be generated in response to the agent's permission (e.g., payment permission corresponding to the agent) not being greater than the entity's permission (e.g., the paying entity's payment permission). Alternatively, in box 325, the generation of a first credential (e.g., an agent proxy credential) can be refused in response to the agent's permission being greater than the entity's permission. In box 320, a payment request can be received. The payment request can indicate the amount, payee, merchant category, and scenario. In box 330, second-level permission convergence can be performed to determine whether a third credential (e.g., a payment token) should be generated. In box 335, a third credential can be generated if the token permissions indicated by the payment request are no greater than the agent's permissions. The third credential can indicate the single payment amount, scenario, merchant type, validity period, and number of payments. Alternatively, in box 340, the generation of a third credential can be refused if the token permissions indicated by the payment request are greater than the agent's permissions.

[0066] As an example, in the first-level permission convergence, the permission scope declared by the first credential to be generated is compared dimension-by-dimensionally with the authorization scope of the second credential to ensure that the permissions of the first credential converge to within the permissions of the second credential. In the second-level permission convergence, the payment parameters declared by the third credential to be generated are compared dimension-by-dimensionally with the permission scope of the first credential to ensure that the permissions of the third credential converge to within the permissions of the first credential. In some cases, if any dimension (e.g., the dimension indicated by the corresponding permission) exceeds its bounds, the generation of either the first credential or the third credential is refused.

[0067] In some examples, the executable scope of each layer of credentials can be represented as a permission vector (PV). The permission vector may include at least one of the following: a set of authorized agents, a set of scenarios, a set of merchant category codes, a set of capability codes, a set of scenario wallets, a single transaction limit, a daily limit, a monthly limit, and an effective and expiration time. The second credential, the first credential, and the third credential satisfy the following relationship:

[0068] in, Indicates the second voucher. Indicates the first certificate. Indicates a third certificate. This indicates a subset or numerical limit relationship. In other words, the permission range of the third credential does not exceed that of the first credential, and the permission range of the first credential does not exceed that of the second credential. If any dimension does not satisfy the above relationship, it is determined that the permissions are not convergent, and the generation of the corresponding lower-level credential is rejected accordingly.

[0069] Let's illustrate this with a simple example. Assume the payer is an individual user named User 1, whose second credential indicates a total credit limit of 100,000 yuan for the main account, allowing transactions including air travel and hotel accommodations, and an authorized agent including a travel agent. When generating a first credential for this travel agent based on the second credential, the allowed transactions can be narrowed down to air travel and hotel accommodations, the single transaction limit to 5,000 yuan, and the daily limit to 10,000 yuan. Thus, although the travel agent is authorized to act as an agent, it can only make payments on behalf of User 1 within the air travel and hotel accommodation scenarios each day, up to a single transaction limit of 5,000 yuan, and it will never exceed the limit of User 1's main account. This layered permission narrowing intercepts unauthorized payments at the credential generation stage, reducing the likelihood of unauthorized payments compared to discovering permission mismatches only during payment execution.

[0070] Figure 4 A flowchart of an example process 400 for layer-by-layer verification during payment execution, based on some examples in this article, is shown. Figure 4 As shown, in box 405, a payment execution request is received. The payment execution request may include an execution token reference, payment amount, and payee. Subsequently, layer-by-layer verification is performed in a bottom-up order, and the consistency of the credential chain hash is verified. Based on the verification result, payment execution is allowed in box 435 or rejected in box 430, and a payment execution verification event is written in box 440.

[0071] Specifically, at box 410, a verification associated with the third credential (third-level verification) is performed. For example, third-level verification may include verifying the status of the third credential (also known as token status, e.g., valid or invalid), its validity period, number of uses, and whether the payment parameters match the payment request. In response to passing the verification at 410, a verification associated with the first credential (second-level verification, corresponding to...) is performed. Figure 4 (Box 415) verifies whether the status, validity period, and payment parameters of the first voucher and the third voucher meet the permission scope indicated by the first voucher. In response to passing the verification of the first voucher, it performs the verification associated with the second voucher (first-level verification, corresponding to...). Figure 4 (Box 420) verifies the status of the second credential, authentication information (e.g., KYC), and the availability of the associated funds account. That is, the layer-by-layer verification proceeds from bottom to top in the order of the third credential, the first credential, and the second credential (i.e., payment execution token, smart agent agent credential, and real-name entity credential).

[0072] In box 425, perform a credential chain hash check. For example, the credential chain hash check may include recalculating the credential chain hash (corresponding to the second check value) and comparing it with the credential chain hash (corresponding to the first check value) stored in the third credential. In response to both matching and all checks passing, in box 435, in response to the first check value being equal to the second check value, payment execution is allowed; otherwise, in box 430, payment execution is rejected, a reason code is returned, and written to the evidence storage chain. Regardless of whether it is allowed or rejected, in box 440, the payment execution check event is written to the evidence storage chain.

[0073] In some examples, the third credential includes a first checksum, which is calculated based on multiple credentials. The first checksum (credential chain hash) can be calculated using a hash function based on references to multiple credentials and constraint fields such as version information, status information, and digest information of each credential. For example, the credential chain hash can be calculated as follows:

[0074] in, , , These represent the identifiers for the second, first, and third vouchers, respectively. , , These represent the version information of the second, first, and third vouchers, respectively. , , These represent the statuses of the second, first, and third credentials, respectively. `principal_permission_hash`, `proxy_permission_hash`, and `token_permission_hash` represent the permission digests of the second, first, and third credentials, respectively. The identifier references the adjudication result, where principal_permission_hash, proxy_permission_hash, and token_permission_hash can be calculated as follows: ; Here, allowed_scenes represents the set of permitted scenarios, which is the set of business scenarios that the payment entity authorizes the smart agent to execute, and may include one or more scenario codes; authorized_agents represents the set of authorized smart agents, which is the set of identity identifiers of smart agents that the payment entity authorizes to act as its agents for payment; linked_accounts represents the set of linked fund accounts, which is the set of identifiers of fund accounts that are bound to the payment entity and can be used for payment; and total_credit_limit represents the total credit limit, which is the upper limit of the payment amount set by the payment entity for its authorized smart agents.

[0075]

[0076] Here, `agent_identity_ref` represents the agent's identity reference, i.e., the identity identifier of the agent associated with the first credential; `capability_codes` represents the capability code set, i.e., the set of identifiers for the types of operational capabilities granted to the agent after capability authentication. For example, capability codes may include flight booking, hotel booking, procurement, etc.; `allowed_scene_codes` represents the allowed scene code set, i.e., the set of identifiers for business scenarios authorized to operate by the first credential. The scope of permissions for the allowed scene code set does not exceed the allowed scene set of the second credential; `allowed_mcc_codes` represents the allowed merchant category code set, i.e., the set of identifiers for merchant category codes authorized for transactions by the first credential; `max_single_amount` represents the single transaction limit, i.e., the upper limit of a single payment amount authorized by the first credential; `daily_limit` represents the daily limit, i.e., the upper limit of the cumulative payment amount authorized by the first credential in a single day; `monthly_limit` represents the monthly limit, i.e., the upper limit of the cumulative payment amount authorized by the first credential in a single month; and `valid_until` represents the validity period expiration time, i.e., the effective expiration timestamp of the first credential.

[0077]

[0078] Where, amount represents the payment amount, i.e., the payment amount corresponding to the payment request; payee_ref represents the payee reference, i.e., the payee identification information corresponding to the payment request; mcc_code represents the merchant category code, i.e., the merchant category identification information corresponding to the payment request; scene_code represents the scene code, i.e., the transaction scene identification information corresponding to the payment request; and max_uses represents the maximum number of uses, i.e., the maximum number of times the third credential is allowed to be used for payment.

[0079] The above text This represents a hash function (e.g., SHA-256). This indicates a concatenation operation. During payment execution, by comparing the stored voucher chain hash with the recalculated voucher chain hash on-site, it is possible to detect whether the reference or key constraint fields of any of the three layers of vouchers have been replaced, tampered with, or misreferenced. This provides cross-layer voucher integrity protection, and compared to verifying only a single voucher signature, it can detect cross-layer reference misalignment.

[0080] Figure 5 A timing diagram 500 is shown illustrating the generation of a real-name subject credential (i.e., a second credential) based on some examples in this document. Figure 5 The example illustrates multiple swimlanes, including Real-Name Entity 505, Real-Name Entity Credential Management Module 515, Real-Name Authentication Verification Service 525, Funds Account Verification Service 530, Platform Risk Control Strategy 535, Credential Storage 540, and Evidence Storage Chain 545. Specifically, Real-Name Entity 505 corresponds to the payment entity in the payment request; Real-Name Entity Credential Management Module 515 generates a second credential; Real-Name Authentication Verification Service 525 verifies the entity type and real-name authentication level; Funds Account Verification Service 530 verifies the associated funds account and the list of available accounts; Platform Risk Control Strategy 535 provides risk control configuration during credential generation; Credential Storage 540 stores credentials in an immutable append-only manner; and Evidence Storage Chain 545 records key events during the generation process.

[0081] As an example, the real-name subject 505 can submit (502) subject identity information to the real-name subject credential management module 515. The real-name subject credential management module 515 can call the real-name authentication verification service 525 to verify (504) the subject type and real-name authentication level. For example, the real-name authentication verification service 525 can return (506) the KYC level verification result to the real-name subject credential management module 515. In some cases, the real-name subject credential management module 515 can refuse (508) to generate a subject credential (e.g., a second credential) in response to the subject type and / or real-name authentication level failing verification. Further, the real-name subject credential management module 515 can write (510) an authentication failure event to the evidence storage chain 545. Alternatively, the real-name subject credential management module 515 can call the fund account verification service 530 to verify (512) the associated fund account set in response to the subject type and / or real-name authentication level passing verification. For example, the fund account verification service 530 can return (514) a list of available accounts to the real-name entity certificate management module 515. Alternatively, the real-name entity certificate management module 515 can refuse (516) to generate a subject certificate (e.g., a second certificate) in response to the failure of the associated fund account set to pass verification. Further, the real-name entity certificate management module 515 can write (518) an account verification failure event to the evidence storage chain 545. The real-name entity 505 can submit (520) a set of authorized smart agents, (522) a set of allowed scenarios, and (524) a total credit limit to the real-name entity certificate management module 515. Subsequently, the real-name entity certificate management module 515 can call the fund account verification service 530 to verify (526) the associated fund account set. For example, the fund account verification service 530 can return (528) a list of available accounts to the real-name entity certificate management module 515. In some cases, the Real-Name Subject Credential Management Module 515 may generate (530) the Real-Name Subject Credential field in response to the existence of an available account. Further, the Real-Name Subject Credential Management Module 515 may append (532) the Real-Name Subject Credential to the Credential Storage 540. For example, the Credential Storage 540 may return (534) a successful write result to the Real-Name Subject Credential Management Module 515. Further, the Real-Name Subject Credential Management Module 515 may write (536) a Subject Credential Creation Event to the Evidence Storage Chain 545. The Real-Name Subject Credential Management Module 515 may (return) the identifier of the Subject Credential (also known as the Real-Name Subject Credential) to the Real-Name Subject 505.

[0082] In some examples, the real-name subject certificate (second certificate) may include at least the fields shown in Table 1 below. It should be understood that the field names, data types, and values ​​in the table below are merely exemplary, and corresponding fields may be added, deleted, or adjusted as needed in different embodiments, and the scope of this document is not limited thereto.

[0083]

[0084] Taking User 1's real-name authentication credentials as an example, in a simple example, after completing real-name authentication, User 1 obtains an L3 level authentication level, with a total credit limit of XXX, linked to their own financial account, and allowed scenarios including air travel and hotel accommodation. The authorized agent set includes travel agents authorized by User 1. The above information is organized into User 1's real-name authentication credentials, serving as the first-level credentials used to verify "who owns this money and who is responsible" in subsequent payments, but it does not itself prove that a certain agent can execute a specific payment.

[0085] Figure 6 A timing diagram 600 illustrating the generation and basic verification of agent proxy credentials (i.e., first credentials) based on some examples in this paper is shown. Figure 6 The example illustrates multiple swimlanes, including the agent or requester 605, the proxy credential generation module 615, the subject credential management module 625, the agent identity verification service 635, the scene wallet service 645, the request field validator 655, and the evidence storage chain 665. Specifically, the proxy credential generation module 615 generates the first credential; the subject credential management module 625 loads the real-name subject credential (second credential) for reference and verification; the agent identity verification service 635 verifies the agent's identity and authentication level; the scene wallet service 645 verifies the existence and ownership of the scene wallet; the request field validator 655 verifies required fields and formats; and the evidence storage chain 665 records key events during the generation process.

[0086] As an example, agent / requester 605 can submit a proxy credential generation request (602) to proxy credential generation module 615, which includes the subject credential reference, agent identity, capability code, scenario, MCC, limit, and validity period. Proxy credential generation module 615 can call subject credential management module 625 to load (604) real-name subject credential. For example, subject credential management module 625 can return (606) subject credential status and authorization scope to proxy credential generation module 615.

[0087] In some cases, the proxy credential generation module 615 may reject (608) the proxy credential generation request in response to the absence or unavailability of the principal credential. Further, the proxy credential generation module 615 may write (610) a principal credential verification failure event to the evidence storage chain 665.

[0088] Alternatively, the proxy credential generation module 615 may, in response to the validity of the principal credential, invoke the agent identity verification service 635 to verify (612) the agent's identity and KYA level. For example, the agent identity verification service 635 may return (614) the KYA verification result to the proxy credential generation module 615. In some cases, the proxy credential generation module 615 may, in response to the agent failing KYA, reject (616) the proxy credential generation request. Further, the proxy credential generation module 615 may write (618) an agent identity verification failure event to the evidence storage chain 665.

[0089] Alternatively, the proxy credential generation module 615 may, in response to the valid identity of the smart agent, call the scenario wallet service 645 to verify (620) the existence and ownership of the scenario wallet. For example, the scenario wallet service 645 may return (622) a set of valid scenario wallets to the proxy credential generation module 615. The proxy credential generation module 615 may call the request field validator 655 to verify (624) the required fields and format. For example, the request field validator 655 may return (626) the field verification result to the proxy credential generation module 615. In some cases, the proxy credential generation module 615 may reject (628) the proxy credential generation request in response to missing or incorrectly formatted request fields. Further, the proxy credential generation module 615 may write (630) a request field verification failure event to the evidence storage chain 665.

[0090] In some examples, the agent agent credential (first credential) may include at least the fields shown in Table 2 below.

[0091]

[0092] Continuing with the example of User 1, User 1 configures a smart agent proxy credential for its authorized travel smart agent. This proxy credential strongly references User 1's real-name entity credential, achieving a K3-level smart agent authentication level, and narrows the scope of permissions to: a single transaction limit of no more than 5,000 yuan, a daily limit of no more than 10,000 yuan, and permitted scenario codes limited to air travel and hotel accommodation. Therefore, the travel smart agent only has proxy payment permissions within the limited scope granted by User 1, serving as a second-level credential to verify "whether this smart agent can make payments on behalf of others and how much it can spend," but it does not itself prove that a payment has been approved.

[0093] Figure 7 A timing diagram 700 illustrating the first-level permission convergence verification based on some examples in this document is shown. Figure 7In the example, sequence 700 involves multiple swimlanes, including the proxy credential generation module 705, the first-level permission convergence verification module 715, the permission convergence rule base 725, the real-name subject credential 735, and the evidence storage chain 745. Specifically, the proxy credential generation module 705 requests the first-level permission convergence verification, the first-level permission convergence verification module 715 performs the verification, the permission convergence rule base 725 provides convergence rules such as scenarios, merchant category codes, limits, and agent authorization, and the real-name subject credential 735, i.e., the second credential, provides permission vectors such as the authorized agent set, allowed scenarios, allowed merchant category code range, and total credit limit.

[0094] For example, the proxy credential generation module 705 can request (702) first-level permission convergence verification from the first-level permission convergence verification module 715. The first-level permission convergence verification module 715 can call the permission convergence rule library 725 to load (704) the permission convergence rule set. The permission convergence rule library 725 can return (706) scenario, MCC, limit, and agent authorization rules to the first-level permission convergence verification module 715. The first-level permission convergence verification module 715 can call the real-name subject credential 735 to read (708) the authorized agent set, allowed scenarios, MCC range, and total credit limit. The real-name subject credential 735 can return (710) the subject credential permission vector to the first-level permission convergence verification module 715.

[0095] For example, the first-level permission convergence verification module 715 can perform (712) agent authorization verification to verify whether the agent belongs to the agent authorized by the payment entity. In some cases, the first-level permission convergence verification module 715 can respond to the agent not being authorized by returning (714) agent not authorized to the proxy certificate generation module 705 and write (716) first-level permission out-of-bounds event to the evidence storage chain 745.

[0096] Alternatively, the first-level permission convergence verification module 715 can respond to the authorization of the intelligent agent by performing (718) scenario code convergence verification to verify whether the agent scenario belongs to the scenario limited by the payment subject. In some cases, the first-level permission convergence verification module 715 can respond to the scenario code going out of bounds by returning (720) scenario code going out of bounds to the agent certificate generation module 705 and writing (722) scenario code going out of bounds event to the evidence storage chain 745.

[0097] Alternatively, the first-level permission convergence verification module 715 can respond to the successful convergence of the scenario by performing (724) MCC convergence verification to verify whether the set of agent merchants belongs to the merchant range limited by the payment subject. In some cases, the first-level permission convergence verification module 715 can respond to the MCC out-of-bounds event by returning (726) Merchant Code Out-of-bounds to the agent certificate generation module 705 and writing (728) MCC out-of-bounds event to the evidence storage chain 745.

[0098] Alternatively, the first-level permission convergence verification module 715 can respond to the successful MCC convergence by performing (728) limit convergence verification, verifying that the single / daily / monthly limit is less than or equal to the main limit. In some cases, the first-level permission convergence verification module 715 can respond to the limit exceeding the limit by returning (730) the amount exceeds the limit to the proxy certificate generation module 705 and writing (732) the limit exceeding the limit event to the evidence storage chain 745.

[0099] Alternatively, the first-level permission convergence verification module 715 can respond to the passing of all convergence verifications by writing (734) permission convergence L1 pass to the evidence storage chain 745 and returning (736) the result of passing the first-level permission convergence to the proxy credential generation module 705.

[0100] As an example, the first-level permission convergence check determines, dimension by dimension, whether the first configuration information of the first credential meets the first condition, that is, whether the permission scope indicated by the first credential falls within the first permission set indicated by the second credential. Specifically, the check includes: agent authorization check, that is, determining whether the agent identity reference belongs to the authorized agent set ( ); Scene code convergence verification, that is, determining whether the set of allowed scene codes for the proxy credential is a subset of the set of allowed scene codes for the real-name subject credential ( Merchant category code convergence verification, that is, determining whether the set of allowed merchant category codes of the agent certificate falls within the range of allowed merchant category codes of the real-name subject certificate. ); and limit convergence verification, that is, determining whether the single limit, daily limit and monthly limit of the agency voucher do not exceed the total credit limit of the real-name subject voucher ( (etc.). If all dimensions converge, write a first-level permission convergence pass event (e.g., PERMISSION_CONVERGENCE_L1_PASS) to the evidence storage chain 745; if any dimension exceeds the limit, write the corresponding permission exceedance event and refuse to generate the first credential.

[0101] Wherein, `agent_ref` represents the agent identity reference, i.e., the identity identifier of the agent associated with the first credential; `authorized_agents` represents the authorized agent set, i.e., the set of identity identifiers of agents authorized to act as payment agents, recorded in the second credential; `agent_ref∈authorized_agents` indicates whether the agent identity reference belongs to the authorized agent set; `proxy_scenes` represents the allowed scene code set of the first credential, i.e., the set of identifiers of business scenarios authorized to operate by the first credential; `principal_scenes` represents the allowed scene set of the second credential, i.e., the set of business scenarios authorized to be executed by the payment subject; `proxy_scenes` `principal_scenes` indicates whether the set of allowed scene codes for the first credential is a subset of the set of allowed scene codes for the second credential; `proxy_mcc_set` represents the set of allowed merchant category codes for the first credential, i.e., the set of identifiers of merchant category codes authorized for transaction by the first credential; `principal_mcc_range` represents the range of allowed merchant category codes for the second credential, i.e., the range of identifiers of merchant category codes authorized for transaction by the payment entity; `proxy_mcc_set` `principal_mcc_range` indicates whether the set of allowed merchant category codes for the first credential falls within the range of allowed merchant category codes for the second credential; `max_single_amount` indicates the single transaction limit, i.e., the upper limit of the single payment amount authorized by the first credential; `total_credit_limit` indicates the total credit limit, i.e., the upper limit of the payment amount set by the payment entity for its authorized smart agent as recorded in the second credential; `max_single_amount≤total_credit_limit` indicates whether the single transaction limit of the first credential does not exceed the total credit limit of the second credential; `daily_limit` indicates the daily limit, i.e., the upper limit of the cumulative payment amount authorized by the first credential in a single day; `monthly_limit` indicates the monthly limit, i.e., the upper limit of the cumulative payment amount authorized by the first credential in a single month; `PERMISSION_CONVERGENCE_L1_PASS` indicates the first-level permission convergence pass event, i.e., the event type identifier written to the evidence storage record when the first credential meets the convergence conditions in all verification dimensions.

[0102] Figure 8 A timing diagram 800 illustrating the second-level permission convergence verification based on some examples in this document is shown. Figure 8 In the example, sequence 800 involves multiple swimlanes, including the execution token generation module 805, the second-level permission convergence and verification module 815, the agent proxy credential 825, the cumulative quota service 835, and the evidence storage chain 845. The execution token generation module 805 generates the third credential, which is then verified by the second-level permission convergence and verification module 815. The agent proxy credential 825, also known as the first credential, provides permission ranges such as single transaction limit, daily limit, monthly limit, allowed merchant category code set, and allowed scenario code set. The cumulative quota service 835 queries the cumulative amount for the current day and month and atomically updates the cumulative quota.

[0103] For example, the execution token generation module 805 can submit (802) transaction parameters to the second-level permission convergence verification module 815, including amount, MCC, scenario, and timestamp. The second-level permission convergence verification module 815 can call the agent proxy credential 825 to read (804) the proxy credential permission range. For example, the agent proxy credential 825 can return (806) single transaction limit, daily limit, monthly limit, MCC set, and scenario set to the second-level permission convergence verification module 815.

[0104] The second-level permission convergence verification module 815 can perform (806) single-transaction amount verification to check whether the amount is less than the maximum single-transaction limit. In some cases, the second-level permission convergence verification module 815 can respond to a single-transaction amount exceeding the limit by returning (808) the amount exceeds the limit to the execution token generation module 805 and writing (810) the amount exceeding the limit event to the evidence storage chain 845.

[0105] Alternatively, the second-level permission convergence verification module 815 may, in response to a single amount verification passing, call the cumulative amount service 835 to query (812) the cumulative amount for the day and month. For example, the cumulative amount service 835 may return (814) daily_accumulated or monthly_accumulated to the second-level permission convergence verification module 815. The second-level permission convergence verification module 815 may perform (816) verification of the cumulative limit. In some cases, the second-level permission convergence verification module 815 may, in response to a cumulative amount exceeding the limit, return (818) cumulative_amount_overflow to the execution token generation module 805 and write (820) cumulative amount exceeding the limit event to the evidence storage chain 845.

[0106] Alternatively, the second-level permission convergence verification module 815 may, in response to successful amount convergence, perform (822) mcc convergence verification, verifying request_mcc∈proxy_mcc_set. In some cases, the second-level permission convergence verification module 815 may, in response to mcc out of bounds, return (824) mcc_code_overflow_l2 to the execution token generation module 805 and write (826) mcc out of bounds event to the evidence storage chain 845.

[0107] Alternatively, the second-level permission convergence verification module 815 can respond to the successful MCC convergence by performing (828) scene code convergence verification, verifying request_scene∈proxy_scene_set. In some cases, the second-level permission convergence verification module 815 can respond to scene code out of bounds by returning (830) scene_code_overflow_l2 to the execution token generation module 805 and writing (832) scene code out of bounds event to the evidence storage chain 845.

[0108] Alternatively, the second-level permission convergence verification module 815 can, in response to all convergence verifications passing, call the cumulative quota service 835 to atomically update (834) the cumulative quota. For example, the cumulative quota service 835 can return (836) the result of successful atomic update to the second-level permission convergence verification module 815. The second-level permission convergence verification module 815 can write (838) permission_convergence_l2_pass to the evidence storage chain 845 and return (840) the result of successful second-level permission convergence to the execution token generation module 805.

[0109] The second-level permission convergence verification checks each dimension to determine whether the payment information meets the second condition, that is, whether the payment parameters of this payment fall within the second permission set indicated by the first voucher. Specifically, the verification includes: single transaction amount verification, that is, determining whether the amount of this payment does not exceed the single transaction limit (…). ); Cumulative limit verification, which determines whether the sum of the cumulative amount for the day and the amount in this transaction does not exceed the daily limit ( ), whether the sum of the cumulative amount for the month and the amount for this transaction does not exceed the monthly limit ( Merchant category code convergence verification, that is, determining whether the merchant category code of this payment belongs to the set of allowed merchant category codes ( ); and scene code convergence verification, that is, determining whether the scene code for this payment belongs to the set of allowed scene codes ( If all dimensions converge, write a Level 2 permission convergence pass event (e.g., PERMISSION_CONVERGENCE_L2_PASS) to the evidence storage chain 845 and generate a third credential; if any dimension exceeds the limit, write events such as amount exceeding the limit, cumulative amount exceeding the limit, merchant category code exceeding the limit, or scenario code exceeding the limit and refuse to generate a third credential.

[0110] Wherein, `amount` represents the payment amount for this transaction, i.e., the payment amount corresponding to the payment request; `max_single_amount` represents the single transaction limit, i.e., the upper limit of the single payment amount authorized for the first voucher; `amount≤max_single_amount` indicates whether the payment amount for this transaction does not exceed the single transaction limit; `daily_accumulated` represents the daily cumulative amount, i.e., the cumulative value of the payment amount executed by the first voucher within the current day; `daily_accumulated+amount≤daily_limit` indicates whether the sum of the daily cumulative amount and the payment amount for this transaction does not exceed the daily limit of the first voucher; `monthly_accumulated` represents the monthly cumulative amount, i.e., the cumulative value of the payment amount executed by the first voucher within the current month; `monthly_accumulated+amount≤monthly_limit` indicates whether the sum of the monthly cumulative amount and the payment amount for this transaction does not exceed the monthly limit of the first voucher. `mcc_code` represents the merchant category code, i.e., the merchant category identifier information corresponding to the payment request; `allowed_mcc_codes` represents the set of allowed merchant category codes, i.e., the identifier set of merchant category codes for which the first credential is authorized to be traded; `mcc_code∈allowed_mcc_codes` indicates whether the merchant category code of this payment belongs to the set of allowed merchant category codes; `scene_code` represents the scene code, i.e., the transaction scene identifier information corresponding to the payment request; `allowed_scene_codes` represents the set of allowed scene codes, i.e., the identifier set of business scenes for which the first credential is authorized to be operated; `scene_code∈allowed_scene_codes` indicates whether the scene code of this payment belongs to the set of allowed scene codes; `PERMISSION_CONVERGENCE_L2_PASS` represents the second-level permission convergence pass event, i.e., the event type identifier written to the evidence storage record when the payment parameters meet the convergence conditions in all verification dimensions.

[0111] In some examples, the payment execution token (third credential) may include at least the fields shown in Table 3 below.

[0112]

[0113] Continuing with the example of User 1, when the travel agent books a flight ticket for User 1 priced at 1850 yuan, the payment amount of 1850 yuan does not exceed the single transaction limit of 5000 yuan, and the cumulative daily amount does not exceed the daily limit of 10000 yuan. The merchant category code belongs to the set of allowed merchant category codes, and the scenario code belongs to the air travel scenario. Therefore, the second-level permission convergence verification passes, and the system generates a payment execution token (third credential) accordingly. This execution token serves as the third-level credential to verify whether "this payment has been approved and whether the amount and parameters are consistent," and by default, it can only be used once, thus distinguishing between one-time execution authorization and long-term proxy authorization.

[0114] Figure 9 A schematic diagram (900) illustrating a three-tiered credential responsibility division and strong referencing relationship based on some examples in this paper is shown. Figure 9 In the example, the first layer is the principal credential 905, also known as the second credential, which is used to verify the paying entity of the payment request. It proves the ownership of funds but does not prove that the agent can execute a certain payment. The second layer is the agent credential 915, also known as the first credential, which is used to verify the payment authority of the agent. It proves the agent's agency authority within a limited scope but does not prove that a certain payment has been adjudicated. The third layer is the execution token 925, also known as the third credential, which is used to verify the payment parameters of the payment token. It proves that this payment has been adjudicated but does not extend to long-term authorization.

[0115] like Figure 9 As shown, the terms "reference and permissions not less than" are marked between the main document 905 and the proxy document 915, and between the proxy document 915 and the execution token 925. This indicates that the lower-level document strongly references the upper-level document, and the permission scope of the upper-level document is not less than the permission scope of the lower-level document. In other words, in the generation direction, the proxy document 915 strongly references the main document 905, and its permissions converge to the main document 905; the execution token 925 strongly references the proxy document 915 (and can also reference the main document 905), and its permissions converge to the proxy document 915. In the verification direction, references are taken layer by layer from the execution token 925 to the proxy document 915, and then to the main document 905, with verification performed layer by layer. Through this division of responsibilities and strong reference relationships, the three layers of documents each undertake non-overlapping proof responsibilities, maintaining reference consistency and permission convergence across levels.

[0116] In some scenarios, a three-tiered credential visualization management function can be provided to users, enabling them to intuitively view and manage the status and configuration of each credential layer. For example, the system provides a visualization component associated with multiple credentials. This component presents the hierarchical relationships, status information, permission scope information, and validity period information between the credentials. As an example, the visualization component can display the reference relationships between the second credential (real-name entity credential), the first credential (smart agent proxy credential), and the third credential (payment execution token) in a tree structure or hierarchical card format. For each credential layer, the visualization component can present at least one of the following information: Second credential layer: type of payment entity (individual or enterprise), authentication level, balance of associated funds account, total credit limit, list of authorized smart agents and their respective sub-credit limits, allowed scenario set, and validity period, etc. For example, first credential layer: identity information of each smart agent, KYA authentication level and multi-dimensional capability graph, associated scenario wallet, set of allowed scenario codes, set of allowed merchant category codes, single transaction limit, daily limit, monthly limit, daily cumulative usage amount, monthly cumulative usage amount, and validity period, etc. For example, the third credential layer includes: a list of currently valid execution tokens, the payment amount for each token, payee information, merchant category code, scenario code, validity period, and token status.

[0117] Through the visualization component, users can view the entire three-tiered credential structure on a single interface, clearly understanding their account's basic financial status, the balance allocation of each agent, and their permission scope. As an example, the visualization component can also receive user actions and adjust the configuration information of at least one of multiple credentials based on these actions. The configuration information may include at least one of the following: permission scope, limit information, validity period, and status. Alternatively, users can perform at least one of the following management operations through the visualization component: Limit Adjustment: Users can adjust the limit information of a target agent's proxy credential. For example, if a user previously set a daily limit of 2000 yuan for an agent, they can adjust it to 500 yuan using the input or sliding controls in the visualization component. After receiving the adjustment operation, the system verifies whether the adjusted limit does not exceed the total credit limit of the upper-level real-name entity credential, and updates the limit information of the target credential after successful verification. This operation enables users to dynamically tighten the payment boundaries of agents. Validity Management: Users can adjust the validity period of the target credential. For example, a user can shorten the validity period of an agent's proxy credential using a date selection control, or immediately terminate its validity. Upon receiving the adjustment operation, the system updates the effective or expiration time field of the target credential. Permission Scope Adjustment: Users can adjust the permission scope of a target agent's proxy credential. For example, removing certain scene codes from the allowed scene code set, or removing certain merchant category codes from the allowed merchant category code set. Upon receiving the adjustment operation, the system verifies whether the adjusted permission scope is still a subset of the permission scope of its parent credential, and updates it after successful verification. Credential Revocation: When a user no longer needs the agent's permissions, they can use the revoke control in the visual component to set the target agent's proxy credential to an invalid state (e.g., revoked state). In response to this operation, the system changes the target credential's state to revoked and, according to the aforementioned cross-layer linkage failure propagation mechanism, changes all lower-level execution tokens referencing this credential to the corresponding state. Agent Capability Configuration Adjustment: Users can adjust the capability configuration information corresponding to a target agent through the visual component, such as modifying or adding / deleting its capability code set. Changes in the capability code set can be visually represented in a visualization component using a multi-dimensional capability graph (such as a radar chart). Upon receiving any of the aforementioned user operations, the system updates the configuration information of the corresponding credential and writes the configuration change event to the record. The record includes the configuration before the change, the configuration after the change, the type of change operation, and the operation timestamp.

[0118] In some situations, the aforementioned adjustments reflect the user's dynamic management of the agent's "hard boundaries." Hard boundaries refer to the insurmountable constraints on the agent during payment execution, such as single transaction limits, daily limits, allowed scenario codes, and allowed merchant category codes. Through visual components, users can tighten hard boundaries as needed, thereby flexibly controlling payment risks without revoking the agent's overall authorization.

[0119] Figure 10 A flowchart of an example payment process 1000 according to some scenarios is shown. Process 1000 can be implemented at electronic device 110. See below for reference. Figure 1 To describe process 1000.

[0120] Figure 10 A flowchart of an example payment process 1000 according to some scenarios is shown. Process 1000 can be implemented at electronic device 110. See below for reference. Figure 1 To describe process 1000.

[0121] In box 1010, electronic device 110 can, in response to receiving a payment request from a smart agent, obtain multiple credentials associated with the payment request. The multiple credentials include at least a first credential and a second credential. The first credential is used to verify the smart agent's payment authority, and the second credential is used to verify the payment subject of the payment request.

[0122] In box 1020, electronic device 110 can perform a verification process for a payment request based on multiple credentials.

[0123] In box 1030, electronic device 110 can process payment requests based on the verification results of the verification process.

[0124] In some cases, multiple credentials may also include a third credential, which is used to verify the payment parameters of the payment token.

[0125] In some cases, the payment request includes first reference information corresponding to a third credential, and obtaining multiple credentials associated with the payment request includes: obtaining a third credential based on the first reference information, the third credential including second reference information of the first credential; obtaining a first credential based on the second reference information, the first credential including third reference information of the second credential; and obtaining a second credential based on the third reference information.

[0126] In this way, by retrieving documents layer by layer through the reference chain between documents, the integrity and traceability of documents are ensured.

[0127] In some cases, the third credential also includes a first verification value, which is calculated based on multiple credentials. The process of verifying the payment request includes: generating a second verification value based on multiple credentials; and performing the verification process of the payment request based on a comparison of the first verification value and the second verification value.

[0128] In this way, verification value comparison is used to prevent tampering with credentials.

[0129] In some cases, generating a second verification value based on multiple credentials includes generating a second verification value based on multiple constraint fields corresponding to the multiple credentials, wherein the constraint fields include at least one of the version information, status information and summary information of the corresponding credentials.

[0130] In this way, key metadata of credentials is included in the verification, enhancing the ability to prevent tampering.

[0131] In some cases, the process of verifying a payment request includes: performing a first verification associated with a third document; performing a second verification associated with the first document in response to passing the first verification; and performing a third verification associated with the second document in response to passing the second verification.

[0132] This method, with its layered sequential verification, terminates invalid requests early, improving efficiency.

[0133] In some cases, performing the first verification associated with the third credential includes: verifying whether the third credential is in a valid state; and in response to the third credential being in a valid state, verifying whether the payment parameters of the payment token are consistent with the payment request.

[0134] In this way, the validity of the payment token and the matching of parameters are verified first.

[0135] In some cases, performing a second verification associated with the first credential includes: verifying whether the first credential is in a valid state; and in response to the first credential being in a valid state, verifying whether the payment parameters of the payment token meet the first condition indicated by the first credential.

[0136] This method is used to verify the boundaries of the agent's permissions.

[0137] In some cases, performing a third verification associated with the second credential includes: verifying whether the second credential is valid; and, in response to the second credential being valid, verifying the account information and authentication information of the paying entity.

[0138] This method ultimately verifies the identity of the payment entity.

[0139] In some cases, payment parameters include at least one of the following: the amount of payment corresponding to the payment request; the business party information corresponding to the payment request; the scenario information corresponding to the payment request; and the validity period corresponding to the payment request.

[0140] In some cases, the third credential includes a second reference to the first credential, and process 1000 further includes: in response to a change in the state of the first credential to a first state, triggering an adjustment of the third credential to a second state, the second state being determined based on the first state.

[0141] In this way, the status of the voucher is updated accordingly.

[0142] In some cases, process 1000 may also include: in response to a change in the state of the second credential to the third state, triggering an adjustment of the first credential to the fourth state, the fourth state being determined based on the third state.

[0143] In this way, changes in the underlying state are propagated upwards.

[0144] In some cases, the second credential indicates at least one of the following: the type of the payer; the authentication information of the payer; the account information of the payer; the smart agent associated with the payer; and the payment configuration information associated with the payer.

[0145] In some cases, the first credential indicates at least one of the following: the agent's identity information; the agent's authentication information; the agent's capability information; payment configuration information associated with the agent; and the validity period associated with the agent.

[0146] In some cases, processing payment requests based on the verification results of the verification process includes: triggering the execution of payment corresponding to the payment request in response to a verification result indicating that the verification passed; and rejecting the payment request in response to a verification result indicating that the verification failed.

[0147] In some cases, processing a payment request based on the verification result of the verification process includes: providing a prompt message in response to the verification result meeting preset conditions to determine whether to continue executing the payment request; and processing the payment request based on the operation result of the prompt message.

[0148] In this way, boundary situations are manually confirmed, increasing flexibility.

[0149] In some cases, process 1000 also includes writing the verification result into a record of evidence, which also indicates at least one of the generation information of multiple vouchers and the change information of multiple vouchers.

[0150] This method fully records the verification process and the voucher lifecycle, facilitating auditing.

[0151] In some cases, multiple credentials may also include a fourth credential, which is used to verify the scope of the agent's task execution.

[0152] In this way, additional credentials are introduced to limit the scope of tasks and refine access control.

[0153] In some cases, process 1000 may also include: providing a visualization component associated with multiple credentials, the visualization component being used to present at least one of the following: hierarchical relationships between the multiple credentials; status information of the multiple credentials; permission scope information of the multiple credentials; and validity period information of the multiple credentials.

[0154] In this way, the hierarchy, status, permissions, and validity period of the credential chain can be intuitively displayed through visual components, making it easier for users to understand and manage.

[0155] In some cases, process 1000 also includes: receiving user actions through a visualization component; and adjusting the configuration information of at least one of the multiple credentials based on the user actions.

[0156] In this way, users can directly adjust the voucher configuration on the visual interface, improving management efficiency and interactive experience.

[0157] In some cases, the configuration information includes at least one of the following: the scope of permissions for the corresponding credential; the limit information for the corresponding credential; the validity period of the corresponding credential; and the status of the corresponding credential.

[0158] This approach supports dynamic adjustment of key attributes of vouchers, enhancing the system's flexibility and maintainability.

[0159] Figure 11 A flowchart of an example process 1100 for generating payment vouchers under certain circumstances is shown. Process 1100 can be implemented at electronic device 110. See below for reference. Figure 1 To describe process 1100.

[0160] In box 1110, electronic device 110 can obtain a second credential, which is used to verify the payment subject.

[0161] In box 1120, electronic device 110 can generate a first credential based on the second credential, the first credential being used to verify the payment authority of the smart agent.

[0162] In box 1130, electronic device 110 may, in response to receiving a payment request from smart agent, generate a third credential based on a first credential, the third credential being used to verify the payment parameters of the payment token.

[0163] In some cases, the first document includes third reference information of the second document, and the third document includes second reference information of the first document and fourth reference information of the second document.

[0164] In this way, the three layers of vouchers are linked together by referencing information to form a traceable voucher chain, which facilitates verification and management.

[0165] In some cases, generating a first credential based on a second credential includes: receiving first configuration information associated with an agent; and generating a first credential in response to the first configuration information satisfying a first condition, wherein the first condition is associated with a first set of permissions indicated by the second credential.

[0166] In this way, the generation of smart agent credentials must comply with the permission scope defined by the payment subject credentials to ensure that permissions are not exceeded.

[0167] In some cases, generating a third credential based on a first credential in response to receiving a payment request from an agent includes: obtaining payment information associated with the payment request in response to receiving a payment request from an agent; and generating a third credential in response to the payment information satisfying a second condition, the second condition being associated with a second set of permissions indicated by the first credential.

[0168] In this way, the generation of payment tokens needs to verify whether the request parameters are within the scope of the agent's authorization, thus achieving dynamic fine-grained authorization.

[0169] In some cases, process 1100 may further include: generating a first verification value based on the first voucher, the second voucher, and the third voucher; and adding the first verification value to the third voucher.

[0170] In this way, the verification value of the entire credential chain is anchored to the payment token credential, ensuring that any credential change can be detected.

[0171] In some cases, process 1100 further includes writing a first verification value into a record of evidence storage, which also indicates the generation information of multiple vouchers, including a first voucher, a second voucher, and a third voucher.

[0172] In this way, the verification value is simultaneously recorded in the evidence storage, forming a double guarantee with the certificate chain, which facilitates auditing.

[0173] In some cases, process 1100 further includes updating the evidence record based on the change information in response to a change in at least one of the multiple credentials.

[0174] In this way, changes to vouchers are synchronized to the stored vouchers in real time, maintaining the integrity and consistency of audit information.

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

[0176] Figure 12A schematic structural block diagram of an example device 1200 for payment under certain scenarios is shown. Device 1200 may be implemented as or included in electronic device 110. The various modules / components in device 1200 may be implemented by hardware, software, firmware, or any combination thereof.

[0177] like Figure 12 As shown, the device 1200 includes: a first acquisition module 1210, configured to acquire multiple credentials associated with the payment request in response to receiving a payment request from an agent, the multiple credentials including at least a first credential and a second credential, the first credential being used to verify the payment authority of the agent, and the second credential being used to verify the payment subject of the payment request; a first verification module 1220, configured to perform a verification process on the payment request based on the multiple credentials; and a processing module 1230, configured to process the payment request based on the verification result of the verification process.

[0178] In some cases, multiple credentials may also include a third credential, which is used to verify the payment parameters of the payment token.

[0179] In some cases, the payment request includes first reference information corresponding to the third credential, and the acquisition module is further configured to: acquire the third credential based on the first reference information, wherein the third credential includes second reference information of the first credential; acquire the first credential based on the second reference information, wherein the first credential includes third reference information of the second credential; and acquire the second credential based on the third reference information.

[0180] In some cases, the third credential also includes a first verification value, which is calculated based on multiple credentials. The verification module is also configured to: generate a second verification value based on multiple credentials; and perform a verification process for the payment request based on a comparison of the first and second verification values.

[0181] In some cases, the first verification module 1220 is also configured to generate a second verification value based on multiple constraint fields corresponding to multiple vouchers, wherein the constraint fields include at least one of the version information, status information and summary information of the corresponding voucher.

[0182] In some cases, the first verification module 1220 is also configured to: perform a first verification associated with the third credential; perform a second verification associated with the first credential in response to passing the first verification; and perform a third verification associated with the second credential in response to passing the second verification.

[0183] In some cases, the first verification module 1220 is also configured to: verify whether the third credential is in a valid state; and in response to the third credential being in a valid state, verify whether the payment parameters of the payment token are consistent with the payment request.

[0184] In some cases, the first verification module 1220 is also configured to: verify whether the first credential is in a valid state; and in response to the first credential being in a valid state, verify whether the payment parameters of the payment token meet the first condition indicated by the first credential.

[0185] In some cases, the first verification module 1220 is also configured to: verify whether the second credential is in a valid state; and in response to the second credential being in a valid state, verify the account information and authentication information of the payment subject.

[0186] In some cases, payment parameters include at least one of the following: the amount of payment corresponding to the payment request; the business party information corresponding to the payment request; the scenario information corresponding to the payment request; and the validity period corresponding to the payment request.

[0187] In some cases, the third credential includes second reference information to the first credential, and the device 1200 also includes a first state adjustment module configured to: in response to a change in the state of the first credential to a first state, trigger an adjustment of the third credential to a second state, the second state being determined based on the first state.

[0188] In some cases, the device 1200 also includes a second state adjustment module configured to: in response to a change in the state of the second credential to a third state, trigger an adjustment of the first credential to a fourth state, the fourth state being determined based on the third state.

[0189] In some cases, the second credential indicates at least one of the following: the type of the payer; the authentication information of the payer; the account information of the payer; the smart agent associated with the payer; and the payment configuration information associated with the payer.

[0190] In some cases, the first credential indicates at least one of the following: the agent's identity information; the agent's authentication information; the agent's capability information; payment configuration information associated with the agent; and the validity period associated with the agent.

[0191] In some cases, the processing module 1230 is also configured to: trigger the execution of payment corresponding to the payment request in response to a verification result indicating that the verification has passed; and reject the payment request in response to a verification result indicating that the verification has failed.

[0192] In some cases, the processing module 1230 is also configured to: provide a prompt message in response to the verification result meeting a preset condition, for determining whether to continue executing the payment request; and process the payment request based on the operation result of the prompt message.

[0193] In some cases, the device 1200 also includes a first evidence storage module configured to write the verification result into an evidence storage record, which also indicates at least one of the generation information of multiple credentials and the change information of multiple credentials.

[0194] In some cases, multiple credentials may also include a fourth credential, which is used to verify the scope of the agent's task execution.

[0195] In some cases, the device 1200 also includes a visualization module configured to provide visualization components associated with multiple credentials, the visualization components being used to present at least one of the following: hierarchical relationships between the multiple credentials; status information of the multiple credentials; permission scope information of the multiple credentials; and validity period information of the multiple credentials.

[0196] In some cases, the visualization module is also configured to: receive user actions through the visualization component; and adjust the configuration information of at least one of multiple credentials based on the user actions.

[0197] In some cases, the configuration information includes at least one of the following: the scope of permissions for the corresponding credential; the limit information for the corresponding credential; the validity period of the corresponding credential; and the status of the corresponding credential.

[0198] Figure 13 A schematic structural block diagram of an example device 1300 for generating payment vouchers under certain circumstances is shown. Device 1300 may be implemented as or included in electronic device 110. The various modules / components in device 1300 may be implemented by hardware, software, firmware, or any combination thereof.

[0199] like Figure 13 As shown, the device 1300 includes: a second acquisition module 1310 configured to acquire a second credential, the second credential being used to verify the payment subject; a first generation module 1320 configured to generate a first credential based on the second credential, the first credential being used to verify the payment authority of the smart agent; and a second generation module 1330 configured to generate a third credential based on the first credential in response to receiving a payment request from the smart agent, the third credential being used to verify the payment parameters of the payment token.

[0200] In some cases, the first document includes third reference information of the second document, and the third document includes second reference information of the first document and fourth reference information of the second document.

[0201] In some cases, the first generation module 1320 is further configured to: receive first configuration information associated with the agent; and generate a first credential in response to the first configuration information satisfying a first condition, wherein the first condition is associated with a first set of permissions indicated by the second credential.

[0202] In some cases, the second generation module 1330 is further configured to: in response to receiving a payment request from the smart agent, obtain payment information associated with the payment request; and in response to the payment information satisfying a second condition, generate a third credential, the second condition being associated with a second set of permissions indicated by the first credential.

[0203] In some cases, the device 1300 also includes a third generation module configured to: generate a first verification value based on the first credential, the second credential, and the third credential; and add the first verification value to the third credential.

[0204] In some cases, the device 1300 also includes a second evidence storage module configured to write a first verification value into an evidence storage record, the evidence storage record also indicating the generation information of multiple credentials, including a first credential, a second credential, and a third credential.

[0205] In some cases, the evidence storage module is also configured to update the evidence storage record based on the change information in response to a change in at least one of the multiple credentials.

[0206] The modules included in device 1200 or 1300 can be implemented in various ways, including software, hardware, firmware, or any combination thereof. In some cases, one or more modules can be implemented using software and / or firmware, such as machine-executable instructions stored on a storage medium. In addition to or as an alternative to machine-executable instructions, some or all of the units in device 1200 or 1300 can be implemented at least partially by one or more hardware logic components. By way of example and not limitation, exemplary types of hardware logic components that can be used include field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-chips (SoCs), complex programmable logic devices (CPLDs), and so on.

[0207] Figure 14 A schematic block diagram is shown that can be used to implement the example device 1400 of this document. For example, a computing device according to some examples of this document can be implemented by device 1400. Figure 14 As shown, device 1400 includes a processing unit 1410, such as a central processing unit or a graphics processing unit, which can perform various appropriate actions and processes according to computer program instructions stored in a storage unit 1420, such as a read-only memory (ROM), or loaded from a storage unit 1430 into a storage unit 1420, such as random access memory (RAM). The storage unit 1420 may also store various programs and data required for the operation of device 1400. The processing unit 1410 and the storage unit 1420 are connected to each other via a bus. Input / output (I / O) interfaces are also connected to the bus.

[0208] Multiple components in device 1400 can be connected to I / O interfaces, including: input units 1450 such as keyboards and mice; output units 1460 such as various types of displays and speakers; storage units 1430 such as disks and optical discs; and communication units 1440 such as network cards, modems, and wireless transceivers. Communication unit 1440 allows device 1400 to exchange information or data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0209] Processing unit 1410 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processing unit 1410 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processing unit 1410 performs the various methods and processes described above, such as method 1000 and / or method 1100.

[0210] For example, in some examples, method 1000 and / or method 1100 may be implemented as a computer software program, i.e., program product 1425, which is tangibly contained in a machine-readable medium, such as storage unit 1430. In some examples, part or all of the computer program may be loaded and / or installed on device 1400 via ROM and / or communication unit 1440. When the computer program is loaded into RAM and executed by processing unit 1410, one or more steps of method 1000 and / or method 1100 described above may be performed. Alternatively, in other examples, processing unit 1410 may be configured to perform method 1000 and / or method 1100 by any other suitable means (e.g., by means of firmware).

[0211] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), etc.

[0212] The program code used to implement the methods described herein may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0213] In the context of this document, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0214] Furthermore, while the operations are described in a specific order, this should be understood as requiring that such operations be performed in the specific order shown or in sequential order, or requiring that all illustrated operations be performed to achieve the desired result. In certain contexts, multitasking and parallel processing may be advantageous. Similarly, although some specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this paper. Certain features described in the context of individual examples can also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation can also be implemented individually or in any suitable sub-combination in multiple implementations.

[0215] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A method for making a payment, comprising: In response to receiving a payment request from an intelligent agent, multiple credentials associated with the payment request are obtained, the multiple credentials including at least a first credential and a second credential, the first credential being used to verify the payment authority of the intelligent agent, and the second credential being used to verify the payment subject of the payment request; Based on the multiple credentials, a verification process for the payment request is performed; as well as The payment request is processed based on the verification result of the verification process.

2. The method according to claim 1, wherein the plurality of credentials further includes a third credential, the third credential being used to verify the payment parameters of the payment token.

3. The method according to claim 2, wherein the payment request includes first reference information corresponding to the third credential, and the step of obtaining multiple credentials associated with the payment request includes: Based on the first reference information, the third credential is obtained, wherein the third credential includes the second reference information of the first credential; Based on the second reference information, the first credential is obtained, wherein the first credential includes third reference information of the second credential; and Based on the third reference information, the second credential is obtained.

4. The method according to claim 2, wherein the third voucher further includes a first verification value, the first verification value being calculated based on the plurality of vouchers, and the process of performing the verification of the payment request includes: Based on the multiple credentials, a second verification value is generated; as well as Based on the comparison between the first verification value and the second verification value, the verification process for the payment request is performed.

5. The method according to claim 4, wherein generating the second verification value based on the plurality of credentials includes: The second verification value is generated based on multiple constraint fields corresponding to the multiple credentials, wherein the constraint fields include at least one of the version information, status information and summary information of the corresponding credentials.

6. The method according to claim 2, wherein performing the verification process for the payment request includes: Perform the first verification associated with the third credential; In response to passing the first verification, a second verification associated with the first credential is performed; as well as In response to passing the second verification, a third verification associated with the second credential is performed.

7. The method of claim 6, wherein performing the first verification associated with the third credential comprises: Verify whether the third credential is valid; as well as In response to the third credential being in the valid state, verify whether the payment parameters of the payment token are consistent with the payment request.

8. The method of claim 6, wherein performing the second verification associated with the first credential comprises: Verify whether the first credential is valid; as well as In response to the first credential being in the valid state, the payment parameters of the payment token are verified to meet the first condition indicated by the first credential.

9. The method of claim 6, wherein performing the third verification associated with the second credential comprises: Verify whether the second credential is valid; as well as In response to the second credential being in the valid state, the account information and authentication information of the payment subject are verified.

10. The method of claim 2, wherein the payment parameters include at least one of the following: The amount of payment corresponding to the payment request; Business party information corresponding to the payment request; Scenario information corresponding to the payment request; The validity period corresponding to the payment request.

11. The method of claim 2, wherein the third credential includes second reference information to the first credential, and the method further comprises: In response to the first credential changing to a first state, the third credential is adjusted to a second state, which is determined based on the first state.

12. The method according to claim 1, further comprising: In response to the second credential changing its state to a third state, the first credential is adjusted to a fourth state, which is determined based on the third state.

13. The method of claim 1, wherein the second credential indicates at least one of the following: The type of the payment entity; The authentication information of the payment entity; The account information of the payment entity; The intelligent agent associated with the payment entity; Payment configuration information associated with the payment entity.

14. The method of claim 1, wherein the first credential indicates at least one of the following: The identity information of the intelligent agent; The authentication information of the intelligent agent; The capabilities of the intelligent agent; Payment configuration information associated with the intelligent agent; The validity period associated with the intelligent agent.

15. The method according to claim 1, wherein processing the payment request based on the verification result of the verification process includes: In response to the verification result indicating that the verification passed, the payment corresponding to the payment request is triggered. as well as In response to the verification result indicating that the verification failed, the payment request is rejected.

16. The method according to claim 1, wherein processing the payment request based on the verification result of the verification process includes: In response to the verification result meeting the preset conditions, a prompt message is provided to determine whether to continue executing the payment request; as well as The payment request is processed based on the result of the operation on the prompt information.

17. The method according to claim 1, further comprising: The verification result is written into the evidence storage record, which also indicates at least one of the generation information of the plurality of vouchers and the change information of the plurality of vouchers.

18. The method of claim 1, wherein the plurality of credentials further comprises a fourth credential, the fourth credential being used to verify the task execution scope of the agent.

19. The method according to claim 1, further comprising: Provide a visualization component associated with the plurality of credentials, the visualization component being used to present at least one of the following: The hierarchical relationship between the multiple credentials; Status information of the multiple credentials; The permission scope information of the multiple credentials; The validity period information of the multiple certificates.

20. The method of claim 19, further comprising: User actions are received through the visualization component; as well as Based on the user's operation, adjust the configuration information of at least one of the multiple credentials.

21. The method of claim 20, wherein the configuration information includes at least one of the following: The scope of permissions for the corresponding credentials; The limit information for the corresponding voucher; The validity period of the corresponding certificate; The status of the corresponding voucher.

22. A method for generating payment vouchers, comprising: Obtain a second credential, which is used to verify the payment entity; A first certificate is generated based on the second certificate, and the first certificate is used to verify the payment authority of the smart agent. as well as In response to receiving a payment request from the smart agent, a third credential is generated based on the first credential, the third credential being used to verify the payment parameters of the payment token.

23. The method of claim 22, wherein the first credential includes third reference information of the second credential, and the third credential includes second reference information of the first credential and fourth reference information of the second credential.

24. The method of claim 22, wherein generating the first certificate based on the second certificate comprises: Receive the first configuration information associated with the agent; as well as In response to the first configuration information satisfying a first condition, the first credential is generated, wherein the first condition is associated with a first set of permissions indicated by the second credential.

25. The method of claim 22, wherein generating a third credential based on a first credential in response to receiving a payment request from the agent comprises: In response to receiving a payment request from the intelligent agent, obtain payment information associated with the payment request; as well as In response to the payment information satisfying the second condition, the third credential is generated, the second condition being associated with the second set of permissions indicated by the first credential.

26. The method of claim 25, further comprising: Based on the first certificate, the second certificate, and the third certificate, a first verification value is generated; as well as Add the first verification value to the third credential.

27. The method of claim 26, further comprising: The first verification value is written into the evidence storage record, which also indicates the generation information of multiple vouchers, including the first voucher, the second voucher, and the third voucher.

28. The method of claim 27, further comprising: In response to a change in at least one of the plurality of credentials, the evidence storage record is updated based on the change information.

29. A device for making payments, comprising: The first acquisition module is configured to, in response to receiving a payment request from an agent, acquire multiple credentials associated with the payment request, the multiple credentials including at least a first credential and a second credential, the first credential being used to verify the payment authority of the agent, and the second credential being used to verify the payment subject of the payment request; The first verification module is configured to perform a verification process on the payment request based on the multiple credentials; as well as The processing module is configured to process the payment request based on the verification result of the verification process.

30. An apparatus for generating payment vouchers, comprising: The second acquisition module is configured to acquire a second credential, which is used to verify the payment entity. The first generation module is configured to generate a first credential based on the second credential, and the first credential is used to verify the payment authority of the smart agent. as well as The second generation module is configured to generate a third credential based on the first credential in response to receiving a payment request from the smart agent. The third credential is used to verify the payment parameters of the payment token.

31. An electronic device, comprising: At least one processing unit; as well as At least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions causing the electronic device to perform the method according to any one of claims 1 to 21 or 22 to 28 when executed by the at least one processing unit.

32. A computer-readable storage medium having a computer program stored thereon, the computer program being executable by a processor to implement the method according to any one of claims 1 to 21 or 22 to 28.

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

Images