تأثیر تغییرات کوکی شخص ثالث را بر گردش کار پرداخت خود بررسی کنید

کوکی‌های شخص ثالث ممکن است توسط محدودیت‌های مرورگر، تنظیمات کاربر ، پرچم‌های توسعه‌دهنده یا سیاست‌های سازمانی مسدود شوند.

شما باید مطمئن شوید که سایت یا سرویس شما، صرف نظر از اینکه کوکی‌های شخص ثالث در دسترس باشند یا نباشند، تجربه‌ای عالی را برای همه کاربران فراهم می‌کند.

این صفحه حاوی اطلاعاتی درباره مسیرهای رایج کاربران است که ممکن است در صورت مسدود شدن کوکی‌های شخص ثالث تحت تأثیر قرار گیرند.

مسیرهای رایج کاربران

بسیاری از گردش‌های کاری پرداخت و خرید به کوکی‌های شخص ثالث متکی هستند. جدول زیر برخی از مسیرهای کاربری را که ممکن است در صورت غیرفعال شدن کوکی‌های شخص ثالث تحت تأثیر قرار گیرند، فهرست می‌کند و APIهای جایگزینی را پیشنهاد می‌دهد که توسعه‌دهندگان می‌توانند برای جلوگیری از خرابی از آنها استفاده کنند. این فهرست ممکن است جامع نباشد و با در دسترس قرار گرفتن راه‌حل‌های بیشتر برای Privacy Sandbox به‌روزرسانی شود.

سفرهای کاربری مرتبط با پرداخت‌های خود را آزمایش کنید

بهترین راه برای بررسی اینکه آیا جریان‌های کاربری شما تحت تأثیر محدودیت‌های کوکی‌های شخص ثالث قرار دارند یا خیر، بررسی آنها با فعال بودن پرچم آزمایش کوکی‌های شخص ثالث است.

برای اطمینان از اینکه وب‌سایت شما طبق انتظار کار می‌کند، جریان زیر را با کوکی‌های شخص ثالث محدود شده آزمایش کنید:

• پرداخت بین سایتی : جریان‌های پرداختی را که به یک ارائه‌دهنده پرداخت شخص ثالث متکی هستند (مانند پرداخت با <example-provider>) آزمایش کنید. مطمئن شوید که:
  • تغییر مسیر با موفقیت انجام می‌شود.
  • درگاه پرداخت به درستی فعال شده است.
  • فرآیند پرداخت بدون خطا انجام شود.
  • کاربر همانطور که انتظار می‌رفت به وب‌سایت شما هدایت می‌شود.
• داشبوردهای پرداخت : بررسی کنید که ویجت‌های داشبورد تراکنش مطابق انتظار با محدودیت کوکی‌های شخص ثالث کار کنند. تأیید کنید که کاربر می‌تواند:
  • به داشبورد دسترسی پیدا کنید.
  • تمام پرداخت‌ها را طبق انتظار مشاهده کنید.
  • بدون خطا بین بخش‌های مختلف داشبورد (مثلاً تاریخچه تراکنش‌ها، جزئیات پرداخت) حرکت کنید.
• مدیریت روش‌های پرداخت : بررسی کنید که ابزارک‌های مدیریت روش پرداخت مطابق انتظار کار کنند. با مسدود کردن کوکی‌های شخص ثالث، موارد زیر را بررسی کنید:
  • افزودن یا حذف یک روش پرداخت همانطور که انتظار می‌رود کار می‌کند.
  • پرداخت با روش‌های پرداخت ذخیره‌شده قبلی تحت تأثیر قرار نمی‌گیرد.
• تشخیص کلاهبرداری : مقایسه کنید که راهکار تشخیص کلاهبرداری شما با و بدون کوکی‌های شخص ثالث چگونه کار می‌کند.
  • آیا مسدود کردن کوکی‌های شخص ثالث مراحل اضافی ایجاد می‌کند و باعث ایجاد اصطکاک بیشتر کاربر می‌شود؟
  • آیا هنوز هم می‌تواند الگوهای مشکوک را تشخیص دهد، حتی زمانی که کوکی‌های شخص ثالث در مرورگر مسدود شده‌اند؟
• دکمه پرداخت شخصی‌سازی‌شده : بررسی کنید که آیا دکمه‌های پرداخت با وجود محدودیت کوکی‌های شخص ثالث، به درستی نمایش داده می‌شوند یا خیر.
  • آیا کاربر می‌تواند خریدها را تکمیل کند، حتی اگر دکمه شخصی‌سازی‌شده روش ترجیحی او را نمایش ندهد؟

پرداخت‌های بین سایتی

