Cookie của bên thứ ba có thể bị chặn do các hạn chế của trình duyệt, chế độ cài đặt của người dùng, cờ của nhà phát triển hoặc chính sách của doanh nghiệp.
Bạn cần đảm bảo trang web hoặc dịch vụ của mình mang đến trải nghiệm tuyệt vời cho tất cả người dùng, dù có hay không có cookie của bên thứ ba.
Trang này chứa thông tin về những hành trình phổ biến của người dùng có thể bị ảnh hưởng khi cookie của bên thứ ba bị chặn.
Hành trình phổ biến của người dùng
Nhiều quy trình thanh toán và mua sắm dựa vào cookie của bên thứ ba. Bảng sau đây liệt kê một số hành trình của người dùng có thể bị ảnh hưởng nếu cookie của bên thứ ba bị tắt và đề xuất các API thay thế mà nhà phát triển có thể sử dụng để tránh bị gián đoạn. Danh sách này có thể chưa đầy đủ và có thể được cập nhật khi có thêm các giải pháp Hộp cát về quyền riêng tư.
Kiểm thử hành trình của người dùng liên quan đến việc thanh toán
Cách tốt nhất để kiểm tra xem luồng người dùng có bị ảnh hưởng bởi các hạn chế về cookie của bên thứ ba hay không là thực hiện các luồng đó khi bật cờ kiểm thử cookie của bên thứ ba.
Để đảm bảo trang web của bạn hoạt động như dự kiến, hãy kiểm thử quy trình sau khi hạn chế cookie của bên thứ ba:
- Thanh toán trên nhiều trang web: Kiểm thử quy trình thanh toán dựa vào nhà cung cấp dịch vụ thanh toán bên thứ ba (chẳng hạn như Thanh toán bằng <example-provider>). Đảm bảo rằng:
- Quá trình chuyển hướng diễn ra thành công.
- Cổng thanh toán được tải đúng cách.
- Quy trình thanh toán có thể hoàn tất mà không gặp lỗi.
- Người dùng được chuyển hướng trở lại trang web của bạn như mong đợi.
- Trang tổng quan về thanh toán: Kiểm tra để đảm bảo các tiện ích trang tổng quan về giao dịch hoạt động như mong đợi khi cookie của bên thứ ba bị hạn chế. Xác minh rằng người dùng có thể:
- Truy cập vào trang tổng quan.
- Xem tất cả các khoản thanh toán như dự kiến.
- Điều hướng chính xác giữa các phần của trang tổng quan (ví dụ: nhật ký giao dịch, thông tin thanh toán).
- Quản lý phương thức thanh toán: Kiểm tra để đảm bảo các tiện ích quản lý phương thức thanh toán hoạt động như mong đợi. Khi cookie của bên thứ ba bị chặn, hãy kiểm tra xem:
- Việc thêm hoặc xoá phương thức thanh toán diễn ra như mong đợi.
- Việc thanh toán bằng các phương thức thanh toán đã lưu trước đó sẽ không bị ảnh hưởng.
- Phát hiện hành vi gian lận: So sánh cách giải pháp phát hiện hành vi gian lận của bạn hoạt động khi có và không có cookie của bên thứ ba.
- Việc chặn cookie của bên thứ ba có làm phát sinh thêm các bước, gây ra thêm phiền toái cho người dùng không?
- Liệu tính năng này có thể phát hiện các mẫu hình đáng ngờ khi cookie của bên thứ ba bị chặn trong trình duyệt không?
- Nút thanh toán được cá nhân hoá: Kiểm thử xem các nút thanh toán có hiển thị chính xác khi cookie của bên thứ ba bị hạn chế hay không.
- Người dùng có thể hoàn tất giao dịch mua ngay cả khi nút được cá nhân hoá không hiển thị phương thức thanh toán mà họ muốn dùng không?
Thanh toán trên nhiều trang web
Một số nhà cung cấp dịch vụ thanh toán có thể dựa vào cookie của bên thứ ba để cho phép người dùng truy cập vào tài khoản của họ trên nhiều trang web của người bán mà không cần xác thực lại. Hành trình của người dùng này có thể bị ảnh hưởng đối với những người chọn duyệt web mà không dùng cookie của bên thứ ba.
Biểu mẫu thanh toán được nhúng
Hãy cân nhắc các miền sau:
payment-provider.examplecung cấp dịch vụ thanh toán cho các trang web của người bán và lưu trữ dữ liệu thanh toán cũng như dữ liệu phiên của người dùng.merchant.examplelà một trang web nhúng biểu mẫu thanh toán dopayment-provider.examplecung cấp.
Người dùng vừa đăng nhập vào payment-provider.example (ví dụ: trong khi hoàn tất quy trình thanh toán trên một trang web khác). Người dùng bắt đầu quy trình thanh toán trên merchant.example.
Khi có cookie của bên thứ ba, biểu mẫu thanh toán payment-provider.example được nhúng trên merchant.example sẽ có quyền truy cập vào cookie phiên cấp cao nhất của riêng biểu mẫu đó được đặt trên payment-provider.example trong bối cảnh cấp cao nhất.
Tuy nhiên, nếu cookie của bên thứ ba bị chặn, thì thành phần được nhúng sẽ không có quyền truy cập vào cookie cấp cao nhất của riêng thành phần đó.
Một giải pháp có thể tuỳ chỉnh bằng FedCM
payment-provider.example nên cân nhắc việc triển khai FedCM để đóng vai trò là nhà cung cấp dịch vụ danh tính. Phương pháp này có thể phù hợp khi:
payment-provider.exampleđược nhúng trên các trang web không liên quan của bên thứ ba.payment-provider.exampleđược nhúng trên hơn 5 trang web có liên quan.
Lợi ích chính của FedCM là giao diện người dùng có thể cung cấp cho người dùng nhiều thông tin hơn về bối cảnh cho lựa chọn của họ. Khi người dùng cho phép, FedCM cho phép chia sẻ dữ liệu tuỳ chỉnh giữa Bên phụ thuộc (merchant.example) và Nhà cung cấp dịch vụ danh tính (payment-provider.example). Bên phụ thuộc có thể chọn hỗ trợ một hoặc nhiều nhà cung cấp dịch vụ danh tính và giao diện người dùng FedCM sẽ chỉ hiển thị có điều kiện.
Tuỳ thuộc vào nhu cầu, nhà phát triển có thể chọn giữa chế độ thụ động để lời nhắc FedCM tự động xuất hiện khi người dùng đăng nhập bằng nhà cung cấp danh tính, hoặc chế độ chủ động khi quy trình đăng nhập sẽ được kích hoạt sau một hành động của người dùng, chẳng hạn như nhấp vào nút thanh toán.
FedCM cũng đóng vai trò là tín hiệu tin cậy cho Storage Access API (SAA), cho phép thành phần nhúng truy cập vào cookie chưa được phân vùng cấp cao nhất sau khi người dùng đồng ý đăng nhập bằng nhà cung cấp của thành phần nhúng mà không cần thêm lời nhắc người dùng.
Giải pháp tập trung vào quyền truy cập vào bộ nhớ
Một API khác mà bạn nên cân nhắc là Storage Access API (SAA).
Với SAA, người dùng sẽ được nhắc cho phép payment-provider.example nhúng để truy cập vào cookie cấp cao nhất của riêng mình. Nếu người dùng phê duyệt quyền truy cập, biểu mẫu có thể hiển thị như khi có cookie của bên thứ ba.
Giống như với FedCM, người dùng sẽ phải phê duyệt yêu cầu trên mọi trang web mới nơi payment-provider.example được nhúng. Hãy xem bản minh hoạ SAA để hiểu cách API này hoạt động.
Nếu câu lệnh SAA mặc định không phù hợp với nhu cầu của bạn, hãy cân nhắc triển khai FedCM để có trải nghiệm tuỳ chỉnh hơn.
Giảm thiểu rào cản cho người dùng trên một số ít trang web có liên quan
Nếu cả trang web của người bán và nhà cung cấp dịch vụ thanh toán đều thuộc cùng một công ty, bạn có thể sử dụng API Bộ trang web có liên quan (RWS) để khai báo mối quan hệ giữa các miền. Điều này có thể giúp giảm sự khó chịu cho người dùng: ví dụ: nếu insurance.example và payment-portal-insurance.example nằm trong cùng một RWS, payment-portal-insurance.example sẽ tự động có quyền truy cập vào cookie cấp cao nhất của riêng mình khi quyền truy cập vào bộ nhớ được yêu cầu trong thành phần nhúng payment-portal-insurance.example.
Các giải pháp thử nghiệm khác
Một API thử nghiệm khác có thể hữu ích trong trường hợp này là Partitioned Popins (Cửa sổ bật lên được phân vùng). API này hiện đang trong giai đoạn phát triển.
Với Partitioned Popins, người dùng có thể được yêu cầu nhập thông tin đăng nhập để đăng nhập vào payment-provider.example trong một popin do merchant.example mở. Bộ nhớ sẽ được phân vùng theo merchant.example của chương trình mở. Trong trường hợp này, payment-provider.example
embed sẽ có quyền truy cập vào các giá trị lưu trữ được đặt trong popin. Với giải pháp này, người dùng sẽ phải đăng nhập vào nhà cung cấp dịch vụ thanh toán trên mọi trang web.
Thanh toán bằng đường liên kết thanh toán
Một số nhà cung cấp dịch vụ thanh toán cung cấp dịch vụ tạo đường liên kết thanh toán, giúp hiển thị trang thanh toán tuỳ chỉnh cho trang web của người bán. Dịch vụ đường liên kết thanh toán và cổng thông tin người dùng cho nhà cung cấp dịch vụ thanh toán thường được triển khai trên các miền khác nhau, ví dụ: payment-provider.example và payment-link.example.
payment-link.example nhúng một biểu mẫu thanh toán do payment-provider.example cung cấp. Đây là một biến thể của mẫu biểu mẫu thanh toán được nhúng.
FedCM, SAA và RWS cũng là những lựa chọn đáng cân nhắc trong trường hợp này.
Trang tổng quan về hoạt động thanh toán
Một số ứng dụng hiển thị trang tổng quan về giao dịch cho người dùng trên nhiều trang web, cung cấp một chế độ xem tập trung về các hoạt động tài chính của họ. Điều này đòi hỏi trang tổng quan phải truy cập vào dữ liệu dành riêng cho người dùng trên nhiều miền.
Hãy cân nhắc các miền sau:
earnings.examplecung cấp một trang tổng quan về khoản thanh toán có thể được nhúng vào nhiều ứng dụng web. Dịch vụ này lưu trữ dữ liệu thu nhập của người dùng và thông tin phiên.catsitting.examplevàdogsitting.examplelà các trang web riêng biệt, cả hai đều nhúng trang tổng quanearnings.example.
Người dùng đăng nhập vào tài khoản earnings.example của họ. Khi truy cập vào catsitting.example hoặc dogsitting.example, họ có thể xem thu nhập của mình. Trang tổng quan earnings.example được nhúng dựa vào cookie cấp cao nhất và hiển thị thông tin thu nhập được cá nhân hoá của người dùng.
Giống như trong các ví dụ khác, thành phần earnings.example được nhúng sẽ không có quyền truy cập vào cookie cấp cao nhất khi cookie của bên thứ ba bị vô hiệu hoá.
Trang tổng quan của bên thứ nhất
Trong trường hợp cả 3 miền đều thuộc về cùng một bên, hãy cân nhắc sử dụng SAA cùng với RWS.
Với SAA, earnings.example có thể truy cập vào cookie cấp cao nhất của mình khi có sự cho phép của người dùng. Nếu bên này sử dụng earnings.example trên tối đa 4 miền, thì việc khai báo mối quan hệ giữa các miền đó bằng RWS có thể mang lại trải nghiệm mượt mà hơn cho người dùng.
Nếu cùng một bên nhúng tiện ích này trên hơn 5 miền, thì họ không thể khai báo mối quan hệ giữa tất cả các trang web nhúng và miền của tiện ích, vì RWS chỉ hỗ trợ tối đa 6 trang web trong một bộ (1 trang web chính và 5 trang web được liên kết).
Phân phối trang tổng quan trên quy mô lớn
Trong các trường hợp sau, SAA và RWS có thể không phải là giải pháp tối ưu:
- Bạn phân phối một giải pháp trang tổng quan cho các trang web của bên thứ ba.
- Bạn có hơn 5 trang web nhúng tiện ích trang tổng quan.
Trong trường hợp này, earnings.example nên cân nhắc việc triển khai FedCM để đóng vai trò là một nhà cung cấp dịch vụ danh tính. Điều này có nghĩa là người dùng sẽ cần đăng nhập vào dogsitting.example bằng một tài khoản do earnings.example quản lý.
FedCM cung cấp một giao diện người dùng có thể tuỳ chỉnh, giúp người dùng biết rõ thông tin nào đang được chia sẻ. Với FedCM, dogsitting.example có thể yêu cầu earnings.example chia sẻ quyền tuỳ chỉnh, chẳng hạn như để truy cập vào dữ liệu giao dịch.
FedCM cũng đóng vai trò là tín hiệu tin cậy cho Storage Access API và earnings.example nhúng sẽ được cấp quyền truy cập bộ nhớ vào cookie cấp cao nhất của riêng mình mà không cần thêm lời nhắc người dùng khi gọi SAA API.
Cài đặt trang tổng quan dành riêng cho trang web
Nếu không cần chia sẻ dữ liệu trên nhiều trang web, hãy cân nhắc việc phân vùng cookie bằng CHIPS. CHIPS có thể hữu ích trong việc lưu trữ các lựa chọn ưu tiên dành riêng cho trang web, chẳng hạn như bố cục trang tổng quan hoặc bộ lọc.
Quản lý phương thức thanh toán
Một quy trình phổ biến khác là người dùng xem và chỉnh sửa phương thức thanh toán của họ trong một thành phần được nhúng mà không cần rời khỏi trang web lưu trữ.
Hãy xem xét quy trình sau:
payments.examplecung cấp một công cụ quản lý thanh toán có thể được nhúng trên các trang web. Dịch vụ này lưu trữ dữ liệu thanh toán và thông tin phiên của người dùng.shop.examplelà một trang web nhúng công cụpayments.exampleđể cho phép người dùng xem, chỉnh sửa hoặc chọn phương thức thanh toán ưu tiên được liên kết với tài khoảnshop.examplecủa họ.
Các nhà cung cấp dịch vụ thanh toán triển khai tính năng quản lý phương thức thanh toán cũng nên cân nhắc việc trở thành một nhà cung cấp dịch vụ danh tính bằng FedCM. Với FedCM, người dùng sẽ có thể đăng nhập vào Bên phụ thuộc (shop.example) bằng tài khoản do Nhà cung cấp dịch vụ danh tính (payments.example) quản lý.
Với sự cho phép của người dùng, FedCM cho phép chia sẻ dữ liệu tuỳ chỉnh giữa bên phụ thuộc và nhà cung cấp dịch vụ danh tính. Lợi ích chính của việc sử dụng FedCM là giao diện người dùng có thể cung cấp cho người dùng nhiều thông tin hơn về lựa chọn của họ. Đây cũng là tín hiệu tin cậy cho Storage Access API, cho phép thành phần nhúng truy cập vào cookie cấp cao nhất của thành phần đó.
Khi cookie của bên thứ ba bị vô hiệu hoá, thành phần payments.example được nhúng sẽ không có quyền truy cập vào cookie cấp cao nhất. Trong trường hợp này, SAA có thể giúp đảm bảo hoạt động diễn ra đúng cách bằng cách yêu cầu quyền truy cập vào bộ nhớ.
Đôi khi, bạn không cần chia sẻ bộ thông tin trong thành phần nhúng với các trang web nhúng khác. payments.example chỉ cần lưu trữ các lựa chọn ưu tiên khác nhau của người dùng cho từng trang web nhúng cụ thể. Trong trường hợp này, hãy cân nhắc việc phân vùng cookie bằng CHIPS. Với CHIPS, cookie được đặt trong payments.example được nhúng trên shop.example sẽ không thể truy cập được bằng payments.example được nhúng trên another-shop.example.
Một API thử nghiệm khác có thể được dùng trong quy trình người dùng này là Partitioned Popins (Popin được phân vùng).
Khi người dùng đăng nhập vào payments.example trong một cửa sổ bật lên do shop.example mở, bộ nhớ sẽ được phân vùng theo trình mở và thành phần nhúng payments.example sẽ có quyền truy cập vào các giá trị bộ nhớ được đặt trong cửa sổ bật lên. Tuy nhiên, phương pháp này yêu cầu người dùng nhập thông tin đăng nhập để đăng nhập vào nhà cung cấp dịch vụ thanh toán trên mọi trang web.
Phát hiện gian lận
Hệ thống phân tích rủi ro có thể phân tích dữ liệu được lưu trữ trong cookie để xác định các mẫu khác thường. Ví dụ: nếu người dùng đột ngột thay đổi địa chỉ giao hàng và thực hiện một số giao dịch mua lớn bằng thiết bị mới, thì điểm số gian lận tiềm ẩn có thể tăng lên. Cookie phát hiện hành vi gian lận thường là cookie của bên thứ ba, được đặt trên trang web của người bán bởi các nhà cung cấp dịch vụ thanh toán hoặc các tiện ích dịch vụ phòng chống hành vi gian lận.
Mặc dù các quy định hạn chế đối với cookie của bên thứ ba không được làm hỏng hệ thống phát hiện hành vi gian lận, nhưng chúng có thể gây thêm phiền toái cho người dùng. Nếu không thể xác minh chắc chắn rằng một người dùng là hợp pháp do cookie bị chặn, thì hệ thống có thể yêu cầu các bước kiểm tra bổ sung, chẳng hạn như hoàn tất quy trình xác minh danh tính.
Để hỗ trợ phát hiện hành vi gian lận khi cookie của bên thứ ba bị chặn, hãy cân nhắc việc tích hợp Private State Tokens (PST) API vào giải pháp phát hiện hành vi gian lận của bạn. Với PST, nhà cung cấp dịch vụ thanh toán có thể đăng ký làm bên phát hành mã thông báo và cấp cho người dùng mã thông báo không phụ thuộc vào cookie của bên thứ ba. Sau đó, bạn có thể đổi các mã thông báo này trên trang web của người bán để kiểm tra xem người dùng có đáng tin cậy hay không. Hãy xem tài liệu dành cho nhà phát triển PST để biết thông tin chi tiết về cách triển khai.
Hộp cát về quyền riêng tư đang thử nghiệm các API chống gian lận khác.
Nút thanh toán được cá nhân hoá
Các nút thanh toán (chẳng hạn như Thanh toán bằng <phương thức thanh toán ưu tiên>) được nhúng trên các trang web của người bán thường dựa vào thông tin trên nhiều trang web do nhà cung cấp dịch vụ thanh toán đặt. Điều này giúp cá nhân hoá và người dùng có thể tận hưởng quy trình thanh toán suôn sẻ bằng phương thức thanh toán mà họ muốn. Nếu cookie của bên thứ ba bị chặn trong trình duyệt của người dùng, điều này có thể ảnh hưởng đến việc hiển thị nút thanh toán được cá nhân hoá.
Mặc dù SAA có thể cho phép truy cập vào bộ nhớ, nhưng lời nhắc bắt buộc có thể không mang lại trải nghiệm lý tưởng cho người dùng.
Chúng tôi đang khám phá một giải pháp tiềm năng nhắm đến trường hợp sử dụng này một cách cụ thể: Khung được phân vùng với quyền truy cập vào dữ liệu cục bộ chưa được phân vùng. API này hiện đang trong giai đoạn phát triển và bạn có thể định hình tương lai của API. Hãy tự mình dùng thử và đưa ra ý kiến phản hồi.
Trợ giúp và phản hồi
Nếu có thắc mắc hoặc ý kiến phản hồi về hành trình của người dùng hoặc các API được mô tả trong hướng dẫn này, bạn có thể chia sẻ ý kiến phản hồi của mình.