Agent Payments Protocol (AP2)
AP2 is Google's open protocol for secure, verifiable payment authorization between AI agents, merchants, and payment providers. It introduces cryptographically-signed Mandates as tamper-proof proof of user intent.
AP2 is Google’s open protocol for secure, verifiable payment authorization between AI agents, merchants, and payment providers. It introduces cryptographically-signed Mandates as tamper-proof proof of user intent, supports traditional card rails and stablecoin settlement, and is designed as the payment execution layer beneath UCP’s commerce orchestration.
What is it?
AP2 is a payment-specific protocol that solves the trust problem in agent-mediated transactions: how does a merchant know that an AI agent is authorized to spend a user’s money, and how do you audit what happened if something goes wrong?
Google announced AP2 in September 2025 with over 60 partner companies. The spec is published on GitHub at google-agentic-commerce/AP2 and documentation lives at ap2-protocol.org.
AP2 is not a commerce protocol – it does not handle product discovery, carts, or fulfillment. It handles one thing: making payments between agents and merchants trustworthy and auditable. It pairs with UCP for full commerce flows, but can also be used independently for any agent-to-agent or agent-to-merchant payment scenario.
Problem it solves
When an AI agent initiates a payment on behalf of a user, three trust problems emerge:
-
Authorization – How does the merchant prove the user actually authorized this specific purchase? The agent said the user wants to buy X, but can the merchant verify that claim?
-
Authenticity – How does the merchant know the agent’s request accurately reflects the user’s true intent? What if the agent hallucinated or was manipulated into making a different purchase?
-
Accountability – If a fraudulent or incorrect transaction occurs, who is responsible? The user? The agent? The agent platform? The merchant?
Existing payment infrastructure (card networks, ACH, wire) was designed for humans clicking “confirm.” It has no concept of delegated agent authority. AP2 fills this gap with a deterministic trust model built on cryptographic verification rather than inference-based trust.
Architecture / How it works
Core flow
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
┌──────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────┐
│ User │ │ User Agent │ │ Merchant │ │ Payment │
│ │ │ (Gemini) │ │ Agent │ │ Provider │
└────┬─────┘ └──────┬───────┘ └──────┬───────┘ └────┬─────┘
│ │ │ │
│ 1. Grant Mandate │ │ │
│ (sign intent) │ │ │
│─────────────────>│ │ │
│ │ │ │
│ │ 2. Present Mandate │ │
│ │ + payment request │ │
│ │────────────────────>│ │
│ │ │ │
│ │ │ 3. Verify Mandate│
│ │ │ + authorize pay │
│ │ │─────────────────>│
│ │ │ │
│ │ │ 4. Settlement │
│ │ │<─────────────────│
│ │ │ │
│ │ 5. Confirmation │ │
│ │<────────────────────│ │
│ 6. Receipt │ │ │
│<─────────────────│ │ │
The Mandate model
The Mandate is AP2’s core innovation. It is a tamper-proof, cryptographically-signed digital contract that serves as verifiable proof of a user’s payment instructions. A Mandate contains:
- What the user authorized (merchant, amount, currency, items)
- Who the user delegated authority to (specific agent identity)
- Constraints (maximum amount, expiration time, merchant restrictions)
- Cryptographic signature from the user’s credential
The Mandate is not inference-based (“the agent probably has permission”) – it is deterministic (“here is a signed, verifiable proof of exactly what the user authorized”). Any party in the chain can verify it independently.
Verifiable Digital Credentials (VDCs)
AP2 builds its trust model on VDCs – cryptographically signed digital certificates that establish identity and authority. Unlike API keys or bearer tokens, VDCs support:
- Delegation chains – User signs authority to Agent A, Agent A can delegate a subset to Agent B, and each link in the chain is verifiable.
- Selective disclosure – The merchant sees only the information needed for checkout (e.g., shipping address, payment token), not the user’s full identity.
- Revocation – Users can revoke agent authority at any time, and revocation is verifiable in real-time.
Key concepts
Payment types supported
AP2 is explicitly multi-rail:
- Traditional cards – Credit and debit cards via existing card network infrastructure.
- Bank transfers – Real-time bank-to-bank transfers (e.g., FedNow, SEPA Instant).
- Stablecoins and crypto – Via the x402 extension, co-developed with Coinbase.
x402 stablecoin extension
The x402 extension integrates Coinbase’s stablecoin infrastructure with AP2’s identity and compliance layer. This is significant because it enables:
- Micro-settlements – Fractions of a cent for API calls, inference tokens, or streaming data. Traditional card rails have minimum transaction sizes that make micropayments uneconomical.
- Always-on settlement – Stablecoin transactions settle in seconds, 24/7, without card network batch processing delays.
- Programmable payments – Smart contract logic can enforce Mandate constraints on-chain, providing an additional verification layer.
Google provides the identity, policy, and compliance scaffolding. Coinbase provides the programmable settlement rail. The combination makes agent-to-agent payments viable at scales where traditional rails are impractical.
Multi-party payments
AP2 supports payment flows involving more than two parties:
- Split payments – A single purchase split across multiple payment methods or payers.
- Marketplace payouts – Agent buys from a marketplace, AP2 handles the split between marketplace and seller.
- Agent-to-agent settlement – One agent paying another agent for a service (e.g., a shopping agent paying a price-comparison agent for data).
Authorization scopes
Users grant Mandates with specific scopes:
- Single-use – One transaction, one merchant, one amount.
- Recurring – Authorized for repeated purchases within constraints (e.g., “up to $50/month at this grocery store”).
- Budget-capped – Agent can make purchases freely up to a cumulative limit.
- Category-restricted – Agent can only buy within specific product categories.
Code / Integration example
Creating and verifying a Mandate:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
# User-side: creating a mandate
mandate = AP2Mandate(
user_id="user-456",
agent_id="gemini-shopping-agent",
merchant_constraints={
"merchant_id": "merchant-789",
"max_amount": Money(amount=150.00, currency="USD"),
},
expires_at="2026-04-12T00:00:00Z",
scope="single_use",
)
signed_mandate = user_credential.sign(mandate)
# Merchant-side: verifying a mandate
@app.post("/ap2/v1/payment/authorize")
async def authorize_payment(request: AP2PaymentRequest):
# Verify the mandate signature chain
mandate = request.mandate
is_valid = await ap2.verify_mandate(
mandate=mandate,
expected_merchant="merchant-789",
expected_amount=request.total,
)
if not is_valid:
raise AP2AuthorizationError("Invalid or expired mandate")
# Process payment via the specified rail
if mandate.payment_rail == "card":
result = await card_processor.charge(mandate.payment_token, request.total)
elif mandate.payment_rail == "x402":
result = await stablecoin_processor.settle(mandate.payment_token, request.total)
return AP2PaymentResponse(
transaction_id=result.id,
status="authorized",
settlement_time=result.estimated_settlement,
)
Comparison with related protocols
| Dimension | AP2 (Google) | ACP Payments (Stripe SPT) | Visa Trusted Agent Protocol |
|---|---|---|---|
| Scope | Payment authorization + settlement | Payment token exchange | Agent identity + payment credential delegation |
| Trust model | Mandates (cryptographic proof of intent) | Shared Payment Tokens (scoped, single-use) | HTTP message signatures + JWT ID tokens |
| Payment rails | Cards, bank transfers, stablecoins | Stripe-processed cards and wallets | Visa network only |
| Multi-rail | Yes (explicit design goal) | No (Stripe only) | No (Visa only) |
| Micropayments | Yes (via x402 stablecoins) | No (standard Stripe minimums) | No |
| Agent-to-agent | Yes | No | No |
| Maturity | Pre-production (v0.1.0 on GitHub) | Production (live in ChatGPT) | Pilot (hundreds of test transactions) |
AP2 is the most ambitious of the three in scope, but also the least mature. ACP’s SPT model is simpler and already in production. For enterprise planning, the pragmatic path is to implement ACP for near-term ChatGPT/Shopify commerce and track AP2 for medium-term multi-rail and stablecoin capabilities.
Current adoption / Maturity
- Spec status: v0.1.0 released on GitHub with Python and Android sample implementations.
- Partners: 60+ companies announced at launch, including major payment providers and retailers.
- Production readiness: Not yet available for consumer use. The protocol is in specification and pilot phase.
- Sample code: Python and Android reference implementations available on GitHub.
- Timeline: Commercial production deployment has not been announced. Given UCP (which depends on AP2 for payments) is in early access as of March 2026, AP2 production is likely mid-to-late 2026.
Honest assessment
AP2 is architecturally sound – the Mandate model is more rigorous than SPTs for complex delegation scenarios. But it is significantly behind ACP in production maturity. The stablecoin angle via x402 is genuinely novel for enterprise payments, but enterprise procurement and compliance teams will need time to accept stablecoin settlement. The traditional card rail support makes AP2 practical without crypto adoption.
Spec links
- GitHub repository: https://github.com/google-agentic-commerce/AP2
- Specification: https://github.com/google-agentic-commerce/AP2/blob/main/docs/specification.md
- Protocol documentation: https://ap2-protocol.org
- Google Cloud announcement: https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol