तीसरे पक्ष की कुकी से जुड़े बदलावों का, आपके पेमेंट वर्कफ़्लो पर क्या असर पड़ेगा, यह देखना

ब्राउज़र की पाबंदियों, उपयोगकर्ता की सेटिंग, डेवलपर फ़्लैग या कंपनी की नीति की वजह से, तीसरे पक्ष की कुकी ब्लॉक की जा सकती हैं.

आपको यह पक्का करना होगा कि आपकी साइट या सेवा, सभी उपयोगकर्ताओं को बेहतरीन अनुभव दे. भले ही, तीसरे पक्ष की कुकी उपलब्ध हों या न हों.

इस पेज पर, उपयोगकर्ता के सामान्य अनुभवों के बारे में जानकारी दी गई है. तीसरे पक्ष की कुकी ब्लॉक होने पर, इन अनुभवों पर असर पड़ सकता है.

उपयोगकर्ताओं की सामान्य गतिविधियां

पेमेंट और खरीदारी से जुड़े कई वर्कफ़्लो, तीसरे पक्ष की कुकी पर निर्भर होते हैं. यहां दी गई टेबल में, उपयोगकर्ता के कुछ ऐसे सफ़र की जानकारी दी गई है जिन पर तीसरे पक्ष की कुकी बंद होने का असर पड़ सकता है. साथ ही, इसमें ऐसे वैकल्पिक एपीआई के बारे में बताया गया है जिनका इस्तेमाल करके डेवलपर, कुकी बंद होने से होने वाली समस्याओं से बच सकते हैं. यह पूरी सूची नहीं है. साथ ही, Privacy Sandbox के ज़्यादा समाधान उपलब्ध होने पर इसे अपडेट किया जा सकता है.

उपयोगकर्ता का अनुभव	सुझाए गए एपीआई
क्रॉस-साइट चेकआउट	FedCM Related Website Sets Storage Access API (SAA) scienceपार्टिशन किए गए पॉप-इन
पेमेंट डैशबोर्ड	FedCM Storage Access API (SAA) Related Website Sets CHIPS
पैसे चुकाने के तरीके मैनेज करना	FedCM Storage Access API (SAA) Related Website Sets CHIPS scienceपार्टिशन किए गए पॉप-इन
धोखाधड़ी का पता लगाना	प्राइवेट स्टेट टोकन
लोगों की दिलचस्पी के हिसाब से चेकआउट बटन	scienceस्थानीय अनपार्टिशन किए गए डेटा को ऐक्सेस करने वाले फ़ेंस्ड फ़्रेम

पेमेंट से जुड़ी उपयोगकर्ता की गतिविधियों को टेस्ट करना

यह टेस्ट करने का सबसे अच्छा तरीका है कि तीसरे पक्ष की कुकी पर पाबंदी लगने से, आपके उपयोगकर्ता फ़्लो पर असर पड़ा है या नहीं. इसके लिए, तीसरे पक्ष की कुकी की टेस्टिंग का फ़्लैग चालू करके उपयोगकर्ता फ़्लो को आज़माएं.

यह पक्का करने के लिए कि आपकी वेबसाइट उम्मीद के मुताबिक काम कर रही है, तीसरे पक्ष की कुकी पर पाबंदी लगाकर इस फ़्लो की जांच करें:

