AP2: एजेंट पेमेंट्स प्रोटोकॉल

यह AP2 v0.2, स्वायत्त एजेंट भुगतानों के पीछे के क्रिप्टोग्राफिक मैंडेट सिस्टम का एक तकनीकी गहन विश्लेषण है। मैंने इसे Camunda 8 पर एक वास्तविक डेमो बनाने के बाद लिखा है, और मैंने ap2-protocol.org पर स्पेसिफिकेशन के खिलाफ हर दावे को सत्यापित किया है, न कि प्रेस कवरेज के खिलाफ। लॉन्च सप्ताह के अधिकांश लेख ऐसी शब्दावली का उपयोग करते हैं जिसे वर्तमान स्पेसिफिकेशन ने पहले ही बदल दिया है। मैं इसे वहीं चिह्नित करूँगा जहाँ यह मायने रखता है।

यह जिस समस्या का समाधान करता है

“क्या आप किसी AI को अपना क्रेडिट कार्ड देंगे?” यही वह सवाल है जिसका जवाब मैंने Agents, Orchestrated के EP 03 के लिए देने की कोशिश की। जो प्रोटोकॉल इसका सही जवाब देता है वह AP2 है।

एक एजेंट जो पैसे खर्च कर सकता है, वह एक एजेंट से मौलिक रूप से भिन्न होता है जो सवालों के जवाब दे सकता है। जब कोई एजेंट किसी सर्च API को कॉल करता है और वह गलत हो जाता है, तो आपको एक बुरा परिणाम मिलता है। जब वह किसी पेमेंट API को कॉल करता है और वह गलत हो जाता है, तो आपके पैसे चले जाते हैं।

पारंपरिक उत्तर है: भुगतान के समय मानवीय उपस्थिति की आवश्यकता होती है। अप्रूव पर क्लिक करें। OTP दर्ज करें। जो ठीक है, जब तक कि एजेंट को सुबह 2 बजे FIFA टिकट की कीमतें गिरने पर तुरंत खरीदना न हो, जब आप सो रहे हों।

AP2 एक विशिष्ट समस्या का समाधान करता है: एक मानव एजेंट को खर्च करने का अधिकार कैसे सौंपता है, इस तरह से कि वह क्रिप्टोग्राफिक रूप से सीमित हो, श्रृंखला में हर पक्ष द्वारा ऑडिट करने योग्य हो, और किसी भी केंद्रीय प्राधिकरण को फोन किए बिना लागू करने योग्य हो?

इसका उत्तर मैंडेट्स हैं। यही पूरा प्रोटोकॉल है।

AP2 क्या है: मुख्य तथ्य

AP2 = Agent Payments Protocol। एजेंट-आरंभिक भुगतानों के लिए Google का खुला मानक, 16 सितंबर, 2025 को घोषित किया गया, जिसमें Mastercard, PayPal, American Express, Coinbase और Salesforce सहित 60+ लॉन्च पार्टनर शामिल हैं।

तथ्य	विवरण
वर्तमान संस्करण	v0.2, अप्रैल 2026 को जारी किया गया (GitHub: google-agentic-commerce/AP2)
लॉन्च पार्टनर	60+ (Mastercard, PayPal, AmEx, Coinbase, Salesforce)
मानकीकरण	FIDO Alliance (Google ने AP2 को Agentic Auth + Payments TWG को दान किया)
संदर्भ कार्यान्वयन	5 भाषाएँ: Python, Go, TypeScript, Kotlin, Android

शुरुआत में जानने योग्य मुख्य बातें:

• AP2 A2A प्रोटोकॉल (एजेंट-टू-एजेंट, एजेंटों के लिए Google का पीयर मैसेजिंग मानक) का एक विस्तार है। यह A2A के ट्रांसपोर्ट के शीर्ष पर भुगतान मैंडेट सिमेंटिक्स जोड़ता है।
• यह कॉमर्स/चेकआउट परत के रूप में यूनिवर्सल कॉमर्स प्रोटोकॉल (UCP) के साथ एकीकृत होता है।
• यह x402 / स्टेबलकॉइन (USDC) को एक प्रथम-श्रेणी के भुगतान रेल के रूप में समर्थन करता है, न कि बाद के विचार के रूप में। यह सूक्ष्म-लेनदेन के लिए मायने रखता है जहाँ कार्ड इंटरचेंज ($0.50 से $0.80) लेनदेन मूल्य से अधिक होता है।
• स्पेसिफिकेशन का आधारभूत सत्य ap2-protocol.org है, न कि प्रेस कवरेज। सितंबर 2025 के अधिकांश लेख पुरानी शब्दावली का उपयोग करते हैं। मैं इसे वहीं चिह्नित करूँगा जहाँ यह मायने रखता है।

AP2 स्टैक में कहाँ स्थित है

