Chrome đang đề xuất một trải nghiệm mới để người dùng lựa chọn về cookie của bên thứ ba. Bạn cần chuẩn bị trang web cho những người dùng chọn duyệt web mà không cần cookie của bên thứ ba.
Trang này chứa thông tin về những nội dung có thể chịu ảnh hưởng của các thay đổi sắp tới.
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, đồng thời đề xuất các API thay thế mà nhà phát triển có thể sử dụng để tránh sự cố. Danh sách này chưa đầy đủ và có thể thay đổi khi có thêm các giải pháp Hộp cát về quyền riêng tư. Bạn nên chia sẻ ý kiến phản hồi nếu gặp phải bất kỳ trường hợp nào khác bị ảnh hưởng.
Kiểm thử hành trình của người dùng liên quan đến thanh toán
Cách tốt nhất để kiểm tra xem các luồng người dùng của bạn có bị ảnh hưởng bởi các quy định hạn chế về cookie của bên thứ ba hay không là kiểm tra các luồng đó khi bật cờ thử nghiệm cookie của bên thứ ba.
Để đảm bảo trang web của bạn hoạt động như mong đợi, hãy kiểm thử quy trình sau đây với cookie của bên thứ ba bị hạn chế:
- 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>). Hãy đảm bảo rằng:
- Lệnh chuyển hướng đã 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ư dự kiến.
- Trang tổng quan về thanh toán: Kiểm thử để đảm bảo các tiện ích trên trang tổng quan về giao dịch hoạt động như dự kiến 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 mà không gặp lỗi giữa các phần khác nhau 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 thử để đả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 để đảm bảo rằng:
- Việc thêm hoặc xoá phương thức thanh toán hoạt động 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 gian lận: So sánh cách hoạt động của giải pháp phát hiện gian lận khi có và khi không có cookie của bên thứ ba.
- Việc chặn cookie của bên thứ ba có làm tăng thêm các bước, gây ra thêm sự phiền hà cho người dùng không?
- Tính năng này có thể phát hiện các mẫu đá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 tra 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 hàng ngay cả khi nút được cá nhân hoá không hiển thị phương thức mà họ ưu tiên 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 xem xét các miền sau:
payment-provider.example
cung cấp dịch vụ thanh toán cho trang web của người bán, đồng thời lưu trữ dữ liệu phiên và thanh toán của người dùng.merchant.example
là một trang web nhúng biểu mẫu thanh toán dopayment-provider.example
cung 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 chính nó được đặt trên payment-provider.example
trong ngữ cảnh cấp cao nhất.
Tuy nhiên, nếu cookie của bên thứ ba bị chặn, thì nội dung nhúng sẽ không có quyền truy cập vào cookie cấp cao nhất của chính nội dung đó.

Giải pháp có thể tuỳ chỉnh bằng FedCM
payment-provider.example
nên cân nhắc triển khai FedCM để đóng vai trò là nhà cung cấp 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ề 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 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 danh tính và giao diện người dùng FedCM sẽ chỉ hiển thị theo điều kiện.
Tuỳ thuộc vào nhu cầu, nhà phát triển có thể chọn 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 quá trình đăng nhập đượ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 API Truy cập bộ nhớ (SAA), cho phép phần nhúng truy cập vào các cookie cấp cao nhất chưa được phân vùng sau khi người dùng đồng ý đăng nhập bằng nhà cung cấp của phần nhúng mà không cần thêm lời nhắc nào khác cho 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 cần cân nhắc là Storage Access API (SAA).
Với SAA, người dùng sẽ được nhắc cho phép nhúng payment-provider.example
để truy cập vào các cookie cấp cao nhất của riêng họ. 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.
Tương tự 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. Xem màn hình minh hoạ về SAA để hiểu cách hoạt động của API.
Nếu lời nhắc 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 được tuỳ chỉnh hơn.
Giảm sự phiền hà 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 Nhóm 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ự phiền hà cho người dùng: ví dụ: nếu insurance.example
và payment-portal-insurance.example
nằm trong cùng một RWS, thì payment-portal-insurance.example
sẽ tự động có quyền truy cập vào các cookie cấp cao nhất của riêng mình khi yêu cầu quyền truy cập vào bộ nhớ trong 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à Trình bật lên được phân vùng. API này hiện đang trong giai đoạn phát triển tích cực.
Với cửa sổ bật lên được phân vùng, người dùng có thể được yêu cầu nhập thông tin xác thực để đăng nhập vào payment-provider.example
trong cửa sổ bật lên do merchant.example
mở. Bộ nhớ sẽ được phân vùng bởi trình mở merchant.example
. Trong trường hợp này, phần nhúng payment-provider.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. 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 qua đườ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. Đường liên kết này 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 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 phù hợp để cân nhắc trong trường hợp này.
Trang tổng quan về 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 chế độ xem tập trung về các hoạt động tài chính của họ. Để làm được điều này, trang tổng quan cần 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 xem xét các miền sau:
earnings.example
cung cấp một trang tổng quan về khoản thanh toán có thể được nhúng trên nhiều ứng dụng web. Dịch vụ này lưu trữ dữ liệu về thu nhập của người dùng và thông tin về phiên.catsitting.example
vàdogsitting.example
là 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 trên 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, phần nhúng earnings.example
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ị tắt.

