🤖 Agentic Payments Protocols: The Game
A quick introduction to 5 AI payments & commerce protocols
To give AI agents the ability to make online purchases, five (competing) agentic commerce protocols have recently emerged. Your mission: master the protocols.
ACP
AP2
TAP
MAP
UCP
23 missions total
The Three-Party Model
The three key players in ACP transactions
Buyer
Authorizes payments, owns the customer relationship with the merchant
AI Agent
Facilitates discovery and checkout orchestration
Business
Merchant of record, processes payments, fulfills orders
💡 Key architecture decision: The AI Agent never becomes the merchant of record. This preserves existing merchant-customer relationships and ensures chargebacks flow to the actual seller—not the AI platform.
A customer disputes a charge made through an AI agent. Under ACP's model, who handles the chargeback?
Shared Payment Tokens
The payment primitive enabling secure agent-initiated transactions
Tokenization flow: PAN to SPT
💡 Why not just use existing tokens? SPTs are specifically designed for delegation. Unlike a standard PaymentMethod token, an SPT can be granted to a third party (the business) by the agent, with explicit usage constraints. The agent never accesses the underlying PAN.
How does an SPT differ from a standard Stripe PaymentMethod token in this architecture?
SPT Guardrails & Constraints
Programmable security boundaries built into every token
Example SPT response object:
{
"id": "spt_1RgaZcFPC5QUO6ZCDVZuVA8q",
"object": "shared_payment.granted_token",
"usage_limits": {
"currency": "usd",
"max_amount": 5099, // $50.99 in cents
"expires_at": 1751587220 // Unix timestamp
},
"deactivated_at": null
}
💰 max_amount
Hard cap on transaction value. Prevents overcharging.
⏱️ expires_at
Unix timestamp expiry. No stale authorizations.
💱 currency
Locked to specific currency.
🚫 Revocation
Agent can deactivate token anytime via API.
📊 Risk Signals
SPTs pass fraud signals to issuer for better authorization rates.
🏪 Seller Details
Scope the SPT to a specific merchant. Only that seller can charge the token.
An SPT is issued with max_amount: 5099 and expires_at set to 24 hours from now. The merchant attempts to charge $75.00 fifteen minutes later. What happens?
The Transaction Flow
Click each step to trace the request lifecycle
👆 Click each step to understand the data flow at each stage.
At which point in the ACP flow does the AI agent have visibility into the buyer's actual payment credentials?
Agent Simulation
You're the AI agent. Make the right architectural decisions.
ACP Knowledge Check
Test your understanding of ACP architecture
Level 1 Complete!
You've mastered ACP fundamentals. Now let's explore Google's AP2 protocol—a different approach using cryptographic mandates.
📚 ACP Key Takeaways
- Merchant of Record: Businesses retain this status
- SPT Constraints: max_amount, expires_at, currency
- Zero Credential Exposure: Agents use opaque tokens
The Three Mandates
AP2's staged authorization model
1. Intent Mandate
Sarah's signed request: "Buy running shoes, max $150." Delegates authority within constraints.
2. Cart Mandate
Sarah reviews and signs: "Nike Pegasus, $129, Foot Locker." Locks the specific purchase.
3. Payment Mandate
Signals to payment processor: "agent-initiated, user approved." Full context for the network.
💡 Each mandate is signed: Creates a cryptographic chain showing exactly where authorization existed.
Sarah's agent finds three shoe options from different merchants: Nike ($129), Adidas ($135) and Brooks ($145). The agent presents these to Sarah, and she selects the Nike shoes. What is Sarah signing when she approves this selection?
Verifiable Digital Credentials
The cryptographic primitive that makes mandates tamper-proof
Each mandate is a VDC—a tamper-evident, cryptographically signed object:
{
"type": "CartMandate",
"items": [{
"name": "Nike Pegasus",
"price": 12900,
"merchant": "foot_locker_123"
}],
"user_signature": "eyJhbGciOiJS...",
"signed_at": 1751587220
}
💡 Tamper-evident: Signatures are bound to exact values. If anyone modifies "$129" to "$229", verification fails.
A merchant receives a Cart Mandate but modifies the quantity from 1 to 3 before processing. When the user disputes, what happens?
Human-Present vs Human-Not-Present
How the mandate chain handles autonomous agent actions
👤 Human-Present
Agent finds options → User reviews and signs Cart Mandate → Purchase proceeds. The user explicitly approved the specific transaction.
🤖 Human-Not-Present
Agent finds options within Intent Mandate constraints → Purchases autonomously. User accepted risk for actions within their stated constraints.
💡 The Intent Mandate bridges the gap: With autonomous agents, the Intent Mandate serves as authorization—"you may act on my behalf, within these bounds."
An agent autonomously books a $180 hotel when the Intent Mandate specified "under $200." The user disputes, claiming they didn't approve this specific hotel. What's the likely outcome?
Dispute Detective
You're the auditor. Examine the evidence and deliver your verdict.
A user claims they only approved $300 for a laptop purchase, but the merchant charged $500. Both parties are adamant. Your job: examine the cryptographic evidence.
👤 User Claims
"I only approved $300 for the laptop"
🏪 Merchant Claims
"User agreed to $500 including accessories"
{
"type": "IntentMandate",
"user_id": "user_8x7k2m",
"intent": "Purchase laptop",
"max_amount": 50000,
"currency": "usd",
"user_signature": "eyJhbGc...",
"signed_at": 1751587200
}
✓ Signature verified - max_amount: $500
🔎 Examine all evidence before delivering your verdict.
✓ Case Closed
The Four Key Roles
Understanding who does what in the AP2 ecosystem
Shopper
The end user who initiates purchases through their AI agent and signs mandates to authorize transactions
Merchant
Sells goods/services, receives mandates from agents, and submits payment requests to processors
Credentials Provider
Issues and manages Verifiable Digital Credentials (VDCs) that prove identity and authorization
Payment Processor
Validates the mandate chain, processes payments, and maintains the cryptographic audit trail
💡 Separation of concerns: AP2 separates credential issuance from payment processing, allowing specialized providers for each function.
A shopper's AI agent presents a Cart Mandate to a merchant. Before processing, who validates that the mandate's VDC is authentic?
AP2 Knowledge Check
Test your understanding of AP2 architecture
Level 2 Complete!
You've mastered AP2's mandate chains. Now let's explore Visa's TAP—cryptographic signatures for trusted agent verification.
📚 AP2 Key Takeaways
- Three Mandates: Intent → Cart → Payment chain
- VDCs: Tamper-evident signed credentials
- Audit Trail: Clear dispute resolution via signatures
The Cryptographic Handshake
Understanding HTTP Message Signatures (RFC 9421)
Agent's Private Key
Signs every HTTP request to prove identity
Visa's Registry
Contains public keys of all trusted agents
Merchant/CDN
Verifies signature using Visa's public keys
💡 RFC 9421 in action: Every TAP request includes a cryptographic signature in the HTTP headers. The merchant or CDN verifies this signature against Visa's registry—only requests from registered agents pass through.
An agent sends a request to buy sneakers. The merchant receives it but the signature doesn't match any key in Visa's registry. What happens?
The Three Pillars of TAP
Agent Intent, Consumer Recognition, and Payment Information
📋 Agent Intent
"I'm a Visa-trusted agent here to purchase this specific product." Declares the agent's purpose for visiting this page.
👤 Consumer Recognition
Existing merchant tokens, device IDs, loyalty identifiers. Helps merchants recognize returning customers without exposing card numbers.
💳 Payment Information
Hashed credentials, tokenized payment methods. Actual card numbers never touch the agent layer.
💡 Privacy by design: TAP sends hashed or tokenized identifiers—never raw card numbers or PII. The merchant knows "this is a returning customer" without knowing who specifically.
Sarah's agent visits a merchant she's shopped with before. Which TAP component helps the merchant recognize her without exposing her card number?
The Consumer Control Loop
Payment Instructions API and Payment Signals API
1. Payment Instructions API
Consumer sets rules: "Max $200, only electronics, only these merchants." These constraints are stored with Visa.
2. Agent Attempts Purchase
Agent finds a product and sends a purchase signal to Visa's Payment Signals API with the transaction details.
3. Token Unlock (or Block)
Visa checks against consumer's instructions. If compliant, payment token is unlocked. If not, transaction is blocked.
💡 Human-in-the-loop: Even with autonomous agents, the consumer's pre-set rules act as guardrails. The token only unlocks when the purchase matches the consumer's instructions.
An agent tries to buy a $300 item when the consumer set a $200 limit in their Payment Instructions. What happens?
Level 3 Complete!
You've mastered Visa's TAP. Now let's explore Mastercard's Agent Pay—Agentic Tokens and Know Your Agent verification.
📚 TAP Key Takeaways
- RFC 9421 Signatures: Cryptographic agent verification
- Three Pillars: Intent, Recognition, Payment
- Consumer Control: Pre-set rules gate token unlock
Know Your Agent (KYA)
Agent registration and verification before any transaction
1. Agent Submits for Review
Agent developer provides documentation about the agent's purpose, security practices, and intended use cases.
2. Mastercard Verifies Legitimacy
Review process checks agent's compliance, security standards, and business practices—similar to KYC for customers.
3. Cryptographic Keys Issued
Approved agent receives cryptographic keys. Public key added to Mastercard's directory for verification.
💡 KYA = KYC for AI: Just as banks verify customers before opening accounts, Mastercard verifies agents before they can transact. This creates accountability and traceability.
A new AI shopping assistant wants to make purchases using Mastercard. What's the first step?
Agentic Tokens
Dynamic, cryptographically secure payment credentials
Traditional vs Agentic Token flow
🔒 Cryptographically Bound
Token is bound to specific merchant, amount, and time window. Cannot be reused elsewhere.
❌ Useless if Intercepted
Even if stolen, the token only works for its specific, pre-defined context.
🔄 Instantly Revocable
Consumer or issuer can revoke the token at any time, immediately stopping all agent transactions.
💡 Defense in depth: Agentic Tokens replace card numbers so agents never see real credentials. Even if compromised, the token's constraints limit damage.
A hacker intercepts an Agentic Token during transmission. What can they do with it?
The Intent Verification Flow
Biometric consent and the complete transaction lifecycle
1. User Intent
"Buy these running shoes for $120" — User expresses what they want to purchase.
2. Biometric Verification
Mastercard Passkeys confirm identity via fingerprint or face ID. Creates verifiable credential.
3. Intent Capture
Amount ($120), merchant (Foot Locker), product (Nike shoes) locked into verifiable credential.
4. Agent Execution
Agent presents Agentic Token at checkout. Mastercard verifies token + intent match.
💡 Intent = Authorization: The biometrically-verified intent becomes the authorization. If actual purchase differs from captured intent, transaction is rejected.
An agent captured intent for "Nike shoes, $120, Foot Locker" but submits a transaction for "Nike shoes, $180, Foot Locker". What happens?
Level 4 Complete!
You've mastered Mastercard's Agent Pay. Final level: Google's UCP—a unified architecture for commerce interoperability.
📚 MAP Key Takeaways
- Know Your Agent: Verification before transaction
- Agentic Tokens: Bound, revocable credentials
- Intent Verification: Biometric consent flow
The Four-Layer Architecture
UCP's TCP/IP-inspired design for commerce
🛍️ Shopping Service Layer
Core primitives: checkout sessions, line items, totals, shipping. The foundation everything else builds on.
⚡ Capabilities Layer
Major functions: Checkout, Orders, Catalog, Identity Linking. Modular features merchants can support.
🔌 Extensions Layer
Optional add-ons: Discounts, Loyalty, AP2 Mandates, Returns. Merchants choose what to implement.
🔄 Services Layer
Transport: REST APIs, MCP for LLMs, A2A for agent-to-agent. Multiple ways to access the same commerce logic.
💡 TCP/IP for commerce: Just as the internet has layers (physical, network, transport, application), UCP separates concerns so each layer can evolve independently.
A merchant wants to add loyalty point redemption to their checkout. Which UCP layer handles this?
The Four Primary Roles
Clear separation of responsibilities in UCP
Platform (Agent)
Orchestrates the shopping journey. Calls UCP APIs, manages user interaction.
Business
Merchant of Record. Holds liability, fulfills orders, handles disputes.
Credential Provider
Manages tokens and secures PII. Issues payment credentials to agents.
Payment Service Provider
Processes actual payments. Connects to card networks, handles settlement.
💡 Separation of concerns: Unlike traditional e-commerce where these roles blur together, UCP explicitly separates them so each party knows their responsibilities.
An AI agent completes a purchase but the item never arrives. Under UCP's role model, who is liable to the customer?
Dynamic Discovery
How agents find merchant capabilities via /.well-known/ucp
An agent visiting any UCP-enabled merchant fetches their profile:
{
"merchant": "example-store.com",
"ucp_version": "1.0",
"capabilities": [
"checkout",
"orders",
"identity_linking"
],
"extensions": [
"loyalty",
"discounts"
],
"payment_methods": [
"card",
"bank_transfer"
],
"services": {
"rest": "https://api.example-store.com/ucp",
"mcp": "mcp://example-store.com"
}
}
💡 Decentralized onboarding: No central registry needed. Any merchant can publish their UCP profile, and agents automatically discover what's supported. Like robots.txt but for commerce.
An agent wants to buy from a new merchant. How does it learn what payment methods and features are supported?
The Checkout State Machine
Four states guide every UCP transaction
👆 Click each state to understand when the checkout enters that state.
An agent adds items to cart but the merchant requires age verification before selling alcohol. Which state is the checkout in?
Protocol Interoperability
UCP's transport-agnostic design works with MCP, A2A, and AP2
🔧 MCP (Model Context Protocol)
For LLM tool calling. Agents invoke UCP as tools within their context window.
🤝 A2A (Agent-to-Agent)
For multi-agent commerce. Shopping agent talks to merchant's fulfillment agent.
💳 AP2 Mandates
As an extension. UCP checkout can require signed AP2 mandates for payment authorization.
💡 One commerce protocol, many transports: UCP defines what happens (checkout, orders, payments). How it's delivered (REST, MCP, A2A) is separate. This means merchants implement once, support all agent types.
A merchant implements UCP with REST APIs. Later, an AI agent wants to use MCP instead. What does the merchant need to do?
Training Complete!
You've completed the training
👾 I hope you liked it! Thanks for playing. -Joris