التحقّق من تأثير تغييرات ملفات تعريف الارتباط التابعة لجهات خارجية في سير عمل الدفعات

قد يتم حظر ملفات تعريف الارتباط التابعة لجهات خارجية بسبب قيود المتصفّح أو إعدادات المستخدم أو علامات المطوّر أو سياسة المؤسسة.

عليك التأكّد من أنّ موقعك الإلكتروني أو خدمتك يقدّمان تجربة رائعة لجميع المستخدمين، سواء كانت ملفات تعريف الارتباط الخارجية متاحة أم لا.

تحتوي هذه الصفحة على معلومات حول تجارب المستخدمين الشائعة التي قد تتأثر عند حظر ملفات تعريف الارتباط التابعة لجهات خارجية.

رحلات المستخدم الشائعة

تعتمد العديد من عمليات الدفع والتسوّق على ملفات تعريف الارتباط التابعة لجهات خارجية. يعرض الجدول التالي بعض رحلات المستخدمين التي قد تتأثر في حال إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية، ويقترح واجهات برمجة تطبيقات بديلة يمكن للمطوّرين استخدامها لتجنُّب حدوث مشاكل. قد لا تكون هذه القائمة شاملة، ويمكن أن يتم تعديلها عند توفّر المزيد من حلول Privacy Sandbox.

تجربة المستخدم	واجهات برمجة التطبيقات المقترَحة
إتمام عملية الدفع على مواقع إلكترونية مختلفة	FedCM مجموعات المواقع الإلكترونية ذات الصلة Storage Access API (SAA) scienceالنوافذ المنبثقة المقسّمة
لوحات بيانات الدفعات	FedCM واجهة برمجة التطبيقات Storage Access API (SAA) مجموعات المواقع الإلكترونية ذات الصلة CHIPS
إدارة طرق الدفع	FedCM Storage Access API (SAA) مجموعات المواقع الإلكترونية ذات الصلة CHIPS scienceالنوافذ المنبثقة المقسّمة
رصد الاحتيال	Private State Tokens
زر الدفع المخصّص	scienceالأُطر المضمّنة المستقلة مع إمكانية الوصول إلى البيانات المحلية غير المقسّمة

اختبار رحلات المستخدمين المتعلّقة بالدفعات

أفضل طريقة لاختبار ما إذا كانت مسارات المستخدمين تتأثر بقيود ملفات تعريف الارتباط التابعة لجهات خارجية هي الانتقال إليها مع تفعيل علامة اختبار ملفات تعريف الارتباط التابعة لجهات خارجية.

لضمان عمل موقعك الإلكتروني على النحو المتوقّع، اختبِر المسار التالي مع حظر ملفات تعريف الارتباط التابعة لجهات خارجية:

