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

Chrome تجربه جدیدی را برای انتخاب کاربر در مورد کوکی‌های شخص ثالث پیشنهاد می‌کند. شما باید سایت خود را برای کاربرانی که انتخاب می کنند بدون کوکی های شخص ثالث مرور کنند، آماده کنید.

این صفحه حاوی اطلاعاتی در مورد آنچه ممکن است تحت تأثیر تغییرات آتی قرار گیرد، است.

سفرهای مشترک کاربران

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

این نمودار تعاملی را با یک وب‌سایت تجاری (merchant.example) نشان می‌دهد که از ویجت پرداخت از یک ارائه‌دهنده شخص ثالث (payment-provider.example) استفاده می‌کند. هنگامی که کوکی‌های شخص ثالث مسدود می‌شوند، ویجت نمی‌تواند به کوکی سطح بالای خود دسترسی داشته باشد و به طور بالقوه تجربه کاربر را مختل می‌کند.
وقتی کوکی‌های شخص ثالث غیرفعال می‌شوند، ویجت «payment-provider.example» به کوکی جلسه کاربر که در زمینه سطح بالای «payment-provider.example» تنظیم شده است دسترسی نخواهد داشت.

یک راه حل قابل تنظیم با FedCM

payment-provider.example باید پیاده سازی FedCM را به عنوان یک ارائه دهنده هویت در نظر بگیرد. این رویکرد زمانی می تواند مناسب باشد که:

  • payment-provider.example در سایت های شخص ثالث غیر مرتبط تعبیه شده است.
  • payment-provider.example در بیش از پنج سایت مرتبط تعبیه شده است.

مزیت اصلی FedCM این است که رابط کاربری می تواند زمینه بیشتری را برای انتخاب کاربران فراهم کند. با اجازه کاربر، FedCM به اشتراک گذاری داده های سفارشی بین طرف متکی ( merchant.example ) و Identity Provider ( payment-provider.example ) اجازه می دهد. طرف متکی می‌تواند از یک یا چند ارائه‌دهنده هویت پشتیبانی کند و رابط کاربری FedCM فقط به‌صورت مشروط نمایش داده می‌شود.

بسته به نیاز، توسعه‌دهندگان می‌توانند بین حالت غیرفعال برای نمایش خودکار اعلان FedCM زمانی که کاربر با ارائه‌دهنده هویت وارد شده است، یا حالت فعال، زمانی که فرآیند ورود باید پس از اقدامی توسط کاربر آغاز شود، مانند کلیک بر روی دکمه پرداخت، انتخاب کنند.

FedCM همچنین به عنوان یک سیگنال اعتماد برای Storage Access API (SAA) عمل می‌کند، که به embed اجازه می‌دهد تا پس از موافقت کاربر برای ورود به سیستم با ارائه‌دهنده جاسازی، به کوکی‌های پارتیشن نشده سطح بالای خود دسترسی داشته باشد، بدون اینکه نیازی به درخواست کاربر اضافی باشد.

راه حل متمرکز دسترسی به ذخیره سازی

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

درست مانند 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 در حال حاضر در مرحله توسعه فعال است.

با پاپین‌های پارتیشن‌شده، می‌توان از کاربر درخواست کرد که اعتبار خود را برای ورود به payment-provider.example در یک popin باز شده توسط merchant.example وارد کند. فضای ذخیره‌سازی توسط بازکننده 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 بازدید می کنند، می توانند درآمد خود را مشاهده کنند. داشبورد embedded earnings.example به کوکی های سطح بالا متکی است و اطلاعات درآمد شخصی کاربر را نمایش می دهد.

درست مانند نمونه‌های دیگر، embed earnings.example به کوکی‌های سطح بالای خود که کوکی‌های شخص ثالث غیرفعال هستند، دسترسی نخواهد داشت.

نموداری که سناریویی را نشان می‌دهد که در آن اطلاعات درآمد کاربر، میزبانی شده در gainings.example،       در داشبورد تعبیه شده در dogsitting.example نمایش داده می شود.  وقتی کوکی های شخص ثالث مسدود می شوند،       داشبورد تعبیه شده نمی تواند به کوکی سطح بالای خود دسترسی داشته باشد و از نمایش داده های درآمد شخصی کاربر جلوگیری می کند.
وقتی کوکی‌های شخص ثالث غیرفعال می‌شوند، ویجت «earnings.example» تعبیه‌شده در «dogsitting.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 همچنین به‌عنوان یک سیگنال اعتماد برای Storage Access API عمل می‌کند، و به واحد earnings.example اجازه دسترسی به فضای ذخیره‌سازی به کوکی‌های سطح بالای خود بدون درخواست کاربر اضافی در تماس SAA API داده می‌شود.

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

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

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

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

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

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

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

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

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

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

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

کشف تقلب

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

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

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

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

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

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

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

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

کمک بگیرید

هرگونه شکستگی را به goo.gle/report-3pc-broken گزارش دهید. همچنین می‌توانید یک فرم بازخورد ارسال کنید یا مشکلی را در GitHub در مخزن پشتیبانی توسعه‌دهنده Privacy Sandbox ثبت کنید.