برخی از ارائه‌دهندگان خدمات پرداخت ممکن است برای دسترسی کاربران به حساب خود در چندین سایت تجاری بدون نیاز به احراز هویت مجدد، به کوکی‌های شخص ثالث متکی باشند. این روند کاربر ممکن است برای کسانی که بدون کوکی‌های شخص ثالث به وبگردی می‌پردازند، تحت تأثیر قرار گیرد.

فرم‌های پرداخت جاسازی‌شده

دامنه‌های زیر را در نظر بگیرید:

• payment-provider.example خدمات پرداخت را به سایت‌های تجاری ارائه می‌دهد و داده‌های پرداخت و جلسه کاربر را ذخیره می‌کند.
• merchant.example وب‌سایتی است که فرم پرداخت ارائه شده توسط payment-provider.example را در خود جای داده است.

کاربری به تازگی وارد payment-provider.example شده است (برای مثال، هنگام تکمیل پرداخت در سایت دیگری). کاربر فرآیند پرداخت را در merchant.example آغاز می‌کند.

با وجود کوکی‌های شخص ثالث، فرم پرداخت payment-provider.example که در merchant.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 همچنین به عنوان یک سیگنال اعتماد برای API دسترسی به فضای ذخیره‌سازی (SAA) عمل می‌کند، که به جاسازی اجازه می‌دهد پس از موافقت کاربر برای ورود به سیستم با ارائه‌دهنده جاسازی، بدون نیاز به اعلان کاربری اضافی، به کوکی‌های سطح بالای پارتیشن‌بندی نشده خود دسترسی داشته باشد.

راهکار متمرکز بر دسترسی به فضای ذخیره‌سازی

API دیگری که باید در نظر گرفته شود، API دسترسی به ذخیره‌سازی (SAA) است. با SAA، از کاربر خواسته می‌شود که به payment-provider.example embed اجازه دسترسی به کوکی‌های سطح بالای خود را بدهد. اگر کاربر دسترسی را تأیید کند، فرم می‌تواند مانند زمانی که کوکی‌های شخص ثالث در دسترس هستند، رندر شود.

درست مانند FedCM، کاربر باید درخواست را در هر سایت جدیدی که payment-provider.example در آن تعبیه شده است، تأیید کند. برای درک نحوه کار API ، نسخه آزمایشی SAA را ببینید. اگر اعلان پیش‌فرض SAA با نیازهای شما مطابقت ندارد، برای یک تجربه سفارشی‌تر، پیاده‌سازی FedCM را در نظر بگیرید.

کاهش اصطکاک کاربر در تعداد کمی از سایت‌های مرتبط

اگر هم سایت فروشنده و هم ارائه‌دهنده پرداخت متعلق به یک شرکت باشند، می‌توانید از API مجموعه‌های وب‌سایت مرتبط (RWS) برای اعلام روابط بین دامنه‌ها استفاده کنید. این می‌تواند به کاهش اصطکاک کاربر کمک کند: برای مثال، اگر insurance.example و payment-portal-insurance.example در RWS یکسانی باشند، payment-portal-insurance.example هنگام درخواست دسترسی به فضای ذخیره‌سازی در داخل payment-portal-insurance.example ، به طور خودکار به کوکی‌های سطح بالای خود دسترسی پیدا می‌کند.

سایر راه‌حل‌های تجربی

یکی دیگر از APIهای آزمایشی که ممکن است در این سناریو مفید باشد، Partitioned Popins است. این API در حال حاضر در مرحله توسعه فعال است.

با استفاده از Popin های پارتیشن بندی شده، می‌توان از کاربر خواست تا اعتبارنامه‌های خود را برای ورود به payment-provider.example در یک popin که توسط merchant.example باز شده است، وارد کند. فضای ذخیره‌سازی توسط opener merchant.example پارتیشن‌بندی خواهد شد. در این حالت، payment-provider.example embed به مقادیر فضای ذخیره‌سازی تعیین شده در popin دسترسی خواهد داشت. با این راهکار، کاربر باید در هر سایتی به ارائه‌دهنده پرداخت وارد شود.

پرداخت از طریق لینک پرداخت

برخی از ارائه‌دهندگان خدمات پرداخت، سرویسی ارائه می‌دهند که یک لینک پرداخت ایجاد می‌کند و یک صفحه پرداخت سفارشی برای سایت فروشنده ایجاد می‌کند. سرویس لینک پرداخت و پورتال کاربری برای ارائه‌دهنده خدمات پرداخت اغلب در دامنه‌های مختلفی پیاده‌سازی می‌شوند، به عنوان مثال، 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 را در نظر بگیرید. با SAA، earnings.example می‌تواند با اجازه کاربر به کوکی سطح بالای خود دسترسی پیدا کند. اگر این طرف از earnings.example در چهار دامنه یا کمتر استفاده کند، اعلام روابط بین آنها با RWS می‌تواند تجربه کاربری روان‌تری را فراهم کند.

