Fulfillment Overview

This is a brief overview, for more in-depth information check the partner API definition documentation and the openAPI docs.

Checkout Order

In this scenario, Google would provide Order Direct a Checkout Intention where the Cart details would be provided. This message will then be
forwarded to the partner. This includes which products, add-ons and service (take-away or delivery) for the order.

According to the documentation, the endpoint should be responsible for the following:

a ProposedCart which is the received Cart

Delivery time estimation
Delivery fees
Taxes, discounts information
Payment Options (provided by Google or other options)

If the checkout request is invalid but it is recoverable (e.g. items' price changed), the response should include:

a new ProposedOrder with the changes

If the checkout request is not valid but it is not recoverable (e.g. restaurant is closed), the response should include:

why the checkout is refused

If the Partner is unreachable or any other error happens, we take action and reply to Google on partner's behalf, claiming service unavailability.

On all other scenarios, the message replied from the partner would be forwarded to Google as a Checkout Response.
Other technical considerations

Prices provided on a Checkout request are not structured the same way as provided on the inventory feed
A response should be provided within a 5-second frame.

Submit Order

With this call, Google is informing Order Direct that a customer decided to order a previously checked out order. Additionally, payment information
is provided. In order to properly handle this request, the endpoint should:

verify transaction eligibility such as card and fraud detection

Create an order with the partner
Authorize and optionally charge the card
Respond with one of the following statuses:
CREATED: No problems were encountered when processing the submit order request, but provider has not yet confirmed the
order.
CONFIRMED: No problems were encountered when processing the submit order request, and the provider has confirmed the
order.
REJECTED: There was a problem with the order and it could not be created (e.g. problem with payments

Other technical considerations

Not all successful checkout responses trigger a Submit order request

A response should be provided within a 5-second frame

Update Order
Once the order has been created, there is the opportunity to update its state. Common reasons for sending an update include:

A change in the state of an order

The order can no longer be fulfilled
A change in the price of a menu item included in the order
The estimated fulfillment time for the order is available or has changed
A new way for a customer to manage their order becomes available (i.e. customer support or restaurant phone number)
The receipt for the order becomes available

The update flow would be triggered by the partner as they would be the ones with the needed information for it such as delivery time estimations
or if the order could not be fulfilled anymore, for example.

Other technical considerations

It's not needed to provide all states and transitions but a final state is needed on every order (CONFIRMED, REJECTED, CANCELLED)
If the update is successful, there will be a respond with status code 200 with an empty body.