x402 प्रोटोकॉल: HTTP 402 पेमेंट्स से एक्सेस कैसे करें

X402 प्रोटोकॉल एक ओपन, HTTP-नैटिव भुगतान मानक है जो HTTP 402 “भुगतान आवश्यक” प्रतिक्रिया के साथ मानकीकृत हेडर का उपयोग करता है ताकि एक क्लाइंट को सर्वर द्वारा संसाधन लौटाने से पहले भुगतान करने के लिए मजबूर किया जा सके। यह एक सामान्य API कॉल को एक निश्चित उद्धरण → भुगतान → सत्यापन/निपटान → रसीद प्रवाह में बदल देता है, जिसमें नेटवर्कों के बीच सत्यापन और निपटान को संभालने के लिए वैकल्पिक तृतीय-पक्ष सेवाएं होती हैं।

मुख्य निष्कर्ष

• x402 HTTP 402 “भुगतान आवश्यक” और मानकीकृत हेडर का उपयोग करता है ताकि एक सर्वर सेवा देने से पहले भुगतान की मांग कर सके।APIप्रतिक्रिया या वेब संसाधन।
• मुख्य हैंडशेक है 402 + PAYMENT-REQUIRED (उद्धरण) → PAYMENT-SIGNATURE (भुगतान पेलोड) के साथ पुनः प्रयास करें → सत्यापित करें और निपटान करें → 200 + PAYMENT-RESPONSE (रसीद)।
• x402 एक भुगतान योजना को एक विशिष्ट नेटवर्क कार्यान्वयन के साथ जोड़कर नेटवर्क-निष्पक्ष रहता है, और यह सत्यापन और निपटान को एक सुविधा प्रदाता को आउटसोर्स कर सकता है।
• Solanax402 को श्रृंखला-विशिष्ट आंकड़ों के साथ विपणन करता है, जिसमें ~400ms अंतिमता, ~$0.00025 लेनदेन लागत, और Solana पर लॉन्च के बाद से 35M+ x402 लेनदेन और $10M+ मात्रा शामिल है।

X402 एक HTTP भुगतान मानक के रूप में

x402 प्रोटोकॉल में मुख्य कदम यह है कि भुगतान एक पहले दर्जे का HTTP प्रतिक्रिया पैटर्न बन जाता है, न कि एक ऐप-विशिष्ट बिलिंग प्रणाली जो बाद में जोड़ी जाती है। एक संसाधन सर्वर एक अनपेक्षित अनुरोध का उत्तर http 402 और मशीन-पठनीय भुगतान आवश्यकताओं के साथ दे सकता है, और क्लाइंट हेडर्स में एक साइन किया हुआ भुगतान पेलोड के साथ प्रतिक्रिया कर सकता है। यही कारण है कि "x402 की व्याख्या" एक क्रिप्टो उत्पाद पिच की तरह कम और वेब प्लंबिंग के एक गायब टुकड़े को भरने की तरह अधिक पढ़ता है।

यह एजेंट अर्थव्यवस्था के लिए महत्वपूर्ण है क्योंकि एजेंट हर एंडपॉइंट के लिए "साइन अप" नहीं करना चाहते हैं। पारंपरिक एपीआई मौद्रीकरण खातों को मजबूर करता है,एपीआई कुंजी, चालान, और एक अलग प्रमाणीकरण कहानी। x402 अनुक्रम को पलटता है: सर्वर उसी HTTP प्रवाह के भीतर भुगतान शर्तों का उल्लेख करता है, और क्लाइंट भुगतान प्राधिकरण को उसी तरह साबित करता है जैसे वह किसी अन्य अनुरोध संपत्ति को साबित करता है, एक हेडर भेजकर।

x402 को "इंटरनेट नेटिव भुगतान" के लिए एक ओपन स्टैंडर्ड के रूप में निर्दिष्ट किया गया है, जिसका उद्देश्य नेटवर्क, टोकन, और मुद्रा के प्रति उदासीन होना है। स्पेक का केंद्र बिंदु x402 फाउंडेशन रिपॉजिटरी है, जो संगठनों के लिए संगतता का लक्ष्य है जिसे निर्माताओं को ट्रैक करना चाहिए। कॉइनबेस x402 भी मौजूद है, लेकिन इसका अपना README इसे एक विकास फोर्क के रूप में चिह्नित करता है, क्योंकि परियोजना x402 फाउंडेशन के अंतर्गत चली गई है, जो "कॉइनबेस x402" के पीछे की व्यावहारिक शासन वास्तविकता है।

