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

তৃতীয় পক্ষের কুকিজ ব্রাউজার সীমাবদ্ধতা, ব্যবহারকারীর সেটিংস , বিকাশকারী পতাকা , অথবা এন্টারপ্রাইজ নীতি দ্বারা ব্লক করা হতে পারে।

আপনার সাইট বা পরিষেবা আপনার সমস্ত ব্যবহারকারীদের জন্য একটি দুর্দান্ত অভিজ্ঞতা প্রদান করে তা নিশ্চিত করতে হবে, তৃতীয় পক্ষের কুকিজ উপলব্ধ থাকুক বা না থাকুক।

এই পৃষ্ঠায় ব্যবহারকারীদের সাধারণ ভ্রমণ সম্পর্কে তথ্য রয়েছে যা তৃতীয় পক্ষের কুকিজ ব্লক করা হলে প্রভাবিত হতে পারে।

সাধারণ ব্যবহারকারীর ভ্রমণ

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

আপনার পেমেন্ট-সম্পর্কিত ব্যবহারকারীর যাত্রা পরীক্ষা করুন

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

আপনার ওয়েবসাইটটি প্রত্যাশা অনুযায়ী কাজ করছে কিনা তা নিশ্চিত করতে, থার্ড-পার্টি কুকিজ সীমাবদ্ধ রেখে নিম্নলিখিত ফ্লো পরীক্ষা করুন:

• ক্রস-সাইট চেকআউট : তৃতীয় পক্ষের পেমেন্ট প্রদানকারীর উপর নির্ভরশীল পেমেন্ট প্রবাহ পরীক্ষা করুন (যেমন <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 এর প্রধান সুবিধা হলো UI ব্যবহারকারীদের তাদের পছন্দের জন্য আরও প্রসঙ্গ প্রদান করতে পারে। ব্যবহারকারীর অনুমতি নিয়ে, FedCM রিলাইং পার্টি ( merchant.example ) এবং আইডেন্টিটি প্রোভাইডার ( payment-provider.example ) এর মধ্যে কাস্টম ডেটা শেয়ার করার অনুমতি দেয়। রিলাইং পার্টি এক বা একাধিক আইডেন্টিটি প্রোভাইডারকে সমর্থন করতে পারে এবং FedCM UI শুধুমাত্র শর্তসাপেক্ষে প্রদর্শিত হবে।

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

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

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

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

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

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

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

প্রথম পক্ষের ড্যাশবোর্ড

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

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

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

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

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

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

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

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

যদিও থার্ড-পার্টি কুকি বিধিনিষেধ জালিয়াতি সনাক্তকরণ সিস্টেমকে ভেঙে ফেলা উচিত নয়, তবুও তারা অতিরিক্ত ব্যবহারকারীর দ্বন্দ্ব তৈরি করতে পারে। ব্লক করা কুকিজের কারণে যদি সিস্টেম আত্মবিশ্বাসের সাথে যাচাই করতে না পারে যে কোনও ব্যবহারকারী বৈধ, তাহলে পরিচয় যাচাইকরণ সম্পন্ন করার মতো অতিরিক্ত চেকের প্রয়োজন হতে পারে।

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

প্রাইভেসি স্যান্ডবক্স অন্যান্য অ্যান্টি-ফ্রড এপিআই নিয়ে পরীক্ষা-নিরীক্ষা করছে।

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

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

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

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

সাহায্য এবং প্রতিক্রিয়া

এই নির্দেশিকায় বর্ণিত ব্যবহারকারীর ভ্রমণ বা API সম্পর্কে আপনার যদি কোন প্রশ্ন বা প্রতিক্রিয়া থাকে, তাহলে আপনি আপনার প্রতিক্রিয়া জানাতে পারেন।