檢查第三方 Cookie 變更對付款工作流程的影響

Chrome 將針對第三方 Cookie 提供全新的使用者選擇體驗。您需要為選擇不使用第三方 Cookie 的使用者準備網站。

本頁面說明哪些項目可能會受到即將實施的變更影響。

常見的使用者歷程

許多付款和購物工作流程都需要第三方 Cookie。下表列出在停用第三方 Cookie 後可能受到影響的部分使用者歷程,並建議開發人員可使用的其他 API,以免造成服務中斷。這份清單可能不夠詳盡,我們會在推出更多 Privacy Sandbox 解決方案時加以更新。如果您遇到其他受影響的情況,歡迎提供意見回饋

如要測試您的使用者流程是否受到第三方 Cookie 限制的影響,最好的方法就是啟用第三方 Cookie 測試標記,並透過該標記測試。

為確保網站能正常運作,請在限制第三方 Cookie 的情況下測試下列流程:

  • 跨網站結帳:測試仰賴第三方付款供應商 (例如「Pay with <example-provider>」) 的付款流程。請確認:
    • 重新導向成功。
    • 付款閘道已正確載入。
    • 付款程序可順利完成,且不會發生任何錯誤。
    • 使用者會如預期重新導向至您的網站。
  • 付款資訊主頁:測試交易資訊主頁小工具在限制第三方 Cookie 的情況下是否能正常運作。確認使用者可以:
    • 前往資訊主頁。
    • 查看所有預期的付款。
    • 在資訊主頁的不同部分 (例如交易記錄、付款詳細資料) 之間瀏覽時,不會發生錯誤。
  • 管理付款方式:測試付款方式管理小工具是否正常運作。在封鎖第三方 Cookie 的情況下,請測試以下項目:
    • 新增或刪除付款方式的功能正常運作。
    • 使用先前儲存的付款方式付款不會受到影響。
  • 詐欺偵測:比較詐欺偵測解決方案在有和沒有第三方 Cookie 時的運作方式。
    • 封鎖第三方 Cookie 是否會導致額外步驟,進而造成使用者體驗不佳?
    • 如果瀏覽器封鎖第三方 Cookie,系統是否仍可偵測可疑模式?
  • 個人化結帳按鈕:測試付款按鈕是否在限制第三方 Cookie 的情況下正確顯示。
    • 即使個人化按鈕未顯示使用者偏好的付款方式,使用者是否仍可完成購買程序?

跨網站結帳

部分付款服務供應商可能會使用第三方 Cookie,讓使用者在多個商家網站上存取帳戶,而無須重新驗證。如果使用者選擇不使用第三方 Cookie 瀏覽網頁,這個使用者歷程可能會受到影響。

內嵌結帳表單

請考慮下列網域:

  • payment-provider.example 為商家網站提供付款服務,並儲存使用者付款和工作階段資料。
  • merchant.example 是嵌入 payment-provider.example 提供的結帳表單的網站。

使用者剛登入 payment-provider.example (例如在其他網站上完成結帳時)。使用者在 merchant.example 上啟動結帳流程。

有了第三方 Cookie,嵌入 merchant.examplepayment-provider.example 結帳表單就能存取頂層情境中 payment-provider.example 的頂層工作階段 Cookie 設定。不過,如果封鎖第三方 Cookie,嵌入內容就無法存取自己的頂層 Cookie。

下圖顯示與商家網站 (merchant.example) 的互動情形,該網站使用第三方供應商 (payment-provider.example) 的付款小工具。第三方 Cookie 遭到封鎖時,小工具就無法存取頂層 Cookie,可能會影響使用者體驗。
停用第三方 Cookie 後,`payment-provider.example` 小工具就無法存取 `payment-provider.example` 上頂層內容中設定的使用者工作階段 Cookie。

可自訂的 FedCM 解決方案

payment-provider.example 應考慮導入 FedCM,以便擔任身分識別資訊提供者。在下列情況下,這種做法可能很適合:

  • payment-provider.example 已嵌入於不相關的第三方網站。
  • payment-provider.example 已嵌入五個以上的相關網站。

