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 · Delivery history