डिजिटल क्रेडेंशियल्स और भुगतान: Apple बनाम Google Wallet की रणनीति

डिजिटल भुगतान हमेशा बदल रहे हैं। हम चाहते हैं कि वे तेज़, सुरक्षित और उपयोग में आसान हों। साथ ही, Verifiable Credentials (VCs) और मोबाइल पहचान दस्तावेज़ (mdocs) जैसे डिजिटल आईडी उपकरण बेहतर हो रहे हैं। वे लोगों को यह दिखाने के नए तरीके प्रदान करते हैं कि वे कौन हैं। तो, बड़ा सवाल यह है: क्या ये नए डिजिटल आईडी डिजिटल भुगतान को भी बहुत बेहतर या सरल बना सकते हैं?

यह लेख देखता है कि डिजिटल क्रेडेंशियल्स (ISO mdocs और OpenID4VC का उपयोग करके भेजे गए VCs सहित) भुगतान की दुनिया से कैसे जुड़ते हैं। हम कवर करेंगे:

• वर्तमान फ़ोन वॉलेट (Apple Wallet, Google Wallet) पहचान की जानकारी को भुगतान कार्ड की तुलना में कैसे संभालते हैं।
• वर्तमान डिजिटल आईडी मानक जैसे ISO 18013-5/7 mdocs सीधे भुगतान उपकरण के रूप में वास्तव में उपयुक्त क्यों नहीं हैं।
• OpenID4VC जैसे प्रोटोकॉल भविष्य की भुगतान विधियों में क्या भूमिका निभा सकते हैं।
• अन्य (थर्ड-पार्टी) वॉलेट ऐप्स भुगतान सुविधाओं को कैसे संभाल सकते हैं।
• मुख्य समस्याएं और भुगतान प्रणालियों में वेरिफ़ाएबल क्रेडेंशियल्स का उपयोग करने की कोशिश करते समय भविष्य में क्या हो सकता है।

यह टेक्स्ट केवल भुगतान पर ध्यान केंद्रित करके Digital Credentials & Passkeys पर हमारी दूसरी चर्चा को आगे बढ़ाता है।

यह देखने के लिए कि डिजिटल क्रेडेंशियल्स का भुगतान में कैसे उपयोग किया जा सकता है, हमें पहले यह समझना होगा कि आज के मुख्य मोबाइल प्लेटफ़ॉर्म और उनके अंतर्निहित वॉलेट (Apple Wallet, Google Wallet) पहचान की जानकारी को भुगतान संसाधित करने के तरीके से कैसे अलग रखते हैं।

नेटिव प्लेटफ़ॉर्म वॉलेट उपयोगकर्ताओं के लिए परिष्कृत केंद्र बन गए हैं, लेकिन वे आम तौर पर पहचान क्रेडेंशियल्स और भुगतान उपकरणों के बीच एक स्पष्ट अंतर बनाए रखते हैं:

• पहचान क्रेडेंशियल्स (जैसे, mDLs):
  • Apple Wallet: मुख्य रूप से ISO/IEC 18013-5 के अनुरूप मोबाइल ड्राइवर लाइसेंस (mDLs) और राज्य आईडी का समर्थन करता है। WWDC25 के अनुसार, Apple ने पुष्टि की है कि Safari 26 (iOS 26 में) ऑनलाइन प्रस्तुति के लिए W3C Digital Credentials API का समर्थन करेगा, जिसमें org.iso.mdoc प्रोटोकॉल पर विशेष ध्यान दिया जाएगा। यह पहचान विशेषताओं (जैसे, नाम, आयु, पता) को सत्यापित करने के लिए है, भुगतान के लिए नहीं।
  • Google Wallet और Android Credential Manager: Google Wallet भी ISO 18013-5 पर आधारित mDLs का समर्थन करता है। अंतर्निहित Android Credential Manager एक अधिक लचीला ढांचा प्रदान करता है। जबकि इसका Digital Credentials API का कार्यान्वयन प्रोटोकॉल-अज्ञेयवादी है, Android एक डिफ़ॉल्ट कार्यान्वयन प्रदान करता है जो OpenID4VP को परिवहन तंत्र के रूप में उपयोग करता है।
• भुगतान उपकरण (जैसे, क्रेडिट/डेबिट कार्ड):
  • Apple Pay (Apple Wallet के भीतर) और Google Pay (Google Wallet के भीतर) दोनों स्थापित, अत्यधिक विनियमित भुगतान तकनीकों का उपयोग करते हैं। ये मुख्य रूप से EMV (Europay, Mastercard, Visa) मानकों पर आधारित हैं, जिसमें टोकनाइज़ेशन (लेन-देन के लिए वास्तविक कार्ड नंबरों की जगह डिवाइस PANs या DPANs), भुगतान टोकन संग्रहीत करने के लिए सुरक्षित तत्व या हार्डवेयर-समर्थित सुरक्षा, और लेनदेन सुरक्षा के लिए गतिशील क्रिप्टोग्राम शामिल हैं।
  • ये भुगतान प्रणालियाँ मौजूदा भुगतान नेटवर्क (Visa, Mastercard, Amex, आदि) और अधिग्रहण करने वाले बैंकों के साथ सीधे संपर्क करती हैं।

मुख्य बात: नेटिव प्लेटफ़ॉर्म वॉलेट वर्तमान में पहचान क्रेडेंशियल्स बनाम भुगतान कार्ड के लिए अलग-अलग "स्टैक" या तकनीकों के साथ काम करते हैं। एक mdoc पहचान विशेषता को साबित करने के लिए प्रस्तुत किया जाता है; भुगतान करने के लिए एक टोकनयुक्त कार्ड प्रस्तुत किया जाता है। इन नेटिव इकोसिस्टम के भीतर एक mdoc का भुगतान उपकरण के रूप में कोई सीधा उपयोग नहीं है।