यह वह चीज़ है जिसे मैं चाहता था कि किसी ने पहले दिन मेरे लिए स्पष्ट रूप से बनाया होता। एजेंटिक कॉमर्स स्टैक में पाँच विशिष्ट परतें हैं: विभिन्न प्रोटोकॉल, विभिन्न संगठन, विभिन्न समस्याओं का समाधान किया जा रहा है।

परत	प्रोटोकॉल	यह क्या करता है	संरक्षक
1	MCP	मॉडल कॉन्टेक्स्ट प्रोटोकॉल। खोज और टूलिंग: LLM बाहरी क्षमताओं को कैसे खोजते और लागू करते हैं	Anthropic
2	A2A	एजेंट-टू-एजेंट प्रोटोकॉल। ट्रांसपोर्ट: एजेंटकार्ड खोज के माध्यम से एजेंट भूमिकाओं के बीच पीयर HTTP मैसेजिंग	Google
3	AP2 (आप यहाँ हैं)	भुगतान प्राधिकरण: क्रिप्टोग्राफिक रूप से हस्ताक्षरित मैंडेट चेन, SD-JWT, ECDSA P-256, W3C वेरिफिएबल क्रेडेंशियल	Google / FIDO
4	ACP / UCP	चेकआउट HTTP एंडपॉइंट, कार्ट असेंबली, ऑर्डर पूर्ति सिमेंटिक्स	खुला स्पेसिफिकेशन
5	कार्ड, FedNow, x402	सेटलमेंट रेल: Mastercard, Visa, UPI, Pix, USDC स्टेबलकॉइन	नेटवर्क

MCP परिभाषित करता है कि एक एजेंट क्या पढ़ और कॉल कर सकता है। ACP परिभाषित करता है कि एक एजेंट कैसे खरीदता है। AP2 परिभाषित करता है कि उपयोगकर्ता का इरादा और मर्चेंट का शुल्क क्रिप्टोग्राफिक रूप से कैसे प्रमाणित होता है।

ये परतें एक साथ काम करती हैं। आप एक एजेंट को टूल देने के लिए MCP का उपयोग करते हैं। वे टूल अन्य एजेंटों को संदेश भेजने के लिए A2A एंडपॉइंट को लागू करते हैं। AP2 हस्ताक्षरित प्राधिकरण क्रेडेंशियल प्रदान करता है जो उन संदेशों के साथ यात्रा करते हैं। ACP/UCP चेकआउट API को परिभाषित करता है जिसे मर्चेंट उजागर करता है। रेल पैसे का निपटान करते हैं।

चित्र 1: पांच-परत वाला एजेंटिक कॉमर्स स्टैक। AP2 परत 3 पर, ट्रांसपोर्ट और सेटलमेंट के बीच स्थित है, जो क्रिप्टोग्राफिक प्राधिकरण श्रृंखला प्रदान करता है।

चार पक्ष

AP2 चार नामित भूमिकाओं को परिभाषित करता है। हर लेनदेन में इनमें से कुछ या सभी शामिल होते हैं:

भूमिका	वे क्या करते हैं	वास्तविक दुनिया के उदाहरण
शॉपिंग एजेंट	कीमतों की निगरानी करता है, निर्णय लेता है, मैंडेट की बाधाओं के भीतर उपयोगकर्ता की ओर से कार्य करता है	Claude Sonnet, Gemini शॉपिंग एजेंट, कोई भी LLM एजेंट
मर्चेंट एजेंट	AP2-संगत कार्ट एंडपॉइंट को उजागर करता है, Checkout Mandates को सत्यापित करता है, ऑर्डर पूरा करता है	TicketVault, कोई भी ACP-संगत मर्चेंट बैकएंड
क्रेडेंशियल प्रदाता	दोनों मैंडेट को सत्यापित करता है, शॉपिंग एजेंट को भुगतान क्रेडेंशियल जारी करता है	Mastercard Agent Pay, PayPal, Visa
पेमेंट प्रोसेसर	फंडिंग इंस्ट्रूमेंट के खिलाफ लेनदेन का निपटान करता है	कार्ड नेटवर्क, FedNow, Coinbase (x402)

Trusted Surface एक विशेष अवधारणा है: AP2-संगत क्लाइंट (वॉलेट या ऐप) जहाँ उपयोगकर्ता मैंडेट पर हस्ताक्षर करता है। इसे उपयोगकर्ता के डिजिटल हस्ताक्षर प्राधिकरण के रूप में सोचें। यह उपयोगकर्ता की ECDSA निजी कुंजी रखता है और शॉपिंग एजेंट के स्वायत्त रूप से कार्य करने से पहले खुले मैंडेट उत्पन्न करता है।

मैंडेट सिस्टम: मुख्य यांत्रिकी

