AP2: the Agent Payments Protocol, mandates as verifiable credentials, and how we wire it into Agent Builder

When an autonomous agent reaches the checkout page, the payment system on the other side has to answer three questions classical rails never had to ask. Did the human actually authorize this purchase? Does the agent's request match what the human intended? And if the deal goes wrong, who is liable — the user, the agent operator, the merchant, or the bank? AP2, Google's Agent Payments Protocol, was announced on 16 September 2025 with sixty-plus partners (Mastercard, American Express, PayPal, Coinbase, Adyen, Worldpay, Salesforce, ServiceNow, MetaMask, the Ethereum Foundation among them), shipped v0.2 on 28 April 2026 with Human Not Present and Verifiable Intent, and was donated to the FIDO Alliance for community governance. It is the protocol that turns those three questions into cryptographic answers. This post walks the entire spec — the three Mandate types, the four-actor model, the Human Present and Human Not Present flows, the x402 extension for crypto — and ends with the concrete engineering plan for AP2 inside LLM4Agents Agent Builder.

The three questions classical payments cannot answer

A credit-card transaction assumes a human physically pressed "buy." Card networks built their entire chargeback, dispute, and liability framework around that assumption. The card-present standards know who the human was because they saw a chip, a PIN, or a CVC entered in a session bound to a device. The card-not-present standards know who the human was because they saw an authenticated 3-D Secure step, a billing address match, a fraud-scoring decision. In every case, the rail's accountability chain ends at a human who can be reached.

An autonomous agent breaks that chain. The agent might be running in a microVM somewhere it cannot reach the user. It might be operating against an intent the user signed an hour, a day, or a month ago. It might be combining multiple agents, multiple merchants, multiple payment methods into a single composite purchase. None of the existing rail-level proofs of intent — the chip, the PIN, the 3-D Secure step — can be produced by an agent on the user's behalf without either (a) the agent storing the user's secrets, which is a security disaster, or (b) the rail loosening its proof requirements, which is a fraud disaster.

AP2's bet is that there is a third option: capture the intent at the moment the user has it, sign it cryptographically, hand the signature down the chain, and let every downstream actor verify the chain without ever holding the user's secrets. This is the same trick W3C Verifiable Credentials made standard for identity documents, applied to payment authorization. The signature is the proof; the agent does not need to be trusted because the cryptography is.

Mandates: the three signed artifacts

An AP2 transaction is built from a chain of three signed Verifiable Credentials called Mandates. Each Mandate is a self-contained JSON document with subject, issuer, claims, expiration, and a cryptographic proof. The chain captures the full provenance from "what the user originally wanted" to "what was actually charged."

1. Intent Mandate

