আপনার পেমেন্ট ওয়ার্কফ্লোতে তৃতীয় পক্ষের কুকি পরিবর্তনের প্রভাব পরীক্ষা করুন

Chrome তৃতীয় পক্ষের কুকি সংক্রান্ত ব্যবহারকারীর পছন্দের জন্য একটি নতুন অভিজ্ঞতার প্রস্তাব করছে। তৃতীয় পক্ষের কুকিজ ছাড়াই ব্রাউজ করা বেছে নেওয়া ব্যবহারকারীদের জন্য আপনাকে আপনার সাইট প্রস্তুত করতে হবে।

এই পৃষ্ঠায় আসন্ন পরিবর্তনগুলির দ্বারা প্রভাবিত হতে পারে সে সম্পর্কে তথ্য রয়েছে৷

সাধারণ ব্যবহারকারীর যাত্রা

অনেক অর্থপ্রদান এবং কেনাকাটা কর্মপ্রবাহ তৃতীয় পক্ষের কুকির উপর নির্ভর করে। নিম্নলিখিত সারণীতে কিছু ব্যবহারকারীর যাত্রার তালিকা রয়েছে যা তৃতীয় পক্ষের কুকিজ নিষ্ক্রিয় হলে প্রভাবিত হতে পারে এবং বিকল্প APIগুলির পরামর্শ দেয় যা বিকাশকারীরা ভাঙা এড়াতে ব্যবহার করতে পারেন। এই তালিকাটি সম্পূর্ণ নাও হতে পারে এবং আরও গোপনীয়তা স্যান্ডবক্স সমাধান উপলব্ধ হওয়ার সাথে সাথে আপডেট করা হতে পারে। আপনি যদি কোনও অতিরিক্ত প্রভাবিত পরিস্থিতিতে সম্মুখীন হন তবে আমরা আপনাকে আপনার প্রতিক্রিয়া শেয়ার করতে উত্সাহিত করি।

আপনার ব্যবহারকারীর প্রবাহ তৃতীয় পক্ষের কুকি বিধিনিষেধ দ্বারা প্রভাবিত হয় কিনা তা পরীক্ষা করার সর্বোত্তম উপায় হল তৃতীয় পক্ষের কুকি পরীক্ষার পতাকা সক্ষম করে সেগুলির মধ্য দিয়ে যাওয়া৷

আপনার ওয়েবসাইট প্রত্যাশিতভাবে কাজ করছে তা নিশ্চিত করতে, তৃতীয় পক্ষের কুকি সীমাবদ্ধ সহ নিম্নলিখিত প্রবাহটি পরীক্ষা করুন:

  • ক্রস-সাইট চেকআউট : তৃতীয় পক্ষের অর্থপ্রদান প্রদানকারীর উপর নির্ভর করে এমন অর্থপ্রবাহ পরীক্ষা করুন (যেমন <example-provider> দিয়ে অর্থপ্রদান করুন) । নিশ্চিত করুন যে:
    • পুনঃনির্দেশ সফলভাবে ঘটে।
    • পেমেন্ট গেটওয়ে সঠিকভাবে লোড করা হয়েছে.
    • পেমেন্ট প্রক্রিয়া ত্রুটি ছাড়া সম্পন্ন করা যেতে পারে.
    • ব্যবহারকারীকে প্রত্যাশিতভাবে আপনার ওয়েবসাইটে ফিরিয়ে আনা হয়।
  • পেমেন্ট ড্যাশবোর্ড : পরীক্ষা করুন যে লেনদেন ড্যাশবোর্ড উইজেটগুলি প্রত্যাশিতভাবে কাজ করে যাতে তৃতীয় পক্ষের কুকি সীমাবদ্ধ থাকে। যাচাই করুন যে ব্যবহারকারী পারেন:
    • ড্যাশবোর্ড অ্যাক্সেস করুন।
    • প্রত্যাশিত হিসাবে সব পেমেন্ট দেখুন.
    • ড্যাশবোর্ডের বিভিন্ন বিভাগের মধ্যে ত্রুটি ছাড়াই নেভিগেট করুন (যেমন, লেনদেনের ইতিহাস, অর্থপ্রদানের বিবরণ)।
  • অর্থপ্রদানের পদ্ধতি পরিচালনা করুন : পরীক্ষা করুন যে অর্থপ্রদানের পদ্ধতি পরিচালনার উইজেটগুলি প্রত্যাশা অনুযায়ী কাজ করে। তৃতীয় পক্ষের কুকি অবরুদ্ধ করে, পরীক্ষা করুন যে:
    • একটি অর্থপ্রদানের পদ্ধতি যোগ করা বা মুছে ফেলা প্রত্যাশিত হিসাবে কাজ করে।
    • পূর্বে সংরক্ষিত অর্থপ্রদানের পদ্ধতিগুলির সাথে অর্থ প্রদান প্রভাবিত হয় না।
  • জালিয়াতি শনাক্তকরণ : তৃতীয় পক্ষের কুকিজের সাথে এবং ছাড়া আপনার জালিয়াতি সনাক্তকরণ সমাধান কীভাবে কাজ করে তা তুলনা করুন।
    • থার্ড-পার্টি কুকি ব্লক করা কি অতিরিক্ত পদক্ষেপ প্রবর্তন করে, অতিরিক্ত ব্যবহারকারীর ঘর্ষণ সৃষ্টি করে?
    • ব্রাউজারে তৃতীয় পক্ষের কুকি ব্লক করা হলে এটি কি এখনও সন্দেহজনক নিদর্শন সনাক্ত করতে পারে?
  • ব্যক্তিগতকৃত চেকআউট বোতাম : সীমাবদ্ধ তৃতীয় পক্ষের কুকিগুলির সাথে অর্থপ্রদানের বোতামগুলি সঠিকভাবে রেন্ডার হয় কিনা তা পরীক্ষা করুন।
    • ব্যক্তিগতকৃত বোতামটি তাদের পছন্দের পদ্ধতি প্রদর্শন না করলেও ব্যবহারকারী কি ক্রয় সম্পূর্ণ করতে পারেন?

