Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

This page documents the checkout customer journey and associated API actions.

Contents

What is checkout?

Checkout is the final step in the shopping process, where the customer reviews their cart, sees the total price, enters payment information, and confirms the order.

In our platform checkout consists currently of three steps: the cart page, the payment page and the order confirmation page.

image-20240821-115250.png

This document focuses on the cart page and order confirmation page.

How do you interact with the API?

Our ordering API uses endpoint and webhooks, which follow this principle:

  • We broadcast all changes that impact orders via our webhooks.

  • We make available all information on orders via our endpoints.

API Actions

Make sure all this actions are performant and responses are provided within milliseconds. Long response times will translate into long loading times for guests.

Once guests have added items to cart, they will go to the cart page to understand total price and proceed with the order.

Price webhook and endpoint

When a guest goes to the cart page, the contents of their cart are priced against the POS and the final price is displayed to the customer.

To do that, we trigger the Price Order webhook, which signals that an order needs to be priced by the POS. The payload of the webhook includes the order contents for the selected store id and service mode.

The POS must return the price and availability for each item in the order, the total price and any errors using the Price Webhook Callback endpoint.

These pricing actions will be triggered every time guests access the cart page.

Once guests are happy with their order, they will click on Continue and proceed to the payment page, where they will select their preferred payment method and proceed. The RBI platform takes care of the payment step.

Our API offers some control over payments, but these actions are typically not needed. You can learn more about payments here: [link to payments page].

Commit webhook and endpoint

Once guests have inputted their payment information and click on Place Secure Order, we consider the order placed.

When an order is placed, it needs to be acknowledge by and registered in the POS. Every time an order is placed we trigger the Commit Order webhook. The payload of the webhook includes the order id, total order price and customer details.

The POS must respond to the webhook request by using the Commit Webhook callback endpoint. In this callback, the POS should use the status COMMITTED and indicate if there’s any errors that prevented a successful commit using the errors field.

Errors that prevent a successful commit can be related to menu items availability, store availability, POS technical issue, etc. If the order has been committed successfully, no errors should be sent.

Committing and order does not mean that the order should be prepared immediately. In the Commit Order webhook payload we include the fireOrderInSeconds field which indicates when order should be sent (or 'fired') to the kitchen for preparation.

The fireOrderInSeconds mechanism allows for guests to order for a future time and ensure that orders are only prepared at the right time.

For example,

fireOrderInSeconds value

POS action

60

The order should be sent to the kitchen for preparation 60 seconds after the commit webhook.

0

The order should be sent to the kichen for preparation immediately.

null

The order should be held in the POS until a fire webhook is triggered. You can learn more about the fire mechanism below.

Fire webhook & endpoint

As explained above, there’s a difference between committing an order and sending it for preparation. By ‘firing’ an order we refer to sending the order to the kitchen for preparation.

Only committed orders can be fired.

In the commit webhook payload, the fireOrderInSeconds indicates when the order should be send to the kitchen.

The fire webhook can be triggered for any order that hasn’t been fired yet, regardless of the value of fireOrderInSeconds in the commit webhook payload. This means that the fire webhook can be triggered both when fireOrderInSeconds is null or higher than 0.

The POS must response to the webhook by using the the Fire Webhook Callback endpoint. In this callback, the POS should use the status PREPARING and indicate if there’s any errors that prevented a successful commit using the errors field. If the order has been committed successfully, no errors should be sent.

Order event webhook and endpoint

All order events are broadcasted through our order event webhook. You can use it to validate that the statuses you are providing are being reflected correctly in our system, and that the order is moving through statuses correctly.

These are the supported statuses:

Status

Description

CREATED

Order has been created.

PRICED

Order has been priced. The POS has provided price information for the order.

COMMITTED

Order has been committed. The POS has accepted the order.

PREPARING

Order is being prepared in the restaurant

PREPARED

Order has been prepared and is ready for pickup or delivery.

DONE

Order is done. This is the final state for a successful order.

CANCELED

Order has been cancelled.

ERROR

Error with the order. Customer should be notified and refunded.

  • No labels