本總覽概述「訂購端對端」流程，以及該流程如何與執行要求網路服務互動。
排序方式
視餐廳提供的服務而定，「訂購端對端」使用者介面會處理與使用者之間的所有互動，因為他們在訂單中加入菜單品項，並決定自取或外送服務。這項功能使用資料動態饋給中的 Restaurant、Service 和 Menu 實體。
下一步是購物車驗證階段，在此階段，使用者建立的 Cart 將由網路服務處理。
結帳動作
「結帳動作」是 Google 第一次對你的網路服務端點發出的呼叫。
您的網路服務應負責驗證 Cart。您必須確認商品的供應情形和價格、計算及退貨稅、折扣與費用，以及驗證訂單寄送地址。
結帳程序如下：
- 訂購端對端服務會將包含
Cart的CheckoutRequestMessage傳送至執行要求網路服務端點。 - 您的網路服務必須根據目前的價格、供應情形和服務供應商驗證
Cart中的項目。接著可以計算總價，其中包括折扣、稅金和運費。 - 如果要求成功，端點會以
CheckoutResponseMessage回應，其中包含未經修改的Cart。您可以在CheckoutResponseMessage中加入FoodErrorExtension，藉此引發處理錯誤，或視需要提出小幅變更。
Cart 通過驗證後，使用者可能會選擇繼續前往資料流的訂單提交階段。
提交訂單動作
使用者下單時，就會觸發提交訂單動作。您的網路服務必須重新驗證購物車、處理卡片權杖 (如果已啟用線上付款功能)，最後更新訂單狀態。
訂單提交程序依循以下順序：
- 訂購端對端服務會將包含
Order的SubmitOrderRequestMessage傳送至執行要求網路服務端點。如要繼續操作，後端必須再執行一次Cart驗證。 您的網路服務會處理
Order中找到的付款資料，通常會執行下列動作：- 執行權杖驗證、詐欺和其他資格檢查。
- 授權並視情況對卡片收費。
您的端點以
SubmitOrderResponseMessage回應，其中包含以下狀態的OrderUpdate：CREATED(「已訂購」購買狀態)、CONFIRMED(「已接受」購買狀態) 或REJECTED(「已遭拒」)。
使用者下單後，會預期您和「訂購端對端」使用者介面都收到訂單狀態更新。您必須將訂單確認電子郵件傳送給使用者。此外，您需使用 Async Order Update API 將相關訂單的更新資訊傳送給 Google。
非同步訂單更新動作
您必須傳送下列事件的訂單狀態更新資訊給 Google，而非您專屬的任何使用者通知：
OrderState的變更，例如從CREATED轉換至CONFIRMED，以及從CONFIRMED轉換至IN_TRANSIT。- 訂單商品異動，例如價格或供應情形。
- 每當使用者觸發其中一個客戶服務管道的支援要求時。
系統會從網路服務端點，做為包含 OrderUpdate 的 AsyncOrderUpdateRequestMessage 傳送更新。Google 會傳回 AsyncOrderUpdateResponseMessage 回應。
序列圖
下圖呈現執行要求動作如何與網路服務互動。按一下即可放大。
設定執行要求端點
訂購端對端動作會使用 JSON 訊息與您的網路服務進行通訊，並處理餐點訂單的處理、確認和更新作業。設計端對端網路服務時，您必須定義網址端點，以接收來自「訂購端對端」服務的要求訊息，並可將訊息傳回 Google 服務。實作項目必須符合下列規定：
- 您的網路服務必須能夠以
POST要求的形式，從訂購端對端服務接收 JSON 訊息。 - 您的網路服務必須提供稱為「執行要求網址」的可公開存取網址端點，您可以在 Actions Center 中指定這個端點。執行要求網址會用於結帳和提交訂單。您的實作項目必須處理這兩種要求。
- 您的網路服務必須能夠使用訊息驗證方法驗證來自 Google 的訊息。
- 網址端點實作必須要能夠透過單一端點處理結帳和訂單執行要求。不能有一個結帳的網址端點和用於訂購提交訂單的獨立端點。
用戶端程式庫
「工具」一節中的用戶端程式碼產生器可依據 Fulfillment API 規格驗證您的網路服務。