ตรวจสอบผลกระทบของการเปลี่ยนแปลงคุกกี้ของบุคคลที่สามที่มีต่อเวิร์กโฟลว์การชำระเงิน

คุกกี้ของบุคคลที่สามอาจถูกบล็อกโดยข้อจำกัดของเบราว์เซอร์ การตั้งค่าของผู้ใช้ Flag ของนักพัฒนาแอป หรือนโยบายขององค์กร

คุณต้องตรวจสอบว่าเว็บไซต์หรือบริการของคุณมอบประสบการณ์การใช้งานที่ยอดเยี่ยมแก่ผู้ใช้ทั้งหมด ไม่ว่าจะมีการใช้คุกกี้ของบุคคลที่สามหรือไม่ก็ตาม

หน้านี้มีข้อมูลเกี่ยวกับการเดินทางของผู้ใช้ทั่วไปที่อาจได้รับผลกระทบ เมื่อมีการบล็อกคุกกี้ของบุคคลที่สาม

เส้นทางของผู้ใช้ที่พบบ่อย

เวิร์กโฟลว์การชำระเงินและการช็อปปิ้งจำนวนมากอาศัยคุกกี้ของบุคคลที่สาม ตารางต่อไปนี้แสดงเส้นทางของผู้ใช้บางส่วนที่อาจได้รับผลกระทบหากปิดใช้คุกกี้ของบุคคลที่สาม และแนะนำ API ทางเลือกที่นักพัฒนาซอฟต์แวร์สามารถใช้เพื่อหลีกเลี่ยงการหยุดทำงาน รายการนี้อาจไม่ครบถ้วนสมบูรณ์และอาจได้รับการอัปเดตเมื่อโซลูชัน Privacy Sandbox พร้อมใช้งานมากขึ้น

เส้นทางของผู้ใช้	API ที่แนะนำ
การชำระเงินแบบข้ามเว็บไซต์	FedCM ชุดเว็บไซต์ที่เกี่ยวข้อง Storage Access API (SAA) scienceป๊อปอินที่แบ่งพาร์ติชัน
แดชบอร์ดการชำระเงิน	FedCM Storage Access API (SAA) ชุดเว็บไซต์ที่เกี่ยวข้อง CHIPS
จัดการวิธีการชำระเงิน	FedCM Storage Access API (SAA) ชุดเว็บไซต์ที่เกี่ยวข้อง CHIPS scienceป๊อปอินที่แบ่งพาร์ติชัน
การตรวจจับการประพฤติมิชอบ	โทเค็นสถานะส่วนตัว
ปุ่มชำระเงินที่ปรับตามโปรไฟล์ของผู้ใช้	scienceเฟรมที่มีการปิดกั้นพร้อมการเข้าถึงข้อมูลในเครื่องที่ไม่ได้แบ่งพาร์ติชัน

ทดสอบเส้นทางของผู้ใช้ที่เกี่ยวข้องกับการชำระเงิน

วิธีที่ดีที่สุดในการทดสอบว่าโฟลว์ของผู้ใช้ได้รับผลกระทบจากการจำกัดคุกกี้ของบุคคลที่สามหรือไม่ คือการทดสอบโฟลว์เหล่านั้นโดยเปิดใช้ Flag การทดสอบคุกกี้ของบุคคลที่สาม

หากต้องการให้เว็บไซต์ทํางานตามที่คาดไว้ ให้ทดสอบขั้นตอนต่อไปนี้โดย จํากัดคุกกี้ของบุคคลที่สาม

