---
title: "Driver App history and support contract"
description: "Keep history reads, display, order-specific help, and payment boundaries separate."
canonical: https://docs.ordering.co/docs/developers/driver-app/history-support-contract/
---

# Driver App history and support contract

Driver history is a filtered view of standard Orders data in **Completed** and **Cancelled** tabs. It is not a separate financial ledger or support system.

## Availability

Signed-in Drivers can review past cards when the order-list read returns matching statuses under the current filters and pagination. Cards can appear individually or in a client-derived group and can open individual Order details.

The reviewed Driver App has no dedicated Support route, ticket workflow, universal support button, or universal support URL. Order-specific messages and contact controls belong to separate communication contracts.

## Prerequisites

- Use an authenticated Driver session.
- Confirm the selected **Completed** or **Cancelled** tab, filters, connection, pagination, and cached/offline state.
- Treat card identifiers, customer/business data, messages, and payment display as private operational information.
- Use an approved external support process when the app provides no relevant order-specific action.

## Responsibility boundaries

| Owner                    | Responsibility                                                                                                          |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------- |
| Orders list              | Request Driver-scoped past rows, apply filters/pagination, and expose loading/empty/error state                         |
| History card UI          | Display identifier, date, business, order type, status, group, notification, and cached-state indicators when available |
| Order details            | Read and display the selected order and its owned actions                                                               |
| Communication contract   | Own order-specific messages, clipboard, phone, email, and external-app handoffs                                         |
| Payment display contract | Describe displayed paymethod, cash, events, and totals without settlement claims                                        |
| Support organization     | Own tickets, escalation, response, refunds, disputes, and operational resolution outside this route set                 |

## Inputs and result

History consumes the same Driver-scoped order-list contract used by Orders. The result is a page of rows plus pagination and relation/display data. Client code can group returned rows for presentation and update cards from realtime or offline state.

Stable observable states are:

- loading placeholders;
- populated Completed or Cancelled cards;
- grouped display with expandable members;
- empty result under the selected filters;
- request/network error;
- offline **Last Update** cached-display state; pending-sync remains current-release excluded because offline actions are not mounted; and
- later page availability.

No state proves complete history, latest status, support-case creation, refund, payment capture, payout, or settlement.

## Security and privacy

- Minimize displayed and logged order, customer, contact, address, message, and payment data.
- Never send credentials, reset links, PINs, precise coordinates, or payment details through an unverified support channel.
- A phone, email, map, clipboard, or messaging control is an external or mutable handoff, not a passive history read.

## Limits and failure states

- Completed/Cancelled are configured status categories, not payment states.
- Pagination, filters, cache, grouping, sockets, and API plugins can change the visible set.
- Group headers do not establish one atomic order state.
- Payment labels and totals are display data; refunds, fees, tips, cash handling, provider balances, and settlement require finance-owned evidence.
- Absence of a Support route is authoritative for the accepted release source, but does not define an organization's external support process.
- Deployed backend behavior remains unconfirmed.

## Troubleshooting

- If an order is missing, check tab, filters, pagination, connection, and Last Update before escalating.
- If card and detail disagree, refresh once and record the sanitized order reference and visible states.
- If payment display is disputed, use the approved financial/support process; do not infer settlement from status or totals.
- If no order-specific contact option applies, leave the app flow and use the organization's approved support channel.

**Related guides:** [Communication contract](https://docs.ordering.co/docs/developers/driver-app/communication-contract/) · [Delivery history](https://docs.ordering.co/docs/products/driver-app/history/delivery-history/)