בדיקת ההשפעה של השינויים בקובצי cookie של צד שלישי על תהליכי העבודה של התשלומים

יכול להיות שקובצי Cookie של צד שלישי נחסמים בגלל הגבלות בדפדפן, הגדרות משתמש, דגלים למפתחים או מדיניות ארגונית.

אתם צריכים לוודא שהאתר או השירות שלכם מספקים חוויה מעולה לכל המשתמשים, עם או בלי קובצי Cookie של צד שלישי.

בדף הזה מופיע מידע על תהליכים נפוצים שעוברים משתמשים, שעשויים להיות מושפעים מחסימה של קובצי Cookie של צד שלישי.

תהליכים נפוצים שעוברים המשתמשים

הרבה תהליכי עבודה שקשורים לתשלומים ולקניות מסתמכים על קובצי Cookie של צד שלישי. בטבלה הבאה מפורטים כמה תרחישים לשימוש שעלולים להיות מושפעים מהשבתה של קובצי Cookie של צד שלישי, ומוצעים ממשקי API חלופיים שמפתחים יכולים להשתמש בהם כדי למנוע שיבושים. הרשימה הזו חלקית בלבד, והיא עשויה להתעדכן ככל שפתרונות נוספים של ארגז החול לפרטיות יהפכו לזמינים.

התהליך שעובר המשתמש	Recommended APIs
תשלום בקופה באתרים שונים	‫FedCM Related Website Sets Storage Access API (SAA) sciencePartitioned Popins
מרכזי בקרה של תשלומים	‫FedCM Storage Access API (SAA) Related Website Sets CHIPS
ניהול אמצעי התשלום	‫FedCM Storage Access API (SAA) Related Website Sets CHIPS sciencePartitioned Popins
זיהוי הונאות	טוקנים של מצב פרטי
לחצן תשלום בהתאמה אישית	scienceFenced Frames with local unpartitioned data access

בדיקת תהליכים שעוברים משתמשים שקשורים לתשלומים

הדרך הטובה ביותר לבדוק אם זרימות המשתמשים מושפעות מהגבלות על קובצי Cookie של צד שלישי היא לעבור עליהן כשהדגל לבדיקת קובצי Cookie של צד שלישי מופעל.

כדי לוודא שהאתר פועל כמצופה, בודקים את התהליך הבא כשקובצי Cookie של צד שלישי מוגבלים:

• מעבר לתשלום באתר אחר: בודקים את תהליכי התשלום שמסתמכים על ספק תשלומים של צד שלישי (למשל תשלום באמצעות <ספק לדוגמה>). מוודאים את הדברים הבאים:
  • ההפניה האוטומטית מתבצעת בהצלחה.
  • שער התשלומים נטען בצורה תקינה.
  • תהליך התשלום יכול להסתיים ללא שגיאות.
  • המשתמש מופנה בחזרה לאתר שלכם כצפוי.
• לוחות בקרה של תשלומים: בודקים שווידג'טים של לוחות בקרה של עסקאות פועלים כמצופה עם קובצי Cookie מוגבלים של צד שלישי. מוודאים שהמשתמש יכול:
  • ניגשים למרכז הבקרה.
  • כל התשלומים יופיעו כצפוי.
  • אפשר לנווט בין החלקים השונים בלוח הבקרה (למשל, היסטוריית העסקאות, פרטי התשלום) בלי שגיאות.
• ניהול אמצעי התשלום: בדיקה שהווידג'טים לניהול אמצעי התשלום פועלים כמצופה. כשקובצי Cookie של צד שלישי חסומים, צריך לבדוק את הדברים הבאים:
  • הוספה או מחיקה של אמצעי תשלום פועלות כמצופה.
  • השינוי לא משפיע על תשלום באמצעות אמצעי תשלום שנשמרו בעבר.
• זיהוי הונאות: השוואה בין אופן הפעולה של פתרון זיהוי ההונאות עם קובצי Cookie של צד שלישי לבין אופן הפעולה שלו ללא קובצי Cookie של צד שלישי.
  • האם חסימת קובצי Cookie של צד שלישי מוסיפה שלבים, וגורמת לחיכוך נוסף עם המשתמשים?
  • האם הוא עדיין יכול לזהות דפוסים חשודים כשקובצי Cookie של צד שלישי חסומים בדפדפן?
