---
sidebar_label: 'Timeouts and fallbacks'
sidebar_position: 2
---

# Deal timeouts and fallbacks

Two tenant-level settings control how Future Ordering behaves when a loyalty integration does not reserve or fulfill its deals in time:

- **Fallback behaviour** - whether Future Ordering continues without discounts or fails the order once deal fulfillment timeouts or reservation required timeouts are reached.
- **Reservation required** - whether a guest is blocked from starting the payment process until a deal has been reserved on the order.

Future Ordering configures both settings per tenant. Decide on them before building the integration, since they determine what a guest experiences when the loyalty system is slow or unavailable.

## Fulfillment timeout

After every change to the order content, the loyalty integration has 30 seconds to calculate discounts and fulfill the deals for the current order version. As long as the deals are fulfilled within that time, the guest can start the payment process with the discounts applied.

:::tip
Treat the timeout as a limit, not a budget. A discounting integration should respond as fast as possible - within milliseconds, or at worst a few seconds - because the guest cannot pay until the loyalty integration has set the discounts.
:::

:::note
The timeout is currently 30 seconds, but may change in the future.
:::

## Fallback behaviour

If the loyalty integration takes longer than the fulfillment timeout, the fallback setting determines the outcome.

```mermaid
flowchart TD
    A[Order content changes] --> B{Deals fulfilled<br/>within 30 seconds?}
    B -->|Yes| C[Guest can pay,<br/>discounts applied]
    B -->|No| D{Fallback setting}
    D -->|No discounts| E[Guest can pay,<br/>no discounts applied]
    D -->|Fail the order| F[Order failed,<br/>guest must start a new order]
```

### No discounts

The guest can start the payment process, but no discounts are applied to the order.

### Fail the order

The order is considered failed. A failed order is an end state: it can no longer be changed, and the guest has to start a new order.

## Reservation required

When reservation required is turned on, a guest cannot start the payment process until one of the following has occurred:

1. A deal has been reserved on the order for the loyalty integration.
2. 30 seconds have passed since the last change to the order content.

If a deal is reserved, the loyalty integration must also calculate discounts and fulfill the deal. The guest can then pay and place the order as normal.

If the 30 seconds pass instead, the fallback setting determines the outcome:

- **Fail the order** - the order is considered failed and the guest has to start a new order.
- **No discounts** - every change to the order content results in a 30 second wait before the guest can start the payment process, and no discounts are applied unless a deal is reserved and discounts are calculated.

When reservation required is turned off, a missing deal reservation does not block the guest from starting the payment process.

:::warning
Combining reservation required with the no discounts fallback gives the guest a 30 second wait after every basket change whenever the loyalty integration fails to reserve a deal. Make sure the integration reserves a deal for every order, including orders it has no discounts for.
:::

## See also

- [Reserving a deal](./reserving-a-deal.md)
- [Fulfilling a deal](./fulfilling-a-deal.md)