Review your cart before checkout
Cart is a current presentation of one or more cart records plus shared ordering context. It can include ordinary business carts, a Gift Cart, reservation-only carts, or grouped carts. A visible row, total, status, or Checkout button is not an authoritative readiness or settlement receipt.
:::warning Important boundary
Opening or refocusing Cart can start order-option, address, cart, socket, plugin, or pending-payment recovery work. Do not refresh, refocus, or enter Checkout to test whether cart state settled.
:::
Cart families have different readiness
| Cart family | Current presentation boundary | What remains unresolved |
|---|---|---|
| Ordinary business cart | Items and one business context can render | Current catalog, fulfillment, address, totals, payment, and Place eligibility |
| Gift Cart | A cart without the ordinary business branch can render | Gift policy, recipient/fulfillment, refresh survival, payment, and order state |
| Reservation-only cart | A reservation can keep a cart visible even without ordinary item rows | Reservation validity, schedule, amount, and Place eligibility |
| Multi-business carts | Several carts can be grouped for display and Checkout routing | Exact membership, homogeneous readiness, per-cart options, and group settlement |
| Pending cart | A separate pending group/status can appear | Provider, confirmation, payment, and order outcome |
No cart family should inherit readiness rules from another without an exact current result.
Cart entry and refresh are effectful
For an authenticated customer, shared order context can read order options and carts when account, language, or project state becomes ready. A manual refresh can start the same work. The read can then reconcile stored country, option, and address state; synchronize an order type; update order options; replace carts; and trigger downstream actions.
Cart focus can also confirm some pending provider-linked carts automatically. These are not passive display reads. Loading completion, a refreshed list, or a changed status does not prove that every effect settled once.
Stored options and address reconciliation
The current source can combine server order options with locally stored order type, moment, city, country, and address context. It can search for a matching saved address and then update local or server options when values differ.
Stored address, saved address record, default address, active order address, cart address, city filter, and business serviceability are distinct. A matched or displayed address does not prove ownership, default status, freshness, or that every cart uses it. Missing or stale local data must not overwrite a newer authorized server/cart revision.
Visible readiness and Checkout readiness differ
| Visible state | Safe interpretation |
|---|---|
| Cart loading is not shown | The page can still be waiting on shared order state or background work |
| Empty state | No retained cart is currently rendered; this does not prove no cart or pending effect exists |
| Cart row visible | The current list retained the cart; it may still be invalid or stale |
| Checkout button visible | At least one locally valid cart exists in that display group |
| Invalid cart appears beside a valid cart | Readiness is heterogeneous; never infer group-wide eligibility |
| Pending label | A cart is in a pending state; provider/order settlement remains separate |
| Error absent | Some order-context or socket failures may not have a dedicated page-level error state |
| Total or status changes | One projection changed; address, options, payment, provider, and order can still differ |
Checkout routing uses current local grouping and validity. It does not perform a complete server, payment, address, student, gift, reservation, or group eligibility attestation.
School, reservation, and Gift Cart branches
- School carts can require a current authorized student before Place. A cart row cannot prove student ownership, dietary context, or assignment.
- Reservation carts can remain visible with reservation state even when their ordinary product shape differs. A visible reservation is not a current booking receipt.
- Gift Cart uses different business, address, delivery, total, and payment branches. It can be omitted by refresh logic that retains only ordinary business carts, so disappearance does not prove cancellation or cleanup.
- Changing order type, address, moment, account, or project can invalidate any of these branches without immediately updating every visible cart.
Grouping can hide heterogeneous state
Cart groups are built from current local status and group references. Valid carts contribute to buttons and totals, while invalid members can remain in the same displayed group. When only one member is locally valid, routing can still use a different first member's reference.
A group can therefore be invalid-first, partially valid, mixed pending/active, or stale. One button, one total, one group label, or one valid member does not prove exact membership or that the chosen Checkout target is correct.
Socket and memo freshness
Cart and order-option socket events can replace, merge, move, or remove cart state. Timestamp comparisons can reject an older event, but they do not prove one authoritative account/project/cart revision across all callbacks.
Memoized cart rows and groups compare only selected fields or references. A change to validity, address, reservation, payment, business, schedule, or other readiness state can remain visually stale when the compared fields do not change. A quiet screen is not proof of fresh cart state.
Checkout and payment handoffs
| Handoff | What it starts | What it does not prove |
|---|---|---|
| Single Checkout | Review for one selected cart reference | Cart ownership, current options, payment support, or order creation |
| MultiCheckout | Group validation, payment, and placement flow | Complete membership or all-member readiness |
| Pending-cart confirmation | Provider/Ordering reconciliation | No charge, payment success, order creation, or exactly-once execution |
| Gift Checkout | Gift-specific checkout branches | Recipient, fulfillment, payment, or order settlement |
| Orders navigation | Current Ordering order presentation | Provider, wallet, refund, group, socket, or plugin completion |
If a handoff returns, closes, errors, or loses its response, keep cart, payment, provider, and order outcomes separate. Do not repeat Checkout, confirmation, payment, or Place to force convergence.
Unknown and partial outcomes
| Situation | Safe interpretation |
|---|---|
| Cart disappears after refresh | Filtering, replacement, completed status, Gift Cart loss, or stale generation may be involved |
| Stored option/address changes | Reconciliation may have written one layer while carts remain stale |
| One group member updates | Preserve each other member as unresolved |
| Invalid first member routes unexpectedly | Local grouping/target selection is unsafe; do not continue |
| Focus changes a pending cart | Confirmation may already be running; do not trigger another focus cycle |
| Socket update conflicts with the screen | Memoized/local/socket revisions disagree |
| Checkout returns without a result | Cart/payment/order settlement is unknown |
| Account or project changes | Reject all prior cart, option, address, provider, and socket callbacks |
Troubleshoot safely
- Identify whether the visible record is an ordinary cart, Gift Cart, reservation cart, pending cart, or multi-cart member.
- Treat missing loading or error presentation as unknown—not success, absence, or readiness.
- Do not refresh, refocus, switch address or order type, or open Checkout as a diagnostic.
- Preserve invalid, partial, heterogeneous, and stale states without moving items, clearing carts, changing payment, or placing an order.
- If the current authorized cart and downstream state remain inconsistent, use an approved support channel with only a value-free state class.
Support reports should use descriptions such as “cart readiness unresolved” or “group members use different revisions.” Do not include cart contents, options, addresses, student or gift data, payment information, business/account/cart/ order identifiers, provider messages, links, or private screenshots.
Privacy and accessibility
- Cart contents, addresses, schedules, student and gift context, reservations, payments, and group relations can be private. Keep them out of documentation and diagnostics.
- Cart-family scope, loading/empty/error/invalid/pending/partial/stale state, expanded rows, Checkout buttons, and destructive or payment consequences need explicit accessible text.
- Group headings and totals must identify their scope without relying on order, color, icons, or spatial position.
- At large text sizes, rows, warnings, and buttons should reflow without hiding invalid or pending state. Focus should remain predictable after socket updates, refresh, navigation, and provider return.
- Screen-reader, keyboard, switch, safe-area, Back, and reduced-motion behavior require current-platform verification; this guide does not certify them.
Recertification triggers
Revalidate after changes to CartList/CartContent grouping, valid/invalid and pending logic, Gift Cart retention, reservation/school branches, order-options mount or refresh, stored option/address reconciliation, socket merge/rooms, memoization, Checkout routing, pending-provider confirmation, payment/Place/ order handoffs, account/project/session teardown, privacy, or accessibility.
Also recertify after changes to API deployment authority, cart/option/address ownership, operation receipts, idempotency, group membership, stale-response cleanup, or unknown-outcome recovery.