• לחצן תשלום בהתאמה אישית: בדיקה אם לחצני התשלום מוצגים בצורה תקינה כשהשימוש בקובצי Cookie של צד שלישי מוגבל.
  • האם המשתמש עדיין יכול להשלים רכישות גם אם לחצן ההתאמה האישית לא מציג את אמצעי התשלום המועדף שלו?

תשלום באתרים שונים

ספקי תשלומים מסוימים עשויים להסתמך על קובצי Cookie של צד שלישי כדי לאפשר למשתמשים לגשת לחשבון שלהם באתרים שונים של מוכרים בלי צורך לבצע אימות מחדש. המסלול הזה של המשתמשים עשוי להיות מושפע אצל משתמשים שיבחרו לגלוש בלי קובצי Cookie של צד שלישי.

טפסים מוטמעים של תהליך התשלום

דוגמאות לדומיינים:

• ‫payment-provider.example מספקת שירותי תשלום לאתרים של מוכרים, ומאחסנת נתוני תשלום ונתוני סשן של משתמשים.
• ‫merchant.example הוא אתר שמטמיע טופס תשלום שסופק על ידי payment-provider.example.

משתמש התחבר לאתר payment-provider.example (לדוגמה, בזמן השלמת תהליך התשלום באתר אחר). המשתמש מתחיל תהליך תשלום בקופה באתר merchant.example.

כשקובצי Cookie של צד שלישי זמינים, לטופס התשלום payment-provider.example שמוטמע באתר merchant.example יש גישה לקובץ Cookie משלו של סשן ברמה העליונה, שהוגדר באתר payment-provider.example בהקשר של הרמה העליונה. עם זאת, אם קובצי Cookie של צד שלישי חסומים, לרכיב המוטמע לא תהיה גישה לקובצי ה-Cookie שלו ברמה העליונה.

פתרון שניתן להתאים אישית באמצעות FedCM

‫payment-provider.example צריך לשקול הטמעה של FedCM כדי לפעול כספק זהויות. הגישה הזו מתאימה במקרים הבאים:

• ‫payment-provider.example מוטמע באתרים לא קשורים של צדדים שלישיים.
• ‫payment-provider.example מוטמע ביותר מחמישה אתרים קשורים.

היתרון העיקרי של FedCM הוא שממשק המשתמש יכול לספק למשתמשים יותר הקשר לבחירות שלהם. עם הרשאת המשתמש, FedCM מאפשר שיתוף של נתונים מותאמים אישית בין האתר (Relying Party) ‏(merchant.example) לבין ספק הזהויות (payment-provider.example). האתר יכול לבחור לתמוך בספק זהויות אחד או יותר, וממשק המשתמש של FedCM יוצג רק בתנאים מסוימים.

בהתאם לצורך, מפתחים יכולים לבחור בין מצב פסיבי שבו ההנחיה של FedCM מופיעה באופן אוטומטי כשהמשתמש מחובר לספק הזהויות, לבין מצב פעיל שבו תהליך הכניסה מופעל אחרי פעולה של המשתמש, כמו לחיצה על לחצן התשלום.

בנוסף, FedCM פועל כאות מהימן עבור Storage Access API (SAA), שמאפשר להטמעה לגשת לקובצי Cookie ברמה העליונה שלא מחולקים למחיצות אחרי שהמשתמש מסכים להיכנס לחשבון אצל הספק של ההטמעה, בלי שתוצג לו בקשה נוספת.

פתרון שמתמקד בגישה לאחסון

ממשק API נוסף שכדאי לשקול הוא Storage Access API‏ (SAA). עם SAA, המשתמש יתבקש לאשר ל-payment-provider.example embed גישה לקובצי ה-Cookie שלו ברמה העליונה. אם המשתמש מאשר גישה, הטופס יכול להיות מוצג כמו שהוא מוצג כשיש קובצי Cookie של צד שלישי.