शब्दावली नोट: कई लेख अभी भी लॉन्च-सप्ताह की तीन-मैंडेट वाली संरचना (Intent Mandate, Cart Mandate, Payment Mandate) का उपयोग करते हैं। v0.2 स्पेसिफिकेशन इसे दो मैंडेट प्रकारों में पुनर्गठित करता है, प्रत्येक में दो चरण होते हैं। पुरानी संरचना बासी है; v0.2 शब्दावली का उपयोग करें।

दो मैंडेट प्रकार

मैंडेट	के साथ साझा किया गया	यह क्या कैप्चर करता है
Checkout Mandate	मर्चेंट एजेंट	खरीद का अधिकार, आइटम का दायरा, मूल्य सीमा, मर्चेंट अनुमति सूची, TTL
Payment Mandate	क्रेडेंशियल प्रदाता / नेटवर्क	चार्ज करने का अधिकार, फंडिंग इंस्ट्रूमेंट टोकन, राशि की सीमा, श्रेणी प्रतिबंध

खुले बनाम बंद चरण

खुले और बंद के बीच का अंतर ह्यूमन-नॉट-प्रेजेंट भुगतानों के लिए पूरी व्यवस्था है।

	खुला चरण	बंद चरण
कब बनाया गया	मैंडेट सेटअप के समय, मानव उपस्थित	खरीद के समय, मानव अनुपस्थित
द्वारा हस्ताक्षरित	उपयोगकर्ता की वॉलेट कुंजी (ECDSA)	एजेंट की कुंजी (ECDSA)
सामग्री	बाधाएं, दायरा, TTL, अनुमति सूचियां	विशिष्ट कार्ट / सटीक राशि, चेकआउट हैश
उद्देश्य	स्थायी अधिकार	लेनदेन-विशिष्ट प्रमाण

ठोस उदाहरण: FIFA टिकट परिदृश्य

Checkout Mandate, खुला: “मैं अपने एजेंट को TicketVault पर अधिकतम $1,500 प्रत्येक के 2 Cat 3 FIFA टिकट खरीदने के लिए अधिकृत करता हूँ, 24 घंटे में समाप्त होता है।”

Checkout Mandate, बंद: “मैं 2 × Cat 3 $1,350 प्रत्येक पर खरीद रहा हूँ, कुल $2,700, checkout_hash: 0xABC...”

बंद Payment Mandate केवल Checkout Mandate बंद होने के बाद ही बनाया जा सकता है। इसमें बंद Checkout से checkout_hash शामिल होना चाहिए। स्पेसिफिकेशन इस अनुक्रमिक निर्भरता को लागू करता है।

चित्र 2: मैंडेट जीवनचक्र। खुले मैंडेट सेटअप के समय उपयोगकर्ता द्वारा हस्ताक्षरित होते हैं। बंद मैंडेट खरीद के समय एजेंट द्वारा हस्ताक्षरित होते हैं। Payment Mandate के लिए बंद Checkout Mandate से चेकआउट हैश की आवश्यकता होती है।

एक मैंडेट कैसा दिखता है

// Simplified mandate JSON (encoded as SD-JWT in practice)
{
  "id": "mandate_7A3F2026",
  "type": "checkout.open",
  "vct": "mandate.checkout.1",       // schema version, must match exactly
  "user_did": "did:key:z6Mk...",     // DID of user's wallet key
  "agent_did": "did:key:z6Mk...",    // DID of shopping agent
  "constraints": {
    "item_scope": "event-tickets",
    "max_unit_price": 1500,
    "max_quantity": 2,
    "currency": "USD",
    "merchant_allowlist": ["ticketvault.com"],
    "ttl": "2026-07-12T00:00:00Z"
  },
  "signature": "ECDSA_P256_sig_by_user_key..."  // MUST be ECDSA, NOT Ed25519
}

क्रिप्टोग्राफी: यह सिर्फ एक डेटाबेस रिकॉर्ड नहीं, बल्कि एक प्रोटोकॉल क्यों है

बहुत सारे “एजेंटिक भुगतान” समाधान केवल डेटाबेस रिकॉर्ड होते हैं: उपयोगकर्ता एक बॉक्स चेक करता है, ऐप authorized=true लिखता है, एजेंट इसे पढ़ता है। यह उस क्षण टूट जाता है जब आपके पास कई पक्ष होते हैं जो स्वाभाविक रूप से एक-दूसरे पर भरोसा नहीं करते हैं।

AP2 मैंडेट SD-JWTs (Selective Disclosure JSON Web Tokens) होते हैं जो ECDSA P-256 के साथ हस्ताक्षरित होते हैं। स्पेसिफिकेशन स्पष्ट है: Checkout JWT को ECDSA का उपयोग करके हस्ताक्षरित किया जाना चाहिए और Ed25519 का उपयोग नहीं करना चाहिए।