ক্রস সাইট চেকআউট

কিছু অর্থপ্রদান প্রদানকারীরা পুনরায় প্রমাণীকরণের প্রয়োজন ছাড়াই ব্যবহারকারীদের একাধিক মার্চেন্ট সাইট জুড়ে তাদের অ্যাকাউন্ট অ্যাক্সেস করার অনুমতি দেওয়ার জন্য তৃতীয় পক্ষের কুকির উপর নির্ভর করতে পারে। যারা তৃতীয় পক্ষের কুকি ছাড়া ব্রাউজ করতে পছন্দ করেন তাদের জন্য এই ব্যবহারকারীর যাত্রা প্রভাবিত হতে পারে।

এমবেডেড চেকআউট ফর্ম

নিম্নলিখিত ডোমেন বিবেচনা করুন:

  • payment-provider.example বণিক সাইটগুলিতে অর্থপ্রদান পরিষেবা সরবরাহ করে এবং ব্যবহারকারীর অর্থপ্রদান এবং সেশন ডেটা সঞ্চয় করে৷
  • merchant.example হল একটি ওয়েবসাইট যা payment-provider.example দ্বারা প্রদত্ত একটি চেকআউট ফর্ম এম্বেড করে।

একজন ব্যবহারকারী সবেমাত্র payment-provider.example এ লগ ইন করেছেন (উদাহরণস্বরূপ, অন্য সাইটে চেকআউট সম্পূর্ণ করার সময়)। ব্যবহারকারী merchant.example এ একটি চেকআউট প্রক্রিয়া শুরু করে।

তৃতীয় পক্ষের কুকি উপলভ্য থাকলে, merchant.example এ এমবেড করা payment-provider.example চেকআউট ফর্মটি শীর্ষ-স্তরের প্রসঙ্গে payment-provider.example এ সেট করা নিজস্ব টপ-লেভেল সেশন কুকিতে অ্যাক্সেস পাবে। যাইহোক, যদি তৃতীয় পক্ষের কুকি ব্লক করা হয়, তাহলে এম্বেডের নিজস্ব শীর্ষ-স্তরের কুকিগুলিতে অ্যাক্সেস থাকবে না।

