Chrome, तीसरे पक्ष की कुकी के लिए उपयोगकर्ताओं को एक नया अनुभव देने का प्रस्ताव दे रहा है. आपको अपनी साइट को उन उपयोगकर्ताओं के लिए तैयार करना होगा जो तीसरे पक्ष की कुकी के बिना ब्राउज़ करना चाहते हैं.
इस पेज पर, आने वाले समय में होने वाले बदलावों से किस पर असर पड़ सकता है, इस बारे में जानकारी दी गई है.
उपयोगकर्ता की सामान्य गतिविधियां
पेमेंट और खरीदारी के कई वर्कफ़्लो, तीसरे पक्ष की कुकी पर निर्भर करते हैं. नीचे दी गई टेबल में, उपयोगकर्ता के कुछ ऐसे सफ़र के बारे में बताया गया है जिन पर तीसरे पक्ष की कुकी बंद होने का असर पड़ सकता है. साथ ही, इस टेबल में ऐसे अन्य एपीआई के सुझाव भी दिए गए हैं जिनका इस्तेमाल करके डेवलपर, इस तरह के सफ़र में आने वाली रुकावटों से बच सकते हैं. यह पूरी सूची नहीं है. निजता सैंडबॉक्स के ज़्यादा समाधान उपलब्ध होने पर, इस सूची को अपडेट किया जा सकता है. अगर आपको इस बदलाव से जुड़ी कोई और समस्या आती है, तो हमारा सुझाव है कि आप अपना सुझाव, शिकायत या राय शेयर करें.
पेमेंट से जुड़ी उपयोगकर्ता की गतिविधियों की जांच करना
तीसरे पक्ष की कुकी से जुड़ी पाबंदियों से आपके उपयोगकर्ता फ़्लो पर असर पड़ता है या नहीं, यह पता करने का सबसे अच्छा तरीका यह है कि आप तीसरे पक्ष की कुकी की जांच करने वाले फ़्लैग को चालू करके, उन पर नज़र डालें.
यह पक्का करने के लिए कि आपकी वेबसाइट उम्मीद के मुताबिक काम करे, तीसरे पक्ष की पाबंदी वाली कुकी के साथ नीचे दिए गए फ़्लो की जांच करें:
- क्रॉस-साइट चेकआउट: तीसरे पक्ष के पेमेंट प्रोवाइडर (जैसे, <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
एम्बेड किया गया है. एपीआई के काम करने का तरीका समझने के लिए, एसएए का डेमो देखें.
अगर डिफ़ॉल्ट एसएए प्रॉम्प्ट आपकी ज़रूरतों के मुताबिक नहीं है, तो अपनी पसंद के मुताबिक अनुभव पाने के लिए, 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 का इस्तेमाल करें.
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 की मदद से अपनी कुकी को अलग-अलग हिस्सों में बांटें. साइट के हिसाब से प्राथमिकताएं सेव करने के लिए, 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
एम्बेड के पास पॉपिन में सेट की गई स्टोरेज वैल्यू का ऐक्सेस होगा. हालांकि, इस तरीके से उपयोगकर्ताओं को हर साइट पर, पेमेंट की सेवा देने वाली कंपनी में साइन इन करने के लिए क्रेडेंशियल डालने पड़ते हैं.
धोखाधड़ी का पता लगाना
जोखिम का विश्लेषण करने वाले सिस्टम, कुकी में सेव किए गए डेटा का विश्लेषण करके, सामान्य से अलग पैटर्न की पहचान कर सकते हैं. उदाहरण के लिए, अगर कोई उपयोगकर्ता अचानक अपना शिपिंग पता बदलता है और नए डिवाइस का इस्तेमाल करके कई बड़ी खरीदारी करता है, तो धोखाधड़ी के संभावित स्कोर में बढ़ोतरी हो सकती है. धोखाधड़ी का पता लगाने वाली कुकी, आम तौर पर तीसरे पक्ष की कुकी होती हैं. इन्हें पेमेंट की सेवा देने वाली कंपनियां या धोखाधड़ी से बचाने वाली सेवाओं के विजेट, कारोबारी या कंपनी की साइटों पर सेट करते हैं.
तीसरे पक्ष की कुकी से जुड़ी पाबंदियों से, धोखाधड़ी का पता लगाने वाले सिस्टम पर असर नहीं पड़ना चाहिए. हालांकि, इनसे उपयोगकर्ताओं को परेशानी हो सकती है. अगर ब्लॉक की गई कुकी की वजह से, सिस्टम यह पुष्टि नहीं कर पाता कि कोई उपयोगकर्ता मान्य है या नहीं, तो हो सकता है कि उसे पहचान की पुष्टि करने जैसी अन्य जांच करनी पड़े.
तीसरे पक्ष की कुकी ब्लॉक होने पर, धोखाधड़ी का पता लगाने के लिए, अपने धोखाधड़ी का पता लगाने वाले समाधान में प्राइवेट स्टेट टोकन (पीएसटी) एपीआई को इंटिग्रेट करें. पीएसटी की मदद से, पेमेंट की सेवा देने वाली कंपनी, टोकन जारी करने वाली कंपनी के तौर पर रजिस्टर कर सकती है. साथ ही, उपयोगकर्ताओं को ऐसे टोकन दे सकती है जो तीसरे पक्ष की कुकी पर निर्भर नहीं होते. इसके बाद, इन टोकन को व्यापारी/कंपनी/कारोबारी की साइटों पर रिडीम किया जा सकता है, ताकि यह पता लगाया जा सके कि उपयोगकर्ता भरोसेमंद है या नहीं. लागू करने के बारे में ज़्यादा जानकारी के लिए, पीएसटी डेवलपर दस्तावेज़ देखें.
Privacy Sandbox, धोखाधड़ी रोकने के लिए काम करने वाले अन्य एपीआई के साथ प्रयोग कर रहा है.
लोगों के हिसाब से चेकआउट बटन
व्यापारी/कंपनी/कारोबारी की साइटों पर जोड़े गए पेमेंट बटन (जैसे, <preferred payment method> से पेमेंट करें), अक्सर पेमेंट की सुविधा देने वाली कंपनी की ओर से सेट की गई क्रॉस-साइट की जानकारी पर निर्भर होते हैं. इससे उपयोगकर्ताओं को अपनी पसंद के पेमेंट के तरीके से आसानी से चेकआउट करने की सुविधा मिलती है. अगर उपयोगकर्ता के ब्राउज़र में तीसरे पक्ष की कुकी ब्लॉक की गई हैं, तो इससे उपयोगकर्ता के हिसाब से बनाए गए पेमेंट बटन के रेंडर होने पर असर पड़ सकता है.
SAA की मदद से, स्टोरेज को ऐक्सेस किया जा सकता है. हालांकि, ज़रूरी प्रॉम्प्ट की वजह से, उपयोगकर्ता को बेहतर अनुभव नहीं मिल सकता.
हम इस समस्या को हल करने के लिए, एक संभावित तरीका आज़मा रहे हैं. यह तरीका खास तौर पर इस इस्तेमाल के उदाहरण के लिए है: बिना बंटे हुए स्थानीय डेटा का ऐक्सेस देने वाले फ़ेंस किए गए फ़्रेम. फ़िलहाल, एपीआई को डेवलप किया जा रहा है. आने वाले समय में, आपके पास इस एपीआई को बेहतर बनाने का विकल्प होगा. इसे खुद आज़माएं और सुझाव/राय दें या शिकायत करें.
सहायता पाएं
किसी भी तरह की गड़बड़ी की शिकायत करने के लिए, goo.gle/report-3pc-broken पर जाएं. इसके अलावा, सुझाव/राय या शिकायत करने के लिए फ़ॉर्म सबमिट किया जा सकता है. इसके अलावा, GitHub पर निजता सैंडबॉक्स के डेवलपर सहायता रिपॉज़िटरी में जाकर, समस्या की शिकायत भी की जा सकती है.