ECDSA क्यों, Ed25519 क्यों नहीं?

यह सूक्ष्म है और समझने लायक है। Ed25519 नियतात्मक है: एक ही संदेश और निजी कुंजी दिए जाने पर, यह हमेशा एक ही हस्ताक्षर उत्पन्न करता है। इसका मतलब है कि दो समान मैंडेट समान हस्ताक्षर हैश उत्पन्न करते हैं। एक हमलावर जो समय के साथ हस्ताक्षर एकत्र करता है, वह मैंडेट में एम्बेडेड checkout_hash दावे के खिलाफ एक रेनबो टेबल बना सकता है। ECDSA में प्रत्येक हस्ताक्षर ऑपरेशन के लिए एक यादृच्छिक नॉनस शामिल होता है, इसलिए प्रत्येक हस्ताक्षर समान मैंडेट सामग्री के लिए भी अद्वितीय होता है। कोई रेनबो टेबल हमला संभव नहीं है।

क्रिप्टोग्राफिक सूत्र

// From the CSA security framework for AP2
Sig_U(M) = ECDSA.Sign(K_U, Hash(M))

// Verification: any party can run this independently
Verify(M, Sig, PubKey_U) → boolean

// No API call to any central server required
// The credential is self-contained proof

पांच क्रिप्टोग्राफिक गारंटी

1. छेड़छाड़ का सबूत: हस्ताक्षर करने के बाद मैंडेट में कोई भी संशोधन ECDSA हस्ताक्षर को तोड़ देता है। मर्चेंट या क्रेडेंशियल प्रदाता इसे अस्वीकार कर देगा।
2. गैर-अस्वीकृति: उपयोगकर्ता खुले मैंडेट पर हस्ताक्षर करने से इनकार नहीं कर सकता। उनकी निजी कुंजी हस्ताक्षर प्राधिकरण है।
3. पोर्टेबिलिटी: श्रृंखला में हर पक्ष उपयोगकर्ता की सार्वजनिक कुंजी (DID के माध्यम से) का उपयोग करके स्वतंत्र रूप से सत्यापित करता है। कोई केंद्रीय प्राधिकरण नहीं। कोई फोन-होम नहीं।
4. दायरे का प्रवर्तन: बंद मैंडेट को खुले मैंडेट में सभी बाधाओं को पूरा करना चाहिए अन्यथा सत्यापन विफल हो जाता है। एजेंट उपयोगकर्ता के पूर्व-अधिकृत दायरे से अधिक नहीं हो सकता।
5. चयनात्मक प्रकटीकरण: SD-JWT एक मर्चेंट को Checkout Mandate को सत्यापित करते समय आइटम और मूल्य फ़ील्ड देखने की अनुमति देता है, बिना फंडिंग इंस्ट्रूमेंट टोकन देखे। फ़ील्ड प्रति पक्ष चयनात्मक रूप से प्रकट किए जाते हैं।

संवेदनशील पेलोड फ़ील्ड (जैसे फंडिंग इंस्ट्रूमेंट टोकन) को JWT में एम्बेड करने से पहले AES-GCM-256 के साथ एन्क्रिप्ट किया जाता है। उच्च-मूल्य वाले लेनदेन के लिए, स्पेसिफिकेशन हार्डवेयर-समर्थित कुंजी हस्ताक्षर (TPM/HSM) की सिफारिश करता है।

AP2 जारीकर्ता कुंजी खोज के लिए Decentralized Identifiers (DIDs) का उपयोग करता है: कोई प्रमाणपत्र प्राधिकरण नहीं, भरोसा करने के लिए कोई PKI पदानुक्रम नहीं। सत्यापन विशुद्ध रूप से क्रिप्टोग्राफिक है।

खतरे का मॉडल

AP2 अपने खतरे के मॉडल के लिए STRIDE का उपयोग करता है, जिसे बहु-एजेंट इकोसिस्टम के लिए MAESTRO फ्रेमवर्क द्वारा विस्तारित किया गया है। इसे जानना महत्वपूर्ण है क्योंकि यह ठीक वही दिखाता है जिसे AP2 हराने के लिए डिज़ाइन किया गया था।