एक x402 अनुरोध का भुगतान कैसे किया जाता है

एक क्लाइंट द्वारा एक एंडपॉइंट को हिट करने और सर्वर द्वारा 200 OK लौटाने के बीच, x402 इंटरएक्शन को एक पूर्वानुमानित माइक्रोस्ट्रक्चर में मजबूर करता है: उद्धरण, भरना, निपटान, रसीद। प्रोटोकॉल यह स्थिति कोड और हेडर के साथ करता है, न कि एक विशेष SDK हैंडशेक के साथ।

एक सामान्य प्रवाह, जैसा कि x402 फाउंडेशन स्पेक में दस्तावेज़ित किया गया है, इस प्रकार चलता है:

1. क्लाइंट HTTP के माध्यम से एक संसाधन सर्वर से एक संसाधन का अनुरोध करता है। 2. संसाधन सर्वर एक 402 भुगतान आवश्यक प्रतिक्रिया लौटाता है जिसमें एक PAYMENT-REQUIRED हेडर होता है जिसमें एक base64-कोडित PaymentRequired ऑब्जेक्ट होता है जो स्वीकार्य PaymentRequirements की सूची देता है। 3. क्लाइंट एक PaymentRequirement का चयन करता है और एक PaymentPayload बनाता है जो चुने गए (स्कीम, नेटवर्क) जोड़ी से मेल खाता है। 4.

क्लाइंट PAYMENT-SIGNATURE हेडर के साथ अनुरोध को पुनः प्रयास करता है जिसमें PaymentPayload होता है। 5. संसाधन सर्वर या तो स्थानीय रूप से या POST करके payload और आवश्यकताओं को एक facilitator /verify एंडपॉइंट पर सत्यापित करता है। 6. यदि सत्यापन मान्य है, तो संसाधन सर्वर अनुरोध को पूरा करता है, फिर सीधे ऑनचेन या एक facilitator /settle एंडपॉइंट पर POST करके निपटान करता है। 7.

यदि निपटान सफल होता है, तो संसाधन सर्वर 200 OK लौटाता है जिसमें संसाधन शरीर में होता है और एक PAYMENT-RESPONSE हेडर होता है जिसमें एक base64-कोडित निपटान प्रतिक्रिया होती है।

दो विवरण अधिकांश एकीकरण परिणामों को संचालित करते हैं। पहले, यदि ग्राहक पहले से उस संसाधन के लिए भुगतान विवरण जानता है, तो चरण 1 और 2 वैकल्पिक हैं, जो टीमों को बड़े पैमाने पर एक अतिरिक्त राउंड ट्रिप से बचने में मदद करता है। दूसरे, विनिर्देश स्पष्ट रूप से प्रतिक्रिया की गति को भुगतान की गारंटी के खिलाफ व्यापार करने की अनुमति देता है, यही कारण है कि "http 402 भुगतान" स्वचालित रूप से "तत्काल अंतिम निपटान" के समानार्थक नहीं है।

नेटवर्क, योजनाएँ, और सुविधाकर्ता

x402 की चेन-निष्पक्ष दावा एक ही बाधा पर निर्भर करता है: ग्राहकों और सुविधाकर्ताओं को स्पष्ट (योजना, नेटवर्क) जोड़े का समर्थन करना चाहिए। एक योजना पैसे को स्थानांतरित करने का एक तार्किक तरीका है, लेकिन उस योजना का कार्यान्वयन नेटवर्क के अनुसार भिन्न होता है। "सटीक परएथेरियम"और "सोलाना पर सटीक" एक ही इंजीनियरिंग समस्या नहीं हैं, भले ही HTTP सतह समान दिखती हो।

x402 फाउंडेशन रिपॉजिटरी योजनाओं का वर्णन करती है जिसमें exact, upto, और batch-settlement (EVM) शामिल हैं। भिन्नताएँ निष्पादन-शैली के विकल्प हैं। exact एक अनुरोध के लिए एक निश्चित ट्रांसफर है। upto एक अधिकतम सीमा तक की अनुमति है, जिसमें विक्रेता उस अधिकतम तक वास्तविक उपयोग का निपटान करता है। batch-settlement (EVM) एस्क्रो और ऑफ-चेन वाउचर्स का उपयोग करता है ताकि कई छोटे शुल्कों को ऑनचेन बैचों में निपटाया जा सके, बजाय हर HTTP अनुरोध को व्यक्तिगत रूप से निपटाने के।

