fix(orders): a demo order is indistinguishable from a real one in order history #205

Closed
opened 2026-08-28 11:54:03 -05:00 by bermudalamb · 0 comments
Owner

#195 and #203 made the cart say a demo order is a demo order. The durable record still does not.

A minute after checking out, the customer opens /orders and sees a row: item name, $80.00, status completed, processor demo, date. frontend/src/customer/Orders.tsx:22-42 renders processor as a raw column value under a heading of "Processor" — it is not an explanation, and a customer has no reason to read demo as "this did not happen". STATUS_COLORS at :22-26 has no completed key, so <Tag color={undefined}>completed</Tag> renders neutral, visually identical to a real fulfilled order.

So the fix covers the three seconds after the click and leaves the permanent record unqualified — which is the record the customer will actually go back to when they wonder where their item is.

The backend already carries everything needed: orders.processor = 'demo' is written at backend/src/routes/cartCheckout.ts:192 and selected at backend/src/routes/customers.ts:562. This is presentation only.

Fix

Render processor === 'demo' explicitly — a "Demo (not charged)" tag, or a row-level note. Whatever the wording, it has to be legible to someone who does not know what "processor" means.

Worth deciding at the same time whether a demo order should appear in order history at all, or appear in a separated group. It is a real row in a real table, so hiding it would be its own kind of lie; labelling is probably right.

Found by

Code review of #195 (456e1aa), raised as Important 3 — out of that issue's letter but inside its stated standard, "whatever the storefront tells the customer after the click".

#195 and #203 made the cart say a demo order is a demo order. The durable record still does not. A minute after checking out, the customer opens `/orders` and sees a row: item name, `$80.00`, status `completed`, processor `demo`, date. `frontend/src/customer/Orders.tsx:22-42` renders `processor` as a raw column value under a heading of "Processor" — it is not an explanation, and a customer has no reason to read `demo` as "this did not happen". `STATUS_COLORS` at `:22-26` has no `completed` key, so `<Tag color={undefined}>completed</Tag>` renders neutral, visually identical to a real fulfilled order. So the fix covers the three seconds after the click and leaves the permanent record unqualified — which is the record the customer will actually go back to when they wonder where their item is. The backend already carries everything needed: `orders.processor = 'demo'` is written at `backend/src/routes/cartCheckout.ts:192` and selected at `backend/src/routes/customers.ts:562`. This is presentation only. ## Fix Render `processor === 'demo'` explicitly — a "Demo (not charged)" tag, or a row-level note. Whatever the wording, it has to be legible to someone who does not know what "processor" means. Worth deciding at the same time whether a demo order should appear in order history at all, or appear in a separated group. It is a real row in a real table, so hiding it would be its own kind of lie; labelling is probably right. ## Found by Code review of #195 (`456e1aa`), raised as Important 3 — out of that issue's letter but inside its stated standard, "whatever the storefront tells the customer after the click".
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: bermudalamb/redefined-designs#205