खतरा (STRIDE)	हमला	AP2 शमन
स्पूफिंग	झूठे प्राधिकरण का दावा करने वाले जाली मैंडेट हस्ताक्षर	DID-आधारित PKI सत्यापन, HSM-समर्थित कुंजियाँ
छेड़छाड़	पारगमन में बदले गए मैंडेट की सामग्री (मूल्य, दायरा बदलें)	किसी भी संशोधन पर ECDSA हस्ताक्षर टूट जाता है, TLS 1.3
अस्वीकृति	“मैंने इस खरीद को कभी अधिकृत नहीं किया”	खुले मैंडेट पर गैर-अस्वीकार्य ECDSA हस्ताक्षर और ऑडिट ट्रेल
जानकारी का खुलासा	भुगतान उपकरण मर्चेंट को उजागर किया गया	संवेदनशील फ़ील्ड पर AES-GCM-256, SD-JWT चयनात्मक प्रकटीकरण
उन्नयन	एजेंट मैंडेट के दायरे से अधिक हो जाता है (कुछ ऐसा खरीदता है जो अधिकृत नहीं है)	बंद मैंडेट में खुले मैंडेट की बाधाओं को क्रिप्टोग्राफिक रूप से सत्यापित किया गया
मतिभ्रम धोखाधड़ी	मॉडल त्रुटि के कारण LLM गलत चीज़ खरीदता है	सभी खरीद हस्ताक्षरित उपयोगकर्ता इरादे पर आधारित होती हैं, न कि संभाव्य मॉडल आउटपुट पर
एजेंट जबरदस्ती	मर्चेंट एजेंट को मैंडेट के बाहर खरीदने के लिए धोखा देता है	खुले मैंडेट में DID-आधारित मर्चेंट सत्यापन और merchant_allowlist

MAESTRO इसे उभरते बहु-एजेंट खतरों तक विस्तारित करता है: मॉडल पॉइज़निंग, वर्कफ़्लो हाइजैकिंग, इकोसिस्टम मिलीभगत। उच्च-मूल्य वाले लेनदेन के लिए, स्पेसिफिकेशन मैंडेट बंद होने से पहले बहु-एजेंट आम सहमति की आवश्यकताएं की सिफारिश करता है।

प्रवाह: ह्यूमन-प्रेजेंट और ह्यूमन-नॉट-प्रेजेंट

ह्यूमन-प्रेजेंट फ्लो

यह सरल मामला है। भुगतान होने पर उपयोगकर्ता कीबोर्ड पर होता है। Trusted Surface मैंडेट बंद करने से पहले हस्ताक्षर के लिए उपयोगकर्ता को विशिष्ट कार्ट प्रस्तुत करता है।

1. शॉपिंग एजेंट ACP एंडपॉइंट के माध्यम से मर्चेंट पर कार्ट असेंबल करता है
2. एजेंट कार्ट और खुले मैंडेट को Trusted Surface (उपयोगकर्ता का वॉलेट या ऐप) को प्रस्तुत करता है
3. उपयोगकर्ता समीक्षा करता है और हस्ताक्षर करता है, जिससे बंद Checkout Mandate (उपयोगकर्ता द्वारा हस्ताक्षरित, विशिष्ट कार्ट) उत्पन्न होता है
4. उपयोगकर्ता बंद Payment Mandate पर हस्ताक्षर करता है (Checkout हैश को संदर्भित करता है)
5. एजेंट दोनों बंद मैंडेट को Credentials Provider को प्रस्तुत करता है
6. Credentials Provider सत्यापित करता है और एक भुगतान क्रेडेंशियल जारी करता है
7. एजेंट क्रेडेंशियल के साथ मर्चेंट पर चेकआउट पूरा करता है। इसके बाद सेटलमेंट होता है।

ह्यूमन-नॉट-प्रेजेंट फ्लो (v0.2 का प्रमुख)

यह वह है जो एजेंटिक कॉमर्स के लिए मायने रखता है। उपयोगकर्ता ने अग्रिम रूप से बाधाएं निर्धारित कीं; ट्रिगर सक्रिय होने पर एजेंट स्वायत्त रूप से कार्य करता है, संभवतः घंटों या दिनों बाद।

चरण 0 ही सब कुछ है। सेटअप चरण वह है जब मानव उपस्थित होता है। उसके बाद, एजेंट पूरी तरह से स्वायत्त रूप से कार्य करता है। क्रिप्टोग्राफी सीमा को लागू करती है, न कि प्रत्येक लेनदेन को अनुमोदित करने वाला मानव।

सेटअप (मानव उपस्थित, एक बार): उपयोगकर्ता एक खुला Checkout Mandate (बाधाएं, TTL, मर्चेंट दायरा) और एक खुला Payment Mandate (इंस्ट्रूमेंट, राशि की सीमा) पर हस्ताक्षर करता है। दोनों शॉपिंग एजेंट / Trusted Surface द्वारा संग्रहीत किए जाते हैं।

… समय बीतता है। उपयोगकर्ता सो जाता है। सुबह 2 बजे कीमत गिरती है। ट्रिगर सक्रिय होता है …