اگر همان طرف، ویجت را در بیش از پنج دامنه جاسازی کند، نمی‌تواند روابط بین همه سایت‌های جاسازی و دامنه ویجت را اعلام کند، زیرا RWS فقط از شش سایت در یک مجموعه پشتیبانی می‌کند - یک سایت اصلی و پنج سایت مرتبط.

توزیع داشبوردهای مقیاس‌پذیر

در موارد زیر، SAA و RWS ممکن است راه حل بهینه نباشند:

• شما یک راهکار داشبورد برای سایت‌های شخص ثالث توزیع می‌کنید.
• شما بیش از پنج سایت دارید که ویجت داشبورد شما را در خود جای داده‌اند.

در این حالت، earnings.example باید پیاده‌سازی FedCM را به عنوان یک ارائه‌دهنده هویت در نظر بگیرد. این بدان معناست که کاربر باید با حسابی که توسط earnings.example مدیریت می‌شود، وارد dogsitting.example شود.

FedCM یک رابط کاربری قابل تنظیم ارائه می‌دهد که می‌تواند به کاربر کمک کند تا به وضوح بفهمد چه اطلاعاتی به اشتراک گذاشته می‌شود. با FedCM، dogsitting.example می‌تواند از earnings.example درخواست کند تا مجوزهای سفارشی را به اشتراک بگذارد، به عنوان مثال، برای دسترسی به داده‌های تراکنش.

FedCM همچنین به عنوان یک سیگنال اعتماد برای API دسترسی به ذخیره‌سازی عمل می‌کند و به فایل تعبیه‌شده‌ی earnings.example دسترسی ذخیره‌سازی به کوکی‌های سطح بالای خود بدون نیاز به اعلان کاربر اضافی در فراخوانی API SAA اعطا خواهد شد.

تنظیمات داشبورد مخصوص سایت

اگر نیازی به اشتراک‌گذاری داده‌ها در چندین سایت نیست، می‌توانید کوکی‌های خود را با CHIPS پارتیشن‌بندی کنید. CHIPS می‌تواند برای ذخیره تنظیمات خاص سایت، مانند طرح‌بندی داشبورد یا فیلترها، مفید باشد.

مدیریت روش‌های پرداخت

یکی دیگر از جریان‌های رایج این است که کاربر بتواند روش‌های پرداخت خود را در یک جاسازی بدون ترک سایت میزبان مشاهده و ویرایش کند.

جریان زیر را در نظر بگیرید:

• payments.example ابزاری برای مدیریت پرداخت ارائه می‌دهد که می‌تواند در وب‌سایت‌ها تعبیه شود. این سرویس داده‌های پرداخت کاربر و اطلاعات جلسه را ذخیره می‌کند.
• shop.example وب‌سایتی است که ابزار payments.example را در خود جای داده است تا کاربران بتوانند روش‌های پرداخت ترجیحی مرتبط با حساب shop.example خود را مشاهده، ویرایش یا انتخاب کنند.

ارائه‌دهندگان پرداختی که مدیریت روش‌های پرداخت را پیاده‌سازی می‌کنند، باید تبدیل شدن به یک ارائه‌دهنده هویت با FedCM را نیز در نظر بگیرند. با FedCM، کاربر می‌تواند با استفاده از حسابی که توسط ارائه‌دهنده هویت ( payments.example ) مدیریت می‌شود، وارد حساب کاربری طرف اتکا ( shop.example ) شود.

با اجازه کاربر، FedCM امکان اشتراک‌گذاری داده‌های سفارشی بین طرف اعتمادکننده و ارائه‌دهنده هویت را فراهم می‌کند. مزیت اصلی استفاده از FedCM این است که رابط کاربری می‌تواند زمینه بیشتری برای انتخاب‌های کاربران فراهم کند. همچنین به عنوان یک سیگنال اعتماد برای API دسترسی به ذخیره‌سازی عمل می‌کند که به جاسازی اجازه می‌دهد به کوکی‌های سطح بالای خود دسترسی داشته باشد.

با غیرفعال بودن کوکی‌های شخص ثالث، افزونه payments.example به کوکی‌های سطح بالای خود دسترسی نخواهد داشت. در این حالت، SAA می‌تواند با درخواست دسترسی به فضای ذخیره‌سازی، عملکرد صحیح را تضمین کند.