ISO/IEC 18013-5 मानक mDLs और अन्य मोबाइल आईडी (mdocs) के लिए डेटा संरचना को परिभाषित करता है। पहचान सत्यापन के लिए उत्कृष्ट होने के बावजूद, इसका डिज़ाइन भुगतान उपकरण के रूप में सीधे उपयोग के लिए अनुपयुक्त है:

भले ही एक mdoc में सैद्धांतिक रूप से एक PAN या भुगतान टोकन रखने के लिए कस्टम डेटा फ़ील्ड जोड़े जा सकते हैं (जैसा कि ISO 18013-5 कस्टम नेमस्पेस के लिए अनुमति देता है), mdoc मानक स्वयं परिभाषित नहीं करता है:

• गतिशील भुगतान क्रिप्टोग्राम कैसे उत्पन्न या संसाधित करें।
• भुगतान नेटवर्क के साथ ऑनलाइन प्राधिकरण कैसे करें।
• भुगतान लेनदेन के लिए आवश्यक सुरक्षा तंत्र (पहचान डेटा अखंडता से परे)।

इस प्रकार वर्तमान में ISO 18013-5 mdoc को सीधे भुगतान उपकरण के रूप में उपयोग करने का कोई तरीका नहीं है।

जबकि एक mdoc भुगतान उपकरण नहीं है, यह "स्टेप-अप प्रमाणीकरण" प्रवाह में एक भूमिका निभा सकता है, जहाँ एक उच्च-जोखिम वाली कार्रवाई के लिए उपयोगकर्ता की पहचान को स्पष्ट रूप से सत्यापित किया जाना चाहिए। यह भुगतान को निष्पादित करने के लिए इसका उपयोग करने से अलग है। प्रवाह आमतौर पर ऐसा दिखेगा:

1. प्राथमिक प्रमाणीकरण: उपयोगकर्ता एक सेवा में लॉग इन करता है, अक्सर एक पासकी जैसे कम-घर्षण विधि के साथ।
2. स्टेप-अप के लिए ट्रिगर: एक उच्च-सुनिश्चितता कार्रवाई के लिए (जैसे, एक बड़ा बैंक हस्तांतरण, व्यक्तिगत विवरण अपडेट करना), सेवा को एक स्पष्ट पहचान जांच की आवश्यकता होती है।
3. mdoc प्रस्तुति: सेवा उपयोगकर्ता के mdoc (जैसे, ड्राइवर का लाइसेंस) की प्रस्तुति का अनुरोध करती है। उपयोगकर्ता अपने वॉलेट से आवश्यक विशेषताएँ प्रस्तुत करता है।
4. सत्यापन: सेवा mdoc डेटा को एक विश्वसनीय स्रोत या पहले से पंजीकृत पहचान के खिलाफ क्रिप्टोग्राफ़िक रूप से सत्यापित करती है।

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

जबकि mdocs स्वयं भुगतान उपकरण नहीं हैं, OpenID for Verifiable Credentials (OpenID4VC – जिसमें प्रस्तुति के लिए OpenID4VP और जारी करने के लिए OpenID4VCI शामिल हैं) जैसे प्रोटोकॉल एक अधिक लचीली परिवहन परत प्रदान करते हैं।

OpenID4VC की मुख्य विशेषताएँ:

• प्रोटोकॉल, पेलोड नहीं: OID4VC यह परिभाषित करता है कि VCs का अनुरोध और प्रस्तुति कैसे करें, लेकिन यह VC पेलोड के प्रारूप के बारे में काफी हद तक अनभिज्ञ है। यह mdocs, W3C मानक VCs (जैसे, JWT या SD-JWT प्रारूप में), या अन्य कस्टम क्रेडेंशियल प्रकारों का परिवहन कर सकता है।
• उपयोग-मामले की व्यापकता: यह लचीलापन Android जैसे प्लेटफ़ॉर्म (अपने क्रेडेंशियल मैनेजर के माध्यम से) को एक सामान्य तंत्र के माध्यम से विभिन्न प्रकार के क्रेडेंशियल्स के लिए अनुरोधों का समर्थन करने की अनुमति देता है।
• भुगतान VCs के लिए भविष्य की संगतता: यदि भुगतान उद्योग एक वेरिफ़ाएबल "भुगतान टोकन" या "भुगतान प्राधिकरण" क्रेडेंशियल प्रारूप को मानकीकृत करता है, तो OID4VC सैद्धांतिक रूप से उपयोगकर्ता के वॉलेट और एक व्यापारी/PSP के बीच ऐसे क्रेडेंशियल का परिवहन कर सकता है।

हालाँकि, OID4VC स्वयं एक भुगतान समाधान नहीं है:

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

नेटिव प्लेटफ़ॉर्म वॉलेट के अलावा, थर्ड-पार्टी वॉलेट (जैसे, EUDI वॉलेट, बैंक द्वारा प्रदान किए गए वॉलेट, विशेष उद्योग वॉलेट) का एक बढ़ता हुआ इकोसिस्टम उभर रहा है। इन वॉलेट्स को तेज़, कम-घर्षण वाले प्रमाणीकरण और उच्च-सुनिश्चितता वाले विशेषता सत्यापन के बीच मौलिक अंतर को नेविगेट करना होगा, खासकर भुगतान संदर्भों में।

