如要讓使用者結帳，請實作原生結帳整合。這包括建立標準 REST API，讓 Google 能以程式輔助方式，透過伺服器管理結帳程序。這種方法可為使用者提供最流暢的體驗。Google 一開始會為買家顯示使用者介面，日後則計畫支援更多代理程式體驗。
結帳程序
如要進行原生整合，您必須建構 RESTful API，供 Google 呼叫以建立及管理結帳工作階段。
整體流程如下：
- 建立結帳工作階段：使用者和 (選擇性) 服務專員會進入迴圈，將項目新增至工作階段。
- 移交給 Google UI：使用者決定結帳後，代理程式 (如果已參與互動) 會將控制權移交給 Google UI (並傳遞結帳工作階段資料)。
- 手動結帳：使用者現在只需與 Google UI 互動，即可填寫敏感的訂單履行和付款詳細資料，並提交訂單。代理程式不會參與這部分，確保確定性。
- 完成及退貨：Google 使用者介面會顯示「感謝你」頁面，確認訂單。使用者也可以選擇重新導向至服務專員，服務專員可能已收到購買完成通知。
結帳工作階段狀態生命週期
在使用者完成結帳流程的各個步驟時，您必須更新結帳工作階段 status，反映目前的狀態。工作階段會經歷下列生命週期：
incomplete：工作階段建立時的初始狀態。這表示缺少必要資訊 (例如運送方式、稅金或使用者詳細資料)，或是未計算相關費用。ready_for_payment：使用者更新運送地址後，您計算運送選項和總計金額時，但付款方式尚未確定前，請使用這個狀態。ready_for_complete：在完整結帳物件補水期間使用的狀態，一旦選取付款方式並驗證所有訂單詳細資料，就會使用這個狀態。completed：成功處理付款並下單後，系統傳回的最終狀態。canceled：如果結帳工作階段已中止，系統會傳回這個狀態。error：如果發生無法復原的商業邏輯錯誤，導致無法結帳，系統會傳回這個狀態。這項狀態適用於 UCP2026-04-08以上版本。
多項商品結帳程序：
Google 現在支援在單一結帳階段中加入多個不同的明細項目。 一般流程如下：
- 使用者從啟用 UCP 的介面啟動結帳程序 (例如點選產品上的「立即購買」)。
- 系統會發出
POST /checkout-sessions呼叫，其中包含line_items陣列中的所有相異項目。line_items陣列會包含每個結帳項目的個別物件。 - 使用者可以透過
PUT /checkout-sessions/{id}呼叫更新付款方式、履行詳細資料或套用折扣。 - 使用者點選「使用 GPay 付款」按鈕時，系統會發出
POST /checkout-sessions/{id}/complete呼叫。
驗證
如要進一步瞭解如何保護 Native Checkout API 端點，包括支援的驗證方法 (例如 API 金鑰和 OAuth 2.0)，請參閱「驗證與安全性」指南。
開發人員工具
為協助您導入 Native Checkout API，通用商務通訊協定 GitHub 存放區提供下列資源：
- UCP GitHub 存放區：瀏覽主要存放區，取得完整說明文件、規格和社群資源。
- SDK：使用軟體開發套件加快整合速度。 我們提供各種語言專屬的 SDK，包括：
一致性測試：使用一致性測試套件，根據 UCP 規格驗證 API 端點。
確保導入作業符合必要標準和行為。
強烈建議使用這些工具，簡化開發和測試程序。
服務等級目標
下列服務等級目標 (SLO) 適用於 Native Checkout REST API 端點。與 Google 整合的商家應達到這些 API 效能和可用性目標。
| 端點 | 可用性 | 延遲時間 (第 50 個百分位數) | 延遲時間 (第 95 個百分位數) |
|---|---|---|---|
POST /checkout-sessions (建立) |
>= 95% | <= 1 秒 | <= 4 秒 |
PUT /checkout-sessions/{id} (更新) |
>= 95% | <= 1 秒 | <= 5 秒 |
POST /checkout-sessions/{id}/complete (已完成) |
>= 95% | <= 6 秒 | <= 10 秒 |
第 50 個百分位數的延遲時間表示，至少有 50% 的要求預計會在該時間內完成。第 95 個百分位數的延遲時間表示至少有 95% 的要求預計會在該時間內完成。
後續步驟
查看結帳 API 酬載，以及 UCP 版本的技術實作詳細資料：