तीसरे पक्ष की कुकी, ब्राउज़र की पाबंदियों, उपयोगकर्ता सेटिंग, डेवलपर फ़्लैग या एंटरप्राइज़ नीति की वजह से ब्लॉक हो सकती हैं.
आपको यह पक्का करना होगा कि आपकी साइट या सेवा, सभी उपयोगकर्ताओं को बेहतरीन अनुभव देती हो. भले ही, तीसरे पक्ष की कुकी उपलब्ध हों या नहीं.
इस पेज पर, आम तौर पर उपयोगकर्ताओं के सफ़र के बारे में जानकारी दी गई है. तीसरे पक्ष की कुकी ब्लॉक होने पर, इन पर असर पड़ सकता है.
उपयोगकर्ता की सामान्य गतिविधियां
पेमेंट और खरीदारी के कई वर्कफ़्लो, तीसरे पक्ष की कुकी पर निर्भर करते हैं. नीचे दी गई टेबल में, उपयोगकर्ता के कुछ ऐसे सफ़र के बारे में बताया गया है जिन पर तीसरे पक्ष की कुकी बंद होने का असर पड़ सकता है. साथ ही, इस टेबल में ऐसे अन्य एपीआई के सुझाव भी दिए गए हैं जिनका इस्तेमाल करके डेवलपर, ऐप्लिकेशन के काम न करने की समस्या से बच सकते हैं. यह पूरी सूची नहीं है. निजता सैंडबॉक्स के ज़्यादा समाधान उपलब्ध होने पर, इस सूची को अपडेट किया जा सकता है. अगर आपको इस बदलाव से जुड़ी कोई और समस्या आती है, तो हमारा सुझाव है कि आप अपना सुझाव, शिकायत या राय शेयर करें.
पेमेंट से जुड़ी उपयोगकर्ता गतिविधियों की जांच करना
तीसरे पक्ष की कुकी से जुड़ी पाबंदियों से आपके उपयोगकर्ता फ़्लो पर असर पड़ा है या नहीं, यह पता लगाने का सबसे अच्छा तरीका यह है कि आप तीसरे पक्ष की कुकी की जांच करने के लिए फ़्लैग चालू करके, उन पर नज़र डालें.
यह पक्का करने के लिए कि आपकी वेबसाइट उम्मीद के मुताबिक काम कर रही हो, तीसरे पक्ष की कुकी पर पाबंदी लगाकर, नीचे दिए गए फ़्लो की जांच करें:
- क्रॉस-साइट चेकआउट: तीसरे पक्ष के पेमेंट प्रोवाइडर (जैसे, <example-provider> से पेमेंट करें) पर निर्भर रहने वाले पेमेंट फ़्लो की जांच करें. पक्का करें कि:
- रीडायरेक्ट हो जाता है.
- पेमेंट गेटवे सही तरीके से लोड हो.
- पेमेंट की प्रोसेस बिना किसी गड़बड़ी के पूरी हो.
- उपयोगकर्ता को आपकी वेबसाइट पर वापस रीडायरेक्ट कर दिया जाता है.
- पेमेंट डैशबोर्ड: जांचें कि लेन-देन के डैशबोर्ड विजेट, तीसरे पक्ष की कुकी पर लगी पाबंदी के साथ उम्मीद के मुताबिक काम करते हैं या नहीं. पुष्टि करें कि उपयोगकर्ता:
- डैशबोर्ड को ऐक्सेस करें.
- सभी पेमेंट उम्मीद के मुताबिक दिखें.
- डैशबोर्ड के अलग-अलग सेक्शन (जैसे, लेन-देन का इतिहास, पेमेंट की जानकारी) के बीच बिना किसी गड़बड़ी के नेविगेट करना.
- पेमेंट के तरीके मैनेज करना: जांचें कि पेमेंट के तरीके मैनेज करने वाले विजेट, उम्मीद के मुताबिक काम कर रहे हैं या नहीं. तीसरे पक्ष की कुकी ब्लॉक होने पर, यह जांचें कि:
- पेमेंट का तरीका जोड़ने या मिटाने की सुविधा ठीक से काम करती है.
- हालांकि, पहले से सेव किए गए पेमेंट के तरीकों से पेमेंट करने पर कोई असर नहीं पड़ेगा.
- धोखाधड़ी का पता लगाना: तीसरे पक्ष की कुकी के साथ और उनके बिना, धोखाधड़ी का पता लगाने वाले समाधान के काम करने के तरीके की तुलना करें.
- क्या तीसरे पक्ष की कुकी को ब्लॉक करने से, उपयोगकर्ता को अतिरिक्त चरण पूरे करने पड़ते हैं और उसे परेशानी होती है?
- क्या ब्राउज़र में तीसरे पक्ष की कुकी ब्लॉक होने पर भी, यह संदिग्ध पैटर्न का पता लगा सकता है?
- उपयोगकर्ताओं के हिसाब से बनाया गया चेकआउट बटन: जांचें कि तीसरे पक्ष की कुकी पर पाबंदी होने पर, पेमेंट बटन सही तरीके से रेंडर होते हैं या नहीं.
- क्या उपयोगकर्ता, पसंद के मुताबिक बटन पर अपना पसंदीदा तरीका न दिखने पर भी खरीदारी कर सकता है?
क्रॉस-साइट चेकआउट
पेमेंट की सेवा देने वाली कुछ कंपनियां, तीसरे पक्ष की कुकी का इस्तेमाल करती हैं. इससे उपयोगकर्ताओं को कई व्यापारी/कंपनी/कारोबारी की साइटों पर अपने खाते को ऐक्सेस करने की अनुमति मिलती है. इसके लिए, उन्हें फिर से पुष्टि करने की ज़रूरत नहीं होती. तीसरे पक्ष की कुकी के बिना ब्राउज़ करने का विकल्प चुनने वाले उपयोगकर्ताओं पर, इस उपयोगकर्ता अनुभव का असर पड़ सकता है.
एम्बेड किए गए चेकआउट फ़ॉर्म
इन डोमेन पर ध्यान दें:
payment-provider.example, व्यापारी/कंपनी की साइटों को पेमेंट सेवाएं उपलब्ध कराता है. साथ ही, उपयोगकर्ता के पेमेंट और सेशन का डेटा सेव करता है.merchant.exampleएक ऐसी वेबसाइट है जोpayment-provider.exampleसे मिले चेकआउट फ़ॉर्म को एम्बेड करती है.
किसी उपयोगकर्ता ने अभी-अभी payment-provider.example में लॉग इन किया है. उदाहरण के लिए, किसी दूसरी साइट पर चेकआउट की प्रोसेस पूरी करते समय. उपयोगकर्ता ने merchant.example पर चेकआउट की प्रोसेस शुरू की.
तीसरे पक्ष की कुकी उपलब्ध होने पर, merchant.example पर एम्बेड किए गए payment-provider.example चेकआउट फ़ॉर्म के पास, टॉप-लेवल कॉन्टेक्स्ट में payment-provider.example पर सेट की गई अपनी टॉप-लेवल सेशन कुकी का ऐक्सेस होगा.
हालांकि, अगर तीसरे पक्ष की कुकी ब्लॉक की जाती हैं, तो एम्बेड की अपनी टॉप-लेवल कुकी का ऐक्सेस नहीं होगा.
FedCM की मदद से, अपनी पसंद के मुताबिक बनाया जा सकने वाला समाधान
payment-provider.example को आइडेंटिटी प्रोवाइडर के तौर पर काम करने के लिए, FedCM लागू करना चाहिए. यह तरीका तब सही रहता है, जब:
payment-provider.exampleको तीसरे पक्ष की ऐसी साइटों पर एम्बेड किया गया है जो आपके चैनल से जुड़ी नहीं हैं.payment-provider.exampleको मिलती-जुलती पांच से ज़्यादा साइटों पर एम्बेड किया गया हो.
FedCM का मुख्य फ़ायदा यह है कि यूज़र इंटरफ़ेस (यूआई), उपयोगकर्ताओं को उनकी पसंद के बारे में ज़्यादा जानकारी दे सकता है. उपयोगकर्ता की अनुमति मिलने पर, FedCM, भरोसेमंद पक्ष (merchant.example) और आइडेंटिटी प्रोवाइडर (payment-provider.example) के बीच कस्टम डेटा शेयर करने की अनुमति देता है. भरोसेमंद पक्ष, एक या उससे ज़्यादा आइडेंटिटी प्रोवाइडर का इस्तेमाल करने का विकल्प चुन सकता है. साथ ही, FedCM का यूज़र इंटरफ़ेस (यूआई) सिर्फ़ शर्तों के मुताबिक दिखेगा.
ज़रूरत के हिसाब से, डेवलपर पासिव मोड चुन सकते हैं, ताकि उपयोगकर्ता के पहचान की पुष्टि करने वाली सेवा के साथ लॉग इन करने पर, FedCM प्रॉम्प्ट अपने-आप दिखे. इसके अलावा, वे ऐक्टिव मोड भी चुन सकते हैं, ताकि उपयोगकर्ता की किसी कार्रवाई के बाद, लॉगिन की प्रोसेस ट्रिगर हो. जैसे, चेकआउट बटन पर क्लिक करना.
FedCM, Storage Access API (SAA) के लिए भरोसे के सिग्नल के तौर पर भी काम करता है. इससे उपयोगकर्ता, एम्बेड के प्रोवाइडर के साथ साइन इन करने के बाद, एम्बेड की टॉप-लेवल की बिना बंटी हुई कुकी को ऐक्सेस कर सकता है. इसके लिए, उपयोगकर्ता को अलग से प्रॉम्प्ट नहीं दिखाना पड़ता.
स्टोरेज ऐक्सेस पर फ़ोकस करने वाला समाधान
एक और एपीआई, Storage Access API (SAA) है.
एसएए की मदद से, उपयोगकर्ता को payment-provider.example को अपनी टॉप-लेवल कुकी ऐक्सेस करने की अनुमति देने के लिए कहा जाएगा. अगर उपयोगकर्ता ऐक्सेस की अनुमति देता है, तो फ़ॉर्म ठीक उसी तरह रेंडर हो सकता है जैसे तीसरे पक्ष की कुकी उपलब्ध होने पर होता है.
FedCM की तरह ही, उपयोगकर्ता को हर नई साइट पर अनुरोध को स्वीकार करना होगा जहां payment-provider.example एम्बेड किया गया है. एपीआई के काम करने का तरीका समझने के लिए, एसएए का डेमो देखें.
अगर डिफ़ॉल्ट SAA प्रॉम्प्ट आपकी ज़रूरतों के मुताबिक नहीं है, तो ज़्यादा पसंद के मुताबिक अनुभव के लिए, FedCM को लागू करें.
मिलती-जुलती कुछ साइटों पर उपयोगकर्ताओं को आने वाली समस्याओं को कम करना
अगर व्यापारी/कंपनी की साइट और पेमेंट की सुविधा देने वाली कंपनी, दोनों एक ही कंपनी के हैं, तो डोमेन के बीच के संबंधों के बारे में बताने के लिए, मिलते-जुलते वेबसाइट सेट (आरडब्ल्यूएस) एपीआई का इस्तेमाल किया जा सकता है. इससे उपयोगकर्ताओं को होने वाली परेशानी को कम करने में मदद मिल सकती है: उदाहरण के लिए, अगर insurance.example और payment-portal-insurance.example एक ही आरडब्ल्यूएस में हैं, तो payment-portal-insurance.example को अपने टॉप-लेवल कुकी का ऐक्सेस अपने-आप मिल जाएगा. ऐसा तब होगा, जब payment-portal-insurance.example एम्बेड में स्टोरेज ऐक्सेस का अनुरोध किया जाएगा.
एक्सपेरिमेंट के तौर पर उपलब्ध अन्य समाधान
इस स्थिति में, पार्टिशन किए गए पॉपिन नाम का एक और एक्सपेरिमेंटल एपीआई मददगार हो सकता है. फ़िलहाल, एपीआई को डेवलप किया जा रहा है.
अलग-अलग हिस्सों में बंटे पॉपिन की मदद से, उपयोगकर्ता से अपने क्रेडेंशियल डालने के लिए कहा जा सकता है, ताकि वह merchant.example से खोले गए पॉपिन में payment-provider.example में साइन इन कर सके. स्टोरेज को merchant.example खोलने वाले व्यक्ति के हिसाब से पार्टिशन किया जाएगा. इस मामले में, payment-provider.example
एम्बेड के पास पॉपिन में सेट की गई स्टोरेज वैल्यू का ऐक्सेस होगा. इस समाधान के तहत, उपयोगकर्ता को हर साइट पर पेमेंट की सेवा देने वाली कंपनी में साइन इन करना होगा.
पेमेंट लिंक से चेकआउट करना
पेमेंट की सेवा देने वाली कुछ कंपनियां, पेमेंट लिंक जनरेट करने की सेवा देती हैं. यह लिंक, कारोबारी या कंपनी की साइट के लिए पसंद के मुताबिक चेकआउट पेज दिखाता है. पेमेंट लिंक सेवा और पेमेंट प्रोवाइडर के लिए उपयोगकर्ता पोर्टल, अक्सर अलग-अलग डोमेन पर लागू किए जाते हैं. उदाहरण के लिए, payment-provider.example और payment-link.example.
payment-link.example, payment-provider.example की ओर से उपलब्ध कराए गए चेकआउट फ़ॉर्म को एम्बेड करता है. यह एम्बेड किए गए चेकआउट फ़ॉर्म पैटर्न का एक वैरिएशन है.
इस मामले में भी, FedCM,
SAA और
RWS के विकल्प अच्छे हैं.
पेमेंट डैशबोर्ड
कुछ ऐप्लिकेशन, अपने उपयोगकर्ताओं को कई साइटों पर लेन-देन के डैशबोर्ड दिखाते हैं. इससे, उपयोगकर्ताओं को अपनी वित्तीय गतिविधियों की जानकारी एक ही जगह पर मिलती है. इसके लिए, डैशबोर्ड को एक से ज़्यादा डोमेन में उपयोगकर्ता से जुड़ा डेटा ऐक्सेस करना होगा.
इन डोमेन पर ध्यान दें:
earnings.example, पेआउट डैशबोर्ड उपलब्ध कराता है. इसे अलग-अलग वेब ऐप्लिकेशन में जोड़ा जा सकता है. यह सेवा, उपयोगकर्ता की कमाई का डेटा और सेशन की जानकारी सेव करती है.catsitting.exampleऔरdogsitting.exampleअलग-अलग वेबसाइटें हैं, जिनमें दोनों नेearnings.exampleडैशबोर्ड को एम्बेड किया है.
कोई उपयोगकर्ता अपने earnings.example खाते में लॉग इन करता है. catsitting.example या dogsitting.example पर जाकर, वे अपनी कमाई देख सकते हैं. एम्बेड किया गया earnings.example डैशबोर्ड, टॉप लेवल कुकी पर निर्भर करता है. साथ ही, यह उपयोगकर्ता की कमाई की जानकारी को उसके हिसाब से दिखाता है.
दूसरे उदाहरणों की तरह ही, तीसरे पक्ष की कुकी बंद होने पर, earnings.example एम्बेड की अपनी टॉप-लेवल कुकी का ऐक्सेस नहीं होगा.
पहले पक्ष के डैशबोर्ड
अगर तीनों डोमेन एक ही पक्ष के हैं, तो RWS के साथ SAA का इस्तेमाल करें.
एसएए की मदद से, earnings.example उपयोगकर्ता की अनुमति लेकर अपनी टॉप-लेवल कुकी का ऐक्सेस पा सकता है. अगर यह पार्टी चार या उससे कम डोमेन पर earnings.example का इस्तेमाल करती है, तो RWS की मदद से उनके बीच संबंधों का एलान करने से, उपयोगकर्ता को बेहतर अनुभव मिल सकता है.
अगर कोई पार्टी पांच से ज़्यादा डोमेन पर विजेट एम्बेड करती है, तो वह एम्बेड करने वाली सभी साइटों और विजेट के डोमेन के बीच संबंधों का एलान नहीं कर सकती. ऐसा इसलिए, क्योंकि RWS में एक सेट में सिर्फ़ छह साइटें काम करती हैं. इनमें एक प्राइमरी साइट और पांच असोसिएट साइटें शामिल हैं.
बड़े पैमाने पर डैशबोर्ड का डिस्ट्रिब्यूशन
इन मामलों में, SAA और RWS सबसे सही समाधान नहीं हो सकते:
- तीसरे पक्ष की साइटों के लिए डैशबोर्ड का समाधान उपलब्ध कराया जाता है.
- आपके पास पांच से ज़्यादा साइटें हैं जिनमें आपका डैशबोर्ड विजेट एम्बेड किया गया है.
ऐसे में, earnings.example को आइडेंटिटी प्रोवाइडर के तौर पर काम करने के लिए, FedCM लागू करना चाहिए. इसका मतलब है कि उपयोगकर्ता को earnings.example से मैनेज किए जा रहे खाते से, dogsitting.example में लॉग इन करना होगा.
FedCM, उपयोगकर्ता के हिसाब से बनाए जा सकने वाले यूज़र इंटरफ़ेस (यूआई) की सुविधा देता है. इससे उपयोगकर्ता को साफ़ तौर पर यह जानकारी दी जा सकती है कि कौनसी जानकारी शेयर की जा रही है. FedCM की मदद से, dogsitting.example, earnings.example से कस्टम अनुमतियां शेयर करने का अनुरोध कर सकता है. उदाहरण के लिए, ट्रांज़ैक्शन डेटा ऐक्सेस करने के लिए.
FedCM, Storage Access API के लिए भरोसे के सिग्नल के तौर पर भी काम करता है. साथ ही, earnings.example एम्बेड को अपनी टॉप-लेवल कुकी का स्टोरेज ऐक्सेस दिया जाएगा. इसके लिए, SAA API कॉल पर उपयोगकर्ता को कोई अतिरिक्त प्रॉम्प्ट नहीं दिखाया जाएगा.
साइट के हिसाब से डैशबोर्ड की सेटिंग
अगर डेटा को कई साइटों पर शेयर करने की ज़रूरत नहीं है, तो CHIPS की मदद से अपनी कुकी को अलग-अलग हिस्सों में बांटें. सीएचआईपीएस का इस्तेमाल, साइट के हिसाब से प्राथमिकताएं सेव करने के लिए किया जा सकता है. जैसे, डैशबोर्ड का लेआउट या फ़िल्टर.
पैसे चुकाने के तरीके मैनेज करें
उपयोगकर्ता के लिए, होस्ट साइट से बाहर निकले बिना, एम्बेड किए गए पेज पर जाकर, पेमेंट के तरीकों को देखना और उनमें बदलाव करना एक आम फ़्लो है.
इस फ़्लो पर ध्यान दें:
payments.example, पेमेंट मैनेजमेंट टूल उपलब्ध कराता है, जिसे वेबसाइटों पर एम्बेड किया जा सकता है. यह सेवा, उपयोगकर्ता के पेमेंट डेटा और सेशन की जानकारी को सेव करती है.shop.exampleएक ऐसी वेबसाइट है जिसमेंpayments.exampleटूल को एम्बेड किया गया है. इससे उपयोगकर्ताओं को अपनेshop.exampleखाते से जुड़े पेमेंट के तरीकों को देखने, उनमें बदलाव करने या अपनी पसंद के हिसाब से पेमेंट के तरीके चुनने की सुविधा मिलती है.
पेमेंट के तरीकों को मैनेज करने की सुविधा देने वाली कंपनियों को, FedCM की मदद से आइडेंटिटी प्रोवाइडर बनने पर भी विचार करना चाहिए. FedCM की मदद से, उपयोगकर्ता उस खाते का इस्तेमाल करके, भरोसेमंद पक्ष (shop.example) में लॉग इन कर सकता है जिसे आइडेंटिटी प्रोवाइडर (payments.example) मैनेज करता है.
उपयोगकर्ता की अनुमति के साथ, FedCM, भरोसेमंद पक्ष और आइडेंटिटी प्रोवाइडर के बीच कस्टम डेटा शेयर करने की अनुमति देता है. FedCM का इस्तेमाल करने का मुख्य फ़ायदा यह है कि यूज़र इंटरफ़ेस (यूआई) से, उपयोगकर्ताओं को उनकी पसंद के बारे में ज़्यादा जानकारी मिल सकती है. यह Storage Access API के लिए भरोसे के सिग्नल के तौर पर भी काम करता है. इससे एम्बेड को अपनी टॉप-लेवल कुकी ऐक्सेस करने की अनुमति मिलती है.
तीसरे पक्ष की कुकी बंद होने पर, payments.example एम्बेड के पास अपनी टॉप-लेवल कुकी का ऐक्सेस नहीं होगा. इस मामले में, SAA, स्टोरेज का ऐक्सेस पाने का अनुरोध करके, सही तरीके से काम करने में मदद कर सकता है.
कभी-कभी, एम्बेड किए गए कॉन्टेंट में सेट की गई जानकारी को, एम्बेड करने वाली अन्य साइटों के साथ शेयर करने की ज़रूरत नहीं होती. payments.example को सिर्फ़ हर एम्बेड की गई साइट के हिसाब से, उपयोगकर्ता की अलग-अलग प्राथमिकताएं सेव करनी पड़ सकती हैं. ऐसे में, CHIPS का इस्तेमाल करके कुकी को अलग-अलग हिस्सों में बांटें. CHIPS की मदद से, shop.example पर एम्बेड किए गए payments.example में सेट की गई कुकी को another-shop.example पर एम्बेड किए गए payments.example से ऐक्सेस नहीं किया जा सकेगा.
इस उपयोगकर्ता फ़्लो में, पार्टिशन किए गए पॉपिन का इस्तेमाल किया जा सकता है. यह एक एक्सपेरिमेंटल एपीआई है.
जब कोई उपयोगकर्ता shop.example से खोले गए पॉपिन में payments.example में लॉग इन करता है, तो स्टोरेज को खोलने वाले व्यक्ति के हिसाब से बांटा जाएगा. साथ ही, payments.example एम्बेड के पास पॉपिन में सेट की गई स्टोरेज वैल्यू का ऐक्सेस होगा. हालांकि, इस तरीके से उपयोगकर्ताओं को हर साइट पर, पेमेंट की सेवा देने वाली कंपनी में साइन इन करने के लिए क्रेडेंशियल डालने पड़ते हैं.
धोखाधड़ी का पता लगाना
जोखिम का विश्लेषण करने वाले सिस्टम, कुकी में सेव किए गए डेटा का विश्लेषण करके, सामान्य से अलग पैटर्न की पहचान कर सकते हैं. उदाहरण के लिए, अगर कोई उपयोगकर्ता अचानक अपना शिपिंग पता बदलता है और नए डिवाइस का इस्तेमाल करके कई बड़ी खरीदारी करता है, तो धोखाधड़ी के संभावित स्कोर में बढ़ोतरी हो सकती है. धोखाधड़ी का पता लगाने वाली कुकी, आम तौर पर तीसरे पक्ष की कुकी होती हैं. इन्हें पेमेंट की सेवा देने वाली कंपनियां या धोखाधड़ी से बचाने वाली सेवाओं के विजेट, कारोबारी या कंपनी की साइटों पर सेट करते हैं.
तीसरे पक्ष की कुकी से जुड़ी पाबंदियों से, धोखाधड़ी का पता लगाने वाले सिस्टम पर असर नहीं पड़ना चाहिए. हालांकि, इनसे उपयोगकर्ताओं को परेशानी हो सकती है. अगर ब्लॉक की गई कुकी की वजह से, सिस्टम यह पुष्टि नहीं कर पाता कि कोई उपयोगकर्ता मान्य है या नहीं, तो हो सकता है कि उसे पहचान की पुष्टि करने जैसी अन्य जांच करनी पड़े.
तीसरे पक्ष की कुकी ब्लॉक होने पर धोखाधड़ी का पता लगाने के लिए, अपने धोखाधड़ी का पता लगाने वाले समाधान में Private State Tokens (PST) API को इंटिग्रेट करें. पीएसटी की मदद से, पेमेंट की सेवा देने वाली कंपनी, टोकन जारी करने वाली कंपनी के तौर पर रजिस्टर कर सकती है. साथ ही, उपयोगकर्ताओं को ऐसे टोकन दे सकती है जो तीसरे पक्ष की कुकी पर निर्भर नहीं होते. इसके बाद, इन टोकन को व्यापारी/कंपनी/कारोबारी की साइटों पर रिडीम किया जा सकता है, ताकि यह पता लगाया जा सके कि उपयोगकर्ता भरोसेमंद है या नहीं. लागू करने के बारे में जानकारी के लिए, पीएसटी डेवलपर दस्तावेज़ देखें.
Privacy Sandbox, धोखाधड़ी रोकने के लिए काम करने वाले अन्य एपीआई के साथ एक्सपेरिमेंट कर रहा है.
लोगों के हिसाब से चेकआउट बटन
व्यापारी/कंपनी/कारोबारी की साइटों पर जोड़े गए पेमेंट बटन (जैसे, <पसंदीदा पेमेंट का तरीका> से पेमेंट करें), अक्सर पेमेंट की सुविधा देने वाली कंपनी की ओर से सेट की गई क्रॉस-साइट की जानकारी पर निर्भर होते हैं. इससे उपयोगकर्ताओं को अपनी पसंद के पेमेंट के तरीके से आसानी से चेकआउट करने की सुविधा मिलती है. अगर उपयोगकर्ता के ब्राउज़र में तीसरे पक्ष की कुकी ब्लॉक की गई हैं, तो इससे उपयोगकर्ता के हिसाब से पेमेंट बटन रेंडर करने पर असर पड़ सकता है.
SAA की मदद से, स्टोरेज को ऐक्सेस किया जा सकता है. हालांकि, ज़रूरी प्रॉम्प्ट की वजह से, उपयोगकर्ता को बेहतर अनुभव नहीं मिल सकता.
हम इस समस्या को हल करने के लिए, एक संभावित तरीका आज़मा रहे हैं. यह तरीका खास तौर पर इस इस्तेमाल के उदाहरण के लिए है: बिना बंटे हुए स्थानीय डेटा को ऐक्सेस करने वाले फ़ेंस किए गए फ़्रेम. फ़िलहाल, एपीआई पर काम चल रहा है. आने वाले समय में, आपके पास इस एपीआई को बेहतर बनाने का विकल्प होगा. इसे खुद आज़माएं और सुझाव/राय दें या शिकायत करें.
सहायता पाएं
अगर आपको कोई गड़बड़ी मिलती है, तो उसकी शिकायत goo.gle/report-3pc-broken पर करें. आपके पास सुझाव/राय देने या शिकायत करने के लिए फ़ॉर्म सबमिट करने का विकल्प भी है. इसके अलावा, Privacy Sandbox के डेवलपर सहायता रिपॉज़िटरी में जाकर, GitHub पर समस्या दर्ज की जा सकती है.