בדומה ל-FedCM, המשתמש יצטרך לאשר את הבקשה בכל אתר חדש שבו מוטמע payment-provider.example. כדי להבין איך ה-API פועל, אפשר לעיין בהדגמה של SAA. אם הנחיית ברירת המחדל של SAA לא מתאימה לצרכים שלכם, כדאי להטמיע את FedCM כדי לקבל חוויה מותאמת אישית יותר.

הפחתת הקשיים בשימוש במספר קטן של אתרים קשורים

אם האתר של המוכר וספק אמצעי התשלום שייכים לאותה חברה, אפשר להשתמש ב-API של קבוצות של אתרים קשורים (RWS) כדי להצהיר על קשרים בין דומיינים. השימוש ב-RWS יכול לעזור לצמצם את החיכוך עם המשתמשים: לדוגמה, אם insurance.example ו-payment-portal-insurance.example נמצאים באותה קבוצה של אתרים קשורים, payment-portal-insurance.example יקבל באופן אוטומטי גישה לקובצי ה-Cookie שלו ברמה העליונה כשמתבקשת גישה לאחסון בהטמעה של payment-portal-insurance.example.

פתרונות ניסיוניים אחרים

‫API ניסיוני נוסף שיכול להיות שימושי בתרחיש הזה הוא Partitioned Popins. ה-API נמצא כרגע בשלב פיתוח פעיל.

בחלונות קופצים מחולקים, המשתמש יכול להתבקש להזין את פרטי הכניסה שלו כדי להיכנס ל-payment-provider.example בחלון קופץ שנפתח על ידי merchant.example. האחסון יחולק למחיצות על ידי מי שפותח את הקובץ merchant.example. במקרה הזה, לרכיב payment-provider.example embed תהיה גישה לערכי האחסון שהוגדרו בחלון הקופץ. בפתרון הזה, המשתמש יצטרך להיכנס לחשבון אצל ספק התשלום בכל אתר.

דפי תשלום עם קישור לתשלום

יש ספקי תשלומים שמציעים שירות ליצירת קישור לתשלום, שמוביל לדף תשלום מותאם אישית באתר של מוֹכר. לרוב, שירות קישורי תשלום ופורטל משתמשים של ספק התשלומים מיושמים בדומיינים שונים, למשל payment-provider.example ו-payment-link.example.

האתר payment-link.example מטמיע טופס תשלום שסופק על ידי payment-provider.example. זוהי וריאציה של התבנית embedded checkout form. FedCM, SAA and RWS are good options to consider for this case as well.

מרכזי בקרה לתשלומים

יש אפליקציות שמציגות למשתמשים לוחות בקרה של עסקאות בכמה אתרים, וכך מספקות תצוגה מרכזית של הפעילות הפיננסית שלהם. כדי שהלוח יוכל לגשת לנתונים ספציפיים למשתמשים בכמה דומיינים,

דוגמאות לדומיינים:

• ‫earnings.example מספק לוח בקרה לתשלומים שאפשר להטמיע באפליקציות אינטרנט שונות. בשירות הזה מאוחסנים נתוני הרווחים של המשתמשים ופרטי הסשן.
• ‫catsitting.example ו-dogsitting.example הם אתרים נפרדים ששניהם מטמיעים את לוח הבקרה earnings.example.

משתמש מתחבר לחשבון earnings.example שלו. כשהם נכנסים ל-catsitting.example או ל-dogsitting.example, הם יכולים לראות את הרווחים שלהם. לוח הבקרה המוטמע earnings.example מסתמך על קובצי Cookie ברמה העליונה ומציג את פרטי הרווחים המותאמים אישית של המשתמש.

כמו בדוגמאות אחרות, לרכיב ה-earnings.example המוטמע לא תהיה גישה לקובצי ה-Cookie ברמה העליונה שלו אם קובצי ה-Cookie של צד שלישי מושבתים.

לוחות בקרה של צד ראשון

אם שלושת הדומיינים שייכים לאותו צד, מומלץ להשתמש ב-SAA יחד עם RWS. באמצעות SAA, ‏ earnings.example יכול לקבל גישה לקובץ ה-Cookie ברמה העליונה שלו באישור המשתמש. אם הצד הזה משתמש ב-earnings.example בארבעה דומיינים או פחות, הצהרה על קשרים ביניהם באמצעות RWS יכולה לספק חוויית משתמש חלקה יותר.

