AP2 Agent Payments Protocol: An Implementation Guide to Mandates

AP2 secures an agent-led purchase by binding user authority to the checkout contents and payment authorization in signed artifacts. Different parties verify them. Google announced the protocol on September 16, 2025 using Intent Mandate and Cart Mandate language. The April 2026 specification defines a sharper implementation model with Checkout and Payment Mandates, signed receipts, five roles, plus deterministic verification even when an LLM participates in a role. I want to walk through that current model because launch vocabulary is a poor basis for an acceptance test.

TL;DR

• AP2's April 2026 release defines two mandate families: Checkout Mandates for what is purchased and Payment Mandates for authority to pay for that checkout.
• Human-present purchases use user-signed closed mandates. Autonomous purchases pair user-signed open mandates with agent-signed closed mandates that must satisfy the user's constraints.
• Merchants, credential providers, networks, and merchant payment processors have different verification duties. Those checks run in deterministic code.
• Checkout and Payment Receipts preserve acceptance or rejection results and can join the mandates as dispute evidence.
• DeepInspect can govern deliberately routed LLM HTTP traffic used during shopping or checkout. Mandate signing and payment execution remain with their designated AP2 roles.

The launch article and April specification use different vocabularies

Google's September 2025 AP2 announcement describes an Intent Mandate that captures instructions and a Cart Mandate that fixes the selected items and price. That framing explains the problem. A merchant needs evidence that an agent's request reflects the user's authority, while a payment provider needs enough context to assess the resulting transaction.

Implementation work should use the current AP2 specification. It defines Checkout and Payment Mandates, with open and closed forms in autonomous flows, plus Checkout and Payment Receipts. The current release appeared on April 28, 2026, with Human Not Present flows as its stated focus.

I would put a red line through "Intent Mandate" and "Cart Mandate" in a new implementation diagram. Keep those labels when quoting the launch article. Use the current artifact names in schemas and conformance tests, then carry them into logs and operating procedures. Mixing generations creates the kind of ambiguity that appears only after a rejected purchase.

Five roles split the verification work

The April 2026 AP2 specification names five roles: a Shopping Agent, Credential Provider, Merchant, Merchant Payment Processor, and Trusted Surface. One company may perform several roles. It inherits every duty attached to each one.

Product discovery, checkout assembly, and purchase execution belong to the Shopping Agent. Merchants provide the checkout while protecting inventory and prices, including their discounts. A Credential Provider supplies a payment credential after checking the agent's authority to use it, while the Merchant Payment Processor checks that the credential is scoped to that checkout and handles payment processing. On a Trusted Surface, the user sees the intent and gives informed consent before a signed mandate is created.

The Trusted Surface must be non-agentic. AP2 expects the Shopping Agent to be agentic. The Merchant and the two payment roles may use deterministic code or an LLM for communication, but validation and payment processing stay in deterministic code even when a model helps assemble or communicate a transaction. The model cannot grade its own cryptographic authority.

This separation complements agent-to-agent authentication. Authentication establishes the caller and delegation chain. AP2 adds transaction artifacts that bind the authority to a checkout and payment.

Checkout and Payment Mandates bind different facts

A Checkout Mandate gives the Merchant cryptographic evidence that the Shopping Agent may purchase the assembled checkout. The Merchant first supplies a merchant-signed Checkout JWT. The closed Checkout Mandate binds to that JWT through a cryptographic hash. After verification, the Merchant must return a Checkout Receipt recording acceptance or rejection.

A Payment Mandate serves a different verifier population: the Credential Provider and any applicable Network use it as evidence that the Shopping Agent may pay for the particular checkout, as does the Merchant Payment Processor. It carries the checkout binding. The Merchant Payment Processor returns a signed Payment Receipt after acceptance or rejection. Before its hash is used in the Payment Mandate, the specification requires the Checkout JWT to use a non-deterministic signature scheme, giving ECDSA as an example. That requirement reduces the risk of precomputed hash matching against predictable checkout representations.

Version checks belong beside signature checks. Each mandate type carries a vct claim with an exact numeric schema suffix. The allowed examples cover open and closed checkout mandates, plus open and closed payment mandates. AP2 requires exact string matching.

Version drift has security consequences. A parser that accepts an unfamiliar suffix and silently treats it as version 1 has converted protocol evolution into an authorization bypass.

Human-present purchases close both mandates at approval

In the direct flow, the Merchant creates a signed Checkout JWT for the finished checkout. The Shopping Agent builds the Checkout and Payment Mandate content, then sends both to a Trusted Surface, where the user sees the closed checkout and payment details and signs the mandates.