চিত্রটি একটি বণিক ওয়েবসাইট (merchant.example) এর সাথে একটি মিথস্ক্রিয়া দেখায় যা একটি তৃতীয়-পক্ষ প্রদানকারীর (payment-provider.example) থেকে একটি পেমেন্ট উইজেট ব্যবহার করে। যখন তৃতীয় পক্ষের কুকি ব্লক করা হয়, উইজেটটি তার শীর্ষ-স্তরের কুকি অ্যাক্সেস করতে পারে না, সম্ভাব্যভাবে ব্যবহারকারীর অভিজ্ঞতাকে ব্যাহত করে।
যখন তৃতীয় পক্ষের কুকিগুলি নিষ্ক্রিয় করা হয়, তখন `payment-provider.example` উইজেটটি `payment-provider.example`-এর শীর্ষ-স্তরের প্রসঙ্গে সেট করা ব্যবহারকারী সেশন কুকিতে অ্যাক্সেস পাবে না।

FedCM এর সাথে একটি কাস্টমাইজযোগ্য সমাধান

payment-provider.example একটি পরিচয় প্রদানকারী হিসাবে কাজ করার জন্য FedCM বাস্তবায়নের বিষয়টি বিবেচনা করা উচিত। এই পদ্ধতিটি উপযুক্ত হতে পারে যখন:

  • payment-provider.example সম্পর্কহীন তৃতীয় পক্ষের সাইটে এম্বেড করা আছে।
  • payment-provider.example পাঁচটির বেশি সম্পর্কিত সাইটে এম্বেড করা আছে।

FedCM এর প্রধান সুবিধা হল যে UI ব্যবহারকারীদের তাদের পছন্দের জন্য আরও প্রসঙ্গ সরবরাহ করতে পারে। ব্যবহারকারীর অনুমতি নিয়ে, FedCM নির্ভরকারী পক্ষ ( merchant.example ) এবং পরিচয় প্রদানকারী ( payment-provider.example ) এর মধ্যে কাস্টম ডেটা ভাগ করে নেওয়ার অনুমতি দেয়৷ নির্ভরকারী পক্ষ এক বা একাধিক পরিচয় প্রদানকারীকে সমর্থন করতে বেছে নিতে পারে এবং FedCM UI শুধুমাত্র শর্তসাপেক্ষে প্রদর্শিত হবে।

প্রয়োজনের উপর নির্ভর করে, ডেভেলপাররা যখন ব্যবহারকারী পরিচয় প্রদানকারীর সাথে লগ ইন করেন তখন স্বয়ংক্রিয়ভাবে প্রদর্শিত হওয়ার জন্য FedCM প্রম্পটের জন্য প্যাসিভ মোড বা সক্রিয় মোডের মধ্যে একটি বেছে নিতে পারেন, যখন ব্যবহারকারীর দ্বারা একটি ক্রিয়া করার পরে, যেমন একটি চেকআউট বোতামে ক্লিক করার পরে লগইন প্রক্রিয়াটি ট্রিগার করা উচিত।

FedCM স্টোরেজ অ্যাক্সেস API (SAA) এর জন্য একটি বিশ্বাস সংকেত হিসাবেও কাজ করে, যা ব্যবহারকারী এম্বেডের প্রদানকারীর সাথে সাইন ইন করতে সম্মত হওয়ার পরে অতিরিক্ত ব্যবহারকারীর প্রম্পটের প্রয়োজন ছাড়াই এম্বেডকে তার শীর্ষ-স্তরের অ-বিভাজনহীন কুকিজ অ্যাক্সেস করতে দেয়।

স্টোরেজ অ্যাক্সেস ফোকাসড সমাধান

বিবেচনা করার জন্য আরেকটি API হল স্টোরেজ অ্যাক্সেস API (SAA) । SAA এর সাথে, ব্যবহারকারীকে তার নিজস্ব টপ-লেভেল কুকিজ অ্যাক্সেস করার জন্য payment-provider.example এম্বেড করার অনুমতি দেওয়ার জন্য অনুরোধ করা হবে। যদি ব্যবহারকারী অ্যাক্সেস অনুমোদন করে, ফর্মটি তৃতীয় পক্ষের কুকিজ উপলব্ধ হলে যেমনটি করে তেমন রেন্ডার করতে পারে।

FedCM-এর মতোই, ব্যবহারকারীকে প্রতিটি নতুন সাইটে অনুরোধ অনুমোদন করতে হবে যেখানে payment-provider.example এম্বেড করা আছে। API কিভাবে কাজ করে তা বুঝতে SAA ডেমো দেখুন। যদি ডিফল্ট SAA প্রম্পট আপনার প্রয়োজন অনুসারে না হয়, তাহলে আরও কাস্টমাইজড অভিজ্ঞতার জন্য FedCM প্রয়োগ করার কথা বিবেচনা করুন।