• الدفع على مواقع إلكترونية مختلفة: اختبِر مسارات الدفع التي تعتمد على مزوّد خدمة دفع تابع لجهة خارجية (مثل الدفع باستخدام <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 أيضًا كـ إشارة ثقة لواجهة برمجة التطبيقات Storage Access API (SAA)، ما يتيح للمحتوى المضمّن الوصول إلى ملفات تعريف الارتباط غير المقسّمة على المستوى الأعلى بعد موافقة المستخدم على تسجيل الدخول باستخدام مقدّم المحتوى المضمّن، بدون الحاجة إلى طلب إذن إضافي من المستخدم.

حلّ يركّز على الوصول إلى مساحة التخزين

هناك واجهة برمجة تطبيقات أخرى يجب أخذها في الاعتبار وهي Storage Access API (SAA). باستخدام Storage Access API، سيُطلب من المستخدم السماح بتضمين payment-provider.example للوصول إلى ملفات تعريف الارتباط الخاصة به على المستوى الأعلى. في حال موافقة المستخدم على منح إذن الوصول، يمكن عرض النموذج كما يتم عرضه عند توفّر ملفات تعريف الارتباط التابعة لجهات خارجية.

وكما هو الحال مع FedCM، على المستخدم الموافقة على الطلب في كل موقع إلكتروني جديد يتم فيه تضمين payment-provider.example. يمكنك الاطّلاع على العرض التوضيحي لواجهة SAA لفهم طريقة عمل واجهة برمجة التطبيقات. إذا لم يكن طلب SAA التلقائي مناسبًا لاحتياجاتك، ننصحك بتنفيذ FedCM للحصول على تجربة أكثر تخصيصًا.

تقليل الصعوبات التي قد يواجهها المستخدم على عدد قليل من المواقع الإلكترونية ذات الصلة

إذا كان كلّ من الموقع الإلكتروني الخاص بالتاجر ومقدّم خدمة الدفع تابعَين للشركة نفسها، يمكنك استخدام واجهة برمجة التطبيقات مجموعات المواقع الإلكترونية المرتبطة (RWS) للإعلان عن العلاقات بين النطاقات. يمكن أن يساعد ذلك في تقليل المشاكل التي يواجهها المستخدمون، مثلاً، إذا كان insurance.example وpayment-portal-insurance.example ضِمن مجموعة المواقع الإلكترونية المرتبطة نفسها، سيحصل payment-portal-insurance.example تلقائيًا على إذن الوصول إلى ملفات تعريف الارتباط الخاصة به على المستوى الأعلى عند طلب إذن الوصول إلى مساحة التخزين ضِمن عملية التضمين payment-portal-insurance.example.

حلول تجريبية أخرى

هناك واجهة برمجة تطبيقات تجريبية أخرى قد تكون مفيدة في هذا السيناريو، وهي Partitioned Popins. إنّ واجهة برمجة التطبيقات في مرحلة التطوير النشط حاليًا.

باستخدام ميزة "النوافذ المنبثقة المقسّمة"، يمكن أن يُطلب من المستخدم إدخال بيانات الاعتماد لتسجيل الدخول إلى payment-provider.example ضمن نافذة منبثقة فتحها merchant.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 المضمّن من الوصول إلى ملفات تعريف الارتباط ذات المستوى الأعلى إذا كانت ملفات تعريف الارتباط التابعة لجهات خارجية غير مفعّلة.

لوحات بيانات الطرف الأول

في الحالات التي تنتمي فيها النطاقات الثلاثة إلى الجهة نفسها، ننصحك باستخدام SAA مع RWS. باستخدام Storage Access API، يمكن أن يحصل earnings.example على إذن المستخدم للوصول إلى ملف تعريف الارتباط الخاص به في المستوى الأعلى. إذا كان هذا الطرف يستخدم earnings.example على أربعة نطاقات أو أقل، يمكن أن يؤدي الإفصاح عن العلاقات بينها باستخدام RWS إلى توفير تجربة مستخدم أكثر سلاسة.

إذا تضمّن الطرف نفسه الأداة على أكثر من خمسة نطاقات، لن يتمكّن من تحديد العلاقات بين جميع المواقع الإلكترونية التي تضمّن الأداة ونطاق الأداة، لأنّ RWS لا يتيح سوى ما يصل إلى ستة مواقع إلكترونية في المجموعة، أي موقع إلكتروني أساسي وخمسة مواقع إلكترونية مرتبطة.

توزيع لوحات البيانات على نطاق واسع

في الحالات التالية، قد لا يكون SAA و RWS الحل الأمثل:

• توزّع حلّ لوحة بيانات للمواقع الإلكترونية التابعة لجهات خارجية.
• لديك أكثر من خمسة مواقع إلكترونية تضمّ تطبيق لوحة البيانات المصغّر.

في هذه الحالة، على earnings.example التفكير في تنفيذ FedCM ليكون بمثابة موفّر هوية. وهذا يعني أنّه على المستخدم تسجيل الدخول إلى dogsitting.example باستخدام حساب تديره earnings.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، سيتمكّن المستخدم من تسجيل الدخول إلى الجهة المعتمِدة (shop.example) باستخدام الحساب الذي يديره موفّر الهوية (payments.example).

من خلال إذن المستخدم، تتيح FedCM مشاركة بيانات مخصّصة بين الطرف المعتمَد وموفِّر الهوية. تتمثّل الميزة الرئيسية لاستخدام FedCM في أنّ واجهة المستخدم يمكنها أن تقدّم للمستخدمين مزيدًا من السياق بشأن خياراتهم. ويعمل أيضًا كـ إشارة ثقة لواجهة برمجة التطبيقات Storage Access API، ما يسمح بالتضمين بالوصول إلى ملفات تعريف الارتباط ذات المستوى الأعلى.

عند إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية، لن يتمكّن عنصر payments.example المضمّن من الوصول إلى ملفات تعريف الارتباط ذات المستوى الأعلى. في هذه الحالة، يمكن أن يساعد SAA في ضمان التشغيل السليم من خلال طلب إذن الوصول إلى مساحة التخزين.

في بعض الأحيان، لا يلزم مشاركة المعلومات المضبوطة ضمن عملية التضمين مع مواقع إلكترونية أخرى مضمَّنة. قد يحتاج payments.example فقط إلى تخزين إعدادات مفضّلة مختلفة لكل مستخدم على كل موقع إلكتروني مضمَّن. في هذه الحالة، ننصحك بتقسيم ملفات تعريف الارتباط باستخدام CHIPS. باستخدام CHIPS، لن يكون بإمكان payments.example المضمّنة في another-shop.example الوصول إلى مجموعة ملفات تعريف الارتباط التي تم ضبطها ضمن payments.example المضمّنة في shop.example.

هناك واجهة برمجة تطبيقات تجريبية أخرى يمكن استخدامها في مسار المستخدم هذا، وهي Partitioned Popins. عندما يسجّل المستخدم الدخول إلى payments.example من خلال نافذة منبثقة فتحها shop.example، سيتم تقسيم مساحة التخزين حسب التطبيق الذي فتح النافذة، وسيتمكّن عنصر payments.example المضمّن من الوصول إلى قيم مساحة التخزين التي تم ضبطها في النافذة المنبثقة. ومع ذلك، يتطلّب هذا الأسلوب من المستخدمين إدخال بيانات الاعتماد لتسجيل الدخول إلى مقدّم خدمة الدفع على كل موقع إلكتروني.

رصد الاحتيال

يمكن لأنظمة تحليل المخاطر تحليل البيانات المخزَّنة في ملفات تعريف الارتباط لتحديد الأنماط التي تختلف عن القاعدة. على سبيل المثال، إذا غيّر المستخدم فجأة عنوان الشحن وأجرى عدة عمليات شراء كبيرة باستخدام جهاز جديد، يمكن زيادة نتيجة الاحتيال المحتمل. ملفات تعريف الارتباط الخاصة برصد الاحتيال هي عادةً ملفات تعريف ارتباط تابعة لجهات خارجية، ويتم ضبطها على المواقع الإلكترونية الخاصة بالتجّار من خلال أدوات مقدّمي خدمات الدفع أو خدمات منع الاحتيال.

مع أنّ القيود المفروضة على ملفات تعريف الارتباط التابعة لجهات خارجية لن تؤدي إلى تعطيل أنظمة رصد الاحتيال، إلّا أنّها قد تتسبّب في حدوث مشاكل إضافية للمستخدمين. إذا تعذّر على النظام التأكّد من أنّ المستخدم شرعي بسبب حظر ملفات تعريف الارتباط، قد يتطلّب ذلك إجراء عمليات تحقّق إضافية، مثل إكمال عملية التحقّق من الهوية.

للمساعدة في رصد الممارسات الاحتيالية عند حظر ملفات تعريف الارتباط التابعة لجهات خارجية، ننصحك بدمج واجهة برمجة التطبيقات Private State Tokens (PST) API في حلّ رصد الممارسات الاحتيالية. باستخدام PST، يمكن لمقدّم خدمة الدفع التسجيل كجهة إصدار رموز مميّزة ومنح المستخدمين رموزًا مميّزة لا تعتمد على ملفات تعريف الارتباط التابعة لجهات خارجية. ويمكن بعد ذلك استبدال هذه الرموز المميّزة على مواقع التجّار الإلكترونية للتحقّق مما إذا كان المستخدم موثوقًا به. للحصول على تفاصيل التنفيذ، يُرجى الاطّلاع على مستندات المطوّرين حول "ميزة التصفّح الآمن".

تختبر "مبادرة حماية الخصوصية" واجهات برمجة تطبيقات أخرى لمكافحة الاحتيال.

زر الدفع المخصّص

تعتمد أزرار الدفع (مثل الدفع باستخدام <طريقة الدفع المفضّلة>) المضمّنة في المواقع الإلكترونية الخاصة بالتجّار غالبًا على المعلومات المتوفّرة على مواقع إلكترونية متعددة والتي يضبطها مقدّم خدمة الدفع. يتيح ذلك التخصيص، ويمكن للمستخدمين الاستفادة من عملية دفع سلسة باستخدام طريقة الدفع المفضّلة لديهم. إذا تم حظر ملفات تعريف الارتباط التابعة لجهات خارجية في متصفّح المستخدم، قد يؤثر ذلك في عرض زر الدفع المخصّص.

على الرغم من أنّ SAA قد تسمح بالوصول إلى مساحة التخزين، إلا أنّ الطلب المطلوب قد لا يؤدي إلى توفير تجربة مثالية للمستخدم.

نستكشف حلاً محتملاً يستهدف حالة الاستخدام هذه تحديدًا، وهو: إطارات محصّنة مع إمكانية الوصول إلى البيانات المحلية غير المقسّمة. تخضع واجهة برمجة التطبيقات حاليًا لمرحلة تطوير نشطة، ويمكنك المساهمة في تحديد مستقبلها. جرِّب بنفسك وقدِّم ملاحظاتك.

المساعدة والملاحظات والآراء

إذا كانت لديك أسئلة أو ملاحظات حول رحلات المستخدمين أو واجهات برمجة التطبيقات الموضّحة في هذا الدليل، يمكنك مشاركة ملاحظاتك.