प्रश्न
आपको एक डेटा API में पे-पर-रिक्वेस्ट एक्सेस जोड़ना है। एक अनपेड रिक्वेस्ट पर HTTP 402 वापस आना चाहिए, और क्लाइंट को भुगतान करने के बाद मूल रिक्वेस्ट को फिर से आज़माना (retry) चाहिए। RFC 9110 में 402 की स्थिति स्पष्ट करें और पेमेंट आवश्यकताओं, प्रूफ सत्यापन, रिसोर्स बाइंडिंग, रीप्ले सुरक्षा, आइडमपोटेंसी, रिफंड और समाधान को कवर करने वाले एक x402-जैसे एंड-टू-एंड प्रोटोकॉल को डिज़ाइन करें।
इंटरव्यूअर क्या जांच रहा है
- क्या आप 402 के मानकीकृत अर्थ को एक ठोस पेमेंट योजना से अलग पहचानते हैं: RFC 9110 स्टेटस कोड को आरक्षित करता है लेकिन किसी पेमेंट नेटवर्क, मुद्रा या रिस्पॉन्स फॉर्मेट को परिभाषित नहीं करता है।
- क्या आप पेमेंट प्रूफ को रिसोर्स, राशि, प्राप्तकर्ता, नेटवर्क और समाप्ति (expiry) से बाइंड करते हैं ताकि एक पेमेंट को दूसरी रिक्वेस्ट पर न ले जाया जा सके।
- क्या आप क्लाइंट रिट्रीज, टाइमआउट, डुप्लिकेट शुल्क, ब्लॉकचेन पुष्टिकरण में देरी और अकाउंटिंग स्थिरता को संभालते हैं।
- क्या आप पेमेंट सर्विस, रिसोर्स सर्विस, सेटलमेंट पक्ष और ऑडिट लॉग के बीच ट्रस्ट सीमाओं को स्पष्ट कर सकते हैं।
मॉडल उत्तर
402 को HTTP स्टेटस कोड रजिस्ट्री में "Payment Required" के रूप में पंजीकृत किया गया है। RFC 9110 इसे आरक्षित करता है लेकिन एक सार्वभौमिक पेमेंट प्रोटोकॉल को परिभाषित नहीं करता है। एक प्रोटोकॉल को 402 को मशीन-पठनीय चैलेंज के रूप में मानना चाहिए, न कि इस बात के प्रमाण के रूप में कि भुगतान पहले ही हो चुका है।
रिसोर्स सर्विस 402 रिस्पॉन्स में एक विशिष्ट पेमेंट आवश्यकता लौटा सकती है। इसमें रिसोर्स पहचानकर्ता, मेथड और पाथ, राशि, एसेट, नेटवर्क, प्राप्तकर्ता, समाप्ति और नॉनस (nonce) शामिल होना चाहिए। क्लाइंट ठीक इन्हीं फ़ील्ड्स के लिए हस्ताक्षर या भुगतान करता है। सर्विस या एक विश्वसनीय सूत्रधार (फैसिलिटेटर) प्रूफ को सत्यापित करता है, राशि, प्राप्तकर्ता, नेटवर्क और रिसोर्स की जांच करता है, और फिर रिसोर्स सर्विस को एक बार उपयोग होने वाली रसीद प्रदान करता है।
रिसोर्स सर्विस को किसी महंगे ऑपरेशन को निष्पादित करने से पहले रिक्वेस्ट आईडी और पेमेंट आईडी के बीच आइडमपोटेंट संबंध दर्ज करना चाहिए। उसी रिक्वेस्ट आईडी के साथ किया गया पुनः प्रयास समान परिणाम या एक स्पष्ट प्रोसेसिंग स्थिति लौटाता है। सफल भुगतान का अर्थ सफल रिसोर्स निष्पादन नहीं है, इसलिए पेमेंट, ऑथराइजेशन, निष्पादन और रिफंड को ट्रेस करने योग्य स्थितियों की आवश्यकता होती है। एक समाधान (रिकॉन्सिलेशन) जॉब को चेन पुष्टिकरण, सर्विस रिकॉर्ड और वास्तविक डिलीवरी के बीच अंतर खोजना चाहिए।
कार्यान्वयन का खाका
नीचे दिया गया स्यूडोकोड मुख्य चैलेंज और पुनः प्रयास सीमाओं को दिखाता है; एक प्रोडक्शन सिस्टम को पेमेंट वेरिफायर, आइडमपोटेंट स्टोरेज और ऑडिट लॉगिंग की भी आवश्यकता होती है।
handle(request):
id = request.idempotencyKey
if receiptStore.has(id):
return receiptStore.result(id)
requirement = makeRequirement(
resource = canonicalResource(request),
amount = quote(request),
network = "base",
expiresAt = now + 60s,
nonce = randomBytes(16)
)
proof = request.headers["Payment-Proof"]
if proof is missing:
return 402, { "payment-required": requirement }
payment = verifyProof(proof, requirement)
if payment.invalid or payment.expired or payment.replayed:
return 402, { "payment-required": requirement, "reason": "invalid-proof" }
result = executeOnce(id, request, payment)
receiptStore.put(id, payment.id, result)
return 200, resultमुख्य इनवेरिएंट यह है कि canonicalResource और verifyProof समान सामान्यीकरण (normalization) नियमों का उपयोग करें। अन्यथा एक रिसोर्स के कई स्ट्रिंग निरूपण हो सकते हैं और सिग्नेचर सत्यापन ऑथराइजेशन से असहमत हो सकता है। executeOnce को एक अद्वितीय प्रतिबंध (unique constraint), लेनदेन या स्थायी स्थिति की आवश्यकता होती है ताकि पुनः प्रयास साइड इफेक्ट्स की डुप्लिकेट न बना सके।
सामान्य गलतियां
- यह मान लेना कि 402 में एक पेमेंट फ्लो शामिल है। यह केवल यह बताता है कि भुगतान आवश्यक है; प्रोटोकॉल को फ़ील्ड और सत्यापन नियम परिभाषित करने चाहिए।
- रिसोर्स, नेटवर्क, प्राप्तकर्ता, एसेट या समाप्ति की अनदेखी करते हुए केवल राशि की जांच करना, जिससे क्रॉस-रिसोर्स प्रतिस्थापन या क्रॉस-नेटवर्क रीप्ले की संभावना बनती है।
- आइडमपोटेंट रिक्वेस्ट रिकॉर्ड के बिना पेमेंट पुष्टिकरण के तुरंत बाद साइड इफेक्ट्स को निष्पादित करना, जिससे टाइमआउट रिट्री दो बार शुल्क लेती है या रिसोर्स बनाती है।
- सबमिट किए गए चेन लेनदेन को अंतिम सेटलमेंट मानना; पुष्टिकरण में देरी, रीऑर्ग्स (reorgs), फैसिलिटेटर विफलताएं और रिफंड स्टेट मशीन का हिस्सा हैं।
- पेमेंट प्रूफ को लॉग या URL में डालना, जिससे क्रेडेंशियल लीक और रीप्ले जोखिम पैदा होता है।
प्रोडक्शन ट्रेड-ऑफ़
कम मूल्य वाले, कम जोखिम वाले रीड्स के लिए, एक अल्पकालिक कोट, वन-टाइम नॉनस और एसिंक्रोनस अंतिम समाधान स्वीकार्य हो सकता है। उच्च मूल्य वाले राइट्स को डिलीवरी से पहले सत्यापन योग्य सेटलमेंट स्थिति प्राप्त करनी चाहिए और एक आइडमपोटेंट लेनदेन के पीछे निष्पादित होना चाहिए। यदि क्लाइंट्स के पास वॉलेट या ऑन-चेन क्षमताएं नहीं हैं, तो एक फैसिलिटेटर उनकी ओर से भुगतान कर सकता है, लेकिन उसका ट्रस्ट दायरा, शुल्क, सीमाएं और विफलता फॉलबैक स्पष्ट होना चाहिए।
प्रोटोकॉल को मूल्य परिवर्तन, समाप्त हो चुके चैलेंज, आंशिक भुगतान, पेमेंट की सफलता के बाद रिसोर्स विफलता, रिफंड और सर्विस डिग्रेडेशन के लिए नियमों की भी आवश्यकता होती है। एक कैश को पेमेंट प्रूफ वाले रिस्पॉन्स को किसी अन्य प्रिंसिपल के साथ साझा नहीं करना चाहिए; इसकी कुंजी में ऑथराइजेशन परिणाम शामिल होना चाहिए, या इसे केवल सार्वजनिक 402 चैलेंज को कैश करना चाहिए।
संदर्भ
- RFC 9110 HTTP Semantics: 402 पंजीकरण सिमेंटिक्स और HTTP स्टेटस प्रतिबंध।
- x402 Introduction: चैलेंज-संचालित, खाता-रहित पे-पर-रिक्वेस्ट प्रोटोकॉल अवधारणा।
- Coinbase HTTP 402 Core Concepts: पेमेंट आवश्यकताओं, सत्यापन और रिसोर्स एक्सेस के लिए कार्यान्वयन सीमाएं।
फॉलो-अप प्रश्न
आप एक पेमेंट प्रूफ को दो रिसोर्स के लिए उपयोग होने से कैसे रोकते हैं?
पेमेंट आवश्यकता में सामान्यीकृत मेथड, पाथ, क्वेरी डाइजेस्ट या रिसोर्स आईडी डालें और उन फ़ील्ड्स को प्रूफ से कवर करें। सर्विस समान सामान्यीकरण एल्गोरिदम के साथ डाइजेस्ट की पुनर्गणना करती है और प्रत्येक नॉनस या पेमेंट आईडी को सिंगल-यूज़ के रूप में रिकॉर्ड करती है।
क्या 402 चैलेंज हेडर में होना चाहिए या रिस्पॉन्स बॉडी में?
पहले एक वर्शन-युक्त मशीन-पठनीय फॉर्मेट परिभाषित करें। हेडर एक छोटे संकेत के लिए उपयुक्त हैं, जबकि बॉडी एक मल्टी-फ़ील्ड पेमेंट आवश्यकता को ले जा सकती है। किसी भी तरह, इसके आकार को सीमित करें, इसके कंटेंट प्रकार को घोषित करें, और कैशेबल हेडर में संवेदनशील क्रेडेंशियल्स डालने से बचें।
क्या होगा यदि भुगतान सफल हो जाए लेकिन व्यावसायिक निष्पादन विफल हो जाए?
रिक्वेस्ट आईडी द्वारा लिंक की गई अलग-अलग स्थितियों के रूप में पेमेंट, ऑथराइजेशन, निष्पादन और रिफंड को बनाए रखें। यदि ऑपरेशन रिट्री करने योग्य नहीं है, तो रिफंड या मैनुअल समाधान कतार में प्रवेश करें। यदि यह रिट्री करने योग्य है, तो एक प्रोसेसिंग स्थिति लौटाएं और बाद के रीड्स को समान परिणाम लौटाने दें।
क्या x402 को ब्लॉकचेन की आवश्यकता है?
वर्तमान x402 सामग्री ऑन-चेन या फैसिलिटेटर पेमेंट्स को उदाहरण के रूप में उपयोग करती है, लेकिन HTTP 402 स्वयं किसी सेटलमेंट नेटवर्क को निर्धारित नहीं करता है। स्टेटस-कोड सिमेंटिक्स को पेमेंट रेल से अलग करें; रेल बदलने के लिए प्रूफ, फाइनलिटी और रिफंड सिमेंटिक्स को फिर से परिभाषित करने की आवश्यकता होती है।
आप कैसे सत्यापित करते हैं कि सिस्टम कभी दोहरा शुल्क नहीं लेता है?
पेमेंट आईडी, रिक्वेस्ट आईडी और व्यावसायिक संचालन के लिए अद्वितीय प्रतिबंध (unique constraints) जोड़ें; प्रत्येक सत्यापन और निष्पादन परिणाम रिकॉर्ड करें; और क्लाइंट टाइमआउट, सर्विस रीस्टार्ट, डुप्लिकेट वेरिफायर कॉलबैक और विलंबित समाधान को कवर करने वाली विफलताओं को इंजेक्ट करें।