1. शॉपिंग एजेंट ट्रिगर स्थिति का पता लगाता है (लक्ष्य पर या उससे कम कीमत)
2. एजेंट मर्चेंट से क्वेरी करता है और एक Cart Mandate (मर्चेंट द्वारा हस्ताक्षरित, विशिष्ट SKU और कीमत) प्राप्त करता है
3. एजेंट सत्यापित करता है कि कार्ट सभी खुले Checkout Mandate बाधाओं को पूरा करता है (कीमत सीमा पर या उससे कम, अनुमति सूची में मर्चेंट, TTL समाप्त नहीं हुआ)
4. एजेंट बंद Checkout Mandate पर हस्ताक्षर करता है (एजेंट कुंजी, विशिष्ट कार्ट, checkout_hash)
5. एजेंट बंद Checkout Mandate को मर्चेंट को प्रस्तुत करता है, जो खुले (उपयोगकर्ता) और बंद (एजेंट) दोनों हस्ताक्षरों को सत्यापित करता है
6. एजेंट बंद Payment Mandate पर हस्ताक्षर करता है (चरण 4 से checkout_hash को संदर्भित करता है)
7. एजेंट दोनों मैंडेट को Credentials Provider को प्रस्तुत करता है, जो पूरी श्रृंखला को सत्यापित करता है
8. Credentials Provider भुगतान क्रेडेंशियल जारी करता है
9. एजेंट क्रेडेंशियल के साथ मर्चेंट पर चेकआउट पूरा करता है। सेटलमेंट होता है; ऑडिट ट्रेल पूरा हो जाता है।

चित्र 3: ह्यूमन-नॉट-प्रेजेंट फ्लो। चार पक्ष, दो मैंडेट प्रकार, नौ क्रमांकित चरण। पूरी श्रृंखला क्रिप्टोग्राफिक रूप से जुड़ी हुई है।

यह मर्चेंट से कैसे जुड़ता है: यह MCP नहीं है

वह सवाल जो मैं शुरुआत में पूछता रहा: मैंडेट वास्तव में मेरे एजेंट से TicketVault तक कैसे पहुँचता है?

उत्तर: A2A HTTP कॉल के माध्यम से, MCP के माध्यम से नहीं।

MCP टूल और संदर्भ परत है। यह वह तरीका है जिससे Claude (या कोई भी LLM) search_inventory या create_mandate को कॉल करने योग्य टूल के रूप में एक्सेस करता है। LLM उन टूल के साथ क्या करता है (शॉपिंग एजेंट और मर्चेंट एजेंट के बीच के संदेश) A2A है। मैंडेट क्रेडेंशियल पेलोड हैं, न कि MCP टूल परिणाम।

MCP परिभाषित करता है कि एक एजेंट क्या पढ़ और कॉल कर सकता है। मैंडेट A2A कॉल के साथ साक्ष्य कलाकृतियों के रूप में ले जाए जाते हैं, न कि MCP द्वारा स्वयं उत्पन्न किए जाते हैं।

एक वास्तविक AP2 परिनियोजन में, TicketVault का प्रवाह इस प्रकार होगा:

1. शॉपिंग एजेंट TicketVault के AP2 मर्चेंट A2A एंडपॉइंट पर एक हस्ताक्षरित Checkout Mandate (SD-JWT) POST करता है
2. TicketVault का मर्चेंट एजेंट मान्य करता है: हस्ताक्षर सत्यापन, फिर बाधा जांच, फिर चेकआउट हैश मिलान
3. TicketVault एक Checkout रसीद (मर्चेंट द्वारा हस्ताक्षरित) लौटाता है
4. शॉपिंग एजेंट उस रसीद और Payment Mandate को Credentials Provider के A2A एंडपॉइंट पर ले जाता है

हमारे डेमो में, हम इसे एक ही Node.js BFF के भीतर अनुकरण करते हैं: Camunda वर्कर्स वितरित एजेंट भूमिकाएं निभाते हैं, और SSE उनके बीच A2A कॉल को प्रतिस्थापित करता है। यांत्रिकी वास्तविक हैं; वितरण अनुकरण किया गया है। एक डेमो के लिए ईमानदार सरलीकरण।

भुगतान रेल: जानबूझकर मल्टी-रेल

AP2 कार्ड रेल और क्रिप्टो के बीच विजेता नहीं चुनता है। यह उन सभी के लिए विस्तार बिंदु परिभाषित करता है:

रेल	AP2 में यह कैसे काम करता है	इसके लिए सबसे अच्छा
कार्ड नेटवर्क	Mastercard Agent Pay, Visa: Credentials Provider द्वारा जारी टोकनाइज्ड कार्ड क्रेडेंशियल	उच्च-मूल्य वाली उपभोक्ता खरीद, मौजूदा बैंक संबंध
रीयल-टाइम भुगतान	FedNow, UPI, Pix: बैंक हस्तांतरण क्रेडेंशियल	उच्च-मूल्य वाले B2B, ऐसे बाजार जहाँ रीयल-टाइम बैंक हस्तांतरण का प्रभुत्व है
x402 / USDC	एजेंट सीधे एक स्मार्ट वॉलेट रखता है, Base/Ethereum पर USDC, तत्काल सेटलमेंट	सूक्ष्म-लेनदेन, API-से-API भुगतान, कोई इंटरचेंज फ्लोर नहीं