फैसिलिटेटर की भूमिका दूसरा बड़ा डिज़ाइन लीवर है। एक फैसलिटेटर एक सर्वर है जो एक या कई नेटवर्क के लिए भुगतान की सत्यापन और निष्पादन को सुविधाजनक बनाता है। ठोस रूप से, यह संसाधन सर्वर को एक /verify और /settle सतह प्रदान करता है ताकि सर्वर को हर चेन एकीकरण को स्वयं लागू करने की आवश्यकता न हो। यह सुविधा एक नई निर्भरता के साथ आती है: फैसलिटेटर विश्वसनीयता और विश्वास सीमा का हिस्सा बन जाता है, भले ही मानक का stated लक्ष्य विश्वास न्यूनतमकरण हो और फैसलिटेटरों को ग्राहक की मंशा के बाहर धन स्थानांतरित करने की अनुमति न हो।

यहां "x402 प्रोटोकॉल क्रिप्टो" मूल्यांकन अक्सर गलत होते हैं। सही सवाल यह नहीं है कि "क्या x402 तेज है या सस्ता," क्योंकि x402 एक बातचीत और प्रमाण परत है। विलंबता, शुल्क प्रोफ़ाइल, और निपटान की गारंटी (योजना, नेटवर्क) जोड़ी से आती है और यह कि सत्यापन और निपटान स्थानीय रूप से संभाले जाते हैं या किसी सहायक को आउटसोर्स किया जाता है।

x402 एआई एजेंटों के लिए क्यों महत्वपूर्ण है

एआई एजेंट्सडिमांड के स्वरूप को बदलें क्योंकि वे कई छोटे, बार-बार के अनुरोध उत्पन्न करते हैं जिन्हें सदस्यता के साथ मुद्रीकरण करना कठिन होता है और खाता ऑनबोर्डिंग के साथ बाधित करना अजीब होता है। x402 को इस तरह से बनाया गया है कि एजेंटिक भुगतान को सामान्य HTTP जैसा महसूस हो: एजेंट एक एंडपॉइंट को कॉल करता है, 402 कोट प्राप्त करता है, और अपने स्वयं के नियमों के आधार पर भुगतान करने का निर्णय ले सकता है।

सोलाना के x402 पृष्ठ इसे "इंटरनेट-नेटिव भुगतान" के रूप में प्रस्तुत करता है जो स्वायत्त उपकरणों के लिए है, और यह पर निर्भर करता हैस्टेबलकॉइनसेटलमेंट को आर्थिक रेल के रूप में देखा जाता है जो प्रति-अनुरोध मूल्य निर्धारण को समझदारी बनाता है। उस पृष्ठ का दावा है कि सोलाना पर स्थिर मुद्रा भुगतान $11B से अधिक के संचलन में हैं और प्रति माह 200M+ लेनदेन का खाता रखते हैं, जो नेटवर्क को प्रति-अनुरोध सेवाओं के लिए एक उच्च-थ्रूपुट सेटलमेंट लेयर के रूप में स्थापित करता है।

यह तंत्र एजेंट कार्यप्रवाहों के लिए साफ-सुथरा मैप करता है क्योंकि यह एक अलग पहचान और बिलिंग चैनल की आवश्यकता को हटा देता है। एक क्लाइंट जो HTTP बोल सकता है, मानकीकृत हेडर पढ़कर भुगतान करना सीख सकता है, बजाय इसके कि हर API के लिए एक अलग बिलिंग SDK को एकीकृत करे। यह मशीन से मशीन भुगतान के लिए एक महत्वपूर्ण विशेषता है: भुगतान बातचीत सामान्य क्लाइंट के लिए स्पष्ट है, केवल उन लोगों के लिए नहीं जो चेकआउट पृष्ठ पर क्लिक कर रहे हैं।

समझौता यह है कि "भुगतान प्रमाणीकरण है" केवल उतनी ही सुचारू रूप से काम करता है जितना कि योजना और सुविधा प्रदाता के विकल्प अनुमति देते हैं। यदि एक एजेंट हजारों कॉल कर रहा है, तो "हर बार सटीक निपटान" और "बैच-सेटलमेंट बाद में भुनाया गया" के बीच का अंतर एक तंग लूप और एक प्रणाली के बीच का अंतर है जो अपनी समय की बर्बादी पुष्टि की प्रतीक्षा में करती है।

