# AP2 - Agent Payments Protocol Documentation > The Agent Payments Protocol (AP2) is a solution for enabling gen AI agents to make payments on behalf of users, safely, securely, and in a decentralized and privacy protecting manner. This protocol is a part of the broader ecosystem, which includes agentic protocols like A2A and MCP, and encompasses the global nature of payments. # Introduction # Agent Payments Protocol (AP2) ## What is AP2? **Agent Payments Protocol (AP2) is an open protocol for the emerging Agent Economy.** It's designed to enable secure, reliable, and interoperable agent commerce for developers, merchants, and the payments industry. The protocol is available as an extension for the open-source [Agent2Agent (A2A) protocol](https://a2a-protocol.org/) and [Universal Commerce Protocol](https://ucp.dev/documentation/ucp-and-ap2/) with more integrations in progress. Build agents with *(or any framework)*, equip with *(or any tool)*, collaborate via , and use **AP2** to secure payments with gen AI agents. - **Video** Intro in \<7 min ______________________________________________________________________ - **Read the docs** ______________________________________________________________________ [AP2 v0.2 Release and FIDO Alliance Donation](https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/) [FIDO Alliance to Develop Standards for Trusted AI Agent Interactions](https://fidoalliance.org/fido-alliance-to-develop-standards-for-trusted-ai-agent-interactions/) [Agent Payments Protocol Announcement (9/16/2025)](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol) **Explore the detailed technical definition of the AP2 protocol** [Agent Payments Protocol Specification](ap2/specification/) [AP2 and UCP integration guide](https://ucp.dev/documentation/ucp-and-ap2/) ______________________________________________________________________ ## Why an Agent Payments Protocol is Needed Today’s payment systems assume a human is directly clicking "buy" on a trusted website. When an autonomous agent initiates a payment, this core assumption is broken, leading to critical questions that current systems cannot answer: - **Authorization:** How can we verify that a user gave an agent specific authority for a particular purchase? - **Authenticity:** How can a merchant be sure an agent's request accurately reflects the user's true intent, without errors or AI "hallucinations"? - **Accountability:** If a fraudulent or incorrect transaction occurs, who is accountable—the user, the agent's developer, the merchant, the issuer, the PSP, or the orchestration layer? This ambiguity creates a crisis of trust that could significantly limit adoption. Without a common protocol, we risk a fragmented ecosystem of proprietary payment solutions, which would be confusing for users, expensive for merchants, and difficult for financial institutions to manage. AP2 aims to create a common language for any compliant agent to transact securely with any compliant merchant globally. ______________________________________________________________________ ## Core Principles and Goals The Agent Payments Protocol is built on fundamental principles designed to create a secure and fair ecosystem: - **Openness and Interoperability:** As a non-proprietary, open extension for A2A and MCP, AP2 fosters a competitive environment for innovation, broad merchant reach, and user choice. - **User Control and Privacy:** The user must always be in control. The protocol is designed with privacy at its core, using a role-based architecture to protect sensitive payment details and personal information. - **Verifiable Intent, Not Inferred Action:** Trust in payments is anchored to deterministic, non-repudiable proof of intent from the user, directly addressing the risk of agent error or hallucination. - **Clear Transaction Accountability:** AP2 provides a non-repudiable, cryptographic audit trail for every transaction, aiding in dispute resolution and building confidence for all participants. - **Global and Future-Proof:** Designed as a global foundation, the initial version supports common "pull" payment methods like credit and debit cards. The roadmap includes e-wallets, "push" payments such as real-time bank transfers (e.g., UPI and PIX), and digital currencies, recognizing that many countries do not have real-time banking systems. ______________________________________________________________________ ## Key Concept: Verifiable Digital Credentials (VDCs) The Agent Payments Protocol engineers trust into the system using **verifiable digital credentials (VDCs)**. VDCs are tamper-evident, cryptographically signed digital objects that serve as the building blocks of a transaction. There are two primary types of mandates, each existing in two stages: - **Checkout Mandate**: Captures the reference to the specific items and purchase details negotiated between the agent and the merchant, and is **shared with the merchant**. - **Open**: Captures the user's constraints and goals for the transaction before a specific cart is finalized for autonomous execution. - **Closed**: Captures the user's (or agent's) authorization for a specific, finalized checkout. - **Payment Mandate**: Authorizes a payment against a specific payment instrument, and is **shared with the Credential Provider, Networks and the Merchant Payment Processor**. - **Open**: Captures the user's constraints on payment (e.g., budget, allowed instruments) for autonomous execution. - **Closed**: Captures the authorization for a specific transaction amount bound to a finalized checkout. These VDCs operate within a defined role-based architecture and are chained together to provide a complete, verifiable audit trail for both human-present and human-not-present transactions. See more in the sample [Flows](ap2/flows/). ## See it in action - **Human Not Present Cards** ______________________________________________________________________ A sample demonstrating an autonomous transaction where the agent acts without human presence, using traditional card payments. [Go to sample](https://github.com/google-agentic-commerce/AP2/tree/main/code/samples/python/scenarios/a2a/human-not-present/cards/) - **Human Not Present x402** ______________________________________________________________________ A sample demonstrating an autonomous transaction where the agent acts without human presence, using the x402 protocol for payments. [Go to sample](https://github.com/google-agentic-commerce/AP2/tree/main/code/samples/python/scenarios/a2a/human-not-present/x402/) - **Digital Payment Credentials Android** ______________________________________________________________________ A sample demonstrating the use of digital payment credentials on an Android device. [Go to sample](https://github.com/google-agentic-commerce/AP2/tree/main/code/samples/android/scenarios/digital-payment-credentials/) - **Human Present Cards** ______________________________________________________________________ A sample demonstrating a human-present transaction using traditional card payments. [Go to sample](https://github.com/google-agentic-commerce/AP2/tree/main/code/samples/python/scenarios/a2a/human-present/cards/) ______________________________________________________________________ ## Get Started and Build with Us The Agent Payments Protocol provides a mechanism for secure payments, and it's part of a larger picture to unlock the full potential of agent-enabled commerce. We actively seek your feedback and contributions to help build the future of commerce. Our public GitHub repo hosts the lastest version of AP2 specification, documentation and SDK. Standardization of the specification will continue within the Agentic Authentication Technical and Payments Technical Working Groups in FIDO. You can get started today by: - Downloading and running our **code samples**. - **Experimenting with the protocol** and its different agent roles. - Contributing your feedback and **code** to the public repository. [Visit the GitHub Repository](https://github.com/google-agentic-commerce/AP2) # Specification # Executive Summary AI agents will redefine the landscape of digital commerce, promising unprecedented convenience, personalization, and efficiency. However, this shift exposes a fundamental challenge: the world's existing payments infrastructure was not designed for a future where autonomous, non-human agents act on a user's behalf, or transact with each other. Current payment protocols, built on the assumption of direct human-initiated interaction with trusted interfaces, lack the mechanisms to securely validate an agent's authenticity and authority to transact. This creates ambiguity around transaction liability, and threatens adoption of agentic commerce. Without a common, trusted protocol, the industry faces the prospect of a fragmented and insecure ecosystem, characterized by proprietary, siloed solutions that increase complexity for merchants, create friction for users, and prevent financial institutions from uniformly assessing risk. To address this gap, this protocol proposes an open, interoperable protocol for agent payments. This protocol, designed as an extension for emerging agent-to-agent (A2A), model-context protocols (MCP), and Universal Commerce Protocol (UCP), establishes a secure and reliable framework for AI-driven commerce. ## The New Frontier of Commerce: Why Agent Payments Require a Foundational Protocol ### 1.1 The Rise of Agent Commerce The evolution of digital interaction is entering a new phase, moving beyond direct manipulation of UIs to conversational and delegated task execution. AI agents are rapidly becoming primary actors, capable of understanding complex user requests and executing multi-step tasks autonomously. In commerce, this translates into a paradigm shift where agents will manage everything from routine purchases and subscription management to complex product research, price negotiation, and dynamic order bundling across multiple vendors. This new era of agent commerce promises to unlock immense value, offering users a hyper- personalized and frictionless shopping experience while providing merchants with new, intelligent channels to reach and serve customers. ### 1.2 The Foundational Gap: A Crisis of Trust and Liability Despite its promise, the rise of agent commerce exposes a critical vulnerability in the existing digital payments infrastructure. Today's payment protocols are designed around the principle of a human user directly interacting with a trusted interface, such as a merchant's website or a payment provider's app. Authentication, authorization, and liability are all predicated on this direct human involvement. Autonomous agents shatter this assumption. When an agent initiates a payment, fundamental questions arise that current systems are ill-equipped to answer: - Authorization & Auditability: What verifiable proof demonstrates that the user granted the agent the specific authority to make this particular purchase? - Authenticity of Intent: How can a merchant or payment processor be certain that the agent's request accurately reflects the human user's true intent? - Agent Error and "Hallucination": How does the system protect against agent errors, such as misinterpreting a user's request or "hallucinating" product details, which could lead to incorrect purchases? - Accountability: In the event of a fraudulent or erroneous transaction, who is accountable? The user who delegated the task? The developer of the shopping agent? The merchant who accepted the order? The payment network that processed it? Or the PSP/orchestration layer? This ambiguity creates a crisis of trust. Without a robust framework to validate agent authority and assign liability clearly, financial institutions may be hesitant to approve agent-initiated transactions, merchants will be exposed to unacceptable levels of fraud risk, and users will be reluctant to delegate financial authority to agents. ### 1.3 The Risk of a Fragmented Ecosystem In the absence of a universally adopted protocol, the industry will inevitably move toward a patchwork of proprietary, closed-loop solutions. Large retailers might develop bespoke integrations for their specific agents, and payment providers might create siloed ecosystems that do not interoperate. This fragmentation would have severe negative consequences: - For Users: A confusing and inconsistent experience, where their preferred agent may only work with a limited set of merchants or payment methods. - For Merchants: High development and maintenance costs to support multiple, non-standard agent payment integrations, creating a significant barrier to entry for small and medium-sized businesses. - For the Payments Ecosystem: An inability to collect common signals across all agent transactions in order to consistently mitigate fraud, leading to higher costs and suppressed transaction approval rates. An open, interoperable protocol is the most viable path forward. It creates a common language for all participants. It allows for additional data points to be shared about the transaction in a way that wasn’t possible before and ensures that any compliant agent can securely transact with any compliant merchant, fostering a competitive and innovative marketplace. ## Section 2: Guiding Principles for a Trusted Agent Economy The design of this proposed protocol is rooted in a set of core principles intended to build a sustainable, secure, and equitable ecosystem for all participants. These principles serve as the philosophical foundation for the technical architecture that follows. ### 2.1 Openness and Interoperability This protocol is proposed as a non-proprietary, open extension for existing and future agent-to-agent (A2A), model-context protocol (MCP), and Universal Commerce Protocol (UCP). The goal is to provide a common, interoperable payments layer that can be adopted by any ecosystem player. This approach fosters a healthy, competitive environment where developers can innovate on agent capabilities, merchants can reach the broadest possible audience, and users can choose the combination of agents and services that best suits their needs. ### 2.2 User Control and Privacy by Design The user must always be the ultimate authority. The protocol is designed to ensure users have granular control and transparent visibility over their agents' activities. Privacy is a core design tenet. The protocol is designed to protect sensitive user information, including the content of their conversational prompts, the items they are buying and payment details. Through Selective Disclosure, agents involved in the shopping process are prevented from accessing sensitive payment card industry (PCI) data which is handled exclusively by the specialized entities and the secure elements of the payment infrastructure. This focus on privacy and data minimization also ensures that entities only see the data that is absolutely necessary for them to perform their roles. ### 2.3 Verifiable Intent, Not Inferred Action Trust in an AI Agent system cannot be based only on interpreting the ambiguous, probabilistic outputs of a large language model. Transactions must be anchored to deterministic, non-repudiable proof of intent from all parties. This principle directly addresses the risk of agent "hallucination" and misinterpretation. ### 2.4 Clear Transaction Accountability For the payments ecosystem to embrace agent commerce, there can be no ambiguity regarding transaction accountability. A primary objective of this protocol is to provide supporting evidence that helps payment networks establish accountability and liability principles. This clarity is table stakes for gaining the confidence and participation of merchants, issuers, and payment networks. ## Section 3: Architectural Overview: A Role-Based Ecosystem for Secure Transactions To achieve its goals of security, interoperability, and clear accountability, the proposed protocol defines a role-based architecture. Each actor in the ecosystem has a distinct and well-defined set of responsibilities, ensuring a separation of concerns that enhances security and simplifies integration. The agent payments ecosystem consists of the following key roles: - **Shopping Agent (SA):** The Shopping Agent is the primary agent performing product discovery, building the checkout and executing the purchase. - **Credential Provider (CP):** The Credential Provider is the source of Payment Credentials for the purchase. They are responsible for verifying that this Agent is authorized to access this Payment Credential, and scoping the Payment Credential appropriately. - **Merchant (M)**: The Merchant is the source of the Checkout. They are responsible for owning the catalog and fulfilling orders. - **Merchant Payment Processor (MPP)**: The Merchant Payment Processor role is responsible for processing payments for purchases. They are responsible for verifying that the Payment Credential has been authorized to pay for this Checkout. - **Trusted Surface (TS):** The Trusted Surface role is a UI surface that is trusted to get informed user consent for an Intent before creating a user-signed Mandate. - **Network and Issuer**: The provider of the payment network and issuer of payment credentials to the human user. The Credentials Provider may need to interact with the network for issuance of specific tokens for AI agent transactions and the Merchant/PSP may submit these transactions for authorization to issuers via the networks. Some non-normative examples of how the roles could be combined: - The provider of the Shopping Agent could also provide a non-agentic Trusted Surface within their application. - The Shopping Agent could also provide their own Credential Provider. - The Merchant could provide their own Merchant Payment Processor - The Merchant could be a Credential Provider. ## Section 4: Core User Journeys ### 4.1 Human Present Transaction Human delegates a task to an AI Agent which requires a payment to be made (e.g., for shopping) and human is available when the payment has to be authorized. A typical (but not only) way this may happen is as below: - Setup: The User may set up a connection between their preferred Shopping Agent & any of the supported Credential Providers. This may require the User to authenticate themselves on a surface owned by the Credential Provider. - Discovery & Negotiation: The User provides a shopping task to their chosen AI Agent (*which may activate a specialized Shopping Agent to complete the task*). The Shopping Agent interacts with one or more Merchants to assemble a cart that satisfies the User's request. This may include the ability for the merchant to provide loyalty, offers, cross-sell and up-sell information (*via the integration between the Shopping Agent & Merchant*) which the Shopping Agent should represent to the user . - Merchant Validates Cart: A SKU or set of SKUs are authorized by the User for purchase. This is communicated by the Shopping Agent to the Merchant to initiate order creation. The Merchant must sign the Cart that they create for a user, signaling that they will fulfill this cart. - Provide Payment Methods: The Shopping Agent may provide the payment context to the Credentials Provider and request an applicable payment method (shared as a reference or in encrypted form), along with any loyalty/discount information which may be relevant for the payment method selection (*say, card points which can be redeemed towards the txn*). - Show Cart: The Shopping Agent presents the final cart and applicable payment method to the user in a trusted surface and the user can approve it via an authentication process. - Sign & Pay: The user’s signed approval must create a cryptographically signed “Checkout Mandate”. This mandate contains the explicit goods being purchased & their confirmation of purchase. It is shared with the Merchant so they can use this as evidence in case of disputes. Separately, the Payment Mandate may be shared with the network & issuer for transaction authorization. - Payment Execution: The Payment Mandate must be conveyed to the Credential provider and Merchant to complete the transaction. There may be multiple ways this might happen. For example, - The Shopping Agent (SA) may request Credentials Provider to complete a payment with the Merchant OR, - the SA may submit an order with the merchant, triggering a payment authorization flow where the merchant/PSP requests payment method from the Credentials Provider. - Send Transaction to Issuer: The Merchant or PSP routes the transaction to the issuer or the network within which the payment method operates. The transaction packet may be appended with AI agent presence signals ensuring network/issuer get visibility into agentic transactions. - Challenge: Any party (issuer, credential provider, merchant etc.) may choose to challenge the transaction through existing mechanisms like 3DS2. This challenge needs to be presented to the user by the Trusted Surface (*an example of this would be a hosted 3DS*) and may require a redirect to a trusted surface to complete. - Resolve Challenge: The user should have a way to resolve the challenge on a trusted surface (say, banking app, website etc.) - Authorize Transaction: The issuer approves the payment and confirms success back. This is communicated to the User and the Merchant so that the order can be fulfilled. A payment receipt is shared with the Credential Provider confirming the transaction result. In case of a decline, that can also be appropriately communicated. ### 4.2 Human Not Present Transaction Human delegates a task to an AI Agent which requires a payment to be made (e.g., for shopping) and human wants the AI Agent to proceed with the payment in their absence. Some canonical scenarios here could be “*buy these shoes for me when the price drops below $100*” or “*buy 2 tickets to this concert as soon as they become available, make sure we’re close to the main stage but don’t spend more than $1000*”. Key changes from the Human Present modality are noted below: - The Agent must repeat back to the User what they think they are expected to purchase. The User must approve this and confirm that they would like the agent to proceed with the purchase in their absence. This is done by the User going through in-session authentication (biometric etc.) to confirm their intent. - The “Checkout Mandate” signed by the user now contains the list of conditions under which the SA can fulfill the user’s order. This mandate is in an “Open” state while the Agent tries to meet the user’s requirements. Once the SA determines that the requirements can be met, the mandate is “Closed”. - Merchant can force user confirmation: If the Merchant is unsure about their ability to fulfill the user’s needs (e.g. the request is not for a specific SKU), they can force the user to come back into session to confirm the purchase conditions or provide additional information. # Agentic Payment Protocol (v0.2) The Agentic Payment Protocol (AP2) provides a protocol to secure Agent-performed payment transactions. It makes use of the [Agent Authorization model](../agent_authorization/). This specification describes the following: - The different roles of entities within AP2. - The verification responsibilities of these roles. - A [Checkout Mandate](../checkout_mandate/) and [Receipt](../checkout_mandate/#checkout-receipt) for securing *what* is being purchased. - A linked [Payment Mandate](../payment_mandate/) and [Receipt](../payment_mandate/#payment-receipt) for the *payment* of the Checkout. - How the Checkout and Payment Mandates can be used as evidence at the time of dispute. AP2 operates as a security feature within a Commerce Protocol. The exact details of the Commerce Protocol (e.g., catalog APIs, checkout updates, and specific APIs for communication between the different roles) are outside the scope of AP2. AP2 is designed explicitly to be compatible with the Universal Commerce Protocol (UCP) and integrates seamlessly. Illustrative examples are provided for [Human Present ('direct')](../flows/#human-present) and [Human Not Present ('autonomous')](../flows/#human-not-present) flows. ## Roles AP2 considers five roles, who have different responsibilities from a processing and verification perspective. These are as follows: - **Shopping Agent (SA):** The Shopping Agent is the primary agent performing product discovery, building the checkout, and executing the purchase. - **Credential Provider (CP):** The Credential Provider is the source of Payment Credentials for the purchase. They are responsible for verifying that this Agent is authorized to access this Payment Credential, and scoping the Payment Credential appropriately. - **Merchant (M):** The Merchant role is responsible for providing and completing the Checkout. They verify that the Shopping Agent is approved to purchase these particular items and are responsible for the integrity of the inventory, pricing, and any merchant discounts. - **Merchant Payment Processor (MPP):** The Merchant Payment Processor role is responsible for processing payments for purchases. They are responsible for verifying that the Payment Credential shared by the Credential Provider has been authorized to pay for this Checkout instance. - **Trusted Surface (TS):** The Trusted Surface role is a UI surface that is trusted to get informed user consent for an Intent before creating a user-signed Mandate. > Note: While AP2 defines five roles, it is possible for a single entity to play multiple (or even all) of the roles. In that case, they would take on all of the responsibilities of each role they are playing. Roles MAY always delegate their responsibilities to another party. ## Agentic vs Non-Agentic Many of these roles can be considered Agentic or Non-Agentic. A role is Agentic when: - Communication to or from the Role is handled by a non-deterministic LLM. A role is considered Non-Agentic if: - Communication to and from the Role is handled using deterministic code that verifies the authenticity and correctness. - And if no processing done by the role is delegated to an LLM. The following roles MAY be agentic or non-agentic: - Merchant - Merchant Payment Processor - Credential Provider The following role MUST be non-agentic: - Trusted Surface The following role is expected to be agentic: - Shopping Agent When communication happens between two non-agentic Roles, standard web security is sufficient to ensure integrity. However, when either role is agentic, then the Agent itself is a potential attacker. As such, additional tamper-evident mechanisms are needed to ensure secure communication. AP2 assumes that, at a minimum, the Shopping Agent is agentic. In the case where the payment journey happens directly between two non-agentic surfaces (such as a Trusted Surface communicating directly with a non-agentic Merchant), then existing e-commerce security models are sufficient. When this document refers to validation or processing for a particular role, it MUST happen in deterministic code regardless of whether the role is agentic or not. ## Mandates Mandates are the core means that AP2 uses to authorize agents. See [Agent Authorization Framework][agent_authorization.md] for a description of how this works in the general case. AP2 defines two Mandate types: Checkout Mandate and Payment Mandate. The Checkout and Payment Mandate contents are assembled by the Shopping Agent after it has determined what task the user wishes it to perform. The exact details of how this is achieved is outside of the scope of this specification. The Shopping Agent then uses a Trusted Surface to obtain signed Checkout and Payment Mandates, which it will use to authorize payment and complete the Checkout. ### Checkout Mandate The Checkout Mandate is designed to provide the Merchant cryptographic proof that the Shopping Agent is authorized to purchase the Checkout that it has assembled. The Checkout Mandate is provided by the Shopping Agent and verified by the Merchant. The The Merchant MUST provide a merchant-signed JWT containing the Checkout to the Shopping Agent. The closed Checkout Mandate is bound to this Checkout JWT using a cryptographic hash. Once the Merchant has accepted or rejected the Checkout Mandate, it MUST return a Checkout Receipt. For the full details of the Checkout Mandate and Receipt structures, see [Checkout Mandate](../checkout_mandate/). ### Mandate Versioning Each AP2 Mandate type identifies its schema using the `vct` claim. The `vct` value includes a numeric suffix that acts as a schema version number (e.g. `mandate.payment.1`, `mandate.checkout.open.1`). Implementations MUST match the exact `vct` string, including the version suffix. A future incompatible schema revision would introduce a new suffix (e.g. `.2`), allowing old and new versions to be distinguished unambiguously. ### Payment Mandate The Payment Mandate is designed to provide the Credential Provider, Network, and Merchant Payment Processor cryptographic proof that the Shopping Agent is authorized to pay for a particular Checkout. The Payment Mandate is provided by the Shopping Agent and verified by the Credential Provider, Network, and Merchant Payment Processor. The Payment Mandate is bound to a particular Checkout using the cryptographic hash of the Checkout JWT. To prevent rainbow table attacks, the Checkout JWT MUST be signed using a digital signature scheme (e.g., ECDSA) and not a deterministic signature (e.g., Ed25519). Once the Merchant Payment Processor has accepted or rejected the Payment Mandate, a signed Payment Receipt MUST be returned to the Shopping Agent, Credential Provider, and possibly Networks. For the full details of the Payment Mandate and Receipt structures, see [Payment Mandate](../payment_mandate/). ## Modes There are two `modes` that AP2 can consider to operate in. - Human Present (Direct): The User directly sees the closed Checkout and approves it and its payment explicitly. - Human Not Present (Autonomous): The User sees and approves a set of constraints over what closed Checkout and Payment would meet their intent. The Shopping Agent then assembles and approves a closed Checkout and Payment Mandate on their behalf using these open Mandates. Verifiers of Mandates *always* receive a closed Payment and Checkout Mandate, regardless of the mode. The difference is only in how the verification of the Mandate is performed. In the Direct case, the signature on the closed Mandates is validated as coming from a User directly, using a User Credential or a trust list of Agent Providers. In the Autonomous case, the closed Mandates are signed by an Agent key. Trust in this key is provided by open Mandates that are signed by the User or a trust list of Agent Providers. Constraints in these Mandates allow the verifier to verify that the Checkout and Payment match the User's intent. Only constraints relevant to the closed Mandates are shared with the verifier. ### Direct (Human Present) When a Shopping Agent has a Checkout JWT for the closed Checkout from the Merchant, they construct the Checkout and Payment Mandate Content and pass it to a Trusted Surface for display to the user and signing. Upon receiving the Checkout and Payment Mandate, the Shopping Agent forwards the Payment Mandate to the Credential Provider (and possibly the Network) for Verification. Upon successful verification, the the Shopping Agent receives a payment credential. The payment credential and a Checkout Mandate are then provided to the Merchant. The The Merchant verifies the Checkout with what it created, and initiates payment with the Merchant Payment Processor if a Merchant-initiated charge. In the case that the payment method pushes funds to the Merchant, the Merchant will instead receive confirmation of funds sent, and confirm the receipt of those funds. Upon completion, a Checkout Receipt is returned to the Shopping Agent, and the Payment Receipt is returned to the Shopping Agent, Credential Provider and, if applicable, the Network. See [Human Present](../flows/#human-present) for a detailed example. > Note: Because the User approves the closed Checkout, this can often be replaced with a traditional e-commerce journey where the Merchant and the Trusted Surface communicate directly. ### Autonomous (Human Not Present) When a Shopping Agent needs to operate autonomously, it will create open Checkout and Payment Mandate Content and have these authorized by the Trusted Surface. These MUST include the agent's public key as a `cnf` claim. This is required as it is not yet bound to a particular transaction, and so it needs to be constrained for use by the Agent. It is RECOMMENDED to set the `exp` claim for these Mandates to the smallest value that will allow the Shopping Agent to complete the assigned task. After the Shopping Agent has created an appropriate Checkout, to authorize the Checkout, the Shopping Agent MAY now sign it using its Agent Key instead of getting approval on a Trusted Surface. It then MUST provide both the user-signed open Mandate and the agent-signed closed Mandate to the Verifying Parties, as described in the Direct case above. Shopping Agents MUST NOT present any subsequent open Payment or Checkout Mandates without receiving a rejection receipt from the previous one. This is to prevent an Agent approving multiple different Checkouts using the same open Mandate. To ensure user privacy, Shopping Agents MUST present only the disclosures from the open Mandates needed in the evaluation of the closed Mandates. Upon completion, a Checkout Receipt is returned to the Shopping Agent, and the Payment Receipt is returned to the Shopping Agent, Credential Provider and, if applicable, the Network. See [Human Not Present](../flows/#human-not-present) for a detailed example. > Note: In the current specification, the Shopping Agent needs to determine the applicable Mandates and Disclosures ad-hoc based on the Checkout. In the future, utilizing an explicit query language in the commerce protocol can help practical interoperability. #### Agent-to-Agent Delegation Conceptually, it is possible to use this protocol to support delegation of Mandates from one Shopping Agent to another. This is outside the scope of the current specification. ## Dispute Evidence In the case of a dispute, the Checkout Mandate and Receipt, and Payment Mandate and Receipt can be brought together to provide a non-repudiable picture of the transaction. Specific details of how this is used for dispute resolution, retention, and retrieval requirements are outside the scope of this specification. The Checkout Mandate and Receipt MAY be able to be provided by the following roles: - Shopping Agent - Merchant The Payment Mandate and Receipt MAY be able to be provided by the following roles: - Shopping Agent - Credential Provider - Network - Merchant Payment Processor See [Verification: Dispute](#dispute) for the verification rules. > Note: Providing an automated method to retrieve the Checkout Mandate, from either the Shopping Agent or the Merchant, would provide substantial utility to the ecosystem. The exact details are outside the scope of the current version, but would be done by using the Payment Mandate `transaction_id` as the key to request it. ## Verification The following verification rules MUST be followed by these roles upon receipt of the Mandate. > Note: A particular role can always delegate the responsibilities to a technology provider. For example, a Merchant could have their payment processor perform verifications on their behalf. In such a case, the delegate follows the verification rules for that role instead. ### Merchant The Merchant MUST receive an appropriate Checkout Mandate from a Shopping Agent before completing the Checkout. They MUST verify the Checkout Mandate as follows: - Process and verify the Checkout Mandate according to [Verification and Processing Rules](../agent_authorization/#verification-and-processing-rules). - Verify that the hash of the Checkout JWT sent for approval matches the value included for the `checkout_hash` claim. - If open Checkout Mandates are included, verify that the closed Checkout conforms to all of the Constraints by evaluating each Constraint. If any step fails, the Merchant MUST return a Checkout Receipt JWT containing the appropriate error message. ### Credential Provider and Network The Credential Provider and, if applicable, the Network MUST receive an appropriate Payment Mandate from the Shopping Agent before returning a payment credential. They MUST verify the Payment Mandate as follows: - Process and verify the Payment Mandate according to [Verification and Processing Rules](../agent_authorization/#verification-and-processing-rules). - If open Payment Mandates are included, verify that the closed Payment Mandate matches all the Constraints. If any step fails, they MUST return a Payment Receipt JWT containing the appropriate error to the Shopping Agent. ### Merchant Payment Processor The Merchant Payment Processor MUST receive an appropriate Payment Credential from the Merchant before processing the transaction. Merchant Payment Processor MUST verify the Payment Credential is appropriately scoped to the Checkout. One way this can be done is by providing the Closed Payment Mandate inside the Payment Credential. ### Dispute When performing verification at the time of dispute, the following steps MUST be followed to ensure the integrity of the Payment and Checkout Mandate and Receipts. - The Checkout Mandate MUST be verified according to the Merchant Verification rules. - The hash of the `checkout_jwt` MUST be independently computed from the included `checkout_jwt`. - The Checkout Receipt `reference` MUST match the hash of the closed Checkout Mandate. This is calculated in the same manner as the `sd_hash` would be. - The Payment Mandate MUST be verified according to the [Merchant Payment Processor](#merchant-payment-processor) section using the `checkout_hash` from the Checkout Mandate. - The Payment Receipt reference MUST match the hash of the closed Payment Mandate. This is calculated in the same manner as the `sd_hash` would be. After all these steps have been performed successfully, then the information contained in the Checkout Mandate and Payment Mandate is able to be used as evidence as to what the user, and each role saw. ## Extension Points AP2 provides several extension points to allow it to adapt to meet the needs of Agentic Commerce. These are as follows: ### Mandate Constraints This extension point is designed to support constraining Agent behavior, while supporting more complex autonomous use cases. To define a new constraint, the following MUST be specified: - A uniquely defined `type`. - A Schema, including which fields are selectively disclosable. - The evaluation algorithm. ### Checkout Object AP2 is agnostic to the contents of the merchant-signed Checkout JWT. It is created to be compatible with logically represented Checkout Objects, but it does provide an extension point to be adapted to other Checkout Objects. UCP itself also provides such extension points within the protocol, which is the RECOMMENDED way to support new commerce journeys. ### Payment Instrument AP2 is agnostic to the particular payment instrument used. New Payment Instruments are supported by defining a unique `type` in the Payment Instrument JSON object. If necessary, additional properties MAY be defined for that specific `type`. ### Verifiable Digital Credential Formats (VDCs) AP2 specifies the use of `SD-JWT`s for securing the Payment and Checkout Mandates. Payment and Checkout Mandates could be cryptographically secured by other VDCs as mentioned in [Agent Authorization](../agent_authorization/). # Flow Examples There are two categories of flows in AP2: Human Present and Human Not Present. - *Human Present*: The User **directly** approves the closed Checkout and Payment Mandates. - *Human Not Present*: The User approves open Checkout and Payment Mandates while the Agent, acting autonomously, presents them along with Agent-signed closed Checkout and Payment Mandates. A Human Not Present flow can be turned into a Human Present flow by the Merchant (or Credential Provider) returning an `unresolved_constraint` error and bringing the User back into the loop to approve the closed Mandates. All flows below are non-normative examples. They assume that appropriate enrollment and any necessary User Credentials have been set up in advance. ## Human Present This is the `direct` flow where the User is present to directly approve the closed Payment and Checkout Mandates. Human Present flow There are two phases to this flow: **Phase 1: Shopping** Human Present Shopping flow 1. User initiates shopping with the Shopping Agent. 1. The Shopping Agent communicates with the Merchant and assembles a cart. 1. The Shopping Agent goes to Checkout. The Merchant creates a signed Checkout and requires an appropriate mandate to continue. 1. The Shopping Agent retrieves existing Instrument Options from the Credential Provider and selects one. **Phase 2: Payment** Human Present Payment flow 1. The Shopping Agent constructs Payment and Checkout Mandate Content and requests user approval via a Trusted Surface. - *This could use an external Trusted Surface with the User Credential model, or an internal one using the Trusted Agent Provider model.* 1. The Trusted Surface renders the Mandate Content and obtains user authentication (e.g., biometric) and consent. 1. The Trusted Surface uses `user_sk` to sign and create the Payment Mandate and Checkout Mandate. - *The `checkout_jwt` hash is used to permanently link the Mandates.* - *The `user_sk` would be the Agent Provider's key in the Trusted Agent Provider model.* 1. The Trusted Surface passes the Mandates back to the Shopping Agent. 1. The Shopping Agent passes the Payment Mandate to the Credential Provider, who verifies it and creates a payment token. - *As part of this process, the Credential Provider may share the Payment Mandate with the payment network and receive a scoped purchase credential (also called a token).* 1. The Shopping Agent sends this token and the Checkout Mandate to the Merchant. 1. The Merchant verifies the integrity and content of the Checkout Mandate against the current cart state, then initiates the payment with the token and `checkout_jwt` hash. 1. The Merchant Payment Processor verifies the included Payment Mandate in the token and the binding with the `checkout_jwt` hash. 1. The MPP-signed Payment Receipt is returned to the Shopping Agent, Credential Provider, and Network, and the Merchant-signed Checkout Receipt is returned to the Shopping Agent to indicate success. ## Human Not Present Human Not Present flow **Phase 1: Shopping** In the Human Not Present flow, the Shopping phase is split in two. In the first phase, the User sets a shopping task for the Agent. In the second phase, the Agent acts autonomously to complete the task without further human interaction. Human Not Present Shopping flow **Phase 1a: Shopping (Human Present)** In this phase, the User provides the agent authorization for autonomous commerce in the form of open Checkout and Payment Mandates. 1. User initiates shopping with the Shopping Agent. 1. The Shopping Agent assembles the appropriate `open` Mandate Contents for the shopping session and requests user approval via a Trusted Surface. - *This defines a set of constraints where the Shopping Agent can act without requiring further User authorization.* 1. The Trusted Surface renders the Mandate Content and obtains user authentication (e.g., biometric) and consent. 1. The Trusted Surface uses the `user_sk` to sign and create the open Checkout and open Payment Mandates. - *The hash of the open Checkout Mandate is included in the open Payment Mandate to permanently link them.* - *The `agent_pk` is included as a confirmation claim to sender-constrain the Mandate usage.* - *The `user_sk` would be the Agent Provider key in the Trusted Agent Provider model.* The User now leaves the session, having delegated the shopping task to the Shopping Agent. **Phase 1b: Shopping (Human Not Present)** In this phase, the Agent autonomously assembles a Checkout it believes fulfills the assigned task. 1. The Shopping Agent communicates with the Merchant and assembles a cart. 1. The Shopping Agent goes to Checkout. The Merchant creates a signed Checkout and requires an appropriate mandate to continue. **Phase 2: Payment (Human Not Present)** In this phase, the Agent completes the checkout using the provided Mandates. Human Not Present Payment flow 1. The Shopping Agent selects the appropriate existing open Mandates whose constraints apply to the incoming Checkout. - *The Mandate selection mechanism is outside the scope of this specification.* - *To prevent double-spend, the Shopping Agent MUST NOT create multiple overlapping Mandates until it receives an Action Receipt indicating an error. See the Implementation Considerations section for more details.* 1. The Shopping Agent constructs the Payment and Checkout Mandate Contents and signs both closed Mandates using the `agent_sk`. - *The `checkout_jwt` hash is used to permanently link them.* - *The `sd_hash` property of the `kb-sd-jwt` is used to bind the closed mandate to the open one* 1. The Shopping Agent passes the Payment Mandates (Open and Closed) to the Credential Provider, who verifies them and creates a payment token. - *As part of this process, the Credential Provider may share the Payment Mandate with the payment network and receive a scoped purchase credential (also called a token).* 1. The Shopping Agent sends this token and the Checkout Mandates (Open and Closed) to the Merchant. 1. The Merchant verifies the integrity and content of the closed Checkout Mandate against the current cart state, and verifies that the constraints in the open Checkout Mandate have been met. It then initiates the payment with the token, `checkout_jwt` hash, and open Checkout Mandate hash. 1. The Merchant Payment Processor verifies the included Payment Mandates in the token, as well as the bindings with the `checkout_jwt` hash and open Checkout Mandate hash. 1. The MPP-signed Payment Receipt is returned to the Shopping Agent, Credential Provider, and Network, and the Merchant-signed Checkout Receipt is returned to the Shopping Agent to indicate success. # Checkout Mandate The Checkout Mandate is a Mandate used for authorizing the completion of a checkout. ## Usage The Checkout Mandate Content is created by the Shopping Agent, rendered to the User by the Trusted Surface and verified by the Merchant. The Merchant creates a signed Checkout object which is included in closed Checkout Mandate Content. ## Type A closed Checkout Mandate MUST use the value `mandate.checkout.1` for the `vct` claim and an open Checkout Mandate MUST use the value `mandate.checkout.open.1`. See [Mandate Versioning](../specification/#mandate-versioning) for how the version suffix works. ## Mandate Schema The closed Checkout Mandate conforms to the following schema: | Name | Type | Required | Selectively Disclosable | Description | | ------------- | ------- | -------- | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | vct | string | **Yes** | No | Verifiable Credential Type claim as defined in SD-JWT. MUST be 'mandate.checkout'. | | checkout_jwt | string | **Yes** | Yes | base64url-encoded serialized merchant-signed JWT of the Checkout payload. | | checkout_hash | string | **Yes** | No | base64url-encoded hash of the checkout_jwt field value, uniquely identifying this checkout. If this checkout mandate is presented as an sd-jwt and the \_sd_alg field is present then the hash algorithm used MUST match the \_sd_alg field. Otherwise, sha-256 MUST be used. | | iat | integer | No | No | The creation timestamp as a Unix epoch. | | exp | integer | No | No | The expiration timestamp as a Unix epoch. | `checkout_hash` is the base64url-encoded hash of the value of `checkout_jwt`. The algorithm used MUST be the same as the SD-JWT, as defined by the `_sd_alg` claim in the base payload, or `sha-256` if not present. `checkout_jwt` is the merchant-signed JWT containing the details of the checkout. The details of the payload are outside the scope of this specification, when used with the [Universal Commerce Protocol](https://ucp.dev) this MUST be the Checkout object. ## Constraints The following constraints are defined in this document for use with the open Checkout Mandates: - **Allowed Merchant:** Constrains the Merchants that this Checkout Mandate can be used with. - **Line Items:** Defines the valid set of Line Items to be included in the Checkout Mandate. ### Allowed Merchants **Type**: `checkout.allowed_merchants` **Description**: Constrains the possible merchants for this Checkout Mandate. **Properties**: | Name | Type | Required | Selectively Disclosable | Description | | ------- | ------------------------------ | -------- | ----------------------- | ---------------------------------- | | type | string | **Yes** | No | Constraint type identifier. | | allowed | Array\[[Merchant](#merchant)\] | **Yes** | Yes | Array of allowed Merchant objects. | **Evaluation**: The Merchant MUST be present in the revealed elements of `allowed`. If they are not present, or if the `allowed` contains no revealed elements, the constraint is invalid. **Example** ```json { "type": "checkout.allowed_merchants", "allowed": [ {"name": "Merchant Choice", "website": "https://merchant-choice.com" }, {"name": "Second Merchant", "website": "https://second-merchant.com" }, ] } ``` ### Line Items **Type**: `checkout.line_items` **Description**: Defines the sets of line items that are to be present in the checkout_jwt. **Properties**: | Name | Type | Required | Description | | ----- | ------------------------------------------------------ | -------- | -------------------------------- | | type | string | **Yes** | Constraint type identifier. | | items | Array\[[LineItemRequirements](#lineitemrequirements)\] | **Yes** | Array of line item requirements. | **Evaluation**: This constraint is met when: - Each `items` entry in the constraint has a total quantity of matching items in the Checkout. - An item matches an `items` entry if its ID is present in the revealed `acceptable_items`. - No `items` entry or item in the Checkout may be used more than once. One way to implement this is as a maximal flow problem. The graph is defined as follows: 1. Create a node for each `items` entry. 1. Provide an edge from the source to each `items` node with a capacity equal to the quantity. 1. Create a node for each item ID in the Checkout. 1. Provide an edge from each Checkout item node to the sink with a capacity equal to the total quantity of that item ID in the checkout. 1. Provide an edge with infinite capacity between each `items` node and each Checkout item node that matches the revealed `acceptable_items` for that item. The constraint is met if the maximal flow equals the total constraint `items` quantity and the total checkout `items` quantity. > NOTE: This evaluation does not support splitting the open Checkout Mandate across multiple Checkouts. Future constraint extensions can add this support, but consideration must be given to how multiple duplicate orders can be prevented. **Example** ```json { "type": "checkout.line_items", "items": [ { "id": "id-shoe-choices", "acceptable_items": [ {"id": "BAB1234", "title": "Red Style"} {"id": "FAF1234", "title": "Blue Style"} ], "quantity": 1 }, { "id": "id-sock-choices", "acceptable_items": [ {"id": "QRT1234", "title": "The Best Socks"} ], "quantity": 1 }, ] } ``` This would be fulfilled by the following combinations: - Item: Red Style, Item: The Best Socks - Item: Blue Style, Item 3: The Best Socks But it would be invalid to have a Checkout containing: - Item: Red Style, Item: Blue Style - Item: Red Style - Item: Blue Style - Item: The Best Socks ## Checkout Receipt The Checkout Receipt conforms to the following Schema: | Name | Type | Required | Description | | ----------------- | ------------------------------- | -------- | ------------------------------------------------------------------------------------ | | status | [ReceiptStatus](#receiptstatus) | **Yes** | The status of the checkout. | | iss | string | **Yes** | The issuer of the receipt. | | iat | integer | **Yes** | The creation timestamp as a Unix epoch. | | reference | string | **Yes** | The hash of the closed Mandate that this receipt is binding to. | | error | string | No | A unique error code. Present if and only if status is Error. | | error_description | string | No | A human-readable error description. Present if and only if status is Error. | | order_id | string | No | A reference to the order for the checkout. Present if and only if status is Success. | ### ReceiptStatus The status of a receipt. **Values:** `Success`   `Error` ## Examples ### Open Checkout Mandate SD-JWT plus disclosures ```json { "issuer_signed_jwt": { "header": { "alg": "ES256", "typ": "example+sd-jwt", "kid": "agent-provider-key-1" }, "payload": { "delegate_payload": [ { "...": "QtXTJtWqg999CmUWGjHFTWMkRPguDfeK3wGSaInd-dw" } ], "_sd_alg": "sha-256" } }, "disclosures": [ { "digest": "y3aocAD2rhYpJQOUMN016faDFGkTBGEDVl1R1TRHdbw", "decoded": [ "4n3L_-3_Fm2GgyFAF8Ct_g", { "id": "supershoe_limited_edition_gold_sneaker_womens_9_0", "title": "SuperShoe Limited Edition Gold" } ] }, { "digest": "a5UMAdxCk_MRayyVdRhpIAZ0ZhjVLEq1g2BWyruKUwg", "decoded": [ "2zPL6vqLBg2WYAdbW9-1lQ", { "id": "merchant_1", "name": "Demo Merchant", "website": "https://demo-merchant.example" } ] }, { "digest": "QtXTJtWqg999CmUWGjHFTWMkRPguDfeK3wGSaInd-dw", "decoded": [ "laAoWKNRuGnwREjJWYJ7pg", { "vct": "mandate.checkout.open.1", "constraints": [ { "type": "checkout.line_items", "items": [ { "id": "line_1", "acceptable_items": [ { "...": "y3aocAD2rhYpJQOUMN016faDFGkTBGEDVl1R1TRHdbw" } ], "quantity": 1 } ] }, { "type": "checkout.allowed_merchants", "allowed": [ { "...": "a5UMAdxCk_MRayyVdRhpIAZ0ZhjVLEq1g2BWyruKUwg" } ] } ], "cnf": { "jwk": { "crv": "P-256", "kty": "EC", "x": "QpSyxPQHy38xckypDr54gZ3T42zj9iLtV4koyb5U27c", "y": "37HLd7JJinxjJIn8J7HijssoeclbfhdW-gUL7feI9lw" } }, "iat": 1777342357, "exp": 1777345957 } ] } ] } ``` #### Encoded Token ```text eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0IiwgImtpZCI6ICJhZ2VudC1wcm92aWRlci1rZXktMSJ9.eyJkZWxlZ2F0ZV9wYXlsb2FkIjogW3siLi4uIjogIlF0WFRKdFdxZzk5OUNtVVdHakhGVFdNa1JQZ3VEZmVLM3dHU2FJbmQtZHcifV0sICJfc2RfYWxnIjogInNoYS0yNTYifQ.HvCGk7ye_c0LN2-NFG13wfyu3LA--rckTPGm36ugO2aRvsded7ngw1py8W3JF7wBpoQnsKr17tNTF3zLeYcoWA~WyI0bjNMXy0zX0ZtMkdneUZBRjhDdF9nIiwgeyJpZCI6ICJzdXBlcnNob2VfbGltaXRlZF9lZGl0aW9uX2dvbGRfc25lYWtlcl93b21lbnNfOV8wIiwgInRpdGxlIjogIlN1cGVyU2hvZSBMaW1pdGVkIEVkaXRpb24gR29sZCJ9XQ~WyIyelBMNnZxTEJnMldZQWRiVzktMWxRIiwgeyJpZCI6ICJtZXJjaGFudF8xIiwgIm5hbWUiOiAiRGVtbyBNZXJjaGFudCIsICJ3ZWJzaXRlIjogImh0dHBzOi8vZGVtby1tZXJjaGFudC5leGFtcGxlIn1d~WyJsYUFvV0tOUnVHbndSRWpKV1lKN3BnIiwgeyJ2Y3QiOiAibWFuZGF0ZS5jaGVja291dC5vcGVuLjEiLCAiY29uc3RyYWludHMiOiBbeyJ0eXBlIjogImNoZWNrb3V0LmxpbmVfaXRlbXMiLCAiaXRlbXMiOiBbeyJpZCI6ICJsaW5lXzEiLCAiYWNjZXB0YWJsZV9pdGVtcyI6IFt7Ii4uLiI6ICJ5M2FvY0FEMnJoWXBKUU9VTU4wMTZmYURGR2tUQkdFRFZsMVIxVFJIZGJ3In1dLCAicXVhbnRpdHkiOiAxfV19LCB7InR5cGUiOiAiY2hlY2tvdXQuYWxsb3dlZF9tZXJjaGFudHMiLCAiYWxsb3dlZCI6IFt7Ii4uLiI6ICJhNVVNQWR4Q2tfTVJheXlWZFJocElBWjBaaGpWTEVxMWcyQld5cndLVXdnIn1dfV0sICJjbmYiOiB7Imp3ayI6IHsiY3J2IjogIlAtMjU2IiwgImt0eSI6ICJFQyIsICJ4IjogIlFwU3l4UFFIeTM4eGNreXZEcjU0Z1ozVDQyemo5aUx0VjRrb3liNVUyN2MiLCAieSI6ICIzN0hMZDdKSmlueGpKSW44SjdIaWpzc29lY0JsZmhkVy1nVUw3ZmVJOWx3In19LCAiaWF0IjogMTc3NzM0MjM1NywgImV4cCI6IDE3NzczNDU5NTd9XQ~ ``` ### Closed Checkout Mandate SD-JWT plus disclosures ```json { "issuer_signed_jwt": { "header": { "alg": "ES256", "typ": "kb+sd-jwt" }, "payload": { "delegate_payload": [ { "...": "7VLY-eKTFSShLoZRXY5jXcD2UHm1JvPmoANYRqqxy34" } ], "iat": 1777342376, "aud": "merchant", "nonce": "b9c8d7e6f5a4b3c2d1e0f9a8b7c6d5e4", "sd_hash": "FzLoxbbtgQGYZxoSM2NJYJtkFTSsdfUBoVEQ12k7JN8", "_sd_alg": "sha-256" } }, "disclosures": [ { "digest": "FzLoxbbtgQGYZxoSM2NJYJtkFTSsdfUBoVEQ12k7JN8", "decoded": [ "w-n1leFT6z8rHTNHwr5Wow", "checkout_jwt", { "header": { "alg": "ES256", "typ": "JWT" }, "payload": { "order_id": "09414145-b7bi-432e-bf5c-ha0ba0bc4580", "merchant": { "id": "merchant_1", "name": "Demo Merchant", "website": "https://demo-merchant.example" }, "line_items": [ { "id": "line_1", "product": { "id": "supershoe_limited_edition_gold_sneaker_womens_9_0", "title": "SuperShoe Limited Edition Gold — Women's 9", "price": 199.0, "currency": "USD" }, "quantity": 1 } ], "total_price": 199.0, "currency": "USD", "shipping_policy": "Standard Shipping", "return_policy": "30-day returns" } } ] }, { "digest": "7VLY-eKTFSShLoZRXY5jXcD2UHm1JvPmoANYRqqxy34", "decoded": [ "szhpxKrgGJwyqMEN9WI5Sw", { "_sd": [ "3A9UyZJofw2eMP-Lx2tYaNpCcuB8elnhwwLhZLwqFFM" ], "vct": "mandate.checkout.1", "checkout_hash": "NivWhuqfzcvZNapvIEJ2-3tsdQLkiuIcye2g46WVgX8" } ] } ] } ``` #### Encoded Token ```text eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK3NkLWp3dCJ9.eyJkZWxlZ2F0ZV9wYXlsb2FkIjogW3siLi4uIjogIjdWTFktZUtURlNTaExvWlJYWTVqWGNEMlVIbTFKdlBtb0FOWVJxcXh5MzQifV0sICJpYXQiOiAxNzc3MzQyMzc2LCAiYXVkIjogIm1lcmNoYW50IiwgIm5vbmNlIjogImI5YzhkN2U2ZjVhNGIzYzJkMWUwZjlhOGI3YzZkNWU0IiwgInNkX2hhc2giOiAiRnpMb3hiYnRnUUdZWnhvU00yTkpZSnRrRlRTc2RmVUJvVkVRMTJrN0pOOCIsICJfc2RfYWxnIjogInNoYS0yNTYifQ.lSjkli6K3NbKlWOl1gJdWDwiyL88yJVyx32ZJHmvCXfRoItnchXw-MLUDEJv7o9lmTeipS42qNt7Z_oGSnRH1w~WyJzeGhweEtyZ0dKd3lxTUVNOVdJNVN3IiwgeyJfc2QiOiBbIjNBOVV5WkpvZncyZU1QLUx4MnRZYU5wQ2N1QjhlbG5od3dMaFpMd3FRRk0iXSwgInZjdCI6ICJtYW5kYXRlLmNoZWNrb3V0LjEiLCAiY2hlY2tvdXRfaGFzaCI6ICJOaXZXaHVxZnpjdlpOYXB2SUVKMi0zdHNkUUxraXVJY3llMmc0NldWZ1g4In1d~WyJ3LW4xbGVGVDZ6OHJIVE5Id3I1V293IiwgImNoZWNrb3V0X2p3dCIsICJleUpoYkdjaU9pQWlSVk15TlRZaUxDQWlkSGx3SWpvZ0lrcFhWQ0lzSUNKcmFXUWlPaUFpYldWeVkyaGhiblF0YTJWNUxURWlmUS5leUpwWkNJNklDSXdPVFF4TkRFME5TMWlOekJpTFRRNE0yRXRZamcxWXkxaFlUQm1ZVEJqTkRVNE1EQWlMQ0FpYldWeVkyaGhiblFpT2lCN0ltbGtJam9nSW0xbGNtTm9ZVzUwWHpFaUxDQWlibUZ0WlNJNklDSkVaVzF2SUUxbGNtTm9ZVzUwSWl3Z0luZGxZbk5wZEdVaU9pQWlhSFIwY0hNNkx5OWtaVzF2TFcxbGNtTm9ZVzUwTG1WNFlXMXdiR1VpZlN3Z0lteHBibVZmYVhSbGJYTWlPaUJiZXlKcFpDSTZJQ0pzYVY4d0lpd2dJbWwwWlcwaU9pQjdJbWxrSWpvZ0luTjFjR1Z5YzJodlpWOXNhVzFwZEdWa1gyVmthWFJwYjI1ZloyOXNaRjl6Ym1WaGEyVnlYM2R2YldWdWMxODVYekFpTENBaWRHbDBiR1VpT2lBaVUzVndaWEp6YUc5bElFeHBiV2wwWldRZ1JXUnBkR2x2YmlCSGIyeGtJRk51WldGclpYSWdWMjl0Wlc1eklEa2lMQ0FpY0hKcFkyVWlPaUF4T1Rrd01IMHNJQ0p4ZFdGdWRHbDBlU0k2SURFc0lDSjBiM1JoYkhNaU9pQmJleUowZVhCbElqb2dJbk4xWW5SdmRHRnNJaXdnSW1GdGIzVnVkQ0k2SURFNU9UQXdmU3dnZXlKMGVYQmxJam9nSW5SdmRHRnNJaXdnSW1GdGIzVnVkQ0k2SURFNU9UQXdmVjE5WFN3Z0luTjBZWFIxY3lJNklDSnBibU52YlhCc1pYUmxJaXdnSW1OMWNuSmxibU41SWpvZ0lsVlRSQ0lzSUNKMGIzUmhiSE1pT2lCYmV5SjBlWEJsSWpvZ0luTjFZblJ2ZEdGc0lpd2dJbUZ0YjNWdWRDSTZJREU1T1RBd2ZTd2dleUowZVhCbElqb2dJblJ2ZEdGc0lpd2dJbUZ0YjNWdWRDSTZJREU1T1RBd2ZWMHNJQ0pzYVc1cmN5STZJRnQ3SW5SNWNHVWlPaUFpY0hKcGRtRmplVjl3YjJ4cFkza2lMQ0FpZFhKc0lqb2dJbWgwZEhCek9pOHZhSFIwY0hNdkwyUmxiVzh0YldWeVkyaGhiblF1WlhoaGJYQnNaUzl3Y21sMllXTjVJbjBzSUhzaWRIbHdaU0k2SUNKMFpYSnRjMTl2Wmw5elpYSjJhV05sSWl3Z0luVnliQ0k2SUNKb2RIUndjem92TDJoMGRIQnpMeTlrWlcxdkxXMWxjbU5vWVc1MExtVjRZVzF3YkdVdmRHOXpJbjFkZlEuUC1WS3poeUp1bzktUlBpTjVheW5naDdmTFVLY09QQWVaejczU09Zd2Q1UDlZWG1HTE9yTFRXeGdYdkd5UVF0dERETTVELUc0czE5dnhfVTY1ZHJ1UmciXQ~ ``` ### Open Checkout Mandate chained with a Closed Checkout Mandate after processing the delegate SD-JWT. ```json { "issuer_signed_jwt": { "header": { "alg": "ES256", "typ": "example+sd-jwt", "kid": "agent-provider-key-1" }, "payload": { "delegate_payload": [ { "...": "QtXTJtWqg999CmUWGjHFTWMkRPguDfeK3wGSaInd-dw" } ], "_sd_alg": "sha-256" } }, "disclosures": [ { "digest": "y3aocAD2rhYpJQOUMN016faDFGkTBGEDVl1R1TRHdbw", "decoded": [ "4n3L_-3_Fm2GgyFAF8Ct_g", { "id": "supershoe_limited_edition_gold_sneaker_womens_9_0", "title": "SuperShoe Limited Edition Gold" } ] }, { "digest": "a5UMAdxCk_MRayyVdRhpIAZ0ZhjVLEq1g2BWyruKUwg", "decoded": [ "2zPL6vqLBg2WYAdbW9-1lQ", { "id": "merchant_1", "name": "Demo Merchant", "website": "https://demo-merchant.example" } ] }, { "digest": "QtXTJtWqg999CmUWGjHFTWMkRPguDfeK3wGSaInd-dw", "decoded": [ "laAoWKNRuGnwREjJWYJ7pg", { "vct": "mandate.checkout.open.1", "constraints": [ { "type": "checkout.line_items", "items": [ { "id": "line_1", "acceptable_items": [ { "...": "y3aocAD2rhYpJQOUMN016faDFGkTBGEDVl1R1TRHdbw" } ], "quantity": 1 } ] }, { "type": "checkout.allowed_merchants", "allowed": [ { "...": "a5UMAdxCk_MRayyVdRhpIAZ0ZhjVLEq1g2BWyruKUwg" } ] } ], "cnf": { "jwk": { "crv": "P-256", "kty": "EC", "x": "QpSyxPQHy38xckypDr54gZ3T42zj9iLtV4koyb5U27c", "y": "37HLd7JJinxjJIn8J7HijssoeclbfhdW-gUL7feI9lw" } }, "iat": 1777342357, "exp": 1777345957 } ] } ] } { "issuer_signed_jwt": { "header": { "alg": "ES256", "typ": "kb+sd-jwt" }, "payload": { "delegate_payload": [ { "...": "7VLY-eKTFSShLoZRXY5jXcD2UHm1JvPmoANYRqqxy34" } ], "iat": 1777342376, "aud": "merchant", "nonce": "b9c8d7e6f5a4b3c2d1e0f9a8b7c6d5e4", "sd_hash": "FzLoxbbtgQGYZxoSM2NJYJtkFTSsdfUBoVEQ12k7JN8", "_sd_alg": "sha-256" } }, "disclosures": [ { "digest": "7VLY-eKTFSShLoZRXY5jXcD2UHm1JvPmoANYRqqxy34", "decoded": [ "szhpxKrgGJwyqMEN9WI5Sw", { "_sd": [ "3A9UyZJofw2eMP-Lx2tYaNpCcuB8elnhwwLhZLwqFFM" ], "vct": "mandate.checkout.1", "checkout_hash": "NivWhuqfzcvZNapvIEJ2-3tsdQLkiuIcye2g46WVgX8" } ] }, { "digest": "FzLoxbbtgQGYZxoSM2NJYJtkFTSsdfUBoVEQ12k7JN8", "decoded": [ "w-n1leFT6z8rHTNHwr5Wow", "checkout_jwt", { "header": { "alg": "ES256", "typ": "JWT" }, "payload": { "order_id": "09414145-b7bi-432e-bf5c-ha0ba0bc4580", "merchant": { "id": "merchant_1", "name": "Demo Merchant", "website": "https://demo-merchant.example" }, "line_items": [ { "id": "line_1", "product": { "id": "supershoe_limited_edition_gold_sneaker_womens_9_0", "title": "SuperShoe Limited Edition Gold — Women's 9", "price": 199.0, "currency": "USD" }, "quantity": 1 } ], "total_price": 199.0, "currency": "USD", "shipping_policy": "Standard Shipping", "return_policy": "30-day returns" } } ] } ] } ``` #### Encoded Token ```text eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0IiwgImtpZCI6ICJhZ2VudC1wcm92aWRlci1rZXktMSJ9.eyJkZWxlZ2F0ZV9wYXlsb2FkIjogW3siLi4uIjogIlF0WFRKdFdxZzk5OUNtVVdHakhGVFdNa1JQZ3VEZmVLM3dHU2FJbmQtZHcifV0sICJfc2RfYWxnIjogInNoYS0yNTYifQ.HvCGk7ye_c0LN2-NFG13wfyu3LA--rckTPGm36ugO2aRvsded7ngw1py8W3JF7wBpoQnsKr17tNTF3zLeYcoWA~WyI0bjNMXy0zX0ZtMkdneUZBRjhDdF9nIiwgeyJpZCI6ICJzdXBlcnNob2VfbGltaXRlZF9lZGl0aW9uX2dvbGRfc25lYWtlcl93b21lbnNfOV8wIiwgInRpdGxlIjogIlN1cGVyU2hvZSBMaW1pdGVkIEVkaXRpb24gR29sZCJ9XQ~WyIyelBMNnZxTEJnMldZQWRiVzktMWxRIiwgeyJpZCI6ICJtZXJjaGFudF8xIiwgIm5hbWUiOiAiRGVtbyBNZXJjaGFudCIsICJ3ZWJzaXRlIjogImh0dHBzOi8vZGVtby1tZXJjaGFudC5leGFtcGxlIn1d~WyJsYUFvV0tOUnVHbndSRWpKV1lKN3BnIiwgeyJ2Y3QiOiAibWFuZGF0ZS5jaGVja291dC5vcGVuLjEiLCAiY29uc3RyYWludHMiOiBbeyJ0eXBlIjogImNoZWNrb3V0LmxpbmVfaXRlbXMiLCAiaXRlbXMiOiBbeyJpZCI6ICJsaW5lXzEiLCAiYWNjZXB0YWJsZV9pdGVtcyI6IFt7Ii4uLiI6ICJ5M2FvY0FEMnJoWXBKUU9VTU4wMTZmYURGR2tUQkdFRFZsMVIxVFJIZGJ3In1dLCAicXVhbnRpdHkiOiAxfV19LCB7InR5cGUiOiAiY2hlY2tvdXQuYWxsb3dlZF9tZXJjaGFudHMiLCAiYWxsb3dlZCI6IFt7Ii4uLiI6ICJhNVVNQWR4Q2tfTVJheXlWZFJocElBWjBaaGpWTEVxMWcyQld5cndLVXdnIn1dfV0sICJjbmYiOiB7Imp3ayI6IHsiY3J2IjogIlAtMjU2IiwgImt0eSI6ICJFQyIsICJ4IjogIlFwU3l4UFFIeTM4eGNreXZEcjU0Z1ozVDQyemo5aUx0VjRrb3liNVUyN2MiLCAieSI6ICIzN0hMZDdKSmlueGpKSW44SjdIaWpzc29lY0JsZmhkVy1nVUw3ZmVJOWx3In19LCAiaWF0IjogMTc3NzM0MjM1NywgImV4cCI6IDE3NzczNDU5NTd9XQ~~eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK3NkLWp3dCJ9.eyJkZWxlZ2F0ZV9wYXlsb2FkIjogW3siLi4uIjogIjdWTFktZUtURlNTaExvWlJYWTVqWGNEMlVIbTFKdlBtb0FOWVJxcXh5MzQifV0sICJpYXQiOiAxNzc3MzQyMzc2LCAiYXVkIjogIm1lcmNoYW50IiwgIm5vbmNlIjogImI5YzhkN2U2ZjVhNGIzYzJkMWUwZjlhOGI3YzZkNWU0IiwgInNkX2hhc2giOiAiRnpMb3hiYnRnUUdZWnhvU00yTkpZSnRrRlRTc2RmVUJvVkVRMTJrN0pOOCIsICJfc2RfYWxnIjogInNoYS0yNTYifQ.lSjkli6K3NbKlWOl1gJdWDwiyL88yJVyx32ZJHmvCXfRoItnchXw-MLUDEJv7o9lmTeipS42qNt7Z_oGSnRH1w~WyJzeGhweEtyZ0dKd3lxTUVNOVdJNVN3IiwgeyJfc2QiOiBbIjNBOVV5WkpvZncyZU1QLUx4MnRZYU5wQ2N1QjhlbG5od3dMaFpMd3FRRk0iXSwgInZjdCI6ICJtYW5kYXRlLmNoZWNrb3V0LjEiLCAiY2hlY2tvdXRfaGFzaCI6ICJOaXZXaHVxZnpjdlpOYXB2SUVKMi0zdHNkUUxraXVJY3llMmc0NldWZ1g4In1d~WyJ3LW4xbGVGVDZ6OHJIVE5Id3I1V293IiwgImNoZWNrb3V0X2p3dCIsICJleUpoYkdjaU9pQWlSVk15TlRZaUxDQWlkSGx3SWpvZ0lrcFhWQ0lzSUNKcmFXUWlPaUFpYldWeVkyaGhiblF0YTJWNUxURWlmUS5leUpwWkNJNklDSXdPVFF4TkRFME5TMWlOekJpTFRRNE0yRXRZamcxWXkxaFlUQm1ZVEJqTkRVNE1EQWlMQ0FpYldWeVkyaGhiblFpT2lCN0ltbGtJam9nSW0xbGNtTm9ZVzUwWHpFaUxDQWlibUZ0WlNJNklDSkVaVzF2SUUxbGNtTm9ZVzUwSWl3Z0luZGxZbk5wZEdVaU9pQWlhSFIwY0hNNkx5OWtaVzF2TFcxbGNtTm9ZVzUwTG1WNFlXMXdiR1VpZlN3Z0lteHBibVZmYVhSbGJYTWlPaUJiZXlKcFpDSTZJQ0pzYVY4d0lpd2dJbWwwWlcwaU9pQjdJbWxrSWpvZ0luTjFjR1Z5YzJodlpWOXNhVzFwZEdWa1gyVmthWFJwYjI1ZloyOXNaRjl6Ym1WaGEyVnlYM2R2YldWdWMxODVYekFpTENBaWRHbDBiR1VpT2lBaVUzVndaWEp6YUc5bElFeHBiV2wwWldRZ1JXUnBkR2x2YmlCSGIyeGtJRk51WldGclpYSWdWMjl0Wlc1eklEa2lMQ0FpY0hKcFkyVWlPaUF4T1Rrd01IMHNJQ0p4ZFdGdWRHbDBlU0k2SURFc0lDSjBiM1JoYkhNaU9pQmJleUowZVhCbElqb2dJbk4xWW5SdmRHRnNJaXdnSW1GdGIzVnVkQ0k2SURFNU9UQXdmU3dnZXlKMGVYQmxJam9nSW5SdmRHRnNJaXdnSW1GdGIzVnVkQ0k2SURFNU9UQXdmVjE5WFN3Z0luTjBZWFIxY3lJNklDSnBibU52YlhCc1pYUmxJaXdnSW1OMWNuSmxibU41SWpvZ0lsVlRSQ0lzSUNKMGIzUmhiSE1pT2lCYmV5SjBlWEJsSWpvZ0luTjFZblJ2ZEdGc0lpd2dJbUZ0YjNWdWRDSTZJREU1T1RBd2ZTd2dleUowZVhCbElqb2dJblJ2ZEdGc0lpd2dJbUZ0YjNWdWRDSTZJREU1T1RBd2ZWMHNJQ0pzYVc1cmN5STZJRnQ3SW5SNWNHVWlPaUFpY0hKcGRtRmplVjl3YjJ4cFkza2lMQ0FpZFhKc0lqb2dJbWgwZEhCek9pOHZhSFIwY0hNdkwyUmxiVzh0YldWeVkyaGhiblF1WlhoaGJYQnNaUzl3Y21sMllXTjVJbjBzSUhzaWRIbHdaU0k2SUNKMFpYSnRjMTl2Wmw5elpYSjJhV05sSWl3Z0luVnliQ0k2SUNKb2RIUndjem92TDJoMGRIQnpMeTlrWlcxdkxXMWxjbU5vWVc1MExtVjRZVzF3YkdVdmRHOXpJbjFkZlEuUC1WS3poeUp1bzktUlBpTjVheW5naDdmTFVLY09QQWVaejczU09Zd2Q1UDlZWG1HTE9yTFRXeGdYdkd5UVF0dERETTVELUc0czE5dnhfVTY1ZHJ1UmciXQ~ ``` ## Common Types ### Item | Name | Type | Required | Description | | ----- | ------ | -------- | ----------------------------------------------------------- | | id | string | **Yes** | Unique identifier for the line item. Will often be the SKU. | | title | string | **Yes** | Title of the item. | ### LineItemRequirements | Name | Type | Required | Selectively Disclosable | Description | | ---------------- | ---------------------- | -------- | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | id | string | **Yes** | No | Identifier for the line item requirement. | | acceptable_items | Array\[[Item](#item)\] | **Yes** | Yes | Defines a set of line items that are acceptable for this line item requirement. One and only one must be present in the Checkout Mandate. | | quantity | integer | **Yes** | No | Required quantity of matching items. | ### Merchant | Name | Type | Required | Description | | ------- | ------ | -------- | ------------------------------------ | | id | string | **Yes** | Unique identifier for the merchant. | | name | string | **Yes** | Human-readable name of the merchant. | | website | string | No | Website belonging to the merchant. | # Payment Mandate The Payment Mandate is a Mandate used for authorizing the payment for a particular checkout. ## Usage The Payment Mandate Content is created by the Shopping Agent, rendered to the User by the Trusted Surface and verified by the Credential Provider, Network, and Merchant Payment Processor. ## Type A closed Payment Mandate MUST use the value `mandate.payment.1` for the `vct` claim, and an open Payment Mandate MUST use the value `mandate.payment.open.1`. See [Mandate Versioning](../specification/#mandate-versioning) for how the version suffix works. ## Mandate Schema The closed Payment Mandate conforms to the following schema: | Name | Type | Required | Description | | ------------------ | --------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | vct | string | **Yes** | Verifiable Credential Type claim as defined in SD-JWT. MUST be 'mandate.payment'. | | transaction_id | string | **Yes** | base64url-encoded hash of the checkout_jwt field value, uniquely identifying the checkout associated with this. The hash algorithm used MUST be the same as the sd_hash field for this sd-jwt, or sha256 if absent. | | payee | [Merchant](#merchant) | **Yes** | The merchant receiving the payment. | | pisp | [Pisp](#pisp) | No | The Payment Initiation Service Provider. | | payment_amount | [Amount](#amount) | **Yes** | Transaction amount object containing currency (ISO 4217 code, e.g., "USD") and amount (integer minor units per ISO 4217, e.g., 27999 = $279.99). Final value confirmed by the user. | | payment_instrument | [PaymentInstrument](#paymentinstrument) | **Yes** | The payment instrument used. | | execution_date | string | No | ISO8601 date of execution of payment. When absent indicates immediate execution. | | risk_data | object | No | An map of relevant risk signals collected by the trusted surface at time of mandate creation. | | iat | integer | No | The creation timestamp as a Unix epoch. | | exp | integer | No | The expiration timestamp as a Unix epoch. | The open Payment Mandate MAY optionally include any property from the closed Payment Mandate. ### Payment Mandate Constraints The following constraints are defined for Payment Mandates in this document: - **Agent Recurrence:** Provides conditions for the agent reusing this Payment Mandate multiple times. - **Allowed Payee:** Constrains the payee to one of a set of possible Merchants. - **Allowed Payment Instrument:** Constrains the payment instrument to one of a set of possible payment instruments. - **Allowed Payment Initiation Service Provider (PISP):** Constrains the PISP to one of a set of possible PISPs. - **Amount Range:** Constrains the amount to be within a range. - **Budget:** Provides a total amount limit. To be used with the Agent Recurrence constraint. - **Reference:** Constraints the Payment Mandate to its associated open Checkout Mandate, and Checkout Mandates chained from it. - **Execution Date:** Constrains the execution date to a specific range. ### Agent Recurrence **Type**: `payment.agent_recurrence` **Description**: Provides conditions for the agent to reuse this Payment Mandate multiple times. **Properties**: | Name | Type | Required | Description | | --------------- | ------- | -------- | -------------------------------------------------------------------------------------------------------------------------- | | type | string | **Yes** | Constraint type identifier. | | frequency | string | **Yes** | Frequency of allowed recurrences. **Enum:** `ON_DEMAND`, `DAILY`, `WEEKLY`, `BIWEEKLY`, `MONTHLY`, `QUARTERLY`, `ANNUALLY` | | max_occurrences | integer | No | Maximum number of allowed occurrences. | **Evaluation**: Evaluating the budget requires tracking the previous presentations of Payment Mandates associated with this open one. This constraint evaluates as true if the current Payment Mandate is sufficiently separated in time from the previous presentation to meet the `frequency` definition, and the `max_occurrences` limit is greater than or equal to the current occurrences. **Example** ```json { "type": "payment.agent_recurrence", "frequency": "MONTHLY", "max_occurrences": 12 } ``` ### Allowed Payees **Type**: `payment.allowed_payees` **Description**: Defines the set of possible payees for this Payment Mandate. **Properties**: | Name | Type | Required | Selectively Disclosable | Description | | ------- | ------------------------------ | -------- | ----------------------- | ---------------------------------- | | type | string | **Yes** | No | Constraint type identifier. | | allowed | Array\[[Merchant](#merchant)\] | **Yes** | Yes | Array of allowed Merchant objects. | **Evaluation**: The `payee` property of the Payment Mandate MUST be present in the `allowed` array. **Example** ```json { "type": "payment.allowed_payees", "allowed": [ { "name": "Merchant Choice", "website": "https://merchant-choice.com" } ] } ``` ### Allowed Payment Instruments **Type**: `payment.allowed_payment_instruments` **Description**: Defines the set of possible payment instruments for this Payment Mandate. **Properties**: | Name | Type | Required | Selectively Disclosable | Description | | ------- | ------------------------------------------------ | -------- | ----------------------- | ------------------------------------- | | type | string | **Yes** | No | Constraint type identifier. | | allowed | Array\[[PaymentInstrument](#paymentinstrument)\] | **Yes** | Yes | Array of allowed payment instruments. | **Evaluation**: The `payment_instrument` property of the Payment Mandate MUST be present in the `allowed` array. **Example** ```json { "type": "payment.allowed_payment_instruments", "allowed": [ { "id": "abe3c...", "type": "card", "description": "network ··· 1234" }, { "id": "zde4d...", "type": "UPI", "description": "user****@bankname" }, ] } ``` ### Allowed Payment Initiation Service Providers (PISPs) **Type**: `payment.allowed_pisps` **Description**: Defines the set of Payment Initiation Service Providers (PISPs) authorized to facilitate the transaction. **Properties**: | Name | Type | Required | Description | | ------- | ---------------------- | -------- | --------------------------- | | type | string | **Yes** | Constraint type identifier. | | allowed | Array\[[Pisp](#pisp)\] | **Yes** | Array of allowed PISPs. | **Evaluation**: The PISP facilitating the transaction MUST be present in the `allowed` array. **Example** ```json { "type": "payment.allowed_pisps", "allowed": [ { "legal_name": "Example Payment Services Ltd.", "brand_name": "ExamplePay", "domain_name": "examplepay.com" } ] } ``` ### Amount Range **Type**: `payment.amount_range` **Description**: Defines the valid range for the final amount to be within. **Properties**: | Name | Type | Required | Description | | -------- | ------- | -------- | --------------------------------------------------------------------------------- | | type | string | **Yes** | Constraint type identifier. | | currency | string | **Yes** | ISO4217 Alpha-3 currency code. | | max | integer | **Yes** | Maximum allowed amount in minor (cents) unit of currency. | | min | integer | No | Minimal amount in minor (cents) unit of currency. If absent, there is no minimum. | **Evaluation**: The `payment_amount` property of the Payment Mandate MUST be within the range defined by `min` and `max`. The `currency` property of the Payment Mandate MUST match the `currency` property of this constraint. **Example** ```json { "type": "payment.amount_range", "max": 100.50, "min": 10.00, "currency": "USD" } ``` ### Budget **Type**: `payment.budget` **Description**: Defines the maximum total amount that can be spent when using the `payment.agent_recurrence` constraint. **Properties**: | Name | Type | Required | Description | | -------- | ------ | -------- | ---------------------------------------------------- | | type | string | **Yes** | Constraint type identifier. | | max | number | **Yes** | Maximum amount for the budget. | | currency | string | **Yes** | ISO4217 Alpha-3 defining the currency of the amount. | **Evaluation**: Evaluating the budget requires tracking the total amount spent using this Payment Mandate. For this constraint to evaluate as true, the requested amount plus the total sum of amounts from previously closed Payment Mandates MUST be less than or equal to `max`. After approval, the amount MUST be added to the accumulated total for future evaluation. **Example** ```json { "type": "payment.budget", "max": 1000.00, "currency": "USD" } ``` ### Reference **Type**: `payment.reference` **Description**: Constrains this Payment Mandate for use with a particular Checkout Mandate (and its associated closed Mandates). **Properties**: | Name | Type | Required | Description | | -------------------------- | ------ | -------- | ----------------------------------------------- | | type | string | **Yes** | Constraint type identifier. | | conditional_transaction_id | string | **Yes** | Digest of the associated Open Checkout Mandate. | **Evaluation**: The Checkout Mandate for the approved order MUST contain an open Checkout Mandate with a matching hash in its delegate chain. The hash algorithm used MUST be the `_sd_alg` algorithm for the SD-JWT this constraint is in, or `sha-256` if undefined. **Example** ```json { "type": "payment.reference", "conditional_transaction_id": "A4wG4B..." } ``` ### Execution Date **Type**: `payment.execution_date` **Description**: Defines the valid time window for the payment execution. **Properties**: | Name | Type | Required | Description | | ---------- | ------ | -------- | ------------------------------ | | type | string | **Yes** | Constraint type identifier. | | not_before | string | No | Earliest valid execution date. | | not_after | string | No | Latest valid execution date. | **Evaluation**: The `execution_date` of the Payment Mandate MUST be later than or equal to `not_before` (if present) and earlier than or equal to `not_after` (if present). **Example** ```json { "type": "payment.execution_date", "not_before": "2026-03-31T00:00:00Z", "not_after": "2026-04-30T23:59:59Z" } ``` ## Payment Receipt | Name | Type | Required | Description | | ----------------------- | ------------------------------- | -------- | ------------------------------------------------------------------------------------------------------- | | status | [ReceiptStatus](#receiptstatus) | **Yes** | The status of the payment. | | iss | string | **Yes** | The issuer of the receipt. | | iat | integer | **Yes** | The creation timestamp as a Unix epoch. | | reference | string | **Yes** | The hash of the closed Mandate that this receipt is binding to. | | error | string | No | A unique error code. Present if and only if status is Error. | | error_description | string | No | A human-readable error description. Present if and only if status is Error. | | payment_id | string | **Yes** | A unique identifier for the payment. | | psp_confirmation_id | string | No | A unique identifier for the transaction confirmation at the PSP. Present only if status is Success. | | network_confirmation_id | string | No | A unique identifier for the transaction confirmation at the network. Present only if status is Success. | ### ReceiptStatus The status of a receipt. **Values:** `Success`   `Error` ## Examples ### Open Payment Mandate SD-JWT plus disclosures ```json { "issuer_signed_jwt": { "header": { "alg": "ES256", "typ": "example+sd-jwt", "kid": "agent-provider-key-1" }, "payload": { "delegate_payload": [ { "...": "3YRtZ-lBNhI_YhggShrdHhrSuDPSpwMvJ3VWjUnhDQM" } ], "_sd_alg": "sha-256" } }, "disclosures": [ { "digest": "oEH7i1gyb-zn6awwjy57LvzxkQDfD-8tvlC2XuIkgOA", "decoded": [ "s9WPt2U4GapcJsonyEb6bjg", { "id": "merchant_1", "name": "Demo Merchant", "website": "https://demo-merchant.example" } ] }, { "digest": "3YRtZ-lBNhI_YhggShrdHhrSuDPSpwMvJ3VWjUnhDQM", "decoded": [ "ZtKS5FSrIAY6HlGB4Ho7mg", { "vct": "mandate.payment.open.1", "constraints": [ { "type": "payment.amount_range", "currency": "USD", "max": 20000, "min": 0 }, { "type": "payment.allowed_payees", "allowed": [ { "...": "oEH7i1gyb-zn6awwjy57LvzxkQDfD-8tvlC2XuIkgOA" } ] }, { "type": "payment.reference", "conditional_transaction_id": "FzLoxbbtgQGYZxoSM2NJYJtkFTSsdfUBoVEQ12k7JN8" } ], "cnf": { "jwk": { "crv": "P-256", "kty": "EC", "x": "QpSyxPQHy38xckypDr54gZ3T42zj9iLtV4koyb5U27c", "y": "37HLd7JJinxjJIn8J7HijssoeclbfhdW-gUL7feI9lw" } }, "iat": 1777342357, "exp": 1777345957 } ] } ] } ``` #### Encoded Token ```text eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0IiwgImtpZCI6ICJhZ2VudC1wcm92aWRlci1rZXktMSJ9.eyJkZWxlZ2F0ZV9wYXlsb2FkIjogW3siLi4uIjogIjNZUnRaLWxCTmhJX1loZ2dTaHJkSGhyU3VEUFNwd012SjNWV2pVbmhEUU0ifV0sICJfc2RfYWxnIjogInNoYS0yNTYifQ.ZQ_5x2hYLusuUNAA2OJloeS2w3fxZRCsSvcU-wg9fK7nlMmsbpK6EPlntD8oHq5waegxsLmSL51V5hfyaQViMg~WyJzOVdQdDJVNEdhcGNKc255RWI2YmpnIiwgeyJpZCI6ICJtZXJjaGFudF8xIiwgIm5hbWUiOiAiRGVtbyBNZXJjaGFudCIsICJ3ZWJzaXRlIjogImh0dHBzOi8vZGVtby1tZXJjaGFudC5leGFtcGxlIn1d~WyJadEtTNUZTcklBWTZIbEdCNEhvN21nIiwgeyJ2Y3QiOiAibWFuZGF0ZS5wYXltZW50Lm9wZW4uMSIsICJjb25zdHJhaW50cyI6IFt7InR5cGUiOiAicGF5bWVudC5hbW91bnRfcmFuZ2UiLCAiY3VycmVuY3kiOiAiVVNEIiwgIm1heCI6IDIwMDAwLCAibWluIjogMH0sIHsidHlwZSI6ICJwYXltZW50LmFsbG93ZWRfcGF5ZWVzIiwgImFsbG93ZWQiOiBbeyIuLi4iOiAib0VIN2kxZ3liLXpuNmF3d2p5NTdMdnp4a1FEZkQtOHR2bEMyWHVJa2dPQSJ9XX0sIHsidHlwZSI6ICJwYXltZW50LnJlZmVyZW5jZSIsICJjb25kaXRpb25hbF90cmFuc2FjdGlvbl9pZCI6ICJGekxveGJidGdRR1laeG9TTTJOSllKdGtGVFNzZGZVQm9WRVExMms3Sk44In1dLCAiY25mIjogeyJqd2siOiB7ImNydiI6ICJQLTI1NiIsICJrdHkiOiAiRUMiLCAieCI6ICJRcFN5eFBRSHkzOHhja3l2RHI1NGdaM1Q0MnpqOWlMdFY0a295YjVVMjdjIiwgInkiOiAiMzdITGQ3SkppbnhqSkluOEo3SGlqc3NvZWNCbGZoZFctZ1VMN2ZlSTlsdyJ9fSwgImlhdCI6IDE3NzczNDIzNTcsICJleHAiOiAxNzc3MzQ1OTU3fV0~ ``` ### Closed Payment Mandate SD-JWT plus disclosures ```json { "issuer_signed_jwt": { "header": { "alg": "ES256", "typ": "kb+sd-jwt" }, "payload": { "delegate_payload": [ { "...": "G2DuU6IjyDkD-9ItStdsUo48C5uJqDs1E9Hf5GT3TgM" } ], "iat": 1777342370, "aud": "credential-provider", "nonce": "a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3", "sd_hash": "uixoHemmfrrCSbPREo9j-ziLuMkqExsPeWrwA-PK0Ck", "_sd_alg": "sha-256" } }, "disclosures": [ { "digest": "G2DuU6IjyDkD-9ItStdsUo48C5uJqDs1E9Hf5GT3TgM", "decoded": [ "FW6McBJImqODuhQlpI4Idw", { "vct": "mandate.payment.1", "transaction_id": "NivWhuqfzcvZNapvIEJ2-3tsdQLkiuIcye2g46WVgX8", "payee": { "id": "merchant_1", "name": "Demo Merchant", "website": "https://demo-merchant.example" }, "payment_amount": { "amount": 19900, "currency": "USD" }, "payment_instrument": { "id": "stub", "type": "card", "description": "Card ••••4242" } } ] } ] } ``` #### Encoded Token ```text eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK3NkLWp3dCJ9.eyJkZWxlZ2F0ZV9wYXlsb2FkIjogW3siLi4uIjogIkcyRHVVNklqeURrRC05SXRTdGRzVW80OEM1dUpxRHMxRTlIZjVHVDNUZ00ifV0sICJpYXQiOiAxNzc3MzQyMzcwLCAiYXVkIjogImNyZWRlbnRpYWwtcHJvdmlkZXIiLCAibm9uY2UiOiAiYThiN2M2ZDVlNGYzYTJiMWMwZDllOGY3YTZiNWM0ZDMiLCAic2RfaGFzaCI6ICJ1aXhvSGVtbWZyckNTYlBSRW85ai16aUx1TWtxRXhzUGVXcndBLVBLMENrIiwgIl9zZF9hbGciOiAic2hhLTI1NiJ9.TgI6w9zeL993uzAYE9fnAJXjnrpliDY5DpDKTSQoioH3msapVIz0Ex23ncQXwmsSmT3xOqkSpigQD1EYKck-dQ~WyJmVzZNY0JKSW1xT0R1aFFscEk0SWR3IiwgeyJ2Y3QiOiAibWFuZGF0ZS5wYXltZW50LjEiLCAidHJhbnNhY3Rpb25faWQiOiAiTml2V2h1cWZ6Y3ZaTmFwdklFSjItM3RzZFFMa2l1SWN5ZTJnNDZXVmdYOCIsICJwYXllZSI6IHsiaWQiOiAibWVyY2hhbnRfMSIsICJuYW1lIjogIkRlbW8gTWVyY2hhbnQiLCAid2Vic2l0ZSI6ICJodHRwczovL2RlbW8tbWVyY2hhbnQuZXhhbXBsZSJ9LCAicGF5bWVudF9hbW91bnQiOiB7ImFtb3VudCI6IDE5OTAwLCAiY3VycmVuY3kiOiAiVVNEIn0sICJwYXltZW50X2luc3RydW1lbnQiOiB7ImlkIjogInN0dWIiLCAidHlwZSI6ICJjYXJkIiwgImRlc2NyaXB0aW9uIjogIkNhcmQgXHUyMDIyXHUyMDIyXHUyMDIyNDI0MiJ9fV0~ ``` ### Open Payment Mandate chained with a closed Payment Mandate after processing the delegate SD-JWT. ```json { "issuer_signed_jwt": { "header": { "alg": "ES256", "typ": "example+sd-jwt", "kid": "agent-provider-key-1" }, "payload": { "delegate_payload": [ { "...": "3YRtZ-lBNhI_YhggShrdHhrSuDPSpwMvJ3VWjUnhDQM" } ], "_sd_alg": "sha-256" } }, "disclosures": [ { "digest": "oEH7i1gyb-zn6awwjy57LvzxkQDfD-8tvlC2XuIkgOA", "decoded": [ "s9WPt2U4GapcJsonyEb6bjg", { "id": "merchant_1", "name": "Demo Merchant", "website": "https://demo-merchant.example" } ] }, { "digest": "3YRtZ-lBNhI_YhggShrdHhrSuDPSpwMvJ3VWjUnhDQM", "decoded": [ "ZtKS5FSrIAY6HlGB4Ho7mg", { "vct": "mandate.payment.open.1", "constraints": [ { "type": "payment.amount_range", "currency": "USD", "max": 20000, "min": 0 }, { "type": "payment.allowed_payees", "allowed": [ { "...": "oEH7i1gyb-zn6awwjy57LvzxkQDfD-8tvlC2XuIkgOA" } ] }, { "type": "payment.reference", "conditional_transaction_id": "FzLoxbbtgQGYZxoSM2NJYJtkFTSsdfUBoVEQ12k7JN8" } ], "cnf": { "jwk": { "crv": "P-256", "kty": "EC", "x": "QpSyxPQHy38xckypDr54gZ3T42zj9iLtV4koyb5U27c", "y": "37HLd7JJinxjJIn8J7HijssoeclbfhdW-gUL7feI9lw" } }, "iat": 1777342357, "exp": 1777345957 } ] } ] } { "issuer_signed_jwt": { "header": { "alg": "ES256", "typ": "kb+sd-jwt" }, "payload": { "delegate_payload": [ { "...": "G2DuU6IjyDkD-9ItStdsUo48C5uJqDs1E9Hf5GT3TgM" } ], "iat": 1777342370, "aud": "credential-provider", "nonce": "a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3", "sd_hash": "uixoHemmfrrCSbPREo9j-ziLuMkqExsPeWrwA-PK0Ck", "_sd_alg": "sha-256" } }, "disclosures": [ { "digest": "G2DuU6IjyDkD-9ItStdsUo48C5uJqDs1E9Hf5GT3TgM", "decoded": [ "FW6McBJImqODuhQlpI4Idw", { "vct": "mandate.payment.1", "transaction_id": "NivWhuqfzcvZNapvIEJ2-3tsdQLkiuIcye2g46WVgX8", "payee": { "id": "merchant_1", "name": "Demo Merchant", "website": "https://demo-merchant.example" }, "payment_amount": { "amount": 19900, "currency": "USD" }, "payment_instrument": { "id": "stub", "type": "card", "description": "Card ••••4242" } } ] } ] } ``` #### Encoded Token ```text eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0IiwgImtpZCI6ICJhZ2VudC1wcm92aWRlci1rZXktMSJ9.eyJkZWxlZ2F0ZV9wYXlsb2FkIjogW3siLi4uIjogIjNZUnRaLWxCTmhJX1loZ2dTaHJkSGhyU3VEUFNwd012SjNWV2pVbmhEUU0ifV0sICJfc2RfYWxnIjogInNoYS0yNTYifQ.ZQ_5x2hYLusuUNAA2OJloeS2w3fxZRCsSvcU-wg9fK7nlMmsbpK6EPlntD8oHq5waegxsLmSL51V5hfyaQViMg~WyJzOVdQdDJVNEdhcGNKc255RWI2YmpnIiwgeyJpZCI6ICJtZXJjaGFudF8xIiwgIm5hbWUiOiAiRGVtbyBNZXJjaGFudCIsICJ3ZWJzaXRlIjogImh0dHBzOi8vZGVtby1tZXJjaGFudC5leGFtcGxlIn1d~WyJadEtTNUZTcklBWTZIbEdCNEhvN21nIiwgeyJ2Y3QiOiAibWFuZGF0ZS5wYXltZW50Lm9wZW4uMSIsICJjb25zdHJhaW50cyI6IFt7InR5cGUiOiAicGF5bWVudC5hbW91bnRfcmFuZ2UiLCAiY3VycmVuY3kiOiAiVVNEIiwgIm1heCI6IDIwMDAwLCAibWluIjogMH0sIHsidHlwZSI6ICJwYXltZW50LmFsbG93ZWRfcGF5ZWVzIiwgImFsbG93ZWQiOiBbeyIuLi4iOiAib0VIN2kxZ3liLXpuNmF3d2p5NTdMdnp4a1FEZkQtOHR2bEMyWHVJa2dPQSJ9XX0sIHsidHlwZSI6ICJwYXltZW50LnJlZmVyZW5jZSIsICJjb25kaXRpb25hbF90cmFuc2FjdGlvbl9pZCI6ICJGekxveGJidGdRR1laeG9TTTJOSllKdGtGVFNzZGZVQm9WRVExMms3Sk44In1dLCAiY25mIjogeyJqd2siOiB7ImNydiI6ICJQLTI1NiIsICJrdHkiOiAiRUMiLCAieCI6ICJRcFN5eFBRSHkzOHhja3l2RHI1NGdaM1Q0MnpqOWlMdFY0a295YjVVMjdjIiwgInkiOiAiMzdITGQ3SkppbnhqSkluOEo3SGlqc3NvZWNCbGZoZFctZ1VMN2ZlSTlsdyJ9fSwgImlhdCI6IDE3NzczNDIzNTcsICJleHAiOiAxNzc3MzQ1OTU3fV0~~eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK3NkLWp3dCJ9.eyJkZWxlZ2F0ZV9wYXlsb2FkIjogW3siLi4uIjogIkcyRHVVNklqeURrRC05SXRTdGRzVW80OEM1dUpxRHMxRTlIZjVHVDNUZ00ifV0sICJpYXQiOiAxNzc3MzQyMzcwLCAiYXVkIjogImNyZWRlbnRpYWwtcHJvdmlkZXIiLCAibm9uY2UiOiAiYThiN2M2ZDVlNGYzYTJiMWMwZDllOGY3YTZiNWM0ZDMiLCAic2RfaGFzaCI6ICJ1aXhvSGVtbWZyckNTYlBSRW85ai16aUx1TWtxRXhzUGVXcndBLVBLMENrIiwgIl9zZF9hbGciOiAic2hhLTI1NiJ9.TgI6w9zeL993uzAYE9fnAJXjnrpliDY5DpDKTSQoioH3msapVIz0Ex23ncQXwmsSmT3xOqkSpigQD1EYKck-dQ~WyJmVzZNY0JKSW1xT0R1aFFscEk0SWR3IiwgeyJ2Y3QiOiAibWFuZGF0ZS5wYXltZW50LjEiLCAidHJhbnNhY3Rpb25faWQiOiAiTml2V2h1cWZ6Y3ZaTmFwdklFSjItM3RzZFFMa2l1SWN5ZTJnNDZXVmdYOCIsICJwYXllZSI6IHsiaWQiOiAibWVyY2hhbnRfMSIsICJuYW1lIjogIkRlbW8gTWVyY2hhbnQiLCAid2Vic2l0ZSI6ICJodHRwczovL2RlbW8tbWVyY2hhbnQuZXhhbXBsZSJ9LCAicGF5bWVudF9hbW91bnQiOiB7ImFtb3VudCI6IDE5OTAwLCAiY3VycmVuY3kiOiAiVVNEIn0sICJwYXltZW50X2luc3RydW1lbnQiOiB7ImlkIjogInN0dWIiLCAidHlwZSI6ICJjYXJkIiwgImRlc2NyaXB0aW9uIjogIkNhcmQgXHUyMDIyXHUyMDIyXHUyMDIyNDI0MiJ9fV0~ ``` ## Common Types ### Amount | Name | Type | Required | Description | | -------- | ------- | -------- | ---------------------------------------------------------- | | amount | integer | **Yes** | Amount in minor units, according to the ISO-4217 spec. | | currency | string | **Yes** | ISO-4217 3-letter alphabetic currency code of the payment. | ### Merchant | Name | Type | Required | Description | | ------- | ------ | -------- | ------------------------------------ | | id | string | **Yes** | Unique identifier for the merchant. | | name | string | **Yes** | Human-readable name of the merchant. | | website | string | No | Website belonging to the merchant. | ### PaymentInstrument | Name | Type | Required | Description | | ----------- | ------ | -------- | ------------------------------------------------------------------------------------ | | id | string | **Yes** | unique identifier for this instrument | | type | string | **Yes** | unique string identifying this category of instrument | | description | string | No | Description of the instrument to be displayed to the user for informational purposes | ### Pisp | Name | Type | Required | Description | | ----------- | ------ | -------- | ------------------------------------------------------------------------------ | | legal_name | string | **Yes** | Legal name of the PISP. | | brand_name | string | **Yes** | Brand name of the PISP. | | domain_name | string | **Yes** | Domain name of the PISP as secured by the [eIDAS] QWAC certificate of the TPP. | # Security and Privacy Considerations ## Security Considerations Agentic commerce introduces numerous potential security risks. Given the current state of agent security, AP2 assumes that preventing prompt injection attacks is infeasible. Therefore, all LLMs and Agents MUST be considered potential attackers and are explicitly included in the threat model. ### Manipulated Checkout **Threat:** - An attacker steals a signed and authorized Payment Mandate to use it with an unrelated Checkout. **Mitigation** - The Payment Mandate MUST contain a reference to its associated Checkout. - This is via `transaction_id` for closed Payment Mandates and the `mandate.payment.reference` constraint for open ones. **Threat:** - An attacker reuses an open Payment Mandate with a different closed Payment Mandate. - An attacker reuses an open Payment Mandate to approve a different closed Checkout Mandate. **Mitigation** - Closed Mandates MUST contain the `sd_hash` claim to bind them to the presented open Mandate. - Open Mandates MUST contain the Agent's key (via a `cnf` claim) so that only the agent could create a Closed Mandate with a valid signature. **Threat:** - An attacker mismatches a closed Mandate with a different open Mandate. **Mitigation** - Closed Mandates MUST contain the `sd_hash` claim to bind them to the presented open Mandate. **Threat:** - An attacker uses a closed Checkout Mandate with a different checkout session. **Mittigation** - Merchant MUST verify that `checkout_hash` matches the hash of the latest `checkout_jwt`. ### Manipulated Payment **Threat:** - A Shopping or Credential Provider Agent manipulates the Payment in transit, or requests payment without (or differing from) the User's approved Mandate. This causes the Credential Provider to execute a Payment not approved by the Trusted Surface. **Mitigation:** - The Merchant Payment Processor and Credential Provider MUST verify the User's signature on the Payment Mandate to ensure its integrity. - The `checkout_hash` embedded in the `transaction_id` securely links the payment to the associated Checkout Mandate. - Constraint evaluation ensures the payment amounts and payees comply with the authorized limits. ### Payment Credential Theft **Threat:** - An attacker steals the User's Payment Credential or Token after its release to perform a payment in an unauthorized context. **Mitigation:** - The Payment Credential/Token MUST ONLY be released to the Merchant upon the receipt and verification of a final Payment Mandate. This binds the token to the specific transaction. ### Manipulated Discovery **Threat:** - Prompt injection causes the Shopping Agent to select malicious products or make poor purchase decisions. **Mitigation:** - The Merchant signature ensures the integrity of the offering. - Even if the LLM fails to make the optimal choice, constraint enforcement during closed Mandate verification ensures that the worst-case financial and logical impacts are strictly bounded. ### Double Spend **Threat:** - A prompt injected, or otherwise malicious Shopping Agent attempts to approve multiple valid Checkouts using the same open Mandate. **Mitigation:** - The non-deterministic portion of the Shopping Agent MUST avoid signing multiple, overlapping closed Mandates for the same open Mandate without receiving Receipts rejecting the previously released Mandates. - These Receipts MUST be integrity protected from the Shopping Agent's LLM. - Credential Provider, Networks or MPPs MAY reject multiple overlapping Mandates, or invalidate previously issued payment tokens. ## Privacy Considerations ### Open Checkout and Payment Mandate Constraints Open Checkout and Payment Mandate Constraints MAY contain information that is not applicable to the particular Checkout that would leak unnecessary user intent. Selective Disclosure MUST be used to preserve user privacy. To enhance user privacy the Trusted Surface MAY insert decoy digests as described in RFC9901 Section 4.2.5. ### Checkout and Payment Data Minimization To preserve user privacy and the principle of data minimization, Selective Disclosure is used to allow the Checkout Mandate and Payment Mandate to be shared with the relevant parties for securing the Checkout and Payment respectively. The `checkout_hash` links these Mandates allowing them to be joined in the case of a Dispute. > Note: The information contained within the Mandates, or the Mandates themselves could be shared with other parties if appropriate agreements or channels exist, but that is outside the scope of AP2. ### Rainbow Table Attacks Digests in SD-JWTs (for Payment and Checkout Mandates as well as Constraints) MUST include a salt with sufficient entropy to prevent guessing the plaintext. See RFC9901 Section 9.1. For more details. The `checkout_hash` makes use of the entropy already included in the JWT signature to prevent guessing the Checkout contents. If a signing algorithm (e.g. deterministic signature scheme such as `Ed25519`) is used that does not include this then a salt of sufficient entropy MUST be present in the Checkout. # Implementation Considerations ## Roles Below describes what each role needs to care about and examples of how this role might be implemented in the payment ecosystem. ### Merchant The Merchant needs to implement the following: - Provide a Catalog and Checkout endpoints to the Shopping Agent to allow it to perform a commerce protocol, for example as described by the [Universal Commerce Protocol](https://ucp.dev/). - Generate a signed Checkout JWT. - Verify the [Checkout Mandate](../checkout_mandate/) - Or delegate this to a technology provider (such as the MPP). - Complete the Checkout with the Merchant Payment Processor using the Checkout Mandate hash and `payment_token` (scoped to the Payment Mandate). - Or implement this MPP role themselves. - Generate a signed [Checkout Receipt](../checkout_mandate/#checkout-receipt) with appropriate status and return it to the Shopping Agent. Some examples of how the Merchant role could be structured: - Merchant with UCP endpoints. - A Merchant Agent that communicates over agent-to-agent (a2a) with the Shopping Agent, and then to the Merchant backend via UCP. - Combined Merchant and Merchant Payment Processor. - A Merchant with delegated Checkout Mandate verification. - Here the Merchant would provide the Checkout Mandate to a technology provider for verification, and proceed if verification passes. ### Merchant Payment Processor The Merchant Payment Processor needs to implement the following: - Receive the payment token from the Merchant - Verify the [Payment Mandate](../payment_mandate/) in the payment token. - Generate a signed [Payment Receipt](../payment_mandate/#payment-receipt), which is made available to the Shopping Agent, Credential Provider and Network. - Process or verify payment ### Shopping Agent The Shopping Agent needs to implement the following: - Agentic Shopping to determine user intent. - Selecting a payment instrument from a Credential Provider. - Creation of Checkout and Payment Mandate Content. - Obtaining signed Checkout and Payment Mandates via a Trusted Surface. - Present the [Payment Mandate](../payment_mandate/) to the Credential Provider to get the payment token. This involves: - Selecting the appropriate Mandate from storage. - Key-binding with an Agent key (as needed). - Data minimization through Selective Disclosure. - Preventing double spend and handling receipt management. - Presenting the [Checkout Mandate](../checkout_mandate/) to the Merchant as part of completing the Checkout. This involves: - Selecting the appropriate Mandate from storage. - Key-binding with an Agent key (as needed). - Data minimization through Selective Disclosure. - Preventing double spend and handling receipt management. - Receiving Receipts and handling success and error. ### Credential Provider The Credential Provider needs to implement the following: - Providing payment instruments to the Shopping Agent. - Verify the [Payment Mandate](../payment_mandate/). - Obtaining the payment token from the network using the Payment Mandate, or initiate sending of funds to the merchant. - Releasing the payment token or funding reference number. - Receiving and storing the [Payment Receipt](../payment_mandate/#payment-receipt). Examples of how the Credential Provider role can be implemented: - A user's digital Wallet, or payment network that the Shopping Agent links with. - A store of payment instruments provided by the Shopping Agent directly. - A store of Payment instruments provided by the Merchant. ### Trusted Surface The Trusted Surface represents UI that is trusted by all parties to obtain authorization and consent from the end user. It is responsible for: - Displaying Checkout and Payment Mandate Content to the User. - Obtaining user authorization and consent. - Creating signed Checkout and Payment Mandates and delegating them to the Shopping Agent. This role can be played by a lot of different entities. Some examples include: - A deterministic part of the Shopping Agent application. - A standalone User Wallet, or Issuer application. - Trusted User Agents (such as mobile Platforms or Browsers). ## Agent Identification AP2 is designed to constrain Agent behaviors without them having to be inherently trustworthy. As part of implementing a Commerce Protocol, Merchants or Trusted Surfaces MAY wish to only work with trusted Agents. These details are left to the Commerce Protocol layer. ## Hashes When calculating hashes it is important that the same representation is used. This is typically achieved by providing the base64url encoded representation of JSON structures. For dispute resolution this will mean storing the SD-JWTs, along with their disclosures, for the Mandates in their compact serialization. This is to allow easy computation of the `sd_hash`, `checkout_hash`, and Receipt `reference`. For consistency, the same hashing algorithm is required for both the SD-JWT digests and `checkout_hash`. ## Agent Key One important portion of the Autonomous flows is the Agent's key. This is used to transaction-bind the open Mandates and prevent their re-use. It is also used to prevent double spend by preventing the release of overlapping closed Mandates. One way to implement this is through tool calling, where deterministic code verifies the closed Mandate being created before being signed. This responsibility could also be delegated by the Shopping Agent to a technology provider. ## Mandate Management As Mandates are long-lived, the Shopping Agent SHOULD provide a mechanism to manage active Mandates (along with the tasks they are being used in). Limiting the duration of active Mandates, and providing notifications to the User, even when executing autonomously, is important to keep the User in control of their Shopping Agent. In the case of external Trusted Surfaces it could make sense to allow for management of delegated Mandates but that is outside the scope of this specification. # Agent Authorization Due to their non-deterministic processes, even well-behaving Agents need to have their behavior tightly constrained above what a normal authorization model would require of human users. In this document we provide a model for Agentic Authorization to provide clarity to the final Verifier as to what the User approved the Agent to do. AP2 makes use of this model for the payments use case, but the model could be applied more generally in the future. The authorization process is broken into two steps: - **Mandate Delegation**: A User authorizes an Agent to perform some action (or actions) on their behalf. This is done by having the User approve the Mandate Content on a Trusted Surface and delegate the resulting Mandate to the Agent. - **Action Authorization**: Here a Verifier challenges an Agent to provide proof that it is authorized to perform an action on behalf of a User. The Agent does so by presenting a relevant Mandate to the Verifier. Upon completion, the Verifier returns the Agent a Receipt. Mandate Delegation Action Authorization ## Mandate Delegation Mandate Delegation is performed as follows: - The Agent creates Mandate Content that it wishes to be authorized by the User. - The User is shown the Mandate Content on a Trusted Surface. - After authorization and consent from the user, a Mandate is created and passed back to the Agent. - The Agent stores the Mandate for future use. This document defines the following models for Mandate Delegation: - User Credential - Trusted Agent Provider The User Credential approach makes use of an Issuer external to the Agent that the Verifier trusts to guarantee the Trusted Surface. This has the benefit of a single User Credential being able to delegate Mandates to many different Agents, without the Verifier needing to have an explicit trust relationship with each Agent. The Trusted Agent Provider approach makes the provider of the Agent the party trusted by the Verifier. This allows for a simpler trust model, but requires Verifiers to establish trust with every Agent Provider. An Agent Provider could also be an Issuer of User Credentials, blending the two approaches. > NOTE: In the future, other approaches to establishing trust in the Delegated Mandates can be explored. The Mandate Content itself functions independent of the means used to establish trust in its integrity. > > Some other models include a directly trusted user key, rather than a full credential, such as a passkey or hardware-attested key. ### User Credential This is a three-party model involving: - The User Credential Issuer - The Trusted Surface as a Holder of the User Credential - The Agent In this model, the Issuer of the User Credential is being trusted by the Verifier to ensure that the Trusted Surface constructs Mandates only after obtaining appropriate user consent and authorization. Mandate Delegation: User Credential In advance of this flow, the Issuer issues the User Credential to the Holder. The mechanism for issuance is outside the scope of this document; one standard approach can be seen in the [OpenID4VCI](#references) specification. This model performs the creation and delegation of the mandate as part of the presentation of a User's VDC. > NOTE: While this document specifies using OpenID4VP with SD-JWT VCs, other VDC formats such as [ISO mDocs (ISO18013-5)](#references) and protocols such as [18013-7 Annex C](#references) could be made to fulfill the same role. #### Delegation using OpenID4VP [OpenID4VP](#references) provides a standard protocol for presenting VDCs from a holder to a verifier. One feature of the protocol is `transaction_data`, which allows additional information to be approved and signed by the holder of the digital credential. To perform User Credential Delegation with OpenID4VP, the Agent constructs an Authorization Request where the `transaction_data` array contains base64url-encoded JSON objects. The mandate delegation object MUST contain the following properties before encoding: - **type**: **REQUIRED**. MUST be the string value "*delegate*". - **format**: **REQUIRED**. The required VDC format of the returned Mandate. - **delegate_payload**: **REQUIRED**. An array containing the Mandate Content payloads as JSON Objects. - **delegate_disclosures**: **OPTIONAL**. An array that contains any Selective Disclosures in the `delegate_payload`. When constructing the Authorization Response, the `delegate_payload` MUST be included as part of the Key Binding. See [Delegate SD-JWT](#references) for details. Other fields in the Authorization Request MAY be set as normal, such as using the DCQL query to specify the required User Credential. It is RECOMMENDED to use the Digital Credentials API for delegation with OpenID4VP where available to provide higher security and the best quality user experience. Below is a non-normative example of an OpenID4VP Authorization Request to delegate Checkout and Payment Mandates. Base64url-encoded strings are truncated for readability. ```json { "requests": [ { "protocol": "openid4vp-v1-unsigned", "data": { "response_type": "vp_token", "response_mode": "dc_api", "nonce": "b5d4e074-dff5-4cd5-a506-f09dd6f2e33a", "dcql_query": { "credentials": [ { "id": "dpc_credential", "format": "dc+sd-jwt", "meta": { "vct_values": ["com.emvco.dpc"] }, "claims": [ { "path": ["card_last_four"] }, { "path": ["card_network_code"] }, { "path": ["credential_id"] } ] } ] }, "transaction_data": [ "eyJ0eXBlIjoicGF5bWVudF9jYXJkIiwiY3JlZ......5MDBcIn0ifQ==", "eyJ0eXBlIjoiZGVsZWdhdGUiLCJmb3JtYXQiO......aGEtMjU2Il19" ], "client_metadata": { "client_id_scheme": "x509_san_dns", "vp_formats": { "dc+sd-jwt": { "sd-jwt_alg_values": ["ES256"], "kb-jwt_alg_values": ["ES256"] } } } } } ] } ``` **Decoded `transaction_data` Payloads (Informative)** The `transaction_data` array contains two base64url-encoded JSON objects: **Index 0 — Payment Card (UI Data)**: Defines the confirmation UI displayed to the user before they approve the payment. ```json { "type": "payment_card", "credential_ids": ["dpc_credential"], "transaction_data_hashes_alg": ["sha-256"], "merchant_name": "Generic Merchant", "amount": "USD 150.00", "additional_info": "{\"title\":\"Please confirm your purchase details...\",\"tableHeader\":[\"Name\",\"Qty\",\"Price\",\"Total\"],\"tableRows\":[[\"Adult Holland Lop Rabbit\",\"1\",\"150.00\",\"150.00\"]],\"footer\":\"Your total is 150.00\"}" } ``` **Index 1 — Delegate (Cryptographic Mandates)**: Binds the payment to the specific Checkout and Payment Mandate content via the `delegate_payload`. ```json { "type": "delegate", "format": "dc+sd-jwt", "credential_ids": ["dpc_credential"], "transaction_data_hashes_alg": ["sha-256"], "delegate_payload": [ { "vct": "mandate.checkout.1", "checkout_jwt": "eyJhbGciOiJFUzI1NiIs...", "checkout_hash": "3WiKMabE8NRYJgveUbyAZ3pBqRfPrWwGDbOyvbO1eYA", "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "use": "sig", "x": "c09-Eo2PvuO6VrfzLAxTZXBa3ZWkBaa0pR2jcOYKlw", "y": "gRETv5wMvNiZJqckokCyDAjIIEg3Y2m77VryMvS75Ww" } } }, { "vct": "mandate.payment.1", "transaction_id": "3WiKMabE8NRYJgveUbyAZ3pBqRfPrWwGDbOyvbO1eYA", "payment_amount": { "amount": 15000, "currency": "USD" }, "payee": { "id": "merchant_1", "name": "Generic Merchant", "website": "https://demo-merchant.example" }, "payment_instrument": { "id": "b3f1c8a2-6d4e-4f9a-9e3d-8a7c2f1b9d34", "type": "dpc", "description": "DPC ···· 4444" } } ] } ``` Below is a non-normative OpenID4VP Authorization Response containing the user-signed Checkout and Payment Mandates. Long strings have been truncated for readability. ```json { "protocol": "openid4vp-v1-unsigned", "data": { "vp_token": { "dpc_credential": [ "eyJhbGci......jA~WyJiWk5w......Q~WyJCdThH......Q~WyJNUThs......Q~eyJ0eXAi......jZ" ] } } } ``` The `dpc_credential` is a `~`-separated SD-JWT. The decoded components are: **Core SD-JWT Payload (Issuer Credential)** ```json { "iss": "https://digital-credentials.dev", "vct": "com.emvco.dpc", "iat": 1683000000, "exp": 1883000000, "_sd_alg": "sha-256", "_sd": [ "0ygSIMbyCz_SAL7CrZeDg_C3AnqJVgf35I1t1ie0RZs", "1ipSejAAw_lASOeNsGbj3R_3MZNRtalgU9MYvc73Z5g", "3d_ksLaY7NAyu9PQZodRB4XsqF2jquCsl2avOlnWCn8", "PBhW42ATJqcs3_odVhHuTGEDhN7idDmZMLLORR-lAec" ], "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "8jBWriuJBY--u__2jOJfcX4Jj4kEqY4CUX9cf1bQddY", "y": "csH2kOGhlemhRRuPUYFKJYZgVqEXQh2JfotRKGRMfLE" } } } ``` **Selective Disclosures** (Only the three claims requested by the merchant are revealed; remaining fields stay hidden in the undisclosed `_sd` hashes): ```json [ ["bZNpmTeoL5tYU7gKTVkTUA", "card_last_four", "4444"], ["Bu8Gie949nAgBdL6B657Mw", "card_network_code", "ACME"], ["MQ8lrNkAwYlavMT8own4DA", "credential_id", "b3f1c8a2-6d4e-4f9a-9e3d-8a7c2f1b9d34"] ] ``` Multiple Mandate Delegations MAY be requested in a single Authorization Request by providing multiple elements in the `delegate_payload` array. ### Trusted Agent Provider In this model, the Agent Provider is being trusted by Verifiers directly to construct Mandates only after obtaining appropriate user consent and authorization. This model does not require a pre-issued credential. The following steps occur: Mandate Delegation: Trusted Agent Provider - The Agent constructs the Mandate Content and passes it to a Trusted Surface controlled by the Agent Provider. - *For example another, deterministic, part of their application.* - The Agent Provider’s Trusted Surface displays the Mandate Content to the user and obtains any necessary user authorization and consent. - The Agent Provider uses a securely stored signing key to create the Mandate. - *For example, by having the Trusted Surface communicate with the Agent Provider backend to have the mandate signed.* The Agent Provider MUST ensure that the Agent is not able to access the Agent Provider signing key, or use it without the Trusted Surface. See Security and Privacy Considerations for more details of the risks. Below is a non-normative example of an Agent Provider creating a Checkout Mandate as an `sd-jwt-vc` payload. *Decoded Top-Level Payload:* ```json { "iss": "https://agent-provider.example.com", "vct": "com.example.agent_mandate", "iat": 1777326189, "_sd_alg": "sha-256", "delegate_payload": [ { "...": "4UrKesfj0IT5_OE7zLYlXHkAwPbC3JvJgIxku3uq0EE" } ] } ``` *Decoded Disclosure (The Open Mandate):* The hash ending in `uq0EE` reveals the mandate. Notice how the acceptable items and allowed merchants are also hidden behind hashes inside the constraints array: ```json [ "8rGxzvzfSEW7fw4nb_dYx_w", { "vct": "mandate.checkout.open.1", "cnf": { "jwk": { "crv": "P-256", "kty": "EC", "x": "7MAQoKtK...", "y": "i3OUjGXe..." } }, "iat": 1777326189, "exp": 1777329789, "constraints": [ { "type": "checkout.line_items", "items": [ { "id": "line_1", "quantity": 1, "acceptable_items": [ { "...": "LqZRRzN7nzxJCVf0kP5OvvWvits5CcATHkoq_xGoz8s" } ] } ] }, { "type": "checkout.allowed_merchants", "allowed": [ { "...": "UZSGFNQpapJSRQLCeVDfqGzfMCUiJvLL80_kcDai_OI" } ] } ] } ] ``` *Decoded Disclosures (Nested Array Items):* The Agent can selectively disclose the specific line item and merchant authorized by the constraints array above: ```json [ "vK5dz2nnVpgtoC9dZy9uHw", { "id": "supershoe_limited_edition_gold_sneaker_womens_9_0", "title": "SuperShoe Limited Edition Gold" } ] ``` ```json [ "NAhMECHMBjd978UDQqsAYA", { "id": "merchant_1", "name": "Demo Merchant", "website": "https://demo-merchant.example" } ] ``` ## Mandate Structure Mandates form a cryptographically verifiable chain from the original user-approved Mandate through to the closed Mandate used to authorize a particular Verifier’s action. Mandates can be thought of being in two states: - **Closed**: When the Mandate is bound to a particular transaction with a Verifier to authorize the agent to perform an action. This is achieved by the Agent generating a Key Binding JWT (Proof-of-Possession) using the key endorsed in the open Mandate's `cnf` claim. - **Open**: When the Mandate has not yet been bound to a particular transaction. It instead has a set of constraints on the valid content for the closed Mandate, as well as being bound to a particular Agent who is allowed to use the Mandate. Open Mandates are necessary to allow the Agent to perform autonomous actions on the User’s behalf, while still appropriately constraining their behavior. Example: Mandate Chains The above diagram illustrates two examples of a Mandate providing human authorization of the same action (doX with A). In the ‘Human Present’ case, the User directly signs closed Mandate Content, while in the second case, the User signs open Mandate Content. The Agent then signs closed Mandate Content on the user’s behalf, and provides the entire Mandate chain to demonstrate the authorization. Because Open Mandates need to be bound to a particular transaction before use, they MUST support cryptographic Key Binding. ### Mandates using SD-JWT VCs [SD-JWT](#references)s provide a convenient structure for cryptographically securing JSON and a number of useful properties for Mandates: - The Key Binding mechanism allows for the Agent to provide Proof-of-Possession and transaction binding when the user is no longer present. - Selective Disclosure can be used to preserve User privacy while providing the Agent flexibility in decision making by only disclosing the applicable parts of the constraint. > NOTE: While this document uses SD-JWT VCs, other VDCs such as ISO mDocs COULD be used in their place. The Mandate Content for SD-JWTs contains the following claims: - *vct*: **REQUIRED**. A String uniquely identifying the Mandate Type, in addition to the credential type. - *constraints*: **OPTIONAL**. An array of extensible Objects providing Constraints on what is allowed to be present in the closed Mandate. - *type*: **REQUIRED**. A unique String identifying this constraint. - Other properties are present based on the constraint type. - *cnf*: **OPTIONAL**. Contains the confirmation method identifying the Proof-of-Possession key as defined in [RFC7800](#references). This claim is **REQUIRED** if the Mandate is still open. Other properties MAY be included in the Mandate based on the Mandate Type. A Mandate that is still open is NOT REQUIRED to have all of the required fields of a particular Mandate Type, but the eventually closed Mandate MUST include them. Additionally, any claim in SD-JWT-VC MAY also be used. The AP2 specification provides mandate types and constraint types for use with payments. New mandate types and new constraint types MAY be defined in addition to these to meet other use cases. It is RECOMMENDED to use a collision-resistant naming approach, for example via a rDNS prefix controlled by the specifying entity, or an appropriate URN. #### Verification and Processing Rules The verification and processing rules for a chain of SD-JWT mandates are as follows: 1. Verify and process the SD-JWT chain according to [Delegate SD-JWT](#references). 1. Extract claims from open Mandate Content and verify the closed Mandate Content has these values unchanged. 1. Extract each Constraint from each open Mandate Content and evaluate them against the closed Mandate Content based on the Constraint Type. - Any unknown Constraints MUST be treated as failing evaluation. ## Action Authorization Action Authorization happens between an Agent and a Verifier. It is performed when a Verifier needs an Agent to prove that it has the appropriate authorization to perform a particular action (such as executing a purchase). Action Authorization is performed as follows: 1. The Verifier and the Agent interact until the Verifier needs proof of human authorization from the Agent. 1. The Verifier requests a Mandate to be presented that will demonstrate that the Agent is authorized to perform that action. 1. The Agent selects an appropriate Mandate and presents it to the Verifier. If the Mandate is open, then the Agent uses the key endorsed by that Mandate to bind it to the transaction. 1. The Verifier verifies both the integrity of the Mandate and that the Mandate Content allows the Agent to perform the action that they wish to perform. As part of presenting a Mandate, if it contains selective disclosures, the Agent MUST choose which disclosures to include so as to maximize user privacy while still providing authorization. *Note: the mechanism of selecting the appropriate Mandate is an implementation detail of the Shopping Agent and outside the scope of this specification.* The Verifier performs Verification of the Mandate (see [Verification](#verification-and-processing-rules)). Upon acceptance or rejection of the Mandate, the Verifier MUST return a signed Mandate Receipt. Upon receipt of a successful Mandate Receipt, the Agent stores the open Mandate-closed Mandate-Mandate Receipt tuple. The agent reduces the scope of the open mandate based on the receipt, often preventing future presentations entirely. A Mandate Receipt is a Verifier-signed JWT with the following properties: - *iss*: **REQUIRED**. A String containing the issuer of the JWT, which MUST be the Verifier. - *result*: **REQUIRED**. An Enum with value `["success", "error"]` indicating the result of the action authorization. - *reference*: **REQUIRED**. A String value that is the base64url-encoded hash of the received Mandate. When receiving a chain of Mandates, it is a hash over the final SD-JWT in the chain. It is calculated in the same manner as `sd_hash`. The algorithm used MUST be the same as the `_sd_alg` specified for the SD-JWT, or `sha-256` if not specified. - *error*: **OPTIONAL**. A String error code identifying the error. MUST be present when the result is `"error"`. - *error_description*: **OPTIONAL**. A human-readable error description String. It MAY contain additional use-case specific properties, based on the action that was authorized, and the Mandate Type received. ### Errors The following errors are defined for all action authorizations: - `invalid_credential`: Returned when the Mandate fails verification. This represents a terminal error. - `unresolved_constraint`: Returned when the Mandate contains an unknown constraint, or the Verifier is unable to verify that the closed Mandate conforms to the provided constraints. This MAY be used as a signal to fallback to either a directly approved closed Mandate, or other non-agentic flows. - `invalid_mandate`: Returned when the provided Mandate fails to approve the requested action. This represents a terminal error. - `mandates_not_supported`: Indicates that the Verifier does not support mandates for approving this action. This MAY be used as a signal to fallback to non-agentic flows. ## References ### Normative - \[OpenID4VP\]: T. Lodderstedt, K. Yasuda, T. Looker. "[OpenID for Verifiable Presentations](https://openid.net/specs/openid4vp-1_0.html)", OpenID Foundation, 2024. - \[SD-JWT\]: D. Fett, B. Campbell, K. Yasuda, M. B. Jones. "[Selective Disclosure for JWTs (SD-JWT)](https://datatracker.ietf.org/doc/rfc9901/)", February 2025. - \[Delegate SD-JWT\]: G. Oliver. "[Delegate SD-JWT (Individual Draft)](https://github.com/GarethCOliver/gco-delegate-sd-jwt)", 2026. - \[RFC7800\]: M. B. Jones, J. Bradley, H. Tschofenig. "[Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)](https://datatracker.ietf.org/doc/html/rfc7800)", April 2016. ### Informative - \[OpenID4VCI\]: T. Lodderstedt, K. Yasuda, T. Looker. "[OpenID for Verifiable Credential Issuance](https://openid.net/specs/openid4vc-issuance-1_0.html)", OpenID Foundation, 2024. - \[ISO18013-5\]: ISO/IEC JTC 1/SC 17. "[ISO/IEC 18013-5:2021 Personal identification — ISO-compliant driving licence — Part 5: Mobile driving licence (mDL) application](https://www.iso.org/standard/69084.html)", September 2021. - \[ISO18013-7\]: ISO/IEC JTC 1/SC 17. "[ISO/IEC 18013-7:2024 Personal identification — ISO-compliant driving licence — Part 7: Mobile driving licence (mDL) add-on functions](https://www.iso.org/standard/82763.html)", October 2024. # Additional Resources # Glossary | Term | Acronym | Definition | Synonym / Related | | -------------------------------------- | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | Action Authorization | | A process where a Verifier challenges an Agent to provide proof that it is authorized to perform an action on behalf of a User. | | | Agent Payments Protocol | AP2 | An open protocol designed to enable AI agents to securely interoperate and complete payments autonomously. | | | Agent Provider | | An entity that provides the Agent to the User. Can also be a trusted party for Verifiers to construct Mandates directly. | | | Agent2Agent Protocol | [A2A](https://a2a-protocol.org/latest/) | An open standard for secure, collaborative communication and task management between diverse AI agents, regardless of their underlying frameworks. **Context:** AP2 can be implemented as an extension of A2A to facilitate financial transactions, with a focus on high-trust agentic payments. | | | Agentic payments | | Payment flows in which autonomous AI Agents are facilitating the payment. | | | Checkout Mandate | | A Mandate used for authorizing the completion of a checkout. | | | Closed Mandate | | A Mandate that is bound to a particular action with a Verifier to authorize the agent to perform an action. | | | Credentials Provider | CP | A secure entity, like a digital wallet, responsible for managing and executing the user's payment and identity credentials. | | | Deterministic cryptographical proof | | A unique mathematical proof that could be linked to a hardware device. | | | Dynamic Linking | | A core requirement for Strong Customer Authentication (SCA), involving the inclusion of specific transaction details within a Payment Credential to link the SCA to that transaction. **Context:** Ensures the payer explicitly consents to transaction details like amount and payee. | | | Mandate Content | | The specific payload of a Mandate created by the Shopping Agent and rendered to the User, detailing actions the agent handles. | | | Mandate Delegation | | A process where a User authorizes an Agent to perform an action on their behalf. | | | Mandate Receipt | | A Verifier-signed JWT indicating the result of the action authorization. | | | Merchant Endpoint (Or Remote Endpoint) | ME, RE | The web interface or AI agent representing the seller, showcasing products and negotiating the cart. | | | Merchant Payment Processor | MPP | The entity responsible for constructing and sending the transaction authorization message to the payment ecosystem. | Merchant PSP | | Model Context Protocol | MCP | A protocol standardizing how AI models and agents connect to and interact with external resources like tools, APIs, and data sources. | | | Open Mandate | | A Mandate that has not yet been bound to a particular action. It possesses constraints to be applied to a closed mandate to ensure it's validity. | | | Payee | | A person or entity who is the intended recipient of funds from a payment transaction. **Context:** Can request attestations along with payment confirmation. | Merchant, Creditor Name | | Payer | | A person or entity who holds a payment account, allows a payment order from that account. **Context:** Initiates payment orders. | User, Holder | | Payment Agent | | A proposed key role in agent payments responsible for selecting the ideal payment method, validating payment details, and handling errors. **Context:** A Payment Agent is not a necessary requirement to participate in the protocol. MCP-based endpoints can also play similar roles. | | | Payment Credential | | A credential or instrument (or reference to one) which can be charged towards a payment. | Electronic Attestation of Attributes (EAA), Payment Wallet Attestation (PWA), Digital Payment Credentials (DPC), Payment Means Attestation, SPC Credential | | Payment Initiation Service Provider | PISP | A service provider that initiates payments on behalf of the user. | | | Payment Mandate | | A Mandate used for authorizing the payment for a particular checkout. | | | Strong Customer Authentication | SCA | A process required by regulatory frameworks for online identification and transaction initiation in financial services. **Context:** Central to the Payments Rulebook, ensuring security and dynamic linking of transactions. | Strong User Authentication, Integrated SCA | | Trusted Surface | | A secure, non-agentic interface that renders Mandate Content to the User for authorization and consent. The result of which is a Mandate. | | | Universal Commerce Protocol (UCP) | | A protocol providing a Checkout Object standard when used with the Checkout Mandate. | | | User | | The human initiating the task and providing financial authority. | | | User Agent a.k.a. Shopping Agent | UA, SA | The AI surface interacts directly with the user, understanding their needs, and coordinating the purchase. | | | Verifiable digital credential | VDC | An Issuer-signed credential (i.e., a set of Claims) whose authenticity can be verified. **Context:** Typically bound to a cryptographic key and used in the issuer-holder-verifier model. | Digital credential, Verifiable Credential | | Verifiable Presentation | VP | A presentation of one or more VDCs that includes a cryptographic proof of holder binding, created in response to a request from a Verifier. **Context:** Allows a Verifier to confirm that the Holder intended the presentation for them and may reveal only a subset of claims. | | # Frequently Asked Questions 1. What can I do with this protocol today? - We built sample agents around the core AP2 python library that demonstrate a rich shopping experience. Launch the agents, and try shopping for your favorite products! These samples mock actual payment service providers so you can explore with no dependencies. Specifically, watch for the mandates as the agents do their thing. We will be publishing more samples and SDKs soon, and we'd love to see your ideas! You can use the code samples to create your own implementation of a payment taking place between multiple AI Agents or extend the protocol to show new kinds of payment scenarios *(e.g., showing a payment made by a different payment method or using a different way of authentication)*. 1. Can I build my own agent for any of these roles, taking one of these as a template? - Yes you can build your own agent using any of the [roles](../ap2/implementation_considerations/). Get started building with [ADK](https://google.github.io/adk-docs/) and [Agent Builder](https://cloud.google.com/products/agent-builder) from Google Cloud, or any other platform you choose to build agents. 1. Can I build my own agent to participate in this protocol? - Yes, you can build an agent for any of the defined [roles](../ap2/implementation_considerations/). Any agent, on any framework (like LangGraph, AG2 or CrewAI), or on any runtime, is capable of implementing AP2. 1. Can I try this out without actually making a payment? - You can consider setting this up in your internal environments where you may already have ways to invoke fake payment methods which do not require real money movement. 1. Is there a MCP server or a SDK which is ready for "my framework of choice"? - We are working on an SDK and a MCP server right now, in collaboration with payment service providers. Check back soon. 1. Does this work with x402 standard for crypto payments? - We designed AP2 to be a payment-agnostic protocol, so that agentic commerce can securely take place across all types of payment systems. It provides a secure, auditable foundation whether an agent is using a credit card or transacting with stablecoins. This flexible design allows us to extend its core principles to new ecosystems, ensuring a consistent standard for trust everywhere. As a first step, check out \[google-agentic-commerce/a2a-x402\](https://github.com/google-agentic- commerce/a2a-x402/) which is an implementation of A2A in conjunction with the x402 standard. We will be aligning this closely with AP2 over time to make it easy to compose solutions which include all payment methods, including stablecoins. 1. What are verifiable credentials? - These are standardized, cryptographically secure data objects (like the Checkout Mandate and Payment Mandate) that serve as tamper-evident, non-disputable, and cryptographically signed building blocks for a transaction. 1. How does the protocol ensure user control and privacy? - The protocol is designed to ensure the user is always the ultimate authority and has granular control over their agents' activities. It protects sensitive user information, such as conversational prompts and personal payment details, by preventing shopping agents from accessing sensitive PCI or PII data through payload encryption and selective disclosure to ensure data minimization. 1. How does AP2 address transaction accountability? - A primary objective is to provide supporting evidence that helps payment networks establish accountability and liability principles. In a dispute, the network adjudicator (e.g., Card Network) can use the user-signed Checkout Mandate and compare the details of what was agreed upon between the agent and the consumer against the details in the dispute to help determine transaction accountability. 1. What prevents an agent from "hallucinating" and making an incorrect purchase? - The principle of Verifiable Intent, Not Inferred Action addresses this risk. Transactions must be anchored to deterministic, non-repudiable proof of intent from all parties, such as the user-signed Checkout Mandate, rather than relying only on interpreting the probabilistic and ambiguous outputs of a language model. 1. Why was crypto and Web3 support included from day one? - Supporting a broad range of payment types, including digital payment methods ensures the protocol is future-proof. Collaboration with partners like Coinbase, Ethereum Foundation, and Metamask validates AP2's flexibility and bridges the gap between the traditional and Web3 economies, enabling novel use cases like micropayments. 1. How can I get involved? - AP2 is an open source project created by Google, similar to the A2A protocol. Contributions are welcome on Github as discussions, bugs, feature requests, and PRs. Collaboration is happening right now, with new samples, integrations and SDKs being developed – Github is the best way to communicate with the AP2 team. 1. How is UCP different from AP2? And how does it relate to your agentic checkout feature? - AP2: Agent Payments Protocol (AP2) is designed to provide a common language for agents to transact with security and accountability. While the Universal Commerce Protocol orchestrates the broader purchase lifecycle, AP2 is the specialized payment layer responsible for authorizing and signing transactions. AP2 becomes critical in the flow when, in the near future, the transactions become truly agentic and users delegate purchases to their AI Agents. This modular design fosters trust among buyers, merchants, and providers while retaining flexibility. Merchants will be able to integrate AP2 as an extension within the Universal Commerce Protocol for transactions which are driven by AI Agents. - Agentic checkout: Our agentic checkout feature buys things on your behalf directly on a store's website at your direction. The Universal Commerce Protocol is different in that it enables native buying on AI Mode and Gemini. Users are connected directly with the merchant when they natively buy on AI Mode and Gemini, which unlocks additional features such as important post-purchase signals, like order status updates. Soon-to-be available benefits include using loyalty points, and shopping from a previous cart. 1. How do I know when to use AP2? - If you are a merchant who would like to showcase products and allow users to complete inline checkout on Google’s AI surfaces like AI Mode and Gemini, then you should use Universal Commerce Protocol. You can enhance the protocol with the AP2 extension if you plan to build autonomous purchase scenarios where AI Agents can make purchases in the user’s absence. - Outside of Google’s discovery surfaces, if you would like to enable a payments flow between two AI Agents or you want to add verifiable credentials to payment flows between your discovery surface and an AI Agent then you can continue to leverage AP2. 1. What’s next for AP2? - The core specification work will continue in [FIDO](https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/), ensuring it continues as an open, interoperable protocol for all agentic payments. - The code samples and SDK will continue to be enhanced, remaining a state-of-the-art implementation of the AP2 specification.