x402 सूक्ष्म-लेनदेन के लिए विशेष रूप से दिलचस्प है। पारंपरिक कार्ड इंटरचेंज की लागत राशि की परवाह किए बिना प्रति लेनदेन $0.50 से $0.80 होती है। एक एजेंट जो एक API कॉल के लिए $0.01 का भुगतान कर रहा है, वह आर्थिक रूप से कार्ड रेल का उपयोग नहीं कर सकता। x402 और स्टेबलकॉइन इसका समाधान करते हैं: एजेंट USDC रखता है, सीधे ऑन-चेन भुगतान करता है, और बहु-चरणीय प्रतिबद्धताओं के लिए प्रोग्रामेबल एस्क्रो का उपयोग कर सकता है।

अप्रैल 2026 तक तीन नामित सार्वजनिक AP2 परिनियोजन: PayPal का वॉलेट और Google Cloud Conversational Commerce Agent, PayPal के भीतर Mastercard Agent Pay पायलट, और क्रिप्टो भुगतानों के लिए A2A x402 एक्सटेंशन।

हमारा डेमो वास्तविक AP2 से कैसे मेल खाता है

मैंने Agents, Orchestrated के EP 03 के लिए एक Camunda 8 + AP2-आकार का डेमो बनाया। यहाँ ईमानदार मैपिंग है:

हमारा डेमो (Camunda 8 BFF)	वास्तविक AP2
mandateService.js मैंडेट JSON (ES256) बनाता और हस्ताक्षर करता है	Trusted Surface और शॉपिंग एजेंट वास्तविक DID कुंजी प्रबंधन के साथ उचित उपयोगकर्ता-हस्ताक्षरित खुले मैंडेट रखते हैं
Camunda DMN खर्च नीति (ह्यूमन-इन-द-लूप, कैप, वेलोसिटी)	खुले मैंडेट बाधाओं और क्रेडेंशियल प्रदाता के नीति इंजन में एम्बेडेड
SSE इवेंट TicketVault मर्चेंट साइट को चलाते हैं	शॉपिंग एजेंट मर्चेंट एजेंट के A2A एंडपॉइंट पर Checkout Mandate POST करता है (मानक HTTP)
merchant.completeCheckout Camunda वर्कर	विशिष्ट मर्चेंट एजेंट बाइनरी मैंडेट को सत्यापित करता है और ACP चेकआउट निष्पादित करता है
credentials.issueToken Camunda वर्कर	क्रेडेंशियल प्रदाता एजेंट मैंडेट जोड़ी को सत्यापित करता है और भुगतान क्रेडेंशियल जारी करता है
Zeebe उपयोगकर्ता कार्य task_desk_approval (ह्यूमन-इन-द-लूप)	AP2 ह्यूमन-इन-द-लूप एस्केलेशन निर्धारित नहीं करता है; Camunda प्रोटोकॉल के शीर्ष पर इसे शासन के रूप में जोड़ता है

Camunda परत वह जगह है जहाँ हम शासन जोड़ते हैं जिसे AP2 स्वयं अनिवार्य नहीं करता है: DMN खर्च नीति, कैप के 95% पर ह्यूमन-इन-द-लूप एस्केलेशन, पूर्ण प्रक्रिया ऑडिट ट्रेल। AP2 प्राधिकरण प्रोटोकॉल है। Camunda शीर्ष पर शासन ऑर्केस्ट्रेटर है।

v0.2 ने क्या जोड़ा (अप्रैल 2026)

मुख्य विशेषता ह्यूमन-नॉट-प्रेजेंट भुगतान है: एजेंट एक इंटरैक्टिव सहमति प्रॉम्प्ट के बिना पूर्व-अधिकृत लेनदेन को निष्पादित कर सकते हैं, खुले/बंद मैंडेट जोड़ी का उपयोग करके।

• तीन मैंडेट प्रकारों (Intent/Cart/Payment) से दो (Checkout/Payment) में पुनर्गठित किया गया, जिसमें खुले और बंद चरण शामिल हैं
• SD-JWT को मैंडेट एन्कोडिंग मानक के रूप में औपचारिक रूप दिया गया
• स्पेसिफिकेशन में ECDSA MUST / Ed25519 MUST NOT अंतर को स्पष्ट रूप से जोड़ा गया
• x402 / स्टेबलकॉइन रेल के लिए प्रथम-श्रेणी के भुगतान प्रकार के रूप में आधिकारिक समर्थन पेश किया गया
• Python, Go, TypeScript, Kotlin और Android में संदर्भ कार्यान्वयन
• एजेंटिक प्रमाणीकरण और भुगतान तकनीकी कार्य समूह के माध्यम से FIDO Alliance मानकीकरण

