- AI एजेंट स्वायत्त रूप से खरीद, भुगतान और सेटलमेंट कर सकें, इसके लिए कई पेमेंट प्रोटोकॉल समानांतर रूप से उभर रहे हैं
- ACP, UCP, AP2, x402 आदि सभी भुगतान से जुड़े हैं, लेकिन commerce·B2B·एजेंट-टू-एजेंट पेमेंट जैसे अलग-अलग समस्या क्षेत्रों को लक्षित करते हैं
- इंटरनेट मूल रूप से जानकारी के आदान-प्रदान के लिए डिज़ाइन किया गया था, इसलिए इसमें payment layer मौजूद नहीं थी; HTTP 402 status code 1997 में परिभाषित हुआ था, लेकिन व्यवहार में लागू नहीं हुआ
- एजेंट लेनदेन में trust layer पेमेंट से पहले की पूर्वशर्त के रूप में उभर रही है, और ERC-8004 तथा Visa TAP जैसे प्रोटोकॉल यह भूमिका निभाते हैं
- commerce क्षेत्र में OpenAI·Stripe का ACP और Google·Shopify का UCP मुख्य धुरी बन रहे हैं, और ये क्रमशः ChatGPT तथा Gemini वातावरण में उपयोग हो रहे हैं
- एजेंट-टू-एजेंट पेमेंट computing·data·API उपयोग के लिए बड़े पैमाने के micropayments की संभावना खोलते हैं, और स्वायत्त resource trading संरचना का संकेत देते हैं
- आगे चलकर agent economy किसी एक standard पर नहीं, बल्कि अलग भूमिकाओं वाले प्रोटोकॉल के layered stack के रूप में विकसित होने की अधिक संभावना है
एजेंटिक पेमेंट प्रोटोकॉल्स के फैलाव की पृष्ठभूमि
- ACP, UCP, A2P, AXTP, x402 जैसे कई संक्षिप्त नाम सामने आ रहे हैं, जिससे agentic payments क्षेत्र कुछ भ्रमित दिखता है
- प्रोटोकॉल अधिक होने का कारण यह है कि वे सभी एक ही समस्या हल नहीं कर रहे
- commerce, B2B payments, और agent-to-agent payments की आवश्यकताएँ और सीमाएँ अलग-अलग हैं
- इन्हें एक ही समस्या मान लेने पर संरचना को समझना और कठिन हो जाता है
इंटरनेट प्रोटोकॉल की संरचना और payment layer की अनुपस्थिति
- इंटरनेट में TCP/IP, DNS, HTTP/S जैसे कई प्रोटोकॉल साथ मिलकर काम करते हैं और एक सहज user experience बनाते हैं
- TCP/IP: addressing, routing और data के reliable transmission की ज़िम्मेदारी
- DNS: मनुष्यों के लिए पढ़ने योग्य domain name को IP address में बदलता है
- HTTP/S: web page और media request/transfer को संभालता है; HTTPS encryption के जरिए security बढ़ाता है
- gRPC, WebSocket जैसे नए प्रोटोकॉल लगातार जुड़ते रहे हैं, इसलिए इंटरनेट स्थिर संरचना नहीं बल्कि विकसित होता सिस्टम है
- HTTP status code 402(Payment Required) 1997 में परिभाषित हुआ था, लेकिन वास्तव में कभी उपयोग में नहीं आया
- इंटरनेट शुरू से जानकारी के आदान-प्रदान के लिए डिज़ाइन हुआ था, और payments को बाद में अलग financial systems के जरिए जोड़ा गया
- browser से शुरू हुई request क्रमवार merchant, payment gateway, और Visa·ACH जैसे financial networks तक जाती है
- ‘cart में जोड़ने’ से लेकर ‘payment settlement’ तक पूरे flow को कवर करने वाला कोई एकल payment protocol मौजूद नहीं है
एजेंट्स ने payment layer की कमी को उजागर किया
- keyboard और screen को ध्यान में रखकर बनी मौजूदा infrastructure मशीन गति से निर्णय लेकर काम करने वाले software agents के लिए उपयुक्त नहीं है
- जब एजेंट इंसानों की ओर से खरीदारी करते हैं, तो नई समस्याएँ सामने आती हैं
- नया customer type: एजेंट को खुद तय करना होता है कि किस store और product का चयन करना है, और merchants को non-human agents के लिए optimization करनी पड़ती है
→ Agent Engine Optimization(AEO) की अवधारणा उभर रही है
- नया payment channel: chat interface ही payment window बन जाता है, जिससे conversion funnel, A/B testing और cart-abandonment mail जैसी मौजूदा तकनीकों का महत्व घटता है
- नया fraud risk: तुरंत सत्यापित करना पड़ता है कि एजेंट अधिकृत user और वैध payment credentials का उपयोग कर रहा है या चोरी हुए credentials का automated दुरुपयोग कर रहा है
trust layer: लेनदेन पक्ष की पुष्टि
- MCP और A2A एजेंट-टू-एजेंट communication को संभालते हैं, लेकिन ERC-8004 specification स्पष्ट करती है कि वे agent discovery और trust को मूल रूप से संबोधित नहीं करते
- एजेंटों के बीच transaction से पहले वैधता की पुष्टि होनी चाहिए, और merchants को अंधाधुंध bots के बजाय केवल भरोसेमंद agents को अनुमति देनी चाहिए
- इसे हल करने के लिए दो approaches सामने आई हैं
- ERC-8004(Trustless Agents): MetaMask, Google, Coinbase, Ethereum Foundation की भागीदारी वाला on-chain identity·reputation·verification registry, जो Draft EIP चरण में है
- agent registration जानकारी में MCP endpoint, A2A agent card, ENS name, DID आदि भी दर्ज किए जा सकते हैं
- यह मौजूदा agent communication protocols को replace नहीं करता, बल्कि trust और identity जानकारी को supplement करता है
- Visa Trusted Agent Protocol(TAP): Visa द्वारा विकसित किया जा रहा protocol, जो merchants को भरोसेमंद agents और सामान्य bots में अंतर करने के लिए verifiable signature देता है
- यह प्रमाणित करता है कि एजेंट commerce उद्देश्य वाला Visa trusted agent है
- loyalty account या device identifier के जरिए यह भी पुष्टि की जा सकती है कि वह किसी विशिष्ट consumer की ओर से काम कर रहा है
- merchant साथ ही verifiable valid payment credentials की भी पुष्टि कर सकता है
- मुख्य बात: trust ही payment की शुरुआत है; “भुगतान कैसे होगा” से पहले “क्या इस एजेंट पर भरोसा किया जा सकता है” का समाधान ज़रूरी है
commerce protocols: सबसे तेज़ी से विस्तार करता क्षेत्र
- agentic commerce वह संरचना है जिसमें product discovery, selection और payment जैसे खरीद के पूरे क्षण को एजेंट को सौंप दिया जाता है
- इसे standardize करने के लिए दो प्रमुख protocols उभर रहे हैं
- Agentic Commerce Protocol(ACP): OpenAI और Stripe द्वारा संयुक्त रूप से विकसित protocol, जो cart बनाने और PSP को भेजे जाने वाले payment token बनाने का तरीका परिभाषित करता है
- ChatGPT वातावरण में Walmart, Etsy, Instacart के साथ वास्तविक संचालन में है
- cart structure, payment token generation, और checkout completion प्रक्रिया को स्पष्ट रूप से परिभाषित करने वाला transaction-केंद्रित standard
- Universal Commerce Protocol(UCP): Google और Shopify के नेतृत्व वाला protocol, जिसमें merchant खुद ऐसा server कॉन्फ़िगर करता है जिसे agents देख सकें
- इसे Google Search और Gemini में क्रमशः लागू किया जाना है
- merchant capability manifest प्रकाशित करता है और agent उसे discover और negotiate करता है; यह एक orchestration framework है
- commerce क्षेत्र में DNS जैसी भूमिका निभाता है
- संरचनात्मक अंतर: UCP की शुरुआती implementation cost अधिक है, लेकिन यह पूरे flow में अधिक flexibility देता है; ACP को मौजूदा payment systems के साथ जोड़ना अपेक्षाकृत आसान है
- ChatGPT और Gemini दोनों में दिखना है तो ACP और UCP दोनों को साथ सपोर्ट करना पड़ सकता है
payment network स्तर के protocols
- Visa Intelligent Commerce(VIC): Visa द्वारा विकसित protocol, जो agents को Visa network पर payment पूरा करने के लिए card-जैसा secure token देता है
- फिलहाल testing चरण में है और 2026 की दूसरी छमाही में लॉन्च होने की योजना है
- Mastercard Agent Pay(MAP): Mastercard द्वारा विकसित protocol, जो Mastercard network में उपयोग योग्य secure token बनाता है
- यह भी testing चरण में है और 2026 की दूसरी छमाही में लॉन्च होने की योजना है
- दोनों standards की संरचना और उद्देश्य लगभग समान हैं; मुख्य अंतर यह है कि वे केवल अपने-अपने payment network पर ही काम करते हैं
- network स्तर पर जारी tokens के जरिए consumer protection, chargeback handling, और fraud response मौजूदा card payments की तरह ही बनाए रखे जा सकते हैं
B2B payment flows की अलग आवश्यकताएँ
- consumer commerce ध्यान खींचता है, लेकिन वास्तविक transaction volume B2B payments में कहीं अधिक है
- invoice payments, supplier payouts, payroll disbursement आदि enterprise settlements का बड़ा हिस्सा बनाते हैं
- B2B payment flows की विशेषताएँ
- payment amount बड़ा होता है और execution के बाद उसे पलटना कठिन होता है
- invoice matching, approval process, audit trail जैसे internal controls की ज़रूरत होती है
- ACH या wire transfer जैसे rails का उपयोग होता है, जो धीमे हैं लेकिन संरचनात्मक रूप से अधिक flexible हैं
- इस क्षेत्र में कई बार agents किसी मध्यवर्ती layer से गुजरने के बजाय payment rails से सीधे communicate करते हैं
- उपयोग में आने वाले payment rails
- stablecoins(USDC, USDT): on-chain सीधे payment होता है, और transaction के भीतर rules और logic शामिल किए जा सकते हैं
- Catena Labs, Payman जैसी कंपनियाँ इसका वास्तविक उपयोग कर रही हैं
- पारंपरिक rails(ACH, Wire): agent payment जानकारी तैयार करता है और फिर उसे मौजूदा financial rail पर भेजता है
- stablecoins card payments जैसी success assurance और उच्च programmability देते हैं, लेकिन पूरे उद्योग में स्वीकृत कोई स्पष्ट standard अभी नहीं बना है
agent-to-agent payments: सबसे बड़ी संभावना
- इंटरनेट के अधिकांश मूल्यवान resources API keys और subscription models के पीछे बंधे हुए हैं
- मौजूदा approach में account बनाना, prepaid balance भरना और key जारी होने के बाद ही service उपयोग की जा सकती है
- जब अरबों agents code लिखें, आपस में लेनदेन करें और ज़रूरत पड़ने पर resources उपयोग करें, तब यह मॉडल scale नहीं करता
- अभी दिख रही दो प्रमुख friction points
- token depletion समस्या: यदि agent काम के बीच limit तक पहुँच जाए, तो किसी इंसान को manually top-up करना पड़ता है, तभी काम जारी रह सकता है
- API key समस्या: हर नई service की ज़रूरत पर user को खुद signup करके credentials बनाकर agent को देने पड़ते हैं
- इन सीमाओं के कारण agents को पूरी autonomy नहीं मिलती और वे ऐसे junior developer जैसी स्थिति में रह जाते हैं जिन्हें corporate card या core credentials नहीं सौंपे जा सकते
agent-native protocols
- Google Agent to Pay(AP2): A2A framework का हिस्सा, जो यह परिभाषित करता है कि इंसान एजेंट को payment authority delegate करने के लिए किस तरह की mandate संरचना देगा
- यह abstract layer protocol है, जिसे x402, UCP के साथ काम करने के लिए डिज़ाइन किया गया है; यह उनसे mutually exclusive नहीं है
- verifiable credentials के आधार पर निम्न mandates अलग किए जाते हैं
- cart mandate: एजेंट क्या खरीद सकता है, उसकी सीमा
- intent mandate: इंसान वास्तव में क्या चाहता है
- payment mandate: stored payment credentials
- HTTP x402: Coinbase और Cloudflare द्वारा विकसित तरीका, जिसमें restricted resource पर request आने पर HTTP 402 लौटाया जाता है और stablecoin payment की ओर निर्देशित किया जाता है
- Base network और Cloudflare environment में testing चल रही है
- Agent Transaction Protocol(AXTP): Circuit और Chisel द्वारा विकसित किया जा रहा protocol, जो agents को MCP server उपयोग की लागत चुकाने या उसके बदले revenue कमाने में सक्षम बनाने के लिए डिज़ाइन किया गया है
- computing resources, data, और API call units के हिसाब से तुरंत विभाजित होने वाले बड़े पैमाने के micropayments संभव हो सकते हैं, जिससे उन क्षेत्रों में भी भारी नया transaction volume बन सकता है जिनका अब तक सही monetization नहीं हुआ
समग्र protocol संरचना और आगे की दिशा
- इस समय agentic payments ecosystem अभी व्यवस्थित न हुआ मिश्रित परिदृश्य है
- Google-केंद्रित stack बनता दिख रहा है: A2A → AP2 → UCP जैसी संरचना उभर रही है, जो commerce और non-commerce payments दोनों को कवर करती है
- हर protocol अलग abstraction layer पर अपनी भूमिका निभाता है
- agent communication layer: agents के बीच message exchange के तरीके standardize करना (MCP, A2A)
- trust layer: agent identity और trustworthiness का आकलन, identity·reputation management (ERC-8004, Visa TAP)
- delegation layer: payment authority और credentials की उपलब्धता की पुष्टि (AP2 mandates, VIC/MAP tokens)
- transaction flow layer: क्या खरीदा जाए और भुगतान कैसे हो, इसके लिए discovery·negotiation·checkout का प्रबंधन (ACP, UCP)
- authentication layer: transaction की वैधता, security, fraud prevention, cancellation handling
- payment rails layer: वास्तविक payment execution, card·ACH·stablecoin का उपयोग
प्रमुख संकेत
- मौजूदा standards अभी भी निर्माण चरण में हैं, अधूरे हैं और इनका adoption सीमित है
- भविष्य में इनमें से कुछ WAP या Betamax की तरह गायब भी हो सकते हैं
- लेकिन यह तभी होगा जब AI agents खुद ही गायब हो जाएँ, जिसकी संभावना कम है
- merchants, payment providers और financial institutions को जिन बातों पर ध्यान देना चाहिए
- Google का प्रभाव: इंटरनेट standards को दिशा देने का उसका इतिहास रहा है, इसलिए A2A·AP2 और संबंधित stack के लंबे समय तक टिके रहने की संभावना अधिक है
- commerce-first रणनीति: ACP और UCP को सपोर्ट करने पर ChatGPT और Gemini, दोनों प्रमुख consumer LLM environments में visibility मिल सकती है
- trust infrastructure का महत्व: जैसे-जैसे agent traffic बढ़ेगा, identity और reputation की समस्या और जटिल होगी; ERC-8004 और Visa TAP इसी बिंदु को संबोधित करते हैं
- B2B payments का अवसर: बड़ा transaction volume वाला क्षेत्र, जहाँ standards अभी तय नहीं हुए हैं; stablecoin adoption बढ़ रहा है, पर स्पष्ट benchmark नहीं है
- agent-native payments की क्षमता: तेज़, सस्ते, हमेशा चालू और programmable stablecoins एक मजबूत समाधान हो सकते हैं; x402 एक शुरुआती बिंदु है, पर अभी परिपक्व नहीं
- अगला agentic payments परिदृश्य प्रोटोकॉल्स के संयोजन और layers के बीच capability inheritance के जरिए बनने की संभावना रखता है
- ऐसे software की ओर बदलाव, जो खुद resources खोजे, शर्तों पर negotiation करे और भुगतान करे, कौन सा standard बचेगा इससे परे, पहले से जारी है
अभी कोई टिप्पणी नहीं है.