The Intent Mandate is signed by the user (or by the user's agent acting under prior consent) and declares what the user wants done. It is the cryptographic version of "find me white running shoes under $120."

{
  "@context": ["https://www.w3.org/ns/credentials/v2",
                "https://ap2-protocol.org/v0.2"],
  "type": ["VerifiableCredential", "AP2IntentMandate"],
  "id": "urn:uuid:8a3f...e21d",
  "issuer": "did:key:zUser...",
  "validFrom": "2026-05-25T14:21:00Z",
  "validUntil": "2026-05-26T14:21:00Z",
  "credentialSubject": {
    "agentDid": "did:key:zAgent...",
    "description": "White running shoes, size 10 US, under $120",
    "constraints": {
      "maxAmount": { "value": "120.00", "currency": "USD" },
      "categories": ["footwear", "running"],
      "merchantAllowList": ["did:web:merchant.example"],
      "requiresHumanConfirmation": true
    },
    "humanPresent": true
  },
  "proof": { "type": "Ed25519Signature2020", "proofValue": "z3..." }
}

The constraints field is the load-bearing part. It pins the agent's budget, allowed categories, allowed merchants, and whether the user wants a final confirmation step before the agent pulls the trigger. Anything the user does not pre-authorize stays unauthorized.

2. Cart Mandate

The Cart Mandate is the moment the abstract intent collapses into a concrete shopping cart. It is signed by the merchant (or its agent) and contains the exact items, prices, taxes, shipping, and total that the merchant is offering. When the user is present, the user counter-signs the Cart Mandate after reviewing — this is the "what you see is what you pay for" checkpoint. When the user is not present, the user's agent counter-signs it against the constraints in the Intent Mandate.

{
  "@context": ["https://www.w3.org/ns/credentials/v2",
                "https://ap2-protocol.org/v0.2"],
  "type": ["VerifiableCredential", "AP2CartMandate"],
  "id": "urn:uuid:4b1c...f098",
  "issuer": "did:web:merchant.example",
  "validFrom": "2026-05-25T14:23:11Z",
  "validUntil": "2026-05-25T14:38:11Z",
  "credentialSubject": {
    "intentMandateId": "urn:uuid:8a3f...e21d",
    "lineItems": [
      { "sku": "RUN-WHT-10", "qty": 1, "price": "109.00" }
    ],
    "tax": "9.81",
    "shipping": "0.00",
    "total": { "value": "118.81", "currency": "USD" },
    "acceptedPaymentMethods": [
      "card.visa", "card.mastercard", "x402.usdc.base"
    ]
  },
  "proof": [
    { "type": "Ed25519Signature2020", "verificationMethod": "did:web:merchant.example#sign" },
    { "type": "Ed25519Signature2020", "verificationMethod": "did:key:zUser...#sign" }
  ]
}

The dual signature on the Cart Mandate is the key innovation. The merchant signs to commit to the price; the user (or the user's pre-authorized agent) signs to commit to the purchase. Both signatures bind to the same artifact. Neither party can later claim "I never agreed to that cart" because the cart is the cart.

3. Payment Mandate

The Payment Mandate is the final authorization that releases funds. It references the Cart Mandate, names the payment method, and contains whatever rail-specific data the Payment Service Provider needs to settle.

{
  "@context": ["https://www.w3.org/ns/credentials/v2",
                "https://ap2-protocol.org/v0.2"],
  "type": ["VerifiableCredential", "AP2PaymentMandate"],
  "id": "urn:uuid:c910...d4a7",
  "issuer": "did:web:credentials-provider.example",
  "validFrom": "2026-05-25T14:23:47Z",
  "validUntil": "2026-05-25T14:33:47Z",
  "credentialSubject": {
    "cartMandateId": "urn:uuid:4b1c...f098",
    "paymentMethod": {
      "type": "x402.usdc.base",
      "network": "base-mainnet",
      "payerAddress": "0x...",
      "payeeAddress": "0x..."
    },
    "amount": { "value": "118.81", "currency": "USD" }
  },
  "proof": { "type": "Ed25519Signature2020", "proofValue": "z3..." }
}

The signer of the Payment Mandate is the Credentials Provider — typically a bank, a wallet, a card issuer, or in the x402 case a non-custodial wallet that the user controls. This separation matters: the user's agent never sees the user's payment credentials. The Credentials Provider holds them, signs the Payment Mandate against an already-authorized Cart Mandate, and hands the signed artifact to the PSP for settlement.

The four-actor model

AP2 defines a small, sharp role decomposition that everyone in the transaction has to fit into. Confusion about who is doing what was the largest barrier to agent-mediated commerce; the protocol resolves it by naming the actors.

AP2 actor model:

  ┌─────────────┐     ┌─────────────┐    ┌─────────────┐
  │  User Agent │◄───►│ Merchant    │    │  Credentials│
  │ (LLM4Agents,│     │ Agent       │    │  Provider   │
  │  Gemini,    │     │ (Shopify,   │    │  (Bank,     │
  │  Copilot…)  │     │  PayPal,    │    │   Wallet,   │
  │             │     │  Etsy…)     │    │   Issuer)   │
  └─────┬───────┘     └─────┬───────┘    └─────┬───────┘
        │ Intent            │ Cart             │ Payment
        │ Mandate           │ Mandate          │ Mandate
        ▼                   ▼                  ▼
                ┌──────────────────────────────┐
                │   PSP / Payment Network      │
                │   (Adyen, Stripe, Mastercard,│
                │    Base RPC, Solana RPC…)    │
                └──────────────────────────────┘

The User Agent represents the buyer; the Merchant Agent represents the seller; the Credentials Provider holds the payment instrument; the PSP/Network actually moves the money. Each actor signs only what it is authoritative for. The User Agent never signs a Payment Mandate; the Credentials Provider never signs an Intent Mandate; the Merchant never holds the user's private keys. The cryptographic separation enforces the role separation that the legal system already expects.

Human Present vs Human Not Present

The single design decision that lets AP2 work across the entire agent-commerce surface is the explicit split between the two flows.

Human Present. The user is in the loop. They issue an Intent Mandate that does not need to pre-authorize a specific dollar amount because they will sign the Cart Mandate themselves when the agent presents the cart. The Intent Mandate is more about scope ("only this merchant," "only this category") than amount. The user reviews the cart, signs, and the transaction settles. The whole chain captures provenance for the dispute system; the user's final signature is the binding authorization.

Human Not Present. The user signed an Intent Mandate earlier — possibly much earlier — that gave the agent pre-authorization to act under specific constraints. The agent discovers a cart that satisfies the constraints, generates a counter-signature using a key the user already delegated to it, and proceeds. The merchant verifies that the agent's delegated signature traces back to the user's original Intent Mandate, and the transaction settles without bringing the user back into the loop.

The Verifiable Intent feature shipped in v0.2 (April 2026) sharpens the Human Not Present case. The Intent Mandate now carries a structured constraints language — not just maximums but conditionals ("buy only if SKU X drops below $90 between Tuesday and Friday"). This lets agents act on multi-day, multi-condition mandates without re-engaging the user, while keeping the pre-authorization verifiable end-to-end.

Composition with A2A, MCP and x402

AP2 is built on top of the existing agentic stack rather than replacing any part of it.

AP2 over A2A. Mandates are transported as A2A message parts of type data, with an extension URI declaring the AP2 schema. The agent-to-agent communication that runs the negotiation, the cart construction, and the final settlement is plain A2A; the only addition is that some Part objects carry signed Mandates instead of unstructured JSON.

AP2 plus MCP. The agent's tools — fetching prices, querying inventory, computing shipping — are invoked through MCP exactly as before. AP2 does not touch the tool layer; it sits above it. An agent shipping AP2 still uses MCP to look at the merchant's catalog; the difference is that the moment a cart is finalized, the agent now signs a Cart Mandate rather than POSTing an HTTP form.

AP2's x402 extension. The crypto rail support inside AP2 is the x402-on-AP2 extension that Google co-developed with Coinbase, the Ethereum Foundation and MetaMask. A Payment Mandate with paymentMethod.type = "x402.*" tells the PSP to settle the transaction via the x402 facilitator on the named chain. The Mandate chain itself is identical; only the final settlement leg changes. This is the path most native agent-to-agent commerce will take, because it does not require either side to hold a card or to integrate with a traditional acquirer.

The composition is the point. AP2 does not invent a new RPC layer (A2A already did that), a new tool layer (MCP already did that), or a new payment rail (x402 and the existing card networks already did that). It adds the missing piece: the cryptographic authorization chain that proves a human really did, and to what extent, agree.

The dispute story

The reason Mastercard, American Express, PayPal and Adyen signed on is that AP2 gives them something their existing chargeback machinery did not have: a non-repudiable evidence chain that survives the agent intermediation.

When a customer disputes an AP2-mediated transaction, the merchant can produce three signed artifacts: the Intent Mandate (showing the user pre-authorized a category and limits), the Cart Mandate (showing the user or the user's delegated agent signed the exact cart), and the Payment Mandate (showing the Credentials Provider released the funds against that cart). Every link in the chain is cryptographically verifiable; no link depends on a server log that someone could later edit; each artifact carries its own expiry and freshness proof.

If the dispute hinges on "the agent did something I never authorized," the Intent Mandate's constraints field is the evidence. If it hinges on "the merchant charged something different from the cart I approved," the dual-signature on the Cart Mandate is the evidence. If it hinges on "the wrong account was charged," the Payment Mandate's signature from the Credentials Provider is the evidence. The first time card networks have an audit trail across agent boundaries.

The protocol does not eliminate disputes — it never could — but it shifts them from "we have to figure out what happened" to "we have to interpret what the signed evidence shows." That is the same shift TLS made for web fraud twenty years ago, and it is the precondition for the rails to allow large-scale agent commerce at all.

How LLM4Agents wires AP2 into Agent Builder

Our plan for AP2 inside Agent Builder follows the integration pattern we used for the other deAI protocols: ship sensible defaults, expose the right escape hatches, and make composition with A2A/MCP/x402/ERC-8004 the path of least resistance.

Mandate signing as a first-class SDK primitive. Agent Builder exposes a mandates namespace that wraps the W3C VC stack. Operators do not write the JSON-LD; they write business logic. The SDK generates the credential, attaches the proof, and hands back a serialized artifact ready to drop into an A2A message Part.

// Agent Builder SDK — AP2 namespace

const intent = await ap2.intent.sign({
  description: "White running shoes, size 10 US, under $120",
  constraints: {
    maxAmount: { value: "120.00", currency: "USD" },
    categories: ["footwear", "running"],
    requiresHumanConfirmation: true
  },
  validUntil: "PT24H"   // ISO 8601 duration shorthand
})

await a2a.sendMessage(merchantAgent, {
  skill: "checkout",
  parts: [
    { type: "data", data: { ap2: { intentMandate: intent } } }
  ]
})

Key management is delegated to the wallet. Agent Builder never holds the user's signing key. For traditional payments, the Credentials Provider (a card issuer, a bank, a Stripe-issued ephemeral credential) holds it. For x402-route payments, the user's non-custodial wallet holds it. Agent Builder coordinates the signing flow but does not see the secret. The wallet returns the signed Mandate.

Mandates persisted to ERC-8004. For every transaction the agent completes, the hash of the Mandate chain is posted to the agent's ERC-8004 Validation Registry entry. This gives every agent built in Agent Builder a tamper-proof, on-chain history of payments authorized through it. Counterparties looking to hire the agent for the first time can see not only the agent's reputation score, but the verifiable count of how many AP2-mediated transactions it has completed under attested constraints.

Default Cart-Mandate review UI. For Human Present flows, Agent Builder ships a standard cart-review component (web, mobile, Telegram, Discord — wherever the user runs their agent) that renders the Cart Mandate JSON as a human-friendly summary and collects the user's signature. Operators can replace the UI but the protocol contract is fixed: until the user signs, no Cart Mandate is countersigned.

Constraint policies as agent skills. Agents generated by Agent Builder can declare AP2 constraints as A2A Agent Card skills. A "subscription renewal" agent declares an Intent Mandate template with monthly recurrence; a "deal hunter" agent declares a Verifiable Intent template with conditional clauses. Counterparties browsing the agent through its Agent Card see the AP2 constraints the agent is willing to operate under, before the first conversation starts.

x402 the default crypto rail. When an agent transacts through the LLM4Agents marketplace, the AP2 Payment Mandate defaults to x402.usdc.base (USDC on Base for low fees, Coinbase-friendly settlement) with Solana and Polygon as fallbacks. Operators can pin a different chain; they cannot pin a non-AP2 settlement, because the marketplace will reject any unmandated payment.

What still needs to mature

AP2 v0.2 is production-ready for its core flows. The honest critique tracks the gaps the v0.2-to-v1.0 work has to close.

The W3C VC ecosystem is itself still maturing. The Ed25519Signature2020 suite is well supported, but JWT-based VC formats — preferred by some FIDO members for interop with existing identity rails — are arriving more slowly. AP2 will likely have to support both proof formats interchangeably, the same way A2A had to support both JSON-RPC and gRPC bindings.

Mandate revocation needs sharper primitives. A user who delegates a six-month Intent Mandate and changes their mind needs a fast, reliable way to revoke it before the agent acts on it again. The v0.2 spec describes revocation conceptually but leaves the registry design to implementers; the next version should standardize a revocation status endpoint analogous to OCSP for TLS certificates.

Cross-Mandate composition for multi-party deals — a single user paying multiple merchants in one shopping trip, or a B2B procurement order that lines up dozens of suppliers — is currently expressed as multiple parallel Mandate chains. A bundling extension would let one Intent Mandate cover the multi-party flow without forcing the user agent to issue N Intents, each merchant to sign its slice, and the user to track them all separately.

And the FIDO Alliance hand-off, while the right governance move, is going to slow the cadence of breaking changes — appropriate for a payment protocol, painful for early-adopter agent platforms that still want to evolve quickly. We expect the spec to land at v1.0 some time in late 2026, after which point the bar for breaking changes will be appropriately high.

Closing

The agentic stack in mid-2026 finally has the four layers it needs. MCP standardizes the agent-to-tool boundary. A2A standardizes the agent-to-agent boundary. AP2 standardizes the authorization-and-payment boundary. ERC-8004 standardizes the identity-and-reputation boundary. Each protocol is owned by a neutral home (Linux Foundation, FIDO Alliance, Ethereum Foundation), each is composable with the others through well-defined seams, and none of them lock the operator into a single vendor.

AP2 is the layer that, until late 2025, was missing — and it is the one whose absence kept agent commerce stuck in pilot mode for the first half of 2026. With mandates as Verifiable Credentials and the FIDO governance hand-off, the rail networks have what they need to underwrite agent-mediated transactions at scale. Our job inside Agent Builder is to make using it the default rather than an opt-in, and to make the cryptographic guarantees visible to the human in the loop without dumping JSON-LD on their screen.

The spec is at goo.gle/ap2. The reference implementations are public in Python, TypeScript, Kotlin and Go. If you are building any agent whose successful task ends in money changing hands, AP2 belongs on your stack diagram alongside A2A and MCP — and inside Agent Builder, it already is.