स्वीकृति संकेत और व्यावहारिक व्यापारिक समझौते

प्रदान किए गए स्रोतों में सबसे साफ ट्रैक्शन डेटा पॉइंट चेन-विशिष्ट है: सोलाना का x402 पृष्ठ दावा करता है कि जब से x402 ने "इस गर्मी" में सोलाना पर लॉन्च किया, तब से इसने 35M+ लेनदेन और x402 पर $10M+ वॉल्यूम प्रोसेस किया है। उसी पृष्ठ में दावा किया गया है कि सोलाना की ~400ms फाइनलिटी और ~$0.00025 लेनदेन लागत है। ये उस डिप्लॉयमेंट के लिए अपनाने और प्रदर्शन के संकेतों के रूप में उपयोगी हैं, लेकिन ये प्रमाण नहीं हैं कि हर x402 इंटीग्रेशन उन नंबरों को विरासत में लेता है।

स्पेक स्वयं एक अधिक गंभीर रूपरेखा को आगे बढ़ाता है: x402 लचीला है, और कार्यान्वयन प्रतिक्रिया गति को भुगतान गारंटी के खिलाफ संतुलित कर सकते हैं। यही कारण है कि पारिस्थितिकी तंत्र के व्याख्याताओं से "लगभग 2 सेकंड के भीतर निपटारा" जैसी व्यापक दावों को नेटवर्क और डिज़ाइन पर निर्भर समझा जाना चाहिए, न कि HTTP हैंडशेक की एक विशेषता के रूप में।

निर्माताओं को "मानक" को "पारिस्थितिकी तंत्र विपणन" से अलग करने की भी आवश्यकता है। सोलाना का पृष्ठ यह दावा करता है कि क्लाउडफ्लेयर, गूगल और वेरसेल जैसे प्रमुख प्लेटफार्म x402 का समर्थन करते हैं, लेकिन प्रदान किए गए स्रोत यह नहीं बताते कि उत्पाद स्तर पर "समर्थन" का क्या अर्थ है। बिना किसी ठोस एकीकरण सतह के, वह रेखा क्रियाशील नहीं है।

व्यावहारिक दृष्टिकोण यह है कि संकीर्ण रूप से शुरू करें और मापें। उत्पादन में एक (योजना, नेटवर्क) जोड़ी एक खुशहाल पथ प्रदान करती है जिसे अंत से अंत तक उपकरण बनाया जा सकता है। वहां से, टीमें अधिक योजनाएं या नेटवर्क जोड़ सकती हैं, और तय कर सकती हैं कि सत्यापन और निपटान को स्थानीय रखना है या एक मध्यस्थ पर निर्भर रहना है। यही एक कार्यशील डेमो और एक भुगतान परत के बीच का अंतर है जो पुनः प्रयासों, समय समाप्ति, और एजेंट अर्थव्यवस्था में आंशिक विफलताओं को सहन करती है।

लेन-देन

मैंने देखा है कि टीमें x402 को "एक क्रिप्टो पेवॉल" की तरह मानती हैं और फिर उस हिस्से से हैरान होती हैं जो वास्तव में उपयोगकर्ता अनुभव को निर्धारित करता है: (स्कीम, नेटवर्क) जोड़ी और जहां सत्यापन और निपटान होते हैं। HTTP हैंडशेक निश्चित है। निपटान परत निश्चित नहीं है। यदि किसी सुविधा का /verify तेज है लेकिन /settle रुकता है, तो क्लाइंट इसे एक API के रूप में देखता है जो यादृच्छिक रूप से लटकता है, हालांकि हेडर पूरी तरह से मानकीकृत होते हैं।

जो मानसिक मॉडल चिपकता है वह माइक्रोस्ट्रक्चर है। 402 + PAYMENT-REQUIRED उद्धरण है, PAYMENT-SIGNATURE आदेश है, verify और settle निपटान है, और 200 + PAYMENT-RESPONSE रसीद है। एक बार जब यह क्लिक करता है, तो मूल्यांकन "क्या x402 सस्ता है" से बदलकर "इस एंडपॉइंट ने कौन सा निष्पादन शैली चुनी, और इसने कौन सी निर्भरताएँ पेश की," में बदल जाता है, जो एजेंट अर्थव्यवस्था के लिए बिल्कुल सही दृष्टिकोण है।

स्रोत

• सोलाना फाउंडेशन
• x402 फाउंडेशन (गिटहब)
• कॉइनबेस (गिटहब)
• थर्डवेब