אם אותו צד מטמיע את הווידג'ט ביותר מחמישה דומיינים, הוא לא יכול להצהיר על קשרים בין כל האתרים שבהם הווידג'ט מוטמע לבין הדומיין של הווידג'ט, כי קבוצת אתרים קשורים תומכת רק בשישה אתרים – אתר ראשי אחד וחמישה אתרים משויכים.

הפצה של מרכזי בקרה בהיקף נרחב

במקרים הבאים, יכול להיות שפתרונות כמו SAA ו- RWS לא יהיו הפתרון האופטימלי:

• אתם מפיצים פתרון ללוח בקרה לאתרים של צד שלישי.
• יש לכם יותר מחמישה אתרים שמוטמע בהם הווידג'ט של לוח הבקרה.

במקרה כזה, earnings.example צריך לשקול הטמעה של FedCM כדי לפעול כספק זהויות. המשמעות היא שהמשתמש יצטרך להתחבר ל-dogsitting.example באמצעות חשבון שמנוהל על ידי earnings.example.

‫FedCM מציע ממשק משתמש שאפשר להתאים אישית, וכך להסביר למשתמש בצורה ברורה איזה מידע משותף. באמצעות FedCM, האתר dogsitting.example יכול לבקש מ-earnings.example לשתף הרשאות מותאמות אישית, למשל, כדי לגשת לנתוני עסקאות.

בנוסף, FedCM משמש כאות מהימן עבור Storage Access API, והרכיב המוטמע earnings.example יקבל גישה לאחסון של קובצי Cookie משלו ברמה העליונה, ללא בקשה נוספת מהמשתמש בקריאה ל-SAA API.

הגדרות מרכז בקרה ספציפיות לאתר

אם אין צורך לשתף את הנתונים בין כמה אתרים, כדאי להשתמש ב-CHIPS כדי לחלק את קובצי ה-Cookie. קובצי CHIPS יכולים להיות שימושיים לשמירת העדפות ספציפיות לאתר, למשל פריסת לוח הבקרה או מסננים.

ניהול אמצעי תשלום

תרחיש נפוץ נוסף הוא שהמשתמש צופה באמצעי התשלום שלו ועורך אותם בהטמעה בלי לצאת מהאתר המארח.

כדאי להביא בחשבון את התהליך הבא:

• ‫payments.example מספק כלי לניהול תשלומים שאפשר להטמיע באתרים. השירות הזה מאחסן נתוני תשלומים של משתמשים ומידע על סשנים.
• ‫shop.example הוא אתר שמוטמע בו הכלי payments.example כדי לאפשר למשתמשים להציג, לערוך או לבחור אמצעי תשלום מועדפים שמשויכים לחשבון shop.example שלהם.

ספקי תשלומים שמטמיעים ניהול של אמצעי תשלום צריכים גם לשקול להפוך לספקי זהויות עם FedCM. באמצעות FedCM, המשתמש יוכל להתחבר לצד המסתמך (shop.example) באמצעות החשבון שמנוהל על ידי ספק הזהויות (payments.example).

באישור המשתמש, FedCM מאפשר שיתוף של נתונים מותאמים אישית בין האתר (Relying Party) לבין ספק הזהויות. היתרון העיקרי בשימוש ב-FedCM הוא שממשק המשתמש יכול לספק למשתמשים יותר הקשר לגבי הבחירות שלהם. הוא משמש גם כאות מהימן עבור Storage Access API, שמאפשר להטמעה לגשת לקובצי ה-Cookie ברמה העליונה שלה.

כשקובצי Cookie של צד שלישי מושבתים, לרכיב המוטמע payments.example אין גישה לקובצי ה-Cookie ברמה העליונה. במקרה כזה, SAA יכול לעזור להבטיח פעולה תקינה על ידי בקשת גישה לאחסון.