অল্প সংখ্যক সম্পর্কিত সাইটগুলিতে ব্যবহারকারীর ঘর্ষণ হ্রাস করুন

যদি বণিক সাইট এবং পেমেন্ট প্রদানকারী উভয়ই একই কোম্পানির হয়, তাহলে আপনি ডোমেনের মধ্যে সম্পর্ক ঘোষণা করতে Related Website Sets (RWS) API ব্যবহার করতে পারেন। এটি ব্যবহারকারীর ঘর্ষণ কমাতে সাহায্য করতে পারে: উদাহরণস্বরূপ, যদি insurance.example এবং payment-portal-insurance.example একই RWS-এ থাকে, তাহলে payment-portal-insurance.example payment-portal-insurance.example স্বয়ংক্রিয়ভাবে নিজস্ব শীর্ষ-স্তরের কুকিগুলিতে অ্যাক্সেস পাবে।

অন্যান্য পরীক্ষামূলক সমাধান

আরেকটি পরীক্ষামূলক API যা এই পরিস্থিতিতে সহায়ক হতে পারে তা হল Partitioned Popins । API বর্তমানে একটি সক্রিয় বিকাশ পর্যায়ে রয়েছে।

পার্টিশনড পপিনগুলির সাথে, ব্যবহারকারীকে 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 এম্বেডের তৃতীয়-পক্ষ কুকিজ অক্ষম থাকলে তার শীর্ষ-স্তরের কুকিগুলিতে অ্যাক্সেস থাকবে না।

চিত্রটি এমন একটি দৃশ্যের চিত্র তুলে ধরে যেখানে ব্যবহারকারীর উপার্জনের তথ্য, earnings.example-এ হোস্ট করা হয়,       dogsitting.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 একটি কাস্টমাইজযোগ্য UI অফার করে যা ব্যবহারকারীর কাছে স্পষ্টভাবে যোগাযোগ করতে সাহায্য করতে পারে কোন তথ্য ভাগ করা হচ্ছে। FedCM-এর সাথে, dogsitting.example কাস্টম অনুমতি ভাগ করার জন্য, যেমন, লেনদেনের ডেটা অ্যাক্সেস করার জন্য earnings.example অনুরোধ করতে পারে।

FedCM স্টোরেজ অ্যাক্সেস API এর জন্য একটি বিশ্বাস সংকেত হিসাবেও কাজ করে, এবং earnings.example এম্বেড SAA API কলে অতিরিক্ত ব্যবহারকারীর প্রম্পট ছাড়াই নিজস্ব শীর্ষ-স্তরের কুকিগুলিতে স্টোরেজ অ্যাক্সেস মঞ্জুর করবে।

সাইট নির্দিষ্ট ড্যাশবোর্ড সেটিংস

যদি একাধিক সাইট জুড়ে ডেটা ভাগ করার প্রয়োজন না হয়, তাহলে আপনার কুকিজকে CHIPS- এর সাথে ভাগ করার কথা বিবেচনা করুন। CHIPS সাইট-নির্দিষ্ট পছন্দগুলি সংরক্ষণ করতে উপযোগী হতে পারে, উদাহরণস্বরূপ, ড্যাশবোর্ড লেআউট বা ফিল্টার।

অর্থপ্রদানের পদ্ধতি পরিচালনা করুন

অন্য একটি সাধারণ প্রবাহ হল ব্যবহারকারীদের হোস্ট সাইটটি না রেখে একটি এম্বেডের মধ্যে তাদের অর্থপ্রদানের পদ্ধতিগুলি দেখতে এবং সম্পাদনা করা।

নিম্নলিখিত প্রবাহ বিবেচনা করুন:

  • payments.example একটি পেমেন্ট ম্যানেজমেন্ট টুল প্রদান করে যা ওয়েবসাইটে এম্বেড করা যেতে পারে। এই পরিষেবাটি ব্যবহারকারীর পেমেন্ট ডেটা এবং সেশনের তথ্য সংরক্ষণ করে।
  • shop.example হল একটি ওয়েবসাইট যা payments.example example টুলকে এমবেড করে যাতে ব্যবহারকারীরা তাদের shop.example অ্যাকাউন্টের সাথে যুক্ত পছন্দের অর্থপ্রদানের পদ্ধতি দেখতে, সম্পাদনা করতে বা বেছে নিতে পারেন।

