Understand order details and status
Order Details can present one returned order together with conditional status, business, customer, product, financial, history, tracking, message, and subtype information. These layers can come from separate reads, events, and providers. Their visibility does not prove that they are equally fresh, complete, authorized, or settled.
:::warning Details are not an operation receipt
A loaded screen, updated status, moving marker, message control, total, payment row, or available action does not certify the order's newest server state or a completed downstream operation. When layers disagree, keep the order state unknown until the owning surfaces reconcile it.
:::
Entry and ownership boundary
Order Details can be reached from an order list/card or another recognized Customer App handoff. Navigation and a supplied order reference are not authorization. The current account, project, session, guest capability, and order ownership must be re-established before private detail is returned.
| Entry state | Safe interpretation |
|---|---|
| Order card opens details | A navigation request targeted one order reference; ownership and freshness remain separate. |
| Recognized internal link or notification opens details | The destination was recognized; authorization and current order state still require validation. |
| Details are unavailable | Do not infer whether the order exists, belongs to another account, or changed state. |
| Account, project, or session changed | Prior detail, socket, map, message, and provider state must not enter the new generation. |
A multi-read, socket, and provider surface
Order Details can combine several independently settling layers:
| Layer | What it can contribute | What it does not prove |
|---|---|---|
| Order read | Status, timing, fulfillment, products, customer/business snapshots, summary, and subtype data | Current ownership, minimality, or one shared revision across every field |
| Supporting reads | Business, message, loyalty, review, or other related state | That supporting data belongs to the same response time or audience |
| Realtime events | Order, message, driver, or tracking changes | Complete replay, correct room membership, newest revision, or cleanup of old listeners |
| Map/image/contact provider | Marker images, map rendering, directions, or phone handoff | Approved disclosure, exact location, destination accuracy, or completed external action |
| Local navigation/state | Back, refresh, caller context, or optimistic presentation | Server settlement or durable operation completion |
A connected channel is not a freshness receipt. A refresh can start new reads while old callbacks remain pending.
Status and fulfillment sections
The current screen can conditionally show status text, progress, timing or ETA, fulfillment type, business information, driver information, delivery or pickup preferences, and current-order notes.
Status, ETA, driver, map, and fulfillment fields can change independently. A terminal-looking style does not prove payment, refund, review, cancellation, delivery, or group settlement. A missing map or driver section does not make the order invalid, and a visible marker does not certify arrival or route.
Customer, business, products, Bill, and history
| Section | Safe interpretation |
|---|---|
| Customer or delivery snapshot | A returned order-associated snapshot; it is not current profile or address authority. |
| Business or driver snapshot | Returned fulfillment context; contact and location require separate current authorization. |
| Product list | Historical order lines and options; current catalog availability or reorderability is not established. |
| Bill or summary | A displayed financial snapshot that can include totals, discounts, fees, tips, payment, wallet, or refund-related rows. It is not a final canonical amount or provider receipt. |
| Order history | Returned status/change records; visual order or completed styling does not prove actor, causality, freshness, or settlement. |
Order Details must receive purpose-minimal fields. Broad customer, student, gift, financial, contact, address, provider, or credential-bearing relations must not be exposed merely because the order exists.
Conditional order subtypes
| Branch | Possible presentation | Important boundary |
|---|---|---|
| Gift order | Gift-related product or fulfillment state | Credential, recipient, redemption, send, and delivery data require strict minimization and separate settlement. |
| Student or school order | Student-associated order information | Minor identity, school, dietary, and health-adjacent context require exact current authorization and must not leak across accounts. |
| Existing custom order | A distinct existing-order estimate or address snapshot when returned data qualifies | Customer custom-order initiation is not established, and an estimate is not a final total. |
| Grouped order | Membership or related-order context owned by grouped-order surfaces | One order detail does not prove complete group membership, totals, placement, or reconstruction. |
| Financial/provider order | Payment, wallet, refund, tip, fee, or provider-return state | Display does not prove correct recipient, canonical amount, provider settlement, or reversibility. |
Each branch can be absent. Absence does not reveal private subtype data or prove that another account, project, or order lacks the branch.
Action and handoff boundaries
| Visible or related action | Owning boundary | Safe interpretation |
|---|---|---|
| Tracking/map/directions/phone | Tracking and native-provider owners | Pre-action only; location/contact/provider completion is not implied. |
| Business or driver messages | Message participant/read owner | Opening can request read state before navigation; it is not Profile CMS Help or proof of contact. |
| Profile Help | Separate Profile CMS surface | Do not infer it from the Order Details life-saver-style control. |
| Reorder | Past-order or Favorite Order card owner | No reliable universal Order Details Reorder control or exact reconstruction is established. |
| Review | Conditional completed-order review owner | Visibility does not prove eligibility, submission, moderation, or publication. |
| Favorite Order | Historical/favorite card owner | Favorite state is not order ownership or reorder authority. |
| Cancellation | Negative status-reference owner | A returned cancellation status is display-only; no Customer App self-service cancellation control is established. |
Do not repeat, press, or substitute another action to resolve a stale or unknown detail state.
Freshness and unknown outcomes
| Observable outcome | Safe interpretation |
|---|---|
| Loading continues | One or more order/supporting reads remain unresolved. |
| Screen shows an error then navigates away | Local error/navigation changed; order existence and server state remain private and unknown. |
| Status changes but Bill, map, or history does not | Layers can have different revisions or event timing. |
| Bill or payment row changes without status | Financial display and order status settle separately. |
| Socket reconnects | Connection returned; room membership, missed events, snapshot reconciliation, and listener cleanup remain unproved. |
| Message action opens another screen | Navigation/read-state request occurred; participant authorization and read settlement remain separate. |
| Review/Reorder/Favorite state differs elsewhere | Each owning surface can be stale or differently authorized; do not infer success. |
| Subtype data disappears after account/project change | Treat prior data as stale and do not copy or act on it. |
| Response is lost or app restarts | Keep detail and any initiated action unknown; do not automatically repeat it. |
Troubleshooting safely
- A missing order or section must not reveal existence or ownership.
- Do not repeatedly refresh, reopen, reconnect, or reuse a private order link to force current state.
- Do not use map, phone, messages, review, reorder, favorite, cancellation, or payment actions as freshness tests.
- Do not infer final totals, refunds, tips, delivery, review publication, group completeness, gift fulfillment, or student context from one visible layer.
- Keep order, contact, address, financial, student, gift, provider, and message values out of screenshots and diagnostics.
- Use only value-free states such as “order detail unresolved” or “financial display differs from status.”
Accessibility and privacy
Status, progress, ETA, loading, error, stale, unknown, customer/business, product, Bill, history, subtype, tracking, message, and action states need clear semantic headings and text rather than color, icons, motion, or map position alone. Controls need names, roles, disabled/busy/destructive state, predictable focus, safe return, 200% text support, reduced motion, and keyboard/screen-reader operation without exposing private values.
These are verification requirements, not a claim of current accessibility, privacy, financial, or provider certification.
When to recertify
Repeat isolated review after changes to entry/deep-link/notification authority; order/supporting DTOs; status/ETA/history; customer/business/product/Bill; gift/student/custom/grouped/financial branches; sockets, rooms, reconnect and cleanup; tracking/maps/contact; message/read Help distinction; reorder/review/ favorite/cancellation handoffs; account/project/session switching; accessibility; or App/components/API authority pins.
Related guides: View active and past orders · Track an order · Understand grouped orders · Review messages · Review past orders again · Understand cancellation status limits