Payment-Enabled Agents: ACP, AP2, x402, aur MPP Production mein
Un four protocols ka crash course jo OpenAI Agents SDK systems ko money spend karne dete hain: merchants par, APIs ke against, other agents ke saath, aur open economy mein.
19 Concepts. 5 Decisions. Four learning tracks. Reader track 2-3 hours pure reading. Beginner, Intermediate, Advanced tracks roughly 1 day, 2-3 days, 4-5 days.
Core idea: four protocols rivals nahin, layers hain. "ACP ya x402?" galat sawal hai. Consumer shopping agent ACP use karta hai commerce layer par aur card rails settlement par. API-paying agent x402 use kar sakta hai because commerce and settlement collapse into one. Enterprise procurement agent AP2 mandates se authorization prove karta hai, phir MPP/card/stablecoin settlement use karta hai.
Yeh course Build AI Agents, Production Worker, Eval-Driven Development, aur Choosing Agentic Architectures ko reference karta hai. Aap phir bhi yeh course read kar sakte hain. Protocol layers aur decision discipline standalone hain.
Different stack translation table
| Protocol | Primary reference | Alternatives | Governance |
|---|---|---|---|
| ACP | Stripe + OpenAI Agents SDK | Adyen ACP, Shopify checkout | Apache 2.0 |
| AP2 | Google ADK + mandate refs | LangGraph custom signing | Apache 2.0 |
| x402 | Coinbase, Cloudflare helpers | direct EIP-3009, AgentPay | Apache 2.0 |
| MPP | Stripe + Tempo | Lightning, Tempo native | Apache 2.0 |
| MCP | Anthropic/OpenAI clients | LangChain MCP | MIT |
Glossary
- ACP. Agentic Commerce Protocol. Consumer-shopping checkout protocol.
- AP2. Agent Payments Protocol. Signed mandates prove the human authorized spend.
- x402. HTTP 402-based payment flow for machine-to-machine payments.
- MPP. Machine Payments Protocol. Session-based settlement with cap and duration.
- Discovery layer. Agent finds what it can buy.
- Authorization layer. Agent proves it may spend.
- Commerce layer. Cart, checkout, fulfillment, dispute, refund.
- Settlement layer. Money actually moves.
- Mandate. Signed AP2 proof of allowed spending.
- SPT. Shared Payment Token, ACP's capped one-time payment token.
- HTTP 402. Payment Required response used by x402.
- tool_input_guardrail. SDK guardrail that runs before a payment tool executes.
Prerequisites
- Build AI Agents course ya equivalent SDK experience.
- Choosing Architectures course ya equivalent design sense.
- Basic HTTP.
- Basic payment vocabulary: merchant, settlement, dispute, chargeback.
Four learning tracks
| Track | Time | Work |
|---|---|---|
| Reader | 2-3 hours | Concepts and decisions, no code |
| Beginner | ~1 day | x402 examples, ACP test transaction |
| Intermediate | 2-3 days | ACP + x402 + AP2 checks |
| Advanced | 4-5 days | Durable runs, spend limits, HITL, disputes |
The four-layer stack
- Discovery. Kya buy kar sakte hain?
- Authorization. Kya agent allowed hai?
- Commerce. Purchase lifecycle kaise chalega?
- Settlement. Money kahan move hogi?
Part 1: Agent commerce ko new protocols kyun chahiye
Concept 1: Broken assumption
Old payments assume human clicks "buy" at final moment. Agents autonomous tasks mein spend karte hain; system ko prove karna hota hai ke authorization pehle se valid tha.
Concept 2: One protocol cannot win
Shopping, API calls, procurement, and agent marketplaces different layers demand karte hain. Is liye composition important hai.
Concept 3: OpenAI Agents SDK universal client
Har protocol one or more tools ban jata hai. Agent use case ke mutabiq tool choose karta hai; guardrails payment se pehle execute hoti hain.
from agents import Agent, Runner, function_tool
@function_tool
async def pay_api_call(url: str, max_usd: str):
return {"status": "paid", "url": url, "max_usd": max_usd}
agent = Agent(name="buyer", tools=[pay_api_call])
Part 2: Four layers in depth
Concept 4: Discovery
MCP servers, directories, shopping surfaces, A2A registries. Discovery ka output buyable thing ka structured description hota hai.
Concept 5: Identity and Authorization
Agent ka identity aur human authorization separate cheezen hain. AP2 mandates, SPT caps, smart-wallet limits, and SDK guardrails yahan fit hotay hain.
Concept 6: Commerce
Commerce full purchase lifecycle hai: cart, checkout, fulfillment, refunds, disputes. ACP/UCP is layer par strong hain.
Concept 7: Settlement
Settlement money move karta hai: card rails, stablecoin, Lightning, bank transfer. x402 and MPP yahan strong hain.
Part 3: Protocols in depth
Concept 8: ACP
Consumer-shopping protocol. Agent merchant checkout complete karta hai using capped Shared Payment Token. Merchant of record merchant hi rehta hai. Best for real goods/services with disputes and refunds.
Concept 9: AP2
Authorization protocol. Intent Mandate task rules set karta hai; Cart Mandate exact cart approve karta hai; Payment Mandate exact payment authorize karta hai. AP2 money move nahin karta; proof create karta hai.
Concept 10: x402
HTTP-native settlement. Server 402 Payment Required return karta hai; agent signed payment proof ke saath retry karta hai. Best for APIs, data, compute, micropayments.
Concept 11: MPP
Session-based settlement. Agent spending cap and time window pre-authorize karta hai, phir many small metered payments stream karta hai.
Part 4: Composition rules
Concept 12: Minimum viable stack
Use case ke liye smallest layer composition choose karein. Plain API call: x402 may be enough. Consumer shopping: ACP plus card rail. Enterprise procurement: AP2 plus settlement rail.
Concept 13: Protocols layers mein compose, same layer mein compete
ACP and UCP commerce layer par compete karte hain. AP2 authorization layer par ACP ke saath compose kar sakta hai. x402 settlement layer par AP2 ke saath compose kar sakta hai.
Concept 14: Cost and latency
Card settlement slower but dispute-friendly. x402 fast for machine calls. MPP efficient for repeated microcharges. Protocol cost use case economics se decide hoti hai.
Part 5: Decision lab
Decision 1: Consumer shopping agent
Pattern: ACP commerce + SPT/card settlement. Reason: merchant of record, fulfillment, refunds, disputes.
Decision 2: API-paying research agent
Pattern: x402-only. Reason: no cart, no delivery, no chargeback requirement; payment is tied to API response.
Decision 3: Enterprise procurement agent
Pattern: AP2 mandates + composed settlement. Reason: audit needs signed authorization chain.
Decision 4: Multi-agent marketplace
Pattern: AP2 + x402 + ERC-8004 reputation. Reason: agents may have no prior relationship; identity and settlement both matter.
Decision 5: Non-Stripe, non-OpenAI stack
Same architecture travels. Discovery, authorization, commerce, settlement remain. Library names change.
Part 6: Production concerns
Concept 15: Spend-limit enforcement at three levels
- Wallet/provider caps.
- Protocol/session caps.
- SDK
tool_input_guardrailbefore tool execution.
Concept 16: Identity hygiene
Separate wallet/key per agent class. Rotate keys. Log every payment-authorizing action before completion.
Concept 17: Disputes and refunds
ACP/card rails support chargebacks. x402 often final settlement. MPP depends on rail/session rules. Dispute model may decide protocol choice.
Concept 18: Webhooks and async callbacks
Payment systems finish later. FastAPI receives webhook; Inngest/durable function resumes waiting workflow; idempotency prevents duplicate refunds or charges.
Part 7: Closing
Concept 19: Layered composition discipline
Payment-enabled agent design is not "pick a payment API." It is: identify layers, pick one protocol per needed layer, enforce spend before payment, log every action, and know dispute path before launch.
Cheat sheet
Four layers
| Layer | Main question | Common protocol |
|---|---|---|
| Discovery | What is available? | MCP, A2A |
| Authorization | May agent spend? | AP2, SPT, wallet caps |
| Commerce | Full purchase lifecycle? | ACP, UCP |
| Settlement | Money moves where? | cards, x402, MPP |
Canonical compositions
| Use case | Composition |
|---|---|
| Consumer shopping | ACP + card/SPT |
| API micropayment | x402 |
| Enterprise procurement | AP2 + settlement rail |
| Agent marketplace | AP2 + x402 + identity/reputation |
Design-review questions
- Which layers does this use case actually need?
- Where is human authorization proven?
- What caps stop overspend before tool execution?
- What audit row proves what happened?
- What is the refund/dispute path?
References
- ACP specification and OpenAI/Stripe reference materials.
- Google AP2 specification and reference implementations.
- x402 Foundation and Coinbase docs.
- MPP / Stripe and Tempo materials.
- OpenAI Agents SDK docs.