Trang tổng quan của bên thứ nhất
Trong trường hợp cả ba miền đều thuộc 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 ứng dụng khi có quyền của người dùng. Nếu bên này sử dụng earnings.example
trên 4 miền trở xuống, 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 người dùng mượt mà hơn.
Nếu cùng một bên nhúng tiện ích trên nhiều 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 nhóm – một trang web chính và 5 trang web liên kết.
Phân phối trang tổng quan theo 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 giải pháp trang tổng quan cho các trang web 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 triển khai FedCM để đóng vai trò là trình cung cấp 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 thông báo rõ ràng cho người dùng về thông tin đang được chia sẻ. Với FedCM, dogsitting.example
có thể yêu cầu earnings.example
chia sẻ các 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 API Truy cập bộ nhớ và tính năng nhúng earnings.example
sẽ được cấp quyền truy cập bộ nhớ vào các cookie cấp cao nhất của chính nó mà không cần người dùng nhắc thêm trên lệnh gọi API SAA.
Chế độ 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 để lưu trữ các lựa chọn ưu tiên dành riêng cho trang web, ví dụ: bố cục trang tổng quan hoặc bộ lọc.
Quản lý phương thức thanh toán
Một luồng phổ biến khác là người dùng xem và chỉnh sửa phương thức thanh toán trong một phần 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.example
cung 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 của người dùng và thông tin phiên.shop.example
là 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.example
củ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 trở thành nhà cung cấp danh tính thông qua 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 danh tính (payments.example
) quản lý.
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 và nhà cung cấp 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ề bối cảnh cho các lựa chọn của họ. Mã này cũng đóng vai trò là tín hiệu tin cậy cho API Truy cập bộ nhớ, cho phép phần nhúng truy cập vào các cookie cấp cao nhất.
Khi cookie của bên thứ ba bị tắt, tính năng nhúng payments.example
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 đúng cách bằng cách yêu cầu quyền truy cập vào bộ nhớ.
Đôi khi, thông tin được đặt trong nội dung nhúng không cần được chia sẻ trên các trang web nhúng khác. payments.example
có thể chỉ cần lưu trữ các tuỳ 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 phân vùng cookie bằng CHIPS. Với CHIPS, payments.example
được nhúng trên shop.example
sẽ không truy cập được cookie được đặt trong payments.example
được nhúng trên another-shop.example
.
Một API thử nghiệm khác có thể được sử dụng trong luồng người dùng này là Trình bật lên đượ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à 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 với thông thường. Ví dụ: nếu người dùng đột nhiên thay đổi địa chỉ giao hàng và thực hiện một số giao dịch mua hàng lớn bằng một thiết bị mới, thì điểm số về hành vi gian lận tiềm ẩn có thể tăng lên. Cookie phát hiện gian lận thường là cookie của bên thứ ba, do các nhà cung cấp dịch vụ thanh toán hoặc tiện ích dịch vụ phòng chống gian lận đặt trên trang web của người bán.
Mặc dù các hạn chế về cookie của bên thứ ba không được làm hỏng hệ thống phát hiện 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 người dùng là hợp lệ 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 API Mã thông báo trạng thái riêng tư (PST) vào giải pháp phát hiện hành vi gian lậ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 các mã thông báo không dựa vào cookie của bên thứ ba. Sau đó, các mã thông báo này có thể được sử dụng 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 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 thanh toán đặt. Điều này giúp cá nhân hoá và người dùng có thể thanh toán một cách 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, thì đ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 người dùng lý tưở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: Khung được phân vùng có quyền truy cập vào dữ liệu không phân vùng cục bộ. API này hiện đang trong giai đoạn phát triển tích cực và bạn có thể định hình tương lai của API. Tự mình dùng thử và đưa ra ý kiến phản hồi.
Nhận trợ giúp
Báo cáo mọi sự cố gặp phải tại goo.gle/report-3pc-broken. Bạn cũng có thể gửi biểu mẫu phản hồi hoặc báo cáo vấn đề trên GitHub trong kho lưu trữ hỗ trợ nhà phát triển Hộp cát về quyền riêng tư.