FedCM 的主要優點在於,使用者介面可為使用者提供更多選擇的背景資訊。經使用者許可後,FedCM 可在信賴方 (merchant.example) 和身分提供者 (payment-provider.example) 之間分享自訂資料。信賴方可以選擇支援一或多個身分提供者,FedCM UI 只會依條件顯示

視需求而定,開發人員可以選擇使用被動模式,讓 FedCM 提示在使用者透過身分識別提供者登入時自動顯示,或是使用主動模式,在使用者執行動作 (例如點選結帳按鈕) 後觸發登入程序。

FedCM 也做為 Storage Access API (SAA) 的信任信號,可讓嵌入內容在使用者同意透過嵌入內容的供應商登入後,存取頂層未分割的 Cookie,而不需要額外顯示使用者提示。

以儲存空間存取權為重點的解決方案

另一個可考慮的 API 是 Storage Access API (SAA)。使用 SAA 時,系統會提示使用者允許 payment-provider.example 嵌入內容存取自己的頂層 Cookie。如果使用者核准存取權,表單就能像有第三方 Cookie 時一樣顯示。

與 FedCM 一樣,使用者必須在嵌入 payment-provider.example 的每個新網站上核准要求。請參閱 SAA 示範,瞭解 API 的運作方式。如果預設的 SAA 提示訊息不符合您的需求,建議您導入 FedCM,以便提供更個人化的體驗。

減少少數相關網站上的使用者操作不便

如果商家網站和付款供應商屬於同一家公司,您可以使用 Related Website Sets (RWS) API 宣告網域之間的關係。這有助於減少使用者摩擦:舉例來說,如果 insurance.examplepayment-portal-insurance.example 位於相同的 RWS,當 payment-portal-insurance.example 在嵌入 payment-portal-insurance.example 時要求儲存空間存取權,payment-portal-insurance.example 就會自動取得自身頂層 Cookie 的存取權。

其他實驗性質的解決方案

在這種情況下,分區彈出式視窗是另一個可能有用的實驗性 API。這個 API 目前處於開發階段。

使用 Partitioned Popins 時,系統會要求使用者輸入憑證,以便在 merchant.example 開啟的彈出式視窗中登入 payment-provider.example。儲存空間會由開啟器 merchant.example 劃分。在這種情況下,payment-provider.example 嵌入項目將可存取彈出式視窗中設定的儲存值。使用這個解決方案時,使用者必須在每個網站上登入付款服務供應商。

部分付款服務供應商提供的服務會產生付款連結,為商家網站顯示自訂結帳頁面。付款連結服務和付款供應商的使用者入口通常會在不同的網域中實作,例如 payment-provider.examplepayment-link.example

payment-link.example 會嵌入 payment-provider.example 提供的結帳表單。這是嵌入式結帳表單模式的變化版本。在這種情況下,FedCMSAARWS 也是不錯的選擇。

付款資訊主頁

有些應用程式會向使用者顯示多個網站的交易資訊主頁,讓使用者集中查看自己的財務活動。這項功能需要資訊主頁存取多個網域的使用者專屬資料。

請考慮下列網域:

  • earnings.example 提供可嵌入各種網路應用程式的付款資訊主頁。這項服務會儲存使用者收益資料和工作階段資訊。
  • catsitting.exampledogsitting.example 是兩個不同的網站,但都嵌入 earnings.example 資訊主頁。

使用者登入 earnings.example 帳戶。當他們造訪 catsitting.exampledogsitting.example 時,就能查看收益。嵌入的 earnings.example 資訊主頁會使用頂層 Cookie,並顯示使用者的個人化收益資訊。

就像其他範例一樣,如果停用第三方 Cookie,earnings.example 嵌入項目就無法存取頂層 Cookie。

圖表說明在 dogsitting.example 嵌入式資訊主頁中,顯示由 earnings.example 代管的使用者收益資訊。當第三方 Cookie 遭到封鎖時,嵌入式資訊主頁就無法存取其頂層 Cookie,導致無法顯示使用者的個人化收益資料。
停用第三方 Cookie 後,嵌入在 `dogsitting.example` 上的 `earnings.example` 小工具就無法存取 `earnings.example` 上頂層內容中的 Cookie 設定。

第一方資訊主頁