The Shopping Agent forwards the Payment Mandate to the Credential Provider and any applicable Network. After successful verification, it receives a suitably scoped payment credential. It then gives the Merchant that credential and the Checkout Mandate. The Merchant compares the checkout hash with the Checkout JWT it created and initiates the payment when the merchant pulls funds. Push-payment methods follow a different operational path. The Merchant receives confirmation that funds were sent.

Completion produces a Checkout Receipt for the Shopping Agent, while a Payment Receipt goes to that agent and the Credential Provider, plus any applicable Network. Preserve the mandate identifiers and receipt references in separate fields, alongside the checkout hash and transaction correlation identifier. One green "payment successful" event flattens several decisions. Those decisions may later need independent examination.

Autonomous purchases chain open authority to a closed transaction

Human Not Present mode starts before a particular checkout exists. The user approves open Checkout and Payment Mandates on the Trusted Surface. These artifacts contain constraints and the agent's public key in the cnf claim. AP2 recommends the shortest practical expiration time for the task.

Once the Shopping Agent finds an acceptable checkout, it signs closed mandates with its agent key. Verifiers receive both the user-signed open mandate and the agent-signed closed mandate. Deterministic code then checks the signature chain, evaluates every relevant constraint, and confirms that the closed transaction fits the user's authority. Payment constraints can cover an amount range, total budget with recurrence, execution date, and a reference that links payment authority to the related checkout authority.

The specification adds two controls that deserve explicit test cases. First, the Shopping Agent must receive a rejection receipt before presenting a subsequent open Payment or Checkout Mandate. This limits attempts to approve several different checkouts with the same open authority. Second, it must disclose only the open-mandate fields needed to evaluate the closed mandates.

Put two envelopes on the test bench, one marked "required disclosure" and one marked "everything else." The second envelope should stay sealed.

Open authority also exposes the post-authentication gap. A valid user session at task creation says little about the agent key, mandate chain, and verifier decision used hours later. Preserve the login identity separately from the later transaction identities.

Verification failures need receipts, not generic exceptions

The Merchant must receive and verify an appropriate Checkout Mandate before completing the checkout. It processes the mandate under AP2's authorization rules, recomputes the Checkout JWT hash, and evaluates every constraint supplied by an open Checkout Mandate. A failed step produces a Checkout Receipt JWT carrying the appropriate error.

The Credential Provider and applicable Network run the Payment Mandate checks before returning a payment credential. If the user supplied open Payment Mandates, those parties evaluate the closed Payment Mandate against every constraint. Failure produces a Payment Receipt JWT with the error. The Merchant Payment Processor then checks that the payment credential is correctly scoped to the checkout before processing the transaction.

Treat rejection receipts as protocol evidence. Record the rejecting role and receipt signature, then preserve the referenced mandate hash and reason code with the schema version and verification time. Retries should create a visible sequence. They should not overwrite the first rejection. My blunt view is that a generic HTTP 400 here is an evidence-destruction feature: it tells an operator that something failed while discarding the artifact AP2 designed for explaining which authority check failed.

Dispute evidence requires a joined verification procedure

AP2 says the Checkout Mandate and Receipt, plus the Payment Mandate and Receipt, can form a non-repudiable picture of the transaction. The protocol leaves dispute procedure and evidence retention outside its current scope, along with retrieval mechanisms. An implementation therefore needs an evidence owner and retention policy beyond basic conformance.

At dispute time, the verifier repeats the Merchant checks and independently recomputes the hash of the included Checkout JWT. The receipt must point to the closed mandate. Payment evidence then undergoes its own hash and reference checks. Only after those steps can the signed contents support a claim about what the user and each role saw.

Use a transaction identifier to join these artifacts, but retain the signed objects and computed hashes. The AP2 specification notes that automated Checkout Mandate retrieval by transaction_id would be useful and leaves that mechanism for future work. Your current storage design has to close that retrieval gap. Agentic AI audit trails cover the wider run. AP2 evidence proves this narrower commerce decision.

DeepInspect

DeepInspect applies to authenticated HTTP traffic deliberately routed between the Shopping Agent or another application component and an LLM endpoint. At that point, it can evaluate the supplied principal and role against the data classification, model destination, and policy version, then record an allow, block, or redaction decision. That record can carry the AP2 transaction or task correlation identifier so investigators can join a model call to the wider agent run.

AP2 mandate signing and Trusted Surface consent remain outside DeepInspect's boundary. Merchant and Credential Provider verification stay there too, together with receipt validation, payment credential handling, checkout, and payment execution. A clean model-route decision cannot prove that a Checkout Mandate was valid or that a payment processor applied the correct scope. Keep AP2 artifacts with their designated verifiers. Use routed LLM records only for the model traffic they actually observed.

Book a technical deep dive at deepinspect.ai.