概览

此概览总结了端到端订购流程及其与执行 Web 服务的互动方式。

排序

用户在向订单中添加菜单项并决定是自提还是外送（具体取决于餐厅提供的服务）时，订餐端到端界面会处理与用户的所有互动。此体验由数据 Feed 中的 Restaurant、Service 和 Menu 实体提供支持。

下一步是购物车验证阶段，您的 Web 服务会在此阶段处理用户创建的最终 Cart。

结账操作

结账操作是 Google 对您的 Web 服务端点进行的首次调用。您的 Web 服务负责验证 Cart。您必须确认商品的库存状况和价格、计算并退回税费、折扣和费用，并验证订单送货地址。

结账流程遵循以下顺序：

1. 订购端到端服务会向您的执行 Web 服务端点发送包含 Cart 的 CheckoutRequestMessage。
2. 您的 Web 服务需要根据当前价格、库存状况和服务提供商来验证 Cart 中的商品。然后，计算总价，其中包括折扣、税费和运费。
3. 对于成功的请求，您的端点会响应一个包含未修改的 Cart 的 CheckoutResponseMessage。您可以在 CheckoutResponseMessage 中添加 FoodErrorExtension，以便在必要时提出处理错误或建议进行细微更改。

警告： 并非所有结账操作调用都会产生订单。请勿根据结账操作调用来维护状态。

验证 Cart 后，用户可以选择继续执行流程的订单提交阶段。

“提交订单”操作

当用户下单时，系统会触发“提交订单”操作。您的 Web 服务必须重新验证购物车，处理银行卡令牌（如果启用了在线付款），最后更新订单状态。

订单提交流程遵循以下顺序：

1. 订购端到端服务会向您的执行 Web 服务端点发送包含 Order 的 SubmitOrderRequestMessage。您的后端需要再执行一次 Cart 验证，然后才能继续。

2. 您的 Web 服务会处理 Order 中找到的付款详情，通常会执行以下操作：

   1. 执行令牌验证、欺诈和其他资格检查。
   2. 授权并（可选）从卡中扣款。

3. 您的端点会响应一个 SubmitOrderResponseMessage，其中包含状态为 CREATED（“已下单”购买状态）、CONFIRMED（“已接受”购买状态）或 REJECTED（“已拒绝”购买状态）的 OrderUpdate。

下单后，用户希望从您和 Ordering 端到端界面接收订单状态更新。您必须向用户发送订单确认电子邮件。此外，您还可以使用 Asynchronous Order Update API 向 Google 发送相关的订单更新。

异步有序更新操作

无论您是否向用户发送任何通知，对于以下事件，您还必须向 Google 发送订单状态更新：

1. 对 OrderState 的更改，例如从 CREATED 转换为 CONFIRMED，以及从 CONFIRMED 转换为 IN_TRANSIT。
2. 订单项的更改，例如价格或库存状况。
3. 每当用户通过您的某个客户支持渠道触发支持请求时。

更新会以包含 OrderUpdate 的 AsyncOrderUpdateRequestMessage 的形式从您的 Web 服务端点发送。Google 会回复 AsyncOrderUpdateResponseMessage。

序列图

下图演示了执行操作如何与您的 Web 服务进行交互。点击可放大。

设置执行方式端点

端到端订餐 Action 使用 JSON 消息与您的 Web 服务通信，并处理食品订单的处理、确认和更新。在设计订购端到端 Web 服务时，您必须定义一个网址端点，用于接收来自订购端到端服务的请求消息，并能够将消息返回给 Google 服务。您的实现必须满足以下要求：

• 您的 Web 服务必须能够从端到端订购服务接收 JSON 消息作为 POST 请求。
• 您的网站服务必须提供一个可供公开访问的网址端点（称为执行网址），您可以在操作中心中指定此网址。履单网址用于结账和提交订单。您的实现必须处理这两种类型的请求。
• 您的网络服务必须能够使用消息验证方法验证来自 Google 的消息。
• 您对网址端点的实现必须能够通过单个端点同时处理结账和订单履单。您不能使用一个网址端点进行结账，而使用另一个端点提交订单。

客户端库

您可以使用“工具”部分中的客户端代码生成器，根据 Fulfillment API 规范验证您的 Web 服务。