如果三個網域都屬於同一方,建議您使用 SAA 搭配 RWS。有了 SAA,earnings.example 就能在使用者授權的情況下,存取頂層 Cookie。如果此方在四個或更少的網域中使用 earnings.example,透過 RWS 宣告這些網域之間的關係,就能提供更順暢的使用者體驗。

如果同一個使用者在五個以上網域中嵌入小工具,就無法宣告所有嵌入網站與小工具網域之間的關係,因為 RWS 最多只支援一組六個網站 (一個主要網站和五個相關聯網站)。

可調式資訊主頁分發

在下列情況下,SAARWS 可能不是最佳解決方案:

  • 您為第三方網站發布資訊主頁解決方案。
  • 您有超過五個嵌入資訊主頁小工具的網站。

在這種情況下,earnings.example 應考慮導入 FedCM,以便充當身分識別資訊提供者。也就是說,使用者必須使用由 earnings.example 管理的帳戶登入 dogsitting.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,使用者就能使用由 Identity Provider (payments.example) 管理的帳戶登入依賴方 (shop.example)。

在取得使用者授權後,FedCM 可在信賴方和身分提供者之間分享自訂資料。使用 FedCM 的主要優點是,使用者介面可為使用者提供更多選擇的背景資訊。這也能做為 Storage Access API 的信任訊號,讓嵌入內容存取頂層 Cookie。

停用第三方 Cookie 後,payments.example 嵌入項目就無法存取頂層 Cookie。在這種情況下,SAA 可以要求存取儲存空間,確保應用程式正常運作。

有時嵌入內容中的資訊不需要與其他嵌入網站共用。payments.example 可能只需要為每個特定嵌入網站儲存不同的使用者偏好設定。在這種情況下,建議您使用 CHIPS 分割 Cookie。使用 CHIPS 時,shop.example 上嵌入 payments.example 內的 Cookie 設定無法由 another-shop.example 上嵌入的 payments.example 存取。

另一個可在這個使用者流程中使用的實驗 API 是 Partitioned Popins。當使用者在 shop.example 開啟的彈出式視窗中登入 payments.example 時,儲存空間會由開啟者分割,payments.example 嵌入項目將可存取彈出式視窗中設定的儲存空間值。不過,這種做法會要求使用者在每個網站上輸入憑證,才能登入付款服務供應商。

詐欺偵測

風險分析系統可分析儲存在 Cookie 中的資料,找出與常態不同的模式。舉例來說,如果使用者突然變更運送地址,並使用新裝置進行多筆大額購物,潛在詐欺分數就可能會提高。詐欺偵測 Cookie 通常是第三方 Cookie,由付款服務供應商或防詐欺服務小工具在商家網站上設定。

雖然第三方 Cookie 限制不會破壞詐欺偵測系統,但可能會造成額外的使用者摩擦。如果系統因 Cookie 遭到封鎖而無法確實驗證使用者是否合法,可能就需要進行額外檢查,例如完成身分驗證。

如要在封鎖第三方 Cookie 時支援詐欺偵測,請考慮將 Private State Tokens (PST) API 整合至詐欺偵測解決方案。透過 PST,付款服務供應商可以註冊為權杖發出者,並授予不仰賴第三方 Cookie 的使用者權杖。這些權杖可在商家網站上兌換,以便檢查使用者是否可信。如需導入詳細資訊,請參閱 PST 開發人員說明文件

Privacy Sandbox 正在測試其他防詐 API。

個人化結帳按鈕

商家網站上嵌入的付款按鈕 (例如「使用 <偏好付款方式> 付款」) 通常會依賴付款供應商設定的跨網站資訊。這麼做可實現個人化服務,使用者就能透過偏好的付款方式順利結帳。如果使用者的瀏覽器封鎖第三方 Cookie,可能會影響個人化付款按鈕的顯示方式。

雖然 SAA 可允許存取儲存空間,但必要提示可能無法提供理想的使用者體驗。

我們正在探索專門針對此用途的潛在解決方案:具有本機未分割資料存取權的區隔式 Frame。這個 API 目前處於積極開發階段,您可以塑造其未來。親自試用並提供意見回饋

取得說明

請將遇到的任何服務中斷情形回報至 goo.gle/report-3pc-broken。您也可以提交意見回饋表單,或在 GitHub Privacy Sandbox 開發人員支援存放區中回報問題。