प्रश्न और कार्यक्षेत्र (प्रॉम्प्ट और स्कोप)
एक मल्टी-मर्चेंट पेमेंट प्लेटफ़ॉर्म चाहता है कि खरीदार चेकआउट के समय प्राप्तकर्ता (पेई), राशि और मुद्रा की पुष्टि करें और ऐसे क्रिप्टोग्राफ़िक साक्ष्य उत्पन्न करें जिसे कोई बैंक या पेमेंट सेवा सत्यापित कर सके। टीम 2 जुलाई, 2026 को प्रकाशित W3C Secure Payment Confirmation Candidate Recommendation Draft पर विचार कर रही है। मर्चेंट पेज, पेमेंट ऑर्केस्ट्रेटर और जारीकर्ता (इश्यूअर) ऑथेंटिकेशन पेज के ओरिजिन अलग-अलग हो सकते हैं, जबकि पुराने ब्राउज़रों के लिए मौजूदा ऑथेंटिकेशन पाथ को बनाए रखना आवश्यक है।
SPC क्रेडेंशियल रजिस्ट्रेशन से लेकर असर्शन वेरिफिकेशन तक सिस्टम को डिज़ाइन करें। बताएं कि कोई तीसरा पक्ष किसी रिलाइंग पार्टी के लिए ऑथेंटिकेशन कैसे शुरू कर सकता है, सर्वर को किन फ़ील्ड्स को बाइंड करना चाहिए, और API अनुपलब्धता, रद्दीकरण, डुप्लिकेट पेमेंट और रोलबैक को कैसे संभालना है। यह विनिर्देश (स्पेसिफिकेशन) अभी भी एक ड्राफ्ट है; इस स्थिति को सार्वभौमिक ब्राउज़र समर्थन न मानें।
इंटरव्यूअर क्या मूल्यांकन करता है
इंटरव्यूअर यह देखना चाहता है कि क्या आप उपयोगकर्ता को दिखाए गए ट्रांज़ैक्शन विवरण, सर्वर द्वारा अनुमोदित ऑर्डर और ऑथेंटिकेशन असर्शन को एक ही पेमेंट प्रयास (पेमेंट अटेम्प्ट) से बाइंड करते हैं। आपको SPC और WebAuthn के बीच के संबंध तथा क्रॉस-ओरिजिन इनवोकेशन के सुरक्षा प्रभावों को स्पष्ट करना चाहिए।
एक बेहतरीन उत्तर केवल बायोमेट्रिक डायलॉग का वर्णन करने के बजाय payment Permission Policy, securePaymentConfirmationAvailability() की प्राइवेसी सीमाओं, क्रेडेंशियल पृथक्करण, इडेम्पोटेंसी कीज़, रिस्क-आधारित फॉलबैक, साक्ष्य प्रतिधारण (एविडेंस रिटेंशन) और एक रिवर्सिबल रोलआउट को भी कवर करता है।
शुरुआत में पूछे जाने वाले स्पष्टीकरण
- SPC क्रेडेंशियल कौन रजिस्टर करता है, और क्या यह लॉगिन क्रेडेंशियल से अलग है?
- इश्यूअर, मर्चेंट और पेमेंट ऑर्केस्ट्रेटर के ओरिजिन क्या हैं, और कौन सा पक्ष WebAuthn Relying Party है?
- क्या ऑथेंटिकेशन डेटा में राशि, पेई, मुद्रा, ऑर्डर ID और समाप्ति समय (एक्सपायरी) शामिल होना चाहिए?
- क्या SPC अनुपलब्ध होने या रद्द होने पर कोई मौजूदा ऑथेंटिकेशन पाथ सुरक्षित रूप से कार्यभार संभाल सकता है?
- पुनः प्रयासों (रीट्राई), डुप्लिकेट कॉलबैक, रिफंड और विवादों के लिए किन साक्ष्यों की आवश्यकता होती है?
एक 30-सेकंड का उत्तर
“मैं ऑथेंटिकेशन से पहले सर्वर-साइड पर एक अपरिवर्तनीय (इम्यूटेबल) पेमेंट प्रयास बनाऊंगा, एक पेमेंट-विशिष्ट SPC क्रेडेंशियल रजिस्टर करूंगा और अनुमत कॉलर ओरिजिन को प्रतिबंधित करूंगा। सर्वर एक वन-टाइम चैलेंज और ऑर्डर डाइजेस्ट जारी करता है; मर्चेंट SPC को केवल सर्वर-अनुमोदित पेमेंट डेटा पास करता है, और कॉलबैक को ओरिजिन पॉलिसी, चैलेंज, क्रेडेंशियल, यूजर वेरिफिकेशन और ऑर्डर स्थिति के विरुद्ध जांचा जाता है। अनुपलब्धता या रद्दीकरण एक स्पष्ट लेगेसी पाथ का अनुसरण करता है, सफलता का कोई शॉर्टकट नहीं लेता। स्टेट ट्रांज़िशन इडेम्पोटेंसी कीज़ का उपयोग करते हैं। मैं कम जोखिम वाले ट्रैफ़िक से शुरुआत करूंगा, असर्शन विफलताओं, विवादों और फॉलबैक को मापूँगा, और विसंगतियाँ दिखने पर इन-फ़्लाइट साक्ष्यों को सुरक्षित रखते हुए नए SPC प्रयासों को अक्षम कर दूंगा।”
चरण-दर-चरण समाधान
ओरिजिन और क्रेडेंशियल स्वामित्व को परिभाषित करें
SPC WebAuthn पर आधारित है लेकिन किसी तीसरे पक्ष को रिलाइंग पार्टी के लिए सेरेमनी ट्रिगर करने की अनुमति देता है। एक पेमेंट-विशिष्ट Relying Party ID या पेमेंट सबडोमेन का उपयोग करें ताकि लॉगिन और पेमेंट क्रेडेंशियल चुपचाप आपस में बदले न जा सकें। रजिस्ट्रेशन केवल सर्वर द्वारा जारी किए गए यूजर और मर्चेंट बाइंडिंग टोकन को स्वीकार करता है। क्रेडेंशियल ID, ओरिजिन, निर्माण समय, निरस्तीकरण (रिवोकेशन) स्थिति और डिवाइस-बाइंडिंग प्रॉपर्टीज़ को स्टोर करें; ब्राउज़र द्वारा प्रदान की गई Relying Party ID को कभी भी ऑथराइजेशन के रूप में न मानें।
ऑर्डर की स्थिति को चैलेंज से बाइंड करें
एक payment_attempt बनाएं जिसमें ऑर्डर वर्शन, राशि, मुद्रा, पेई, चैलेंज, एक्सपायरी और इडेम्पोटेंसी की शामिल हो। एक चैलेंज का केवल एक बार उपयोग करें। ऑर्डर में संपादन, मुद्रा रूपांतरण या पेई में बदलाव एक नया प्रयास बनाता है। उपयोगकर्ता को दिखाई जाने वाली राशि उसी सर्वर-अनुमोदित रिकॉर्ड या डाइजेस्ट से आती है; मर्चेंट को ब्राउज़र में मान जोड़कर सीधे SPC को कॉल नहीं करना चाहिए।
type PaymentAttempt = {
id: string;
orderVersion: number;
amountMinor: bigint;
currency: string;
payeeOrigin: string;
challenge: Uint8Array;
expiresAt: Date;
status: "created" | "authorizing" | "approved" | "cancelled" | "expired";
};क्रॉस-ओरिजिन सीमा को लागू करें
SPC का महत्वपूर्ण बदलाव यह है कि एक तीसरा पक्ष किसी अन्य रिलाइंग पार्टी से संबंधित क्रेडेंशियल का उपयोग कर सकता है। कॉलर, रिलाइंग पार्टी, ऑर्डर और अनुमत ऑथेंटिकेशन ओरिजिन को सर्वर पॉलिसी में रखें। पेमेंट iframe एम्बेड करने से पहले payment Permission Policy को कॉन्फ़िगर करें और मर्चेंट अनुमति सूची (अलोलिस्ट) के विरुद्ध टॉप-लेवल ओरिजिन को मान्य करें। क्रॉस-ओरिजिन असर्शन वापस आने के बाद, कॉलर को केवल उस ट्रांज़ैक्शन के लिए आवश्यक परिणाम प्राप्त होता है; इसे मनमाने WebAuthn एक्सटेंशन का अनुरोध नहीं करना चाहिए या लॉगिन क्रेडेंशियल तक पहुंच नहीं बनानी चाहिए।
क्षमता का पता लगाएं और फॉलबैक चुनें
PaymentRequest.securePaymentConfirmationAvailability() को प्राथमिकता दें और available को अनुपलब्धता के कारणों से अलग रिकॉर्ड करें; फिंगरप्रिंटिंग को कम करने के लिए उपयोगकर्ता एजेंट जानबूझकर एक अस्पष्ट कारण लौटा सकता है। उपलब्धता अभी भी यह साबित नहीं करती है कि कोई विशेष क्रेडेंशियल मौजूद है। एक जोखिम-आधारित फॉलबैक SPC, बैंक ऑथेंटिकेशन, वन-टाइम कोड या मैन्युअल समीक्षा का चयन कर सकता है। प्रत्येक पाथ ऑर्डर और चैलेंज की फिर से जांच करता है, इसलिए SPC त्रुटि कभी पेमेंट सफलता में नहीं बदल सकती।
असर्शन और पेमेंट सिमेंटिक्स को सत्यापित करें
सर्वर क्लाइंट-डेटा ओरिजिन, चैलेंज, Relying Party ID, हस्ताक्षर, यूजर-वेरिफिकेशन फ़्लैग, क्रेडेंशियल स्थिति और ऑर्डर डाइजेस्ट की पुष्टि करता है। चार्ज करने से पहले created प्रयास का दावा करने के लिए एक सशर्त अपडेट (कंडीशनल अपडेट) का उपयोग करें; डुप्लिकेट कॉलबैक वही परिणाम लौटाते हैं। डाइजेस्ट बेमेल होना एक सुरक्षा विफलता है और इसे अनिश्चित काल तक रीट्राई नहीं किया जाना चाहिए। एक असर्शन यह साबित करता है कि ऑथेंटिकेशन पूरा हो गया है; यह यह साबित नहीं करता है कि धनराशि सेटल हो गई है।
रद्दीकरण, समाप्ति और त्रुटियों को संभालें
रद्दीकरण, कोई ऑथेंटिकेटर न होना, ब्राउज़र का बंद होना और इश्यूअर टाइमआउट अलग-अलग टर्मिनल स्टेट बन जाते हैं। रीट्राई करने पर एक नया प्रयास और चैलेंज बनता है। गेटवे टाइमआउट को पुराने चैलेंज को दोबारा उपयोग नहीं करना चाहिए: पहले इडेम्पोटेंसी की से पूछताछ करें, फिर तय करें कि परिणाम लंबित है, सफल है, या मानवीय समीक्षा की आवश्यकता है। पेमेंट सेवा, मर्चेंट और इश्यूअर के बीच के इवेंट्स में वर्शन होते हैं ताकि कोई पुराना इवेंट नए स्टेट को ओवरराइट न कर सके।
जोखिम की निगरानी करें और साक्ष्य बनाए रखें
SPC उपलब्धता, उपयोगकर्ता रद्दीकरण, असर्शन विफलताएं, डुप्लिकेट कॉलबैक, फॉलबैक दर, चार्ज लेटेंसी और विवादों को ब्राउज़र, ओरिजिन संयोजन, ऑथेंटिकेशन विधि और जोखिम स्तर के आधार पर विभाजित करें। ऑर्डर-डाइजेस्ट हैश, नॉन-रिवर्सिबल क्रेडेंशियल पहचानकर्ता, प्रयास ID, पॉलिसी वर्शन और सत्यापन परिणाम को बनाए रखें; बायोमेट्रिक्स या निजी कुंजियों (प्राइवेट कीज़) को लॉग न करें। क्रॉस-ओरिजिन विसंगतियों, बार-बार क्रेडेंशियल प्रयासों और अचानक राशि परिवर्तनों पर रेट-लिमिट लगाएं।
चरणबद्ध रोलआउट, परीक्षण और रोलबैक
आंतरिक व्यापारियों और कम जोखिम वाली राशियों के साथ शुरुआत करें, फिर ब्राउज़र, ओरिजिन और क्षेत्र के अनुसार विस्तार करें। क्रॉस-ओरिजिन iframes, अनुपलब्ध Permission Policy, उपयोगकर्ता इनकार, अनुपलब्ध क्रेडेंशियल, चैलेंज रीप्ले, ऑर्डर संपादन, डुप्लिकेट कॉलबैक, गेटवे टाइमआउट और रिफंड रेस का परीक्षण करें। रोलबैक पर, नए SPC प्रयास बनाना बंद करें, इन-फ़्लाइट ट्रांज़ैक्शन को स्टेट मशीन के माध्यम से पूरा होने दें, और नए ट्रांज़ैक्शन को लेगेसी पाथ पर रूट करें। विवाद विश्लेषण के लिए असर्शन और ऑर्डर साक्ष्य बनाए रखें।
उच्च गुणवत्ता वाला मॉडल उत्तर
“SPC ऑथेंटिकेशन साक्ष्य उत्पन्न करता है; यह सेटलमेंट नहीं है। मैं एक अपरिवर्तनीय payment_attempt को ऑर्डर वर्शन, राशि, पेई, चैलेंज, ओरिजिन पॉलिसी और इडेम्पोटेंसी की से बाइंड करूंगा। पेमेंट क्रेडेंशियल को लॉगिन क्रेडेंशियल से अलग रखा जाता है, और Permission Policy क्रॉस-ओरिजिन कॉलर्स को सीमित करती है। ऑथेंटिकेशन के बाद, सर्वर WebAuthn असर्शन और ऑर्डर डाइजेस्ट की पुष्टि करता है, फिर चार्ज की स्थिति को सशर्त रूप से आगे बढ़ाता है। अनुपलब्धता, रद्दीकरण और टाइमआउट स्पष्ट फॉलबैक का उपयोग करते हैं, जबकि डुप्लिकेट कॉलबैक स्थापित परिणाम लौटाते हैं। एक चरणबद्ध रोलआउट के दौरान मैं असर्शन विफलताओं, फॉलबैक, विवादों और क्रॉस-ओरिजिन विसंगतियों की निगरानी करूंगा; रोलबैक नए SPC प्रयासों को रोकता है और इन-फ़्लाइट साक्ष्यों को सुरक्षित रखता है।”
सामान्य गलतियां
availableको एक क्रेडेंशियल मानना → उपयोगकर्ता के पास अभी भी कोई उपयोग योग्य क्रेडेंशियल नहीं हो सकता है → क्षमता का पता लगाने और क्रेडेंशियल की उपलब्धता को अलग करें।- ब्राउज़र को राशि चुनने देना → पुष्टि और चार्ज में अंतर आ सकता है → सर्वर ऑर्डर डाइजेस्ट और चैलेंज को बाइंड करें।
- क्रॉस-ओरिजिन कॉल को सामान्य लॉगिन मानना → लॉगिन क्रेडेंशियल या एक्सटेंशन डेटा लीक हो सकता है → पेमेंट क्रेडेंशियल को अलग करें और कॉलर को प्रतिबंधित करें।
- SPC विफलता को पेमेंट सफलता में बदलना → ऑथेंटिकेशन और सेटलमेंट के बीच भ्रम → ऑथेंटिकेशन, चार्ज और सेटलमेंट को अलग-अलग मॉडल करें।
- रीट्राई पर चैलेंज का पुन: उपयोग करना → असर्शन को रीप्ले किया जा सकता है → एक बार उपभोग करें और प्रति प्रयास एक नया चैलेंज जारी करें।
- रोलबैक के दौरान रिकॉर्ड हटाना → विवाद और डुप्लिकेट चार्ज अप्राप्य (अनट्रेसेबल) हो जाते हैं → नए अनुरोधों को रोकें और इन-फ़्लाइट साक्ष्यों को बनाए रखें।
फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: लॉगिन पासकी का पुन: उपयोग क्यों नहीं करते?
पेमेंट और लॉगिन के खतरे, ओरिजिन और ऑथराइजेशन के उद्देश्य अलग-अलग होते हैं। विनिर्देश SPC में WebAuthn क्रेडेंशियल की अनुमति देता है, लेकिन एक पेमेंट सबडोमेन और अलग क्रेडेंशियल लॉगिन अटैक सर्फेस को कम करते हैं। यदि क्रेडेंशियल साझा किए जाते हैं, तो असर्शन का उद्देश्य, Relying Party और सर्वर जांच स्पष्ट होनी चाहिए।
फॉलो-अप 2: आप किसी मर्चेंट को एक डॉलर दिखाकर सौ डॉलर चार्ज करने से कैसे रोकते हैं?
मर्चेंट UI राशि का निर्धारण करने वाला प्राधिकारी नहीं है। पेमेंट सेवा ऑर्डर वर्शन से डाइजेस्ट बनाती है, ऑथेंटिकेशन फ्लो उस डाइजेस्ट को ले जाता है, और चार्ज सेवा केवल उसी प्रयास को स्वीकार करती है। किसी भी फ़ील्ड में बदलाव एक नया प्रयास बनाता है।
फॉलो-अप 3: विस्तृत उपलब्धता कारण लौटाने का क्या जोखिम है?
विस्तृत कारण डिवाइस या कॉन्फ़िगरेशन फिंगरप्रिंट बन सकते हैं, इसलिए उपयोगकर्ता एजेंट unavailable-unknown-reason लौटा सकता है। व्यवसाय इस परिणाम का उपयोग अनुभव चयन के लिए करता है, उपयोगकर्ता प्रोफ़ाइल, जोखिम स्कोर या ऑथराइजेशन तथ्य के रूप में कभी नहीं।
फॉलो-अप 4: क्या पेमेंट सेवा टाइमआउट के बाद SPC को फिर से कॉल कर सकती है?
पहले इडेम्पोटेंसी की द्वारा चार्ज और ऑथेंटिकेशन स्थिति की जांच करें। यदि पुराना प्रयास अनिर्णीत है, तो इसे आंख मूंदकर रीप्ले न करें। इसे स्पष्ट रूप से रद्द या समाप्त करें, फिर एक नए चैलेंज और ऑर्डर डाइजेस्ट के साथ एक नया प्रयास बनाएं।