• การชำระเงินข้ามเว็บไซต์: ทดสอบขั้นตอนการชำระเงินที่ต้องใช้ผู้ให้บริการชำระเงินบุคคลที่สาม (เช่น ชำระเงินด้วย <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 ฝังอยู่ในเว็บไซต์ที่เกี่ยวข้องมากกว่า 5 เว็บไซต์

ประโยชน์หลักของ FedCM คือ UI สามารถให้บริบทเพิ่มเติมแก่ผู้ใช้สำหรับ ตัวเลือกต่างๆ เมื่อได้รับสิทธิ์จากผู้ใช้ FedCM จะอนุญาตให้แชร์ข้อมูลที่กำหนดเอง ระหว่างฝ่ายที่ต้องอาศัยข้อมูล (merchant.example) กับผู้ให้บริการข้อมูลประจำตัว (payment-provider.example) ฝ่ายที่ต้องอาศัยข้อมูลสามารถเลือกที่จะรองรับผู้ให้บริการข้อมูลประจำตัวอย่างน้อย 1 ราย และ UI ของ FedCM จะแสดงแบบมีเงื่อนไขเท่านั้น

นักพัฒนาแอปสามารถเลือกได้ระหว่างโหมด Passive เพื่อให้พรอมต์ FedCM ปรากฏขึ้นโดยอัตโนมัติเมื่อผู้ใช้เข้าสู่ระบบด้วยผู้ให้บริการข้อมูลประจำตัว หรือโหมด Active เมื่อควรทริกเกอร์กระบวนการเข้าสู่ระบบหลังจากที่ผู้ใช้ดำเนินการ เช่น คลิกปุ่มชำระเงิน

นอกจากนี้ FedCM ยังทำหน้าที่เป็นสัญญาณความน่าเชื่อถือสำหรับ Storage Access API (SAA) ซึ่งช่วยให้การฝังเข้าถึงคุกกี้ที่ไม่ได้แบ่งพาร์ติชันระดับบนสุดได้หลังจากที่ ผู้ใช้ตกลงที่จะลงชื่อเข้าใช้กับผู้ให้บริการของการฝัง โดยไม่ต้องมีข้อความแจ้งเพิ่มเติมสำหรับผู้ใช้

โซลูชันที่เน้นการเข้าถึงพื้นที่เก็บข้อมูล

API อีกตัวที่ควรพิจารณาคือ Storage Access API (SAA) เมื่อใช้ SAA ระบบจะแจ้งให้ผู้ใช้อนุญาตให้ payment-provider.example ฝังเพื่อ เข้าถึงคุกกี้ระดับบนสุดของตนเอง หากผู้ใช้อนุมัติการเข้าถึง แบบฟอร์มจะแสดงผลได้เช่นเดียวกับเมื่อมีคุกกี้ของบุคคลที่สาม

เช่นเดียวกับ FedCM ผู้ใช้จะต้องอนุมัติคำขอในทุกเว็บไซต์ใหม่ ที่มีการฝัง payment-provider.example ดูการสาธิต SAA เพื่อทำความเข้าใจวิธีการทำงานของ API หากพรอมต์ SAA เริ่มต้นไม่เหมาะกับความต้องการของคุณ ให้ลองใช้ FedCM เพื่อประสบการณ์การใช้งานที่ปรับแต่งมากขึ้น

ลดอุปสรรคของผู้ใช้ในเว็บไซต์ที่เกี่ยวข้องจำนวนน้อย

หากทั้งเว็บไซต์ผู้ขายและผู้ให้บริการชำระเงินเป็นของบริษัทเดียวกัน คุณสามารถใช้ ชุดเว็บไซต์ที่เกี่ยวข้อง (RWS) API เพื่อประกาศความสัมพันธ์ระหว่างโดเมน ซึ่งจะช่วยลดอุปสรรคของผู้ใช้ได้ เช่น หาก insurance.example และ payment-portal-insurance.example อยู่ใน RWS เดียวกัน payment-portal-insurance.example จะได้รับสิทธิ์เข้าถึงคุกกี้ระดับบนสุดของตัวเองโดยอัตโนมัติเมื่อมีการขอสิทธิ์เข้าถึงพื้นที่เก็บข้อมูลภายใน 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 ซึ่งเป็นรูปแบบที่ดัดแปลงมาจากรูปแบบแบบฟอร์มชำระเงินที่ฝัง FedCM, SAA และ RWS เป็นตัวเลือกที่ควรพิจารณาในกรณีนี้ด้วย

แดชบอร์ดการชำระเงิน

แอปพลิเคชันบางอย่างแสดงแดชบอร์ดธุรกรรมต่อผู้ใช้ในหลายเว็บไซต์ เพื่อให้มุมมองแบบรวมศูนย์ของกิจกรรมทางการเงิน ซึ่งต้องใช้แดชบอร์ดเพื่อเข้าถึงข้อมูลเฉพาะผู้ใช้ในหลายโดเมน

ลองพิจารณาโดเมนต่อไปนี้

• earnings.example มีแดชบอร์ดการชำระเงินที่ฝังใน เว็บแอปพลิเคชันต่างๆ ได้ บริการนี้จะจัดเก็บข้อมูลรายได้ของผู้ใช้และข้อมูลเซสชัน
• catsitting.example และ dogsitting.example เป็นเว็บไซต์แยกกันที่ ฝังแดชบอร์ด earnings.example ทั้งคู่

ผู้ใช้เข้าสู่ระบบบัญชี earnings.example เมื่อเข้าชม catsitting.example หรือ dogsitting.example ผู้ใช้จะดูรายได้ของตนเองได้ แดชบอร์ดearnings.exampleที่ฝังไว้จะใช้คุกกี้ระดับบนสุดและแสดง ข้อมูลรายได้ที่ปรับเปลี่ยนในแบบของผู้ใช้

เช่นเดียวกับตัวอย่างอื่นๆ earnings.exampleฝังจะไม่มีสิทธิ์เข้าถึง คุกกี้ระดับบนสุดเมื่อปิดใช้คุกกี้ของบุคคลที่สาม

แดชบอร์ดของบุคคลที่หนึ่ง

ในกรณีที่ทั้ง 3 โดเมนเป็นของบุคคลเดียวกัน ให้พิจารณาใช้ SAA ร่วมกับ RWS เมื่อใช้ SAA earnings.example จะเข้าถึงคุกกี้ระดับบนสุดได้โดยได้รับสิทธิ์จากผู้ใช้ หากบุคคลที่สามนี้ใช้ earnings.example ในโดเมนไม่เกิน 4 โดเมน การประกาศความสัมพันธ์ระหว่างโดเมนเหล่านั้นด้วย RWS จะช่วยให้ผู้ใช้ได้รับประสบการณ์ที่ราบรื่นยิ่งขึ้น

หากบุคคลเดียวกันฝังวิดเจ็ตในโดเมนมากกว่า 5 โดเมน บุคคลดังกล่าวจะประกาศความสัมพันธ์ระหว่างเว็บไซต์ที่ฝังทั้งหมดกับโดเมนของวิดเจ็ตไม่ได้ เนื่องจาก RWS รองรับเว็บไซต์ในชุดได้สูงสุด 6 เว็บไซต์ ซึ่งประกอบด้วยเว็บไซต์หลัก 1 เว็บไซต์และเว็บไซต์ที่เชื่อมโยง 5 เว็บไซต์

การเผยแพร่แดชบอร์ดที่ปรับขนาดแล้ว

ในกรณีต่อไปนี้ SAA และ RWS อาจไม่ใช่โซลูชันที่ดีที่สุด

• คุณเผยแพร่โซลูชันแดชบอร์ดสำหรับเว็บไซต์ของบุคคลที่สาม
• คุณมีเว็บไซต์มากกว่า 5 เว็บไซต์ที่ฝังวิดเจ็ตแดชบอร์ด

ในกรณีนี้ earnings.example ควรพิจารณาใช้ FedCM เพื่อทำหน้าที่เป็นผู้ให้บริการข้อมูลประจำตัว ซึ่งหมายความว่าผู้ใช้จะต้องเข้าสู่ระบบ dogsitting.example ด้วยบัญชีที่จัดการโดย earnings.example

FedCM มี UI ที่ปรับแต่งได้ซึ่งช่วยสื่อสารกับผู้ใช้ได้อย่างชัดเจนว่า มีการแชร์ข้อมูลใดบ้าง เมื่อใช้ 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 ผู้ใช้จะเข้าสู่ระบบ Relying Party (shop.example) ได้ โดยใช้บัญชีที่จัดการโดยผู้ให้บริการข้อมูลประจำตัว (payments.example)

FedCM อนุญาตให้แชร์ข้อมูลที่กำหนดเองระหว่างฝ่ายที่ต้องอาศัยข้อมูลกับผู้ให้บริการข้อมูลประจำตัวได้เมื่อได้รับสิทธิ์จากผู้ใช้ ประโยชน์หลักของการใช้ FedCM คือ UI สามารถให้บริบทเพิ่มเติมแก่ผู้ใช้ในการเลือกได้ นอกจากนี้ยังทำหน้าที่เป็น สัญญาณความน่าเชื่อถือสำหรับ Storage Access API ซึ่งช่วยให้การฝังเข้าถึงคุกกี้ระดับบนสุดได้

เมื่อปิดใช้คุกกี้ของบุคคลที่สาม payments.exampleฝังจะไม่มี สิทธิ์เข้าถึงคุกกี้ระดับบนสุด ในกรณีนี้ SAA จะช่วยให้มั่นใจได้ว่าการทำงานจะเป็นไปอย่างเหมาะสมโดยการขอสิทธิ์เข้าถึงพื้นที่เก็บข้อมูล

บางครั้งข้อมูลที่ตั้งค่าไว้ในการฝังไม่จำเป็นต้องแชร์ใน เว็บไซต์อื่นๆ ที่ฝัง payments.example อาจต้องจัดเก็บค่ากำหนดของผู้ใช้ที่แตกต่างกันสำหรับเว็บไซต์ที่ฝังแต่ละแห่งเท่านั้น ในกรณีนี้ ให้พิจารณา การแบ่งพาร์ติชันคุกกี้โดยใช้ CHIPS เมื่อใช้ CHIPS คุกกี้ที่ตั้งค่าภายใน payments.example ที่ฝังไว้ใน shop.example จะ เข้าถึงไม่ได้โดย payments.example ที่ฝังไว้ใน another-shop.example

API ทดลองอีกรายการที่อาจใช้ในโฟลว์ผู้ใช้นี้ได้คือ Partitioned Popins เมื่อผู้ใช้เข้าสู่ระบบ payments.example ภายในป๊อปอินที่เปิดโดย shop.example ระบบจะแบ่งพาร์ติชันพื้นที่เก็บข้อมูลตามตัวเปิด และ payments.example แบบฝังจะเข้าถึงค่าพื้นที่เก็บข้อมูลที่ตั้งค่าไว้ภายใน ป๊อปอินได้ อย่างไรก็ตาม วิธีนี้กำหนดให้ผู้ใช้ต้องป้อนข้อมูลเข้าสู่ระบบเพื่อลงชื่อเข้าใช้ ผู้ให้บริการชำระเงินในทุกเว็บไซต์

การตรวจจับการประพฤติมิชอบ

ระบบวิเคราะห์ความเสี่ยงสามารถวิเคราะห์ข้อมูลที่จัดเก็บไว้ในคุกกี้เพื่อระบุรูปแบบที่เบี่ยงเบนไปจากปกติ เช่น หากผู้ใช้เปลี่ยนที่อยู่จัดส่งอย่างกะทันหัน และทำการซื้อจำนวนมากหลายครั้งโดยใช้อุปกรณ์ใหม่ คะแนนการฉ้อโกงที่อาจเกิดขึ้นอาจเพิ่มขึ้น คุกกี้ตรวจหาการประพฤติมิชอบมักเป็นคุกกี้ของบุคคลที่สาม ซึ่งผู้ให้บริการชำระเงินหรือ วิดเจ็ตบริการป้องกันการประพฤติมิชอบตั้งค่าไว้ในเว็บไซต์ของผู้ขาย

แม้ว่าข้อจำกัดของคุกกี้ของบุคคลที่สามไม่ควรทำให้ระบบตรวจจับการฉ้อโกงหยุดทำงาน แต่ก็อาจสร้างความไม่สะดวกเพิ่มเติมให้กับผู้ใช้ได้ หากระบบไม่สามารถยืนยันได้อย่างมั่นใจว่าผู้ใช้เป็นผู้ใช้ที่ถูกต้องเนื่องจากคุกกี้ถูกบล็อก ระบบอาจกำหนดให้มีการตรวจสอบเพิ่มเติม เช่น การยืนยันตัวตนให้เสร็จสมบูรณ์

หากต้องการรองรับการตรวจหาการประพฤติมิชอบเมื่อมีการบล็อกคุกกี้ของบุคคลที่สาม ให้พิจารณา ผสานรวม Private State Tokens (PST) API เข้ากับโซลูชันการตรวจหาการประพฤติมิชอบ PST ช่วยให้ผู้ให้บริการชำระเงินสามารถลงทะเบียนเป็น ผู้ออกโทเค็นและให้โทเค็นแก่ผู้ใช้ที่ไม่ต้องอาศัยคุกกี้ของบุคคลที่สาม จากนั้นจะแลกโทเค็นเหล่านี้ในเว็บไซต์ของผู้ขายเพื่อตรวจสอบว่าผู้ใช้เป็นผู้ใช้ที่เชื่อถือได้หรือไม่ ดูรายละเอียดการติดตั้งใช้งานได้ใน เอกสารประกอบสำหรับนักพัฒนาซอฟต์แวร์ PST

Privacy Sandbox กำลังทดลองใช้ API ป้องกันการประพฤติมิชอบอื่นๆ

ปุ่มชำระเงินที่ปรับเปลี่ยนในแบบของคุณ

ปุ่มชำระเงิน (เช่น ชำระเงินด้วย <วิธีการชำระเงินที่ต้องการ>) ที่ฝังอยู่ใน เว็บไซต์ของผู้ขายมักจะอาศัยข้อมูลข้ามเว็บไซต์ที่ผู้ให้บริการชำระเงินตั้งค่าไว้ ซึ่งช่วยให้ปรับเปลี่ยนในแบบของคุณได้ และผู้ใช้จะได้รับประสบการณ์การชำระเงินที่ราบรื่นด้วย วิธีการชำระเงินที่ต้องการ หากคุกกี้ของบุคคลที่สามถูกบล็อกในเบราว์เซอร์ของผู้ใช้ อาจส่งผลต่อการแสดงปุ่มชำระเงินที่ปรับตามโปรไฟล์ของผู้ใช้

แม้ว่า SAA จะอนุญาตให้เข้าถึงพื้นที่เก็บข้อมูลได้ แต่ข้อความแจ้งที่จำเป็นอาจไม่ทำให้ผู้ใช้ได้รับประสบการณ์ที่ดีที่สุด

เรากำลังพิจารณาโซลูชันที่เป็นไปได้ซึ่งมุ่งเน้นกรณีการใช้งานนี้โดยเฉพาะ นั่นคือ Fenced Frame ที่มีการเข้าถึงข้อมูลในเครื่องแบบไม่แบ่งพาร์ติชัน ปัจจุบัน API อยู่ในขั้นตอนการพัฒนาที่ใช้งานอยู่ และคุณสามารถกำหนด อนาคตของ API ได้ ลองใช้ด้วยตัวคุณเอง และแสดงความคิดเห็น

ความช่วยเหลือและความคิดเห็น

หากมีคำถามหรือความคิดเห็นเกี่ยวกับเส้นทางของผู้ใช้หรือ API ที่อธิบายไว้ใน คู่มือนี้ คุณสามารถแชร์ความคิดเห็นได้