• क्रॉस-साइट चेकआउट: पेमेंट के उन फ़्लो को टेस्ट करें जो तीसरे पक्ष की पेमेंट सेवा देने वाली कंपनी (जैसे कि <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 प्रॉम्प्ट अपने-आप दिखने लगता है. इसके अलावा, डेवलपर ऐक्टिव मोड भी चुन सकते हैं. इससे उपयोगकर्ता की कार्रवाई के बाद लॉगिन प्रोसेस ट्रिगर होती है. जैसे, चेकआउट बटन पर क्लिक करना.

FedCM, Storage Access API (SAA) के लिए भरोसेमंद सिग्नल के तौर पर भी काम करता है. इससे एम्बेड किए गए कॉन्टेंट को, टॉप-लेवल की बिना बंटी हुई कुकी को ऐक्सेस करने की अनुमति मिलती है. ऐसा तब होता है, जब उपयोगकर्ता एम्बेड किए गए कॉन्टेंट के प्रोवाइडर के साथ साइन इन करने के लिए सहमत हो जाता है. इसके लिए, उपयोगकर्ता को किसी अन्य प्रॉम्प्ट की ज़रूरत नहीं होती.

मेमोरी के ऐक्सेस पर फ़ोकस करने वाला समाधान

एक और एपीआई है, Storage Access API (SAA). एसएए की मदद से, उपयोगकर्ता को payment-provider.example एम्बेड करने की अनुमति देने के लिए कहा जाएगा, ताकि वह अपनी टॉप-लेवल कुकी ऐक्सेस कर सके. अगर उपयोगकर्ता ऐक्सेस करने की अनुमति देता है, तो फ़ॉर्म उसी तरह रेंडर हो सकता है जिस तरह तीसरे पक्ष की कुकी उपलब्ध होने पर होता है.

FedCM की तरह ही, उपयोगकर्ता को हर नई साइट पर अनुरोध को स्वीकार करना होगा. इस साइट पर payment-provider.example एम्बेड किया गया है. एपीआई के काम करने का तरीका समझने के लिए, एसएए का डेमो देखें. अगर डिफ़ॉल्ट SAA प्रॉम्प्ट आपकी ज़रूरतों के मुताबिक नहीं है, तो बेहतर अनुभव के लिए FedCM लागू करें.

मिलती-जुलती कुछ साइटों पर उपयोगकर्ता की रुकावटों को कम करना

अगर कारोबारी या कंपनी की साइट और पेमेंट की सुविधा देने वाली कंपनी, दोनों एक ही कंपनी के हैं, तो डोमेन के बीच के संबंध के बारे में बताने के लिए, मिलती-जुलती वेबसाइट के सेट (आरडब्ल्यूएस) एपीआई का इस्तेमाल किया जा सकता है. इससे उपयोगकर्ता के लिए आसानी होती है. उदाहरण के लिए, अगर insurance.example और payment-portal-insurance.example एक ही RWS में हैं, तो payment-portal-insurance.example को अपने-आप टॉप-लेवल कुकी का ऐक्सेस मिल जाएगा. ऐसा तब होगा, जब payment-portal-insurance.example एम्बेड में स्टोरेज ऐक्सेस का अनुरोध किया जाएगा.

एक्सपेरिमेंट के तौर पर उपलब्ध अन्य समाधान

इस मामले में, एक और एक्सपेरिमेंटल एपीआई काम आ सकता है. यह पार्टिशन किए गए पॉप-इन है. फ़िलहाल, इस एपीआई को डेवलप किया जा रहा है.

पार्टिशन किए गए पॉप-इन की मदद से, उपयोगकर्ता से क्रेडेंशियल डालने के लिए कहा जा सकता है, ताकि वह payment-provider.example में साइन इन कर सके. यह पॉप-इन merchant.example ने खोला है. स्टोरेज को ओपनर merchant.example के हिसाब से पार्टिशन किया जाएगा. इस मामले में, payment-provider.example embed के पास, पॉप-इन में सेट की गई स्टोरेज वैल्यू को ऐक्सेस करने की अनुमति होगी. इस समाधान के तहत, उपयोगकर्ता को हर साइट पर पेमेंट की सेवा देने वाली कंपनी के खाते में साइन इन करना होगा.

पेमेंट लिंक से चेकआउट

पेमेंट की सेवा देने वाली कुछ कंपनियां, पेमेंट लिंक जनरेट करने की सुविधा देती हैं. इससे कारोबारी या कंपनी की साइट के लिए, पसंद के मुताबिक चेकआउट पेज रेंडर किया जाता है. पेमेंट लिंक की सेवा और पेमेंट की सेवा देने वाली कंपनी के लिए उपयोगकर्ता पोर्टल को अक्सर अलग-अलग डोमेन पर लागू किया जाता है. उदाहरण के लिए, 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 एम्बेड के पास टॉप-लेवल की कुकी का ऐक्सेस नहीं होगा.

पहले पक्ष के डैशबोर्ड

अगर तीनों डोमेन एक ही पार्टी के हैं, तो SAA के साथ-साथ RWS का इस्तेमाल करें. एसएए की मदद से, 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 की मदद से, उपयोगकर्ता आइडेंटिटी प्रोवाइडर (payments.example) के मैनेज किए गए खाते का इस्तेमाल करके, रिलाइंग पार्टी (shop.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, स्टोरेज का ऐक्सेस दे सकता है. हालांकि, ज़रूरी प्रॉम्प्ट से उपयोगकर्ता को बेहतर अनुभव नहीं मिल सकता.

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

सहायता और सुझाव

अगर आपको इस गाइड में बताई गई उपयोगकर्ता की यात्राओं या एपीआई के बारे में कोई सवाल पूछना है या अपनी राय देनी है, तो अपनी राय शेयर करें.