לפעמים אין צורך לשתף את המידע שמוגדר בהטמעה עם אתרים אחרים שבהם מתבצעת הטמעה. יכול להיות ש-payments.example יצטרך רק לאחסן העדפות משתמש שונות לכל אתר הטמעה ספציפי. במקרה כזה, כדאי להשתמש ב-CHIPS כדי לחלק את קובצי ה-Cookie. עם CHIPS, קובץ ה-Cookie שמוגדר ב-payments.example שמוטמע ב-shop.example לא יהיה נגיש ל-payments.example שמוטמע ב-another-shop.example.

‫API ניסיוני נוסף שאפשר להשתמש בו בתהליך הזה הוא Partitioned Popins. כשהמשתמש מתחבר ל-payments.example בתוך חלון קופץ שנפתח על ידי shop.example, האחסון מחולק לפי החלון שפתח אותו, ולרכיב המוטמע של payments.example תהיה גישה לערכי האחסון שהוגדרו בחלון הקופץ. עם זאת, בגישה הזו המשתמשים צריכים להזין פרטי כניסה כדי להיכנס לחשבון אצל ספק התשלומים בכל אתר.

זיהוי הונאות

מערכות לניתוח סיכונים יכולות לנתח את הנתונים שמאוחסנים בקובצי Cookie כדי לזהות דפוסים שחורגים מהנורמה. לדוגמה, אם משתמש משנה פתאום את כתובת המשלוח שלו ומבצע כמה רכישות גדולות באמצעות מכשיר חדש, יכול להיות שציון הסיכון להונאה יעלה. קובצי Cookie לגילוי הונאות הם בדרך כלל קובצי Cookie של צד שלישי, שמוגדרים באתרים של מוכרים על ידי ספקי תשלומים או ווידג'טים של שירותים למניעת הונאות.

הגבלות על קובצי Cookie של צד שלישי לא אמורות לשבש את המערכות לזיהוי הונאות, אבל הן עלולות ליצור חיכוך נוסף עם המשתמשים. אם המערכת לא יכולה לאמת בוודאות שהמשתמש הוא לגיטימי בגלל קובצי Cookie חסומים, יכול להיות שהיא תדרוש בדיקות נוספות, כמו השלמת אימות הזהות.

כדי לתמוך בזיהוי הונאות כשקובצי Cookie של צד שלישי חסומים, כדאי לשלב את Private State Tokens (PST) API בפתרון לזיהוי הונאות. באמצעות PST, ספק תשלומים יכול להירשם כמנפיק טוקנים ולהעניק למשתמשים טוקנים שלא מסתמכים על קובצי Cookie של צד שלישי. אפשר להשתמש בטוקנים האלה באתרים של מוֹכרים כדי לבדוק אם המשתמש מהימן. פרטים על ההטמעה מופיעים במסמכי התיעוד למפתחים בנושא PST.

במסגרת ארגז החול לפרטיות מתבצעים ניסויים בממשקי API אחרים למניעת הונאות.

כפתור תשלום בהתאמה אישית

לחצני תשלום (כמו תשלום באמצעות <אמצעי התשלום המועדף>) שמוטמעים באתרים של מוֹכרים מסתמכים לעיתים קרובות על מידע חוצה אתרים שמוגדר על ידי ספק התשלומים. כך אפשר להתאים אישית את חוויית הקנייה, והמשתמשים יכולים ליהנות מתהליך תשלום חלק עם אמצעי התשלום המועדף עליהם. אם קובצי Cookie של צד שלישי חסומים בדפדפן של המשתמש, זה יכול להשפיע על העיבוד של לחצן התשלום המותאם אישית.

למרות ש-SAA יכול לאפשר גישה לאחסון, יכול להיות שההנחיה הנדרשת לא תוביל לחוויית משתמש אידיאלית.

אנחנו בודקים פתרון פוטנציאלי שמיועד במיוחד לתרחיש השימוש הזה: Fenced Frames עם גישה מקומית לנתונים לא מחולקים. ה-API נמצא כרגע בשלב פעיל של פיתוח, ואתם יכולים להשפיע על העתיד שלו. אפשר לנסות בעצמכם ולשלוח משוב.

עזרה ומשוב

אם יש לכם שאלות או משוב לגבי תהליכי המשתמש או ממשקי ה-API שמתוארים במדריך הזה, אתם יכולים לשתף את המשוב שלכם.