瀏覽器限制、使用者設定、開發人員標記或企業政策，都可能封鎖第三方 Cookie。
請確保您的網站或服務提供良好的使用者體驗，無論是否使用第三方 Cookie。
本頁面提供資訊，說明第三方 Cookie 遭到封鎖時，可能受到影響的常見使用者歷程。
常見使用者歷程
許多付款和購物工作流程都仰賴第三方 Cookie。下表列出停用第三方 Cookie 後可能受影響的部分使用者歷程，並建議開發人員可使用的替代 API，避免發生中斷情形。這份清單可能不夠詳盡，且會隨著更多 Privacy Sandbox 解決方案推出而更新。
測試與付款相關的使用者歷程
如要測試使用者流程是否受到第三方 Cookie 限制影響，最好的方法是啟用第三方 Cookie 測試標記，然後逐一完成流程。
為確保網站正常運作，請在限制第三方 Cookie 的情況下，測試下列流程：
- 跨網站結帳：測試依賴第三方付款服務供應商的付款流程 (例如「使用 <example-provider> 付款」)。請確認：
- 系統已順利重新導向。
- 付款閘道已正確載入。
- 付款程序可順利完成。
- 使用者會如預期重新導向至您的網站。
- 付款資訊主頁：測試交易資訊主頁小工具是否在第三方 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) 就能存取在頂層環境中，於 payment-provider.example設定的頂層工作階段 Cookie。不過，如果系統封鎖第三方 Cookie，內嵌內容就無法存取自己的頂層 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，打造更個人化的體驗。
減少少數相關網站上的使用者操作障礙
如果商家網站和付款服務供應商都屬於同一間公司，可以使用相關網站集合 (RWS) API 宣告網域之間的關係。這有助於減少使用者摩擦：舉例來說，如果 insurance.example 和 payment-portal-insurance.example 位於同一個相關網站集合中，當在 payment-portal-insurance.example 嵌入內容中要求儲存空間存取權時，payment-portal-insurance.example 會自動取得自己的頂層 Cookie 存取權。
其他實驗性解決方案
另一個可能對此情境有幫助的實驗性 API 是分割式彈出視窗。API 目前處於積極開發階段。
透過分割式彈出視窗，系統會要求使用者輸入憑證，以便在 merchant.example 開啟的彈出視窗中登入 payment-provider.example。儲存空間會由開啟者 merchant.example分割。在本例中，payment-provider.example
嵌入內容將可存取在彈出式視窗中設定的儲存空間值。採用這項解決方案後，使用者必須在每個網站上登入付款服務供應商。
付款連結結帳
部分付款服務供應商提供服務，可產生付款連結，為商家網站算繪自訂結帳頁面。付款連結服務和付款服務供應商的使用者入口通常會實作在不同網域，例如 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資訊主頁會使用頂層 Cookie，並顯示使用者的個人化收益資訊。
如同其他範例，如果停用第三方 Cookie，earnings.example 嵌入內容就無法存取頂層 Cookie。
第一方資訊主頁
如果這三個網域都屬於同一方，建議您同時使用SAA和RWS。透過 SAA，earnings.example 就能在取得使用者授權後存取頂層 Cookie。如果該合作夥伴使用 earnings.example 的網域不超過四個，透過 RWS 聲明網域間的關係，可提供更流暢的使用者體驗。
如果同一方在超過五個網域中嵌入小工具，就無法聲明所有嵌入網站與小工具網域之間的關係，因為 RWS 最多只支援一個集合中的六個網站，包括一個主要網站和五個相關網站。
大規模發布資訊主頁
- 您為第三方網站發布資訊主頁解決方案。
- 您有超過五個網站嵌入資訊主頁小工具。
在這種情況下，earnings.example 應考慮實作 FedCM，做為識別資訊提供者。也就是說，使用者必須以 earnings.example 管理的帳戶登入 dogsitting.example。
FedCM 提供可自訂的 UI，可清楚向使用者說明要分享哪些資訊。透過 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，使用者可以透過身分識別提供者 (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 是分割彈出視窗。使用者在 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 可以允許存取儲存空間，但系統顯示的必要提示可能無法提供理想的使用者體驗。
我們正在探索一項潛在解決方案，專門針對這個用途：具有本機未分割資料存取權的設限框架。這項 API 目前仍在積極開發中，歡迎您參與塑造其未來。親自試用 並提供意見回饋。
說明與意見回饋
如果對本指南所述的使用者歷程或 API 有任何疑問或意見，歡迎提供意見。