گاهی اوقات نیازی نیست اطلاعات موجود در یک جاسازی در سایت‌های جاسازی دیگر به اشتراک گذاشته شود. payments.example ممکن است فقط نیاز به ذخیره تنظیمات مختلف کاربر برای هر سایت جاسازی خاص داشته باشد. در این حالت، پارتیشن‌بندی کوکی‌ها با استفاده از CHIPS را در نظر بگیرید. با CHIPS، کوکی‌های موجود در payments.example که در shop.example تعبیه شده است، توسط payments.example که در another-shop.example تعبیه شده است، قابل دسترسی نخواهند بود.

یکی دیگر از APIهای آزمایشی که می‌تواند به طور بالقوه در این جریان کاربری مورد استفاده قرار گیرد، Popinsهای Partitioned است. وقتی کاربر در یک popin که توسط shop.example باز شده است، وارد payments.example می‌شود، فضای ذخیره‌سازی توسط opener پارتیشن‌بندی می‌شود و payments.example embed به مقادیر فضای ذخیره‌سازی تعیین شده در popin دسترسی خواهد داشت. با این حال، این رویکرد مستلزم آن است که کاربران برای ورود به سیستم ارائه دهنده پرداخت در هر سایت، اعتبارنامه‌ها را وارد کنند.

تشخیص کلاهبرداری

سیستم‌های تحلیل ریسک می‌توانند داده‌های ذخیره شده در کوکی‌ها را تجزیه و تحلیل کنند تا الگوهایی را که از هنجار منحرف می‌شوند، شناسایی کنند. به عنوان مثال، اگر کاربری ناگهان آدرس حمل و نقل خود را تغییر دهد و چندین خرید بزرگ با استفاده از یک دستگاه جدید انجام دهد، امتیاز بالقوه کلاهبرداری می‌تواند افزایش یابد. کوکی‌های تشخیص کلاهبرداری معمولاً کوکی‌های شخص ثالث هستند که توسط ارائه دهندگان پرداخت یا ویجت‌های خدمات پیشگیری از کلاهبرداری در سایت‌های تجاری تنظیم می‌شوند.

اگرچه محدودیت‌های کوکی‌های شخص ثالث نباید سیستم‌های تشخیص تقلب را مختل کند، اما ممکن است باعث ایجاد اصطکاک بیشتر برای کاربر شود. اگر سیستم به دلیل مسدود شدن کوکی‌ها نتواند با اطمینان تأیید کند که کاربر قانونی است، ممکن است به بررسی‌های اضافی مانند تکمیل تأیید هویت نیاز داشته باشد.

برای پشتیبانی از تشخیص کلاهبرداری در هنگام مسدود شدن کوکی‌های شخص ثالث، ادغام API توکن‌های خصوصی دولتی (PST) را در راهکار تشخیص کلاهبرداری خود در نظر بگیرید. با PST، یک ارائه‌دهنده پرداخت می‌تواند به عنوان صادرکننده توکن ثبت نام کند و به کاربران توکن‌هایی اعطا کند که به کوکی‌های شخص ثالث متکی نیستند. سپس می‌توان این توکن‌ها را در سایت‌های تجاری بازخرید کرد تا بررسی شود که آیا کاربر قابل اعتماد است یا خیر. برای جزئیات پیاده‌سازی، به مستندات توسعه‌دهنده PST مراجعه کنید.

Privacy Sandbox در حال آزمایش سایر APIهای ضد کلاهبرداری است.

دکمه پرداخت شخصی‌سازی‌شده

دکمه‌های پرداخت (مانند پرداخت با <روش پرداخت ترجیحی> ) که در سایت‌های تجاری تعبیه شده‌اند، اغلب به اطلاعات بین‌سایتی تعیین‌شده توسط ارائه‌دهنده پرداخت متکی هستند. این امر امکان شخصی‌سازی را فراهم می‌کند و کاربران می‌توانند از پرداخت روان با روش پرداخت ترجیحی خود لذت ببرند. اگر کوکی‌های شخص ثالث در مرورگر کاربر مسدود شوند، این امر می‌تواند بر نمایش دکمه پرداخت شخصی‌سازی‌شده تأثیر بگذارد.

اگرچه SAA می‌تواند دسترسی به فضای ذخیره‌سازی را امکان‌پذیر کند، اما این درخواست ممکن است منجر به یک تجربه کاربری ایده‌آل نشود.

ما در حال بررسی یک راه‌حل بالقوه هستیم که به‌طور خاص این مورد استفاده را هدف قرار می‌دهد: Fenced Frames با دسترسی به داده‌های محلی پارتیشن‌بندی نشده . این API در حال حاضر در مرحله توسعه فعال است و شما می‌توانید آینده آن را شکل دهید. خودتان آن را امتحان کنید و بازخورد خود را ارائه دهید.

کمک و بازخورد

اگر در مورد مسیرهای کاربری یا API های شرح داده شده در این راهنما سؤال یا بازخوردی دارید، می‌توانید بازخورد خود را به اشتراک بگذارید .