एक-पैराग्राफ संस्करण

AP2 एजेंट-आरंभिक भुगतानों के लिए Google का खुला प्रोटोकॉल है। यह एक समस्या का अच्छी तरह से समाधान करता है: एक मानव एजेंट को सीमित खर्च करने का अधिकार कैसे सौंपता है, इस तरह से कि लेनदेन श्रृंखला में हर पक्ष स्वतंत्र रूप से सत्यापित कर सके, एक-दूसरे पर भरोसा किए बिना या किसी केंद्रीय प्राधिकरण को फोन किए बिना? यह एक दो-मैंडेट सिस्टम के माध्यम से ऐसा करता है, एक Checkout Mandate (एजेंट से मर्चेंट तक) और एक Payment Mandate (एजेंट से क्रेडेंशियल प्रदाता तक), जहाँ प्रत्येक मैंडेट में एक खुला चरण (उपयोगकर्ता पूर्व-हस्ताक्षर बाधाएं) और एक बंद चरण (एजेंट विशिष्ट लेनदेन पर हस्ताक्षर करता है) होता है। क्रेडेंशियल ECDSA P-256 के साथ हस्ताक्षरित SD-JWTs होते हैं, जो उन्हें छेड़छाड़-प्रूफ और पोर्टेबल बनाते हैं। AP2 A2A ट्रांसपोर्ट प्रोटोकॉल और ACP/UCP चेकआउट परत के बीच प्राधिकरण परत पर स्थित है। यह MCP नहीं है, और यह एक भुगतान गेटवे नहीं है। यह कार्ड रेल, रीयल-टाइम भुगतान और स्टेबलकॉइन पर काम करता है। v0.2 का प्रमुख परिदृश्य ह्यूमन-नॉट-प्रेजेंट है: एजेंट स्वायत्त रूप से कार्य करता है जबकि उपयोगकर्ता सो रहा होता है, क्रिप्टोग्राफिक बाधाओं से सीमित होता है जिन्हें उन्होंने अग्रिम रूप से निर्धारित किया था।

स्वायत्तता एक बुनियादी आवश्यकता है। एजेंट के चारों ओर की हर चीज़ ही उसकी सुरक्षा है।

संदर्भ

• AP2 स्पेसिफिकेशन: ap2-protocol.org (मैंडेट प्रकार, SD-JWT एन्कोडिंग, ECDSA आवश्यकताओं, पक्ष भूमिकाओं के लिए आधारभूत सत्य)
• Google Cloud: AP2 की घोषणा (लॉन्च संदर्भ, 60+ पार्टनर, FIDO Alliance दान घोषणा)
• AP2 GitHub: google-agentic-commerce/AP2 (Python, Go, TypeScript, Kotlin और Android में संदर्भ कार्यान्वयन, साथ ही चलाने योग्य परिदृश्य)
• क्लाउड सिक्योरिटी अलायंस: AP2 का सुरक्षित उपयोग (STRIDE खतरे का मॉडल, ECDSA P-256 सूत्र, MAESTRO फ्रेमवर्क, AES-GCM-256)
• ACP बनाम AP2 बनाम MCP: प्रोटोकॉल स्टैक तुलना (एजेंटिक कॉमर्स स्टैक का परत-दर-परत विश्लेषण)
• Eco: AP2 v0.2 समझाया गया (v0.2 मैंडेट पुनर्गठन, ह्यूमन-नॉट-प्रेजेंट फ्लो, कुंजी खोज के लिए DIDs)
• Cobo एजेंटिक वॉलेट: AP2 पूर्ण गाइड (x402 विवरण, स्टेबलकॉइन रेल, बहु-पक्षीय वॉलेट एकीकरण)
• UCP: AP2 मैंडेट्स एक्सटेंशन (AP2 चेकआउट परत पर यूनिवर्सल कॉमर्स प्रोटोकॉल के साथ कैसे एकीकृत होता है)
• Google Codelabs: AP2 और UCP के साथ सुरक्षित एजेंट कॉमर्स (आधिकारिक Google ADK के खिलाफ हैंड्स-ऑन कार्यान्वयन)
• arXiv: AP2 के लिए जीरो-ट्रस्ट रनटाइम सत्यापन (AP2 में रीप्ले हमलों और संदर्भ-बाध्यकारी विफलताओं का अकादमिक उपचार)
• AP2: यूरोपीय संघ का परिप्रेक्ष्य (एजेंटिक भुगतानों के लिए यूरोपीय नियामक और मानकीकरण संदर्भ)
• AP2 तकनीकी गाइड: मीडियम / विशाल मैसूर (कोड उदाहरणों के साथ कार्यान्वयन वॉकथ्रू)