उभरती हुई आम सहमति यह है कि Passkeys भुगतान सेवा के लिए मुख्य प्रमाणीकरण के लिए आदर्श हैं, क्योंकि वे फ़िशिंग-प्रतिरोधी हैं और एक सहज उपयोगकर्ता अनुभव के लिए डिज़ाइन किए गए हैं। महत्वपूर्ण भुगतान पुष्टि चरण में एक डिजिटल क्रेडेंशियल प्रस्तुति को शामिल करने से महत्वपूर्ण घर्षण बढ़ेगा और संभवतः कन्वर्ज़न रेट को नुकसान होगा। इसलिए, डिजिटल क्रेडेंशियल्स की प्राथमिक भूमिका एक बार की, उच्च-सुनिश्चितता वाली ऑनबोर्डिंग और KYC चरण में है जो भुगतान क्षमताओं को सक्षम करती है, न कि स्वयं लेनदेन में। ये वॉलेट भुगतान के लिए कैसे दृष्टिकोण अपना सकते हैं, खासकर डिजिटल पहचान सुविधाओं के साथ?

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

• ऐप-टू-ऐप डीप लिंकिंग: यह एक सार्वभौमिक विधि है जहाँ व्यापारी का एप्लिकेशन (नेटिव या वेब) उपयोगकर्ता को एक कस्टम URL स्कीम (जैसे, eudi-wallet://...) का उपयोग करके थर्ड-पार्टी वॉलेट ऐप पर रीडायरेक्ट करता है। लेनदेन का विवरण URL में पैरामीटर के रूप में पास किया जाता है। उपयोगकर्ता द्वारा वॉलेट ऐप में भुगतान की पुष्टि करने के बाद, यह एक और डीप लिंक का उपयोग करके व्यापारी ऐप पर वापस रीडायरेक्ट करता है। यह iOS और Android दोनों पर काम करता है लेकिन इसमें ऐप्स के बीच एक दृश्यमान संदर्भ स्विच शामिल है।
• नेटिव वॉलेट चयन: नेटिव वॉलेट चयन के साथ एक एप्लिकेशन एक सामान्य सिस्टम सेवा को लागू कर सकता है जो सभी पंजीकृत भुगतान हैंडलर या वॉलेट प्रदर्शित करता है। उपयोगकर्ता तब सिस्टम-प्रदत्त UI से अपना पसंदीदा वॉलेट चुन सकता है। यह साधारण डीप लिंकिंग (डिजिटल क्रेडेंशियल API) की तुलना में अधिक एकीकृत अनुभव प्रदान करता है।
• सरल QR कोड-आधारित भुगतान: यह मॉडल डेस्कटॉप-से-मोबाइल प्रवाह के लिए आदर्श है। व्यापारी की वेबसाइट एक QR कोड प्रदर्शित करती है जिसमें लेनदेन का विवरण या एक URL होता है। उपयोगकर्ता इस कोड को अपने मोबाइल वॉलेट ऐप से स्कैन करता है, जो फिर फ़ोन पर पुष्टि को स्वतंत्र रूप से संभालता है। वॉलेट का बैकएंड फिर व्यापारी के सिस्टम को अनुमोदन वापस संचारित करता है।
• मानकीकृत क्रॉस-डिवाइस प्रवाह (FIDO CTAP): QR कोड विधि का एक विकास, यह डेस्कटॉप ब्राउज़र (क्लाइंट) और मोबाइल वॉलेट (एक ऑथेंटिकेटर के रूप में कार्य करते हुए) के बीच एक सीधा, सुरक्षित और एन्क्रिप्टेड चैनल बनाने के लिए FIDO के क्लाइंट टू ऑथेंटिकेटर प्रोटोकॉल (CTAP) जैसे प्रोटोकॉल का उपयोग करता है। यह साधारण QR कोड से अधिक सुरक्षित है क्योंकि ब्राउज़र और फ़ोन सीधे संवाद करते हैं, एक मॉडल जिसे Google द्वारा Passkeys और डिजिटल क्रेडेंशियल्स दोनों के लिए भारी समर्थन प्राप्त है।
• प्रत्यक्ष बैकएंड एकीकरण: कुछ बंद-लूप प्रणालियों में, थर्ड-पार्टी वॉलेट ऐप भुगतान संसाधित करने के लिए सीधे एक पेमेंट सर्विस प्रोवाइडर (PSP) या किसी वित्तीय संस्थान के बैकएंड के साथ इंटरैक्ट कर सकता है, अक्सर मालिकाना API का उपयोग करके।

ये मॉडल भुगतान पुष्टि शुरू करने के लिए "परिवहन परत" प्रदान करते हैं, जिसके भीतर एक क्रिप्टोग्राफ़िक प्रवाह (जैसे EUDI वॉलेट के लिए विस्तृत) हो सकता है।

WWDC25 में घोषणाओं के साथ, ब्राउज़र डिजिटल क्रेडेंशियल्स को कैसे संभालते हैं, इसका परिदृश्य बहुत स्पष्ट हो गया है, जिससे पहचान सत्यापन और भुगतान प्रसंस्करण के बीच अलगाव मजबूत हो गया है। प्लेटफ़ॉर्म थर्ड-पार्टी वॉलेट को W3C Digital Credentials API के माध्यम से पहचान सत्यापन के लिए ब्राउज़रों के साथ इंटरैक्ट करने में सक्षम बना रहे हैं, लेकिन दृष्टिकोण अलग-अलग हैं:

• Apple का रुख (WWDC25 में पुष्टि): Apple ने आधिकारिक तौर पर Safari 26 (iOS 26 के साथ शिपिंग) में Digital Credentials API के लिए समर्थन की घोषणा की। जैसा कि उनके "वेब पर पहचान दस्तावेज़ सत्यापित करें" सत्र में विस्तृत है, कार्यान्वयन विशेष रूप से org.iso.mdoc प्रोटोकॉल का समर्थन करता है। यह वेबसाइटों को Apple Wallet या अन्य पंजीकृत थर्ड-पार्टी दस्तावेज़ प्रदाता ऐप्स में mdocs से वेरिफ़ाएबल जानकारी का अनुरोध करने की अनुमति देता है, लेकिन यह अधिक सामान्य-उद्देश्य वाले OpenID4VP प्रोटोकॉल का समर्थन नहीं करता है। डिजिटल क्रेडेंशियल्स और उन्नत वेब एकीकरण के लिए बढ़ते समर्थन के साथ, सिस्टम प्रदर्शन और सुरक्षा बनाए रखना और भी महत्वपूर्ण हो जाता है - CleanMyMac जैसे उपकरण यह सुनिश्चित करने में मदद करते हैं कि इन तकनीकों के विकसित होने पर आपका Mac सुचारू रूप से चले।
• Google का रुख: Android का क्रेडेंशियल मैनेजर थर्ड-पार्टी वॉलेट को क्रेडेंशियल अनुरोधों के लिए हैंडलर के रूप में पंजीकृत करने की अनुमति देता है। Chrome में इसका Digital Credentials API का कार्यान्वयन OpenID4VP को प्राथमिक परिवहन प्रोटोकॉल के रूप में उपयोग करने पर केंद्रित है। जबकि OpenID4VP एक पेलोड के रूप में एक mdoc ले जा सकता है, प्रोटोकॉल स्वयं Apple के प्रत्यक्ष org.iso.mdoc दृष्टिकोण से अलग है।

महत्वपूर्ण रूप से, ये ब्राउज़र एकीकरण पहचान विशेषताओं के लिए हैं, न कि प्रस्तुत mDoc या VC को भुगतान उपकरण के रूप में मानने के लिए।

यदि कोई उपयोगकर्ता अपने वॉलेट से एक mDL को ब्राउज़र के Digital Credentials API के माध्यम से एक वेबसाइट पर प्रस्तुत करता है, तो वह वेबसाइट चेकआउट के दौरान पते को पहले से भरने या आयु सत्यापन के लिए जानकारी का उपयोग कर सकती है। हालाँकि, वास्तविक भुगतान चरण के लिए अभी भी एक भुगतान विधि (जैसे, Apple Pay, Google Pay, या कार्ड विवरण दर्ज करना) के साथ एक अलग इंटरेक्शन की आवश्यकता होगी। ब्राउज़र API स्वयं एक पहचान क्रेडेंशियल का उपयोग करके वित्तीय लेनदेन शुरू करने या संसाधित करने के लिए डिज़ाइन नहीं किया गया है।

EU डिजिटल पहचान (EUDI) वॉलेट एक उत्कृष्ट केस स्टडी के रूप में कार्य करता है कि कैसे एक थर्ड-पार्टी वॉलेट को ऑपरेटिंग सिस्टम और API उपलब्धता के जटिल, वास्तविक दुनिया के परिदृश्य को नेविगेट करना होगा। इसके कई कार्यों में से, दो सबसे प्रमुख उपयोग के मामले पहचान सत्यापन और भुगतान पुष्टि हैं, और इन दो कार्यों को पूरा करने के लिए तकनीकी रास्ते अलग-अलग हैं, खासकर जब Android के लचीले ढांचे की तुलना Apple के अधिक कठोर कार्यान्वयन से की जाती है।

निम्नलिखित तालिका यह बताती है कि EUDI वॉलेट को पहचान सत्यापन या भुगतान प्राधिकरण के लिए कैसे लागू किया जा सकता है, जो प्लेटफ़ॉर्म पर अलग-अलग समर्थन को उजागर करता है।

तुलना से मुख्य निष्कर्ष:

• Digital Credentials API: यह उभरता हुआ W3C मानक प्रोटोकॉल-अज्ञेयवादी है और दोनों प्लेटफ़ॉर्म पर पहचान के लिए अच्छी तरह से समर्थित है। इसके कार्यान्वयन के लिए, Android लचीले OpenID4VP प्रोटोकॉल का उपयोग करके एक डिफ़ॉल्ट प्रवाह प्रदान करता है, जो विभिन्न क्रेडेंशियल प्रारूपों को ले जा सकता है। इसके विपरीत, Apple का कार्यान्वयन सख्ती से org.iso.mdoc प्रारूप के लिए है। महत्वपूर्ण रूप से, ब्राउज़र इस API को पहचान उपयोग के मामलों के लिए स्कोप करते हैं, भुगतान शुरू करने के लिए नहीं।
• नेटिव वॉलेट चयनकर्ता: दोनों ऑपरेटिंग सिस्टम एक वॉलेट का चयन करने के लिए एक नेटिव UI प्रदान करते हैं, लेकिन अलग-अलग सीमाओं के साथ। Android पहचान और भुगतान दोनों ऐप्स के लिए एक चयनकर्ता प्रदान करता है। iOS पंजीकृत पहचान "दस्तावेज़ प्रदाता" ऐप्स के लिए एक चयनकर्ता प्रदान करता है लेकिन थर्ड-पार्टी भुगतान ऐप्स के लिए एक प्रदान नहीं करता है।
• ऐप-टू-ऐप डीप लिंकिंग: यह सार्वभौमिक वर्कहॉर्स है, जो दोनों प्लेटफ़ॉर्म पर पहचान और भुगतान दोनों उपयोग के मामलों के लिए मज़बूती से काम करता है। यह iOS पर भुगतान के लिए थर्ड-पार्टी वॉलेट को लागू करने का प्राथमिक तरीका बना हुआ है।
• मानकीकृत क्रॉस-डिवाइस: यह FIDO CTAP-आधारित प्रवाह वर्तमान में Google/Android इकोसिस्टम की एक विशेषता है और iOS पर समर्थित नहीं है।

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

यह तुलना स्पष्ट करती है कि जबकि पहचान सत्यापन को डिजिटल क्रेडेंशियल API के माध्यम से तेजी से मानकीकृत किया जा रहा है, EUDI वॉलेट जैसे थर्ड-पार्टी वॉलेट के लिए भुगतान प्राधिकरण अभी भी ऐप-टू-ऐप डीप लिंकिंग जैसे अधिक पारंपरिक नेटिव एकीकरण पैटर्न पर बहुत अधिक निर्भर करता है, खासकर iOS पर।

वॉलेट को लागू करने के लिए चाहे किसी भी भुगतान एकीकरण मॉडल का उपयोग किया जाए, EUDI वॉलेट की भुगतान पुष्टि का मूल EWC RFC008 में विस्तृत एक मानकीकृत क्रिप्टोग्राफ़िक प्रवाह पर निर्भर करता है।

नीचे इस प्रक्रिया का एक उच्च-स्तरीय वॉक-थ्रू है:

यह payment_data ऑब्जेक्ट का एक गैर-मानक उदाहरण है जो वॉलेट को भेजा जाता है, जिसमें उपयोगकर्ता द्वारा पुष्टि के लिए लेनदेन का विवरण होता है।

{
    "payee": "Merchant XYZ",
    "currency_amount": {
        "currency": "EUR",
        "value": "23.58"
    },
    "recurring_schedule": {
        "start_date": "2024-11-01",
        "expiry_date": "2025-10-31",
        "frequency": 30
    }
}

उपयोगकर्ता द्वारा अनुमोदन के बाद, वॉलेट एक की-बाइंडिंग JWT बनाता है। इसके क्लेम यह साबित करते हैं कि उपयोगकर्ता ने विशिष्ट लेनदेन डेटा की पुष्टि की है।

{
    "nonce": "n-0S6_WzA2Mj",
    "aud": "https://example.com/verifier",
    "iat": 1709838604,
    "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4",
    "transaction_data_hashes": ["fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do"]
}

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

वेरिफ़ाएबल क्रेडेंशियल्स (VCs) की क्षमता को समझने का एक शक्तिशाली तरीका उनकी तुलना सफल नेटवर्क भुगतान टोकनाइज़ेशन सिस्टम (जैसे Visa टोकन सर्विस या Mastercard MDES) से करना है।

• भुगतान टोकनाइज़ेशन ने संवेदनशील प्राइमरी अकाउंट नंबर (PAN) को एक सुरक्षित टोकन और एक बार के क्रिप्टोग्राम से बदल दिया। यह लेनदेन के दौरान मुख्य संपत्ति—कार्ड नंबर—की रक्षा करता है।
• वेरिफ़ाएबल क्रेडेंशियल्स का उद्देश्य व्यक्तिगत डेटा के लिए वही करना है जो टोकनाइज़ेशन ने PANs के लिए किया था। कच्चे डेटा (नाम, जन्मतिथि, पता) साझा करने के बजाय, उपयोगकर्ता एक विश्वसनीय जारीकर्ता से क्रिप्टोग्राफ़िक रूप से हस्ताक्षरित क्रेडेंशियल प्रस्तुत करता है।

संक्षेप में, एक VC व्यक्तिगत डेटा के लिए वही है जो एक भुगतान टोकन और क्रिप्टोग्राम कार्ड डेटा के लिए है: एक सुरक्षित, वेरिफ़ाएबल विकल्प जो जोखिम को कम करता है और गोपनीयता को बढ़ाता है।

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

• EMVCo, सुरक्षित भुगतान के लिए मानक निकाय, सक्रिय रूप से FIDO मानकों को EMV 3-D Secure प्रोटोकॉल में एकीकृत कर रहा है। यह पिछले पासकी प्रमाणीकरणों को घर्षण रहित अनुमोदन के लिए एक मजबूत संकेत के रूप में उपयोग करने की अनुमति देता है, जबकि पारंपरिक OTP चुनौतियों के आधुनिक, फ़िशिंग-प्रतिरोधी विकल्प के रूप में Secure Payment Confirmation (SPC) के लिए भी तैयारी कर रहा है। इस पर भी चर्चा चल रही है कि भविष्य में इन प्रवाहों में वेरिफ़ाएबल क्रेडेंशियल्स को कैसे शामिल किया जा सकता है।
• Visa ने Visa Payment Passkey Service की घोषणा की है, जो एक FIDO ऑथेंटिकेटर को भुगतान क्रेडेंशियल्स से सुरक्षित रूप से जोड़ता है। यह सेवा चेकआउट अनुभव को बाधित किए बिना एक ही, घर्षण रहित चरण में पहचान की पुष्टि करने और भुगतान को अधिकृत करने के लिए डिज़ाइन की गई है।
• Mastercard अपनी Mastercard Payment Passkey Service के साथ एक समानांतर रणनीति का पालन कर रहा है, जो अपने टोकन ऑथेंटिकेशन सर्विस (TAS) का लाभ उठाकर पासवर्ड और OTP को पासकी-आधारित बायोमेट्रिक प्रमाणीकरण से बदलता है, जो इसकी टोकनाइज़ेशन सेवाओं (MDES) के साथ कसकर एकीकृत है।

यह एक स्पष्ट प्रवृत्ति दिखाता है: उद्योग एक ऐसे भविष्य की ओर बढ़ रहा है जहाँ एक वॉलेट एक ही, मानकीकृत प्रवाह में पहचान और भुगतान प्राधिकरण दोनों का क्रिप्टोग्राफ़िक रूप से वेरिफ़ाएबल प्रमाण प्रस्तुत कर सकता है।

इस नवाचार का अधिकांश हिस्सा मजबूत नियामक हवाओं से तेज हो रहा है, खासकर यूरोपीय संघ से।

EU का eIDAS 2.0 विनियमन केवल नागरिकों को एक डिजिटल आईडी प्रदान करने के बारे में नहीं है; यह स्पष्ट रूप से EUDI वॉलेट को ऑनलाइन भुगतान के लिए SCA करने की एक विधि के रूप में देखता है। इसका मतलब है कि भविष्य में, EU में बैंकों और भुगतान प्रदाताओं को EUDI वॉलेट को उपयोगकर्ताओं के लिए ऑनलाइन लेनदेन की पुष्टि करने के एक तरीके के रूप में स्वीकार करने की आवश्यकता हो सकती है, जो मालिकाना बैंकिंग ऐप्स या SMS कोड का एक मानक-आधारित विकल्प प्रदान करता है।

EU में एक ऐतिहासिक अविश्वास समझौते ने पहले ही Apple को iPhones पर अपने पहले से बंद NFC इंटरफ़ेस को खोलने के लिए मजबूर कर दिया है। iOS 17.4 (5 मार्च, 2024 को जारी) के अनुसार, Apple ने आवश्यक API लागू कर दिए हैं और उपयोगकर्ताओं को एक डिफ़ॉल्ट संपर्क रहित भुगतान ऐप चुनने की अनुमति दी है, जो यूरोपीय आयोग की 25 जुलाई, 2024 की बाध्यकारी समय सीमा को पूरा करता है। यह अब भविष्य की संभावना नहीं है; यह यूरोपीय आर्थिक क्षेत्र (EEA) में वर्तमान वास्तविकता है।

इस बदलाव का मतलब है कि थर्ड-पार्टी वॉलेट ऐप्स अब iOS पर अपने स्वयं के टैप-टू-पे समाधान पेश कर सकते हैं, जिससे Apple Pay का लंबे समय से चला आ रहा एकाधिकार समाप्त हो गया है। डेवलपर्स के लिए अब उपलब्ध प्रमुख क्षमताओं में शामिल हैं:

• डिफ़ॉल्ट वॉलेट विकल्प: EEA में उपयोगकर्ता एक योग्य थर्ड-पार्टी ऐप को अपने डिफ़ॉल्ट संपर्क रहित भुगतान एप्लिकेशन के रूप में सेट कर सकते हैं, जिसे साइड-बटन डबल-क्लिक के माध्यम से लागू किया जा सकता है।
• पूर्ण एकीकरण: ये वॉलेट भुगतान प्राधिकरण के लिए iPhone की नेटिव सुरक्षा सुविधाओं, जिसमें Face ID और Touch ID शामिल हैं, का उपयोग कर सकते हैं।
• वास्तविक दुनिया में अपनाना: कई प्रमुख खिलाड़ियों ने पहले ही अपने समाधान लॉन्च कर दिए हैं, जिनमें नॉर्वे में Vipps MobilePay और जर्मनी में PayPal शामिल हैं।

इस उद्घाटन के निहितार्थ महत्वपूर्ण हैं और पहले से ही सामने आ रहे हैं:

• बढ़ी हुई प्रतिस्पर्धा: बैंक और फिनटेक अब Apple Pay के साथ उसके अपने प्लेटफ़ॉर्म पर सीधे प्रतिस्पर्धा कर सकते हैं, जिससे जारीकर्ता शुल्क कम होने और नवाचार को बढ़ावा मिलने की उम्मीद है।
• व्यापक क्रेडेंशियल उपयोग: समान API का उपयोग केवल भुगतान से अधिक के लिए किया जा सकता है, जिसमें कॉर्पोरेट बैज, ट्रांजिट पास और होटल की चाबियाँ शामिल हैं, बिना Apple Wallet में होने की आवश्यकता के।
• मानकीकृत क्रेडेंशियल्स के लिए एक मार्ग: यह एक महत्वपूर्ण मिसाल कायम करता है। वही नियामक तर्क जिसने भुगतान ऐप्स के लिए NFC इंटरफ़ेस खोला, अंततः मानकीकृत, तटस्थ "वेरिफ़ाएबल पेमेंट क्रेडेंशियल्स" (जैसे कि EUDI वॉलेट के लिए पायलट किए जा रहे) के लिए समर्थन को अनिवार्य करने के लिए इस्तेमाल किया जा सकता है, जिससे उन्हें मालिकाना समाधानों के साथ काम करने की अनुमति मिलती है।
• वैश्विक मिसाल: जबकि यह परिवर्तन वर्तमान में EEA तक सीमित है, यह एक शक्तिशाली वैश्विक मिसाल कायम करता है। अमेरिका सहित अन्य क्षेत्रों के नियामक बारीकी से देख रहे हैं, और यह दुनिया भर में इसी तरह के उद्घाटन को तेज कर सकता है।

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

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

1. नेटिव ऐप अपनाने को बढ़ावा दें: आपका मोबाइल ऐप आपका भविष्य का वॉलेट है। प्राथमिक उद्देश्य इसे आपके ग्राहकों के लिए एक अनिवार्य उपकरण बनाना है। यह वितरण और जुड़ाव किसी भी भविष्य के क्रेडेंशियल जारी करने या वॉलेट कार्यक्षमता के लिए महत्वपूर्ण आधार है।

2. PayPal मॉडल का पालन करते हुए, भुगतान के लिए Passkeys का उपयोग करें: Passkeys को तुरंत तैनात करें, न केवल लॉगिन के लिए, बल्कि भुगतान प्राधिकरण के लिए भी। Apple Pay जैसे नेटिव प्लेटफ़ॉर्म समाधानों के साथ निकट समानता वाले अनुभव का लक्ष्य रखें। मजबूत ग्राहक प्रमाणीकरण (SCA) की आवश्यकता वाले नियामक वातावरणों के लिए, PayPal के व्यावहारिक दृष्टिकोण को अपनाएं:

   • Passkeys को एक प्राथमिक प्रमाणीकरण कारक के रूप में उपयोग करें।
   • SCA के "कब्जे" कारक को पूरा करने के लिए उन्हें विश्वसनीय डिवाइस सिग्नल (जैसे, आपके ऐप या सुरक्षित कुकीज़ के माध्यम से प्रबंधित "याद किए गए डिवाइस") के साथ मिलाएं।
   • यह संयोजन आपको एक सहज, कम-घर्षण वाला भुगतान पुष्टि अनुभव प्रदान करने की अनुमति देता है जो अत्यधिक सुरक्षित और अनुपालन दोनों है, बिना सार्वभौमिक VC समर्थन की प्रतीक्षा किए।

एक सुरक्षित, पासकी-संरक्षित ऐप को अपनी नींव के रूप में, आप चुनिंदा रूप से नई क्रेडेंशियल तकनीकों को एकीकृत करना शुरू कर सकते हैं जहाँ वे स्पष्ट मूल्य प्रदान करते हैं।

3. वेरिफ़ाएबल पेमेंट क्रेडेंशियल्स के उदय की निगरानी करें: एक VC की अवधारणा जो एक भुगतान टोकन ले जाती है, शक्तिशाली है लेकिन अभी तक मानकीकृत नहीं है। यहाँ आपकी भूमिका एक सक्रिय पर्यवेक्षक और भागीदार होने की है।

   • कार्रवाई: EMVCo और W3C जैसे मानक निकायों के भीतर प्रगति को बारीकी से ट्रैक करें। मानकीकृत वेरिफ़ाएबल पेमेंट क्रेडेंशियल्स का लाभ उठाने के लिए तैयार रहें यदि और जब वे मौजूदा पासकी-आधारित प्रवाह पर एक स्पष्ट लाभ प्रदान करते हैं।

4. पहचान उपयोग के मामलों के लिए डिजिटल क्रेडेंशियल्स को एकीकृत करें: जैसे-जैसे डिजिटल पहचान वॉलेट (जैसे EUDI वॉलेट) कर्षण प्राप्त करते हैं, पहचान-संबंधी कार्यों के लिए डिजिटल क्रेडेंशियल API को एकीकृत करें, भुगतान के लिए नहीं।

   • कार्रवाई: उच्च-सुनिश्चितता प्रक्रियाओं के लिए VC प्रस्तुतियों का उपयोग करें जहाँ वे उत्कृष्टता प्राप्त करते हैं:
     • ऑनबोर्डिंग और KYC: नए खाते की स्थापना को सुव्यवस्थित करें।
     • स्टेप-अप प्रमाणीकरण: उच्च-जोखिम वाली कार्रवाइयों के लिए पहचान सत्यापित करें।
     • खाता पुनर्प्राप्ति: उन उपयोगकर्ताओं के लिए एक सुरक्षित मार्ग प्रदान करें जिन्होंने अपने डिवाइस खो दिए हैं।

किसी भी नई भुगतान तकनीक को अपनाने में अंतिम बाधा उपयोगकर्ता घर्षण है। एक साधारण पासकी प्रवाह को विस्थापित करने से पहले, एक VC-आधारित विकल्प को यह साबित करना होगा कि यह न केवल अधिक सुरक्षित है बल्कि उतना ही सहज भी है।

5. एक-क्लिक अनुभव के खिलाफ लगातार बेंचमार्क करें: एक आधुनिक भुगतान अनुभव का मानक Apple Pay और वेब पर इसके करीबी अनुयायी, PayPal जैसे नेताओं द्वारा निर्धारित किया गया है। आपके द्वारा पेश किया गया कोई भी नया प्रवाह उनके लगभग-तत्काल, एक-क्लिक पुष्टि के साथ प्रतिस्पर्धा करना चाहिए। सभी मौजूदा संकेत बताते हैं कि अधिकांश लेनदेन के लिए, पासकी का फ़िशिंग प्रतिरोध पर्याप्त स्तर की सुरक्षा और एक बेहतर उपयोगकर्ता अनुभव प्रदान करता है। भुगतान प्रवाह में VC प्रस्तुति चरण न जोड़ें यदि यह कोई बोधगम्य घर्षण पेश करता है।

6. WebAuthn के भीतर इन-बैंड डिवाइस सिग्नल पर नज़र रखें: पासकी का विकास स्थिर नहीं है। जबकि डिवाइस-विशिष्ट सिग्नल प्रदान करने के शुरुआती प्रयास बंद कर दिए गए थे, मानक निकाय सक्रिय रूप से WebAuthn प्रोटोकॉल में सीधे मजबूत डिवाइस-बाइंडिंग ट्रस्ट सिग्नल को एकीकृत करने पर काम कर रहे हैं। यह एक RP को पासकी प्रमाणीकरण के दौरान एक विश्वसनीय डिवाइस की पहचान करने की अनुमति देगा, जिससे जोखिम इंजनों के लिए सिग्नल को और मजबूत किया जा सकेगा, बिना किसी अलग, आउट-ऑफ-बैंड VC प्रस्तुति की आवश्यकता के। इस स्थान की बारीकी से निगरानी करें, क्योंकि यह पासकी के घर्षण रहित अनुभव का त्याग किए बिना बढ़ी हुई सुरक्षा का सबसे संभावित मार्ग है।

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

डिजिटल क्रेडेंशियल्स को केवल KYC का समर्थन करने या भुगतान खातों में उपयोगकर्ताओं को प्रमाणित करने से परे भुगतान प्रक्रियाओं का एक अभिन्न अंग बनने के लिए, कई महत्वपूर्ण चुनौतियों का समाधान किया जाना चाहिए:

1. भुगतान-विशिष्ट VCs का मानकीकरण: भुगतान के लिए एक समर्पित, सुरक्षित और व्यापक रूप से स्वीकृत वेरिफ़ाएबल क्रेडेंशियल प्रारूप विकसित करने की आवश्यकता है। इसमें भुगतान टोकन, लेनदेन-विशिष्ट डेटा, और संभावित रूप से गतिशील सुरक्षा तत्वों को समाहित करने की आवश्यकता होगी, जो वर्तमान पहचान-केंद्रित mdocs या सामान्य VCs के दायरे से कहीं अधिक है।
2. भुगतान नेटवर्क के साथ एकीकरण: किसी भी VC-आधारित भुगतान समाधान को मौजूदा वैश्विक भुगतान नेटवर्क (Visa, Mastercard, आदि) के साथ सहजता से एकीकृत होना चाहिए या व्यवहार्य नई रेल का प्रस्ताव करना चाहिए। इसमें जटिल तकनीकी, सुरक्षा और व्यावसायिक मॉडल संरेखण शामिल हैं।
3. नियामक अनुपालन: भुगतान भारी रूप से विनियमित होते हैं (जैसे, यूरोप में PSD2/SCA, विश्व स्तर पर PCI DSS)। एक VC-आधारित भुगतान प्रणाली को सुरक्षा, उपभोक्ता संरक्षण और धोखाधड़ी-रोधी के लिए सभी प्रासंगिक वित्तीय नियमों को पूरा करना होगा।
4. जारीकर्ता और अधिग्रहणकर्ता को अपनाना: बैंकों, वित्तीय संस्थानों (भुगतान VCs के जारीकर्ताओं के रूप में), और व्यापारी अधिग्रहणकर्ताओं को ऐसी प्रणाली का समर्थन करने के लिए बुनियादी ढांचे में निवेश करने की आवश्यकता होगी।
5. सुरक्षा मॉडल: भुगतान VCs के लिए एक मजबूत सुरक्षा मॉडल आवश्यक होगा, जिसमें वित्तीय संदर्भ में जारी करना, भंडारण (आदर्श रूप से हार्डवेयर-समर्थित सुरक्षित तत्वों में), प्रस्तुति और निरस्तीकरण शामिल होगा।
6. उपयोगकर्ता अनुभव: जबकि VCs उपयोगकर्ता नियंत्रण की पेशकश कर सकते हैं, व्यापक रूप से अपनाने के लिए भुगतान का अनुभव तेज़, सहज और विश्वसनीय बना रहना चाहिए।

भविष्य की संभावनाएं:

• भुगतान प्राधिकरण पर्चियों के लिए VCs: VCs एक लिंक किए गए खाते से भुगतान करने के लिए क्रिप्टोग्राफ़िक रूप से हस्ताक्षरित "प्राधिकरण" का प्रतिनिधित्व कर सकते हैं, जिसे OpenID4VP के माध्यम से प्रस्तुत किया जाता है, जबकि वास्तविक धन हस्तांतरण अभी भी पारंपरिक रेल के माध्यम से होता है।
• भुगतान टोकन वाले VCs: एक मानकीकृत VC को एक भुगतान टोकन (EMV DPAN के समान) को सुरक्षित रूप से रखने के लिए परिभाषित किया जा सकता है, जिसे बाद में मौजूदा भुगतान अवसंरचनाओं द्वारा संसाधित किया जाता है।
• बंद-लूप भुगतान VCs: विशिष्ट जारीकर्ता या समुदाय अपने स्वयं के बंद-लूप सिस्टम के भीतर भुगतान के लिए VCs बना सकते हैं।

हालाँकि, ये वर्तमान में काफी हद तक वैचारिक हैं। वर्तमान VC और mdoc विकास के पीछे प्राथमिक प्रेरणा, जो अब ब्राउज़र API के ठोस कार्यान्वयन द्वारा मजबूत हो गई है, पहचान सत्यापन और विशेषता सत्यापन पर केंद्रित है, न कि भुगतान निष्पादन पर।

डिजिटल पहचान और भुगतान का अभिसरण एक जटिल लेकिन नौगम्य परिदृश्य प्रस्तुत करता है। जबकि एक एकल, सार्वभौमिक "वेरिफ़ाएबल पेमेंट क्रेडेंशियल" का वादा आकर्षक है, यह लेख इस निष्कर्ष पर पहुँचता है कि आज भुगतान जारीकर्ताओं के लिए सबसे प्रभावी और व्यावहारिक रणनीति एक अलग वास्तविकता पर आधारित है: सर्वश्रेष्ठ उपयोगकर्ता अनुभव के लिए लड़ाई सर्वोपरि है, और Passkeys सबसे शक्तिशाली हथियार हैं.

रणनीतिक प्लेबुक स्पष्ट है। तत्काल, कम-अफसोस वाला कदम एक अपराजेय नेटिव ऐप स्थापित करने पर ध्यान केंद्रित करना है, इसका उपयोग पासकी-आधारित भुगतानों को तैनात करने के लिए एक वाहन के रूप में करना है जो Apple Pay और PayPal द्वारा निर्धारित घर्षण रहित "एक-क्लिक" मानक को टक्कर दे सकता है। यह दृष्टिकोण परिपक्व, व्यापक रूप से अपनाई गई तकनीक का उपयोग करके आज सुरक्षा (फ़िशिंग प्रतिरोध के माध्यम से) और उपयोगकर्ता अनुभव की मुख्य जरूरतों को संबोधित करता है।

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

भुगतान का भविष्य किसी एक तकनीक से नहीं बल्कि उपयोगकर्ता पर निरंतर ध्यान केंद्रित करने से निर्धारित होगा। सफलता उन जारीकर्ताओं को मिलेगी जो पहले अपने स्वयं के ऐप्स में पासकी-संचालित अनुभव में महारत हासिल करते हैं, जबकि वेरिफ़ाएबल क्रेडेंशियल्स और इन-बैंड पासकी ट्रस्ट सिग्नल के विकास की सोच-समझकर निगरानी करते हैं। उन्हें इन नई तकनीकों को एकीकृत करने के लिए तैयार रहना चाहिए, न कि जब वे केवल उपलब्ध हों, बल्कि केवल तभी जब वे वास्तव में सहज, सुरक्षित और बेहतर भुगतान अनुभव के दुर्जेय बेंचमार्क को पूरा कर सकें।