অর্থপ্রদান প্রদানকারীরা যারা অর্থপ্রদানের পদ্ধতি ব্যবস্থাপনা বাস্তবায়ন করে তাদেরও FedCM এর সাথে পরিচয় প্রদানকারী হওয়ার কথা বিবেচনা করা উচিত। FedCM এর মাধ্যমে, ব্যবহারকারী আইডেন্টিটি প্রোভাইডার ( payments.example ) দ্বারা পরিচালিত অ্যাকাউন্ট ব্যবহার করে Relying Party ( shop.example ) এ লগ ইন করতে সক্ষম হবে।

ব্যবহারকারীর অনুমতি নিয়ে, FedCM নির্ভরকারী পক্ষ এবং পরিচয় প্রদানকারীর মধ্যে কাস্টম ডেটা শেয়ার করার অনুমতি দেয়। FedCM ব্যবহার করার প্রধান সুবিধা হল যে UI ব্যবহারকারীদের তাদের পছন্দের জন্য আরও প্রসঙ্গ প্রদান করতে পারে। এটি স্টোরেজ অ্যাক্সেস API-এর জন্য একটি বিশ্বাস সংকেত হিসাবেও কাজ করে, যা এম্বেডকে তার শীর্ষ-স্তরের কুকিজ অ্যাক্সেস করতে দেয়।

তৃতীয় পক্ষের কুকিজ নিষ্ক্রিয় থাকলে, payments.example এম্বেড এর শীর্ষ-স্তরের কুকিগুলিতে অ্যাক্সেস থাকবে না। এই ক্ষেত্রে SAA স্টোরেজ অ্যাক্সেসের অনুরোধ করে সঠিক অপারেশন নিশ্চিত করতে সাহায্য করতে পারে।

কখনও কখনও এম্বেডের মধ্যে সেট করা তথ্য অন্য এম্বেডিং সাইটগুলিতে ভাগ করার প্রয়োজন হয় না৷ payments.example শুধুমাত্র প্রতিটি নির্দিষ্ট এমবেডিং সাইটের জন্য ভিন্ন ভিন্ন ব্যবহারকারীর পছন্দ সঞ্চয় করতে হতে পারে। এই ক্ষেত্রে, চিপস ব্যবহার করে কুকি পার্টিশন করার কথা বিবেচনা করুন। CHIPS এর সাথে, shop.example এ এমবেড করা payments.example এর মধ্যে সেট করা কুকি another-shop.example এ এমবেড করা payments.example দ্বারা অ্যাক্সেসযোগ্য হবে না।

আরেকটি পরীক্ষামূলক API যা সম্ভাব্যভাবে এই ব্যবহারকারী প্রবাহে ব্যবহার করা যেতে পারে তা হল পার্টিশনড পপিনস । যখন ব্যবহারকারী shop.example দ্বারা খোলা একটি পপিনের মধ্যে payments.example এ লগ ইন করেন, তখন সঞ্চয়স্থানটি ওপেনার দ্বারা বিভাজিত হবে এবং payments.example এম্বেডের পপিনের মধ্যে সেট করা স্টোরেজ মানগুলিতে অ্যাক্সেস থাকবে৷ যাইহোক, এই পদ্ধতির জন্য ব্যবহারকারীদের প্রতিটি সাইটে অর্থপ্রদান প্রদানকারীতে সাইন ইন করতে শংসাপত্রগুলি প্রবেশ করতে হবে।

জালিয়াতি সনাক্তকরণ

ঝুঁকি বিশ্লেষণ সিস্টেমগুলি আদর্শ থেকে বিচ্যুত প্যাটার্নগুলি সনাক্ত করতে কুকিতে সংরক্ষিত ডেটা বিশ্লেষণ করতে পারে। উদাহরণস্বরূপ, যদি একজন ব্যবহারকারী হঠাৎ করে তাদের শিপিং ঠিকানা পরিবর্তন করে, এবং একটি নতুন ডিভাইস ব্যবহার করে বেশ কয়েকটি বড় কেনাকাটা করে, তাহলে সম্ভাব্য জালিয়াতির স্কোর বাড়ানো যেতে পারে। জালিয়াতি সনাক্তকারী কুকিগুলি সাধারণত তৃতীয় পক্ষের কুকি হয়, যা পেমেন্ট প্রদানকারী বা জালিয়াতি প্রতিরোধ পরিষেবা উইজেট দ্বারা বণিক সাইটগুলিতে সেট করা হয়৷

যদিও তৃতীয় পক্ষের কুকি বিধিনিষেধগুলি জালিয়াতি সনাক্তকরণ সিস্টেমগুলিকে ভাঙতে পারে না, তারা অতিরিক্ত ব্যবহারকারীর ঘর্ষণ তৈরি করতে পারে। যদি সিস্টেমটি নিশ্চিতভাবে যাচাই করতে না পারে যে ব্লক করা কুকিজের কারণে একজন ব্যবহারকারী বৈধ, তবে এটির জন্য অতিরিক্ত চেকের প্রয়োজন হতে পারে, যেমন পরিচয় যাচাইকরণ সম্পূর্ণ করা।

তৃতীয় পক্ষের কুকিজ ব্লক করা হলে জালিয়াতি সনাক্তকরণকে সমর্থন করার জন্য, আপনার জালিয়াতি সনাক্তকরণ সমাধানে প্রাইভেট স্টেট টোকেন (PST) API একীভূত করার কথা বিবেচনা করুন। PST এর সাথে, একটি অর্থপ্রদান প্রদানকারী একটি টোকেন প্রদানকারী হিসাবে নিবন্ধন করতে পারে এবং ব্যবহারকারীদের টোকেন প্রদান করতে পারে যা তৃতীয় পক্ষের কুকিজের উপর নির্ভর করে না। ব্যবহারকারী বিশ্বস্ত কিনা তা পরীক্ষা করার জন্য এই টোকেনগুলি বণিক সাইটগুলিতে ভাঙা যেতে পারে৷ বাস্তবায়নের বিশদ বিবরণের জন্য PST বিকাশকারী ডকুমেন্টেশন দেখুন।

গোপনীয়তা স্যান্ডবক্স অন্যান্য জালিয়াতি বিরোধী API-এর সাথে পরীক্ষা করছে৷

ব্যক্তিগতকৃত চেকআউট বোতাম

পেমেন্ট বোতামগুলি (যেমন <পছন্দের অর্থপ্রদানের পদ্ধতি> দিয়ে পে ) বণিক সাইটগুলিতে এম্বেড করা প্রায়শই পেমেন্ট প্রদানকারী দ্বারা সেট করা ক্রস-সাইট তথ্যের উপর নির্ভর করে। এটি ব্যক্তিগতকরণ সক্ষম করে, এবং ব্যবহারকারীরা তাদের পছন্দের অর্থপ্রদানের পদ্ধতির সাথে একটি মসৃণ চেকআউট উপভোগ করতে পারে। ব্যবহারকারীর ব্রাউজারে তৃতীয় পক্ষের কুকিজ ব্লক করা থাকলে, এটি ব্যক্তিগতকৃত অর্থপ্রদান বোতাম রেন্ডারিংকে প্রভাবিত করতে পারে।

যদিও SAA স্টোরেজ অ্যাক্সেসের অনুমতি দিতে পারে, প্রয়োজনীয় প্রম্পট একটি আদর্শ ব্যবহারকারীর অভিজ্ঞতার দিকে নিয়ে যেতে পারে না।

আমরা একটি সম্ভাব্য সমাধান অন্বেষণ করছি যা বিশেষভাবে এই ব্যবহারের ক্ষেত্রে লক্ষ্য করে: স্থানীয় অ-বিভাজনকৃত ডেটা অ্যাক্সেস সহ বেড়াযুক্ত ফ্রেম । এপিআই বর্তমানে একটি সক্রিয় বিকাশ পর্যায়ে রয়েছে এবং আপনি এর ভবিষ্যত গঠন করতে পারেন। এটি নিজে চেষ্টা করুন এবং প্রতিক্রিয়া প্রদান করুন.

সাহায্য পান

কোনো বিচ্ছেদের অভিজ্ঞতা goo.gle/report-3pc-broken- এ রিপোর্ট করুন। এছাড়াও আপনি একটি প্রতিক্রিয়া ফর্ম জমা দিতে পারেন বা গোপনীয়তা স্যান্ডবক্স বিকাশকারী সমর্থন সংগ্রহস্থলে GitHub-এ একটি সমস্যা ফাইল করতে পারেন।