AP2 — Agent Payments Protocol

AP2 (Agent Payments Protocol, version 2) is a sub-protocol layered on A2A v1.0 that enables autonomous agents to initiate, authorize, and settle micropayments as part of their task execution — without requiring human intervention for each transaction.

AP2 launched alongside A2A v1.0 (May 2026) as the first standardized mechanism for agentic commerce: agents paying for API calls, compute time, data licenses, or services rendered by peer agents.

Problem Statement

Agentic workflows increasingly require real-money transactions: a research agent purchasing access to a paywalled dataset, a coding agent paying for cloud compute, or an orchestrator compensating a specialist peer agent for completed work. Prior to AP2, every such payment required either a pre-funded account (no agent autonomy) or manual human approval per transaction (breaks automation).

AP2 solves this by introducing delegated payment authority — humans authorize a budget envelope; agents spend within it autonomously.

Core Concepts

Payment Intent

A Payment Intent is a structured declaration of a proposed transaction. It is the AP2 equivalent of an A2A Task — a stateful, lifecycle-tracked unit of work:

{
  "id": "pay_abc123",
  "amount": { "value": "0.05", "currency": "USD" },
  "recipient": "https://datavendor.example.com",
  "purpose": "Dataset access: climate-records-2024",
  "status": "pending_authorization",
  "expires_at": "2026-05-06T18:00:00Z"
}

Authorization Envelope

Before executing tasks that may incur costs, the orchestrating agent receives an Authorization Envelope from a human principal or a treasury agent. The envelope declares:

The envelope is attached to the agent's task context and propagated through the delegation chain. Sub-agents inherit a constrained envelope: they cannot spend more than their parent delegated.

Lattice Compliance

AP2 follows the same capability lattice constraint that governs A2A delegation:

Effective_budget(A → B) = min(Budget(A), Budget(B.envelope))

An agent cannot delegate more payment authority than it was given. Attempts to do so result in a PAYMENT_SCOPE_EXCEEDED error, which the orchestrator must surface — not silently swallow.

Payment Lifecycle

PENDING_AUTHORIZATION → AUTHORIZED → PROCESSING → SETTLED
                                               ↘ FAILED
                      ↘ REJECTED (by policy or principal)
                      ↘ EXPIRED

The AP2 state machine maps to A2A Task states:

• PENDING_AUTHORIZATION ≈ SUBMITTED (waiting for envelope check)
• AUTHORIZED ≈ WORKING (proceeding through payment rail)
• SETTLED ≈ COMPLETED

Integration with A2A

AP2 extends the A2A Agent Card with a payment_schemes block declaring supported payment rails:

{
  "payment_schemes": {
    "ap2_v1": {
      "treasury_url": "https://pay.example.com/ap2",
      "supported_rails": ["stripe", "usdc"],
      "max_per_transaction": { "value": "10.00", "currency": "USD" }
    }
  }
}

A client agent checks this block before calling a paid skill. If the client's Authorization Envelope is compatible, it attaches it to the SendMessage request header. The receiving agent validates the envelope signature before executing the paid operation.

Security Considerations

• Envelope signature must be verified at every hop. A forged envelope that passes unverified could authorize unlimited spend.
• Replay prevention: Payment Intents include a nonce and expires_at. Servers must reject replayed or expired intents.
• Scope minimization: Prefer narrow allowed_recipients lists over open envelopes wherever possible.
• Audit trail: Every settled Payment Intent is recorded as an artifact on the A2A Task that triggered it.

References

• a2a-protocol
• a2a-mcp-contrast
• capability-lattice-spec
• community-protocol-trust-substrate