Multi-channel orders need one order history

What it is

One account may order in an app, on the web, in a mini-program, at POS, or by phone. Aggregation means those orders enter one “My orders,” with one set of states and after-sales, not per-channel lists that do not know each other. It is not invoice versus till receipt, and not whether one confirmation’s text can be edited. It is where people go to find “what I bought.”

Why it happens

Memory indexes by “I bought,” not by client. Split histories force recall of which surface was used; failed recall sends support a number that may belong to another channel. A store ticket that exists only on paper cannot be claimed online. Channels are often different order stores; aggregation needs an account-level key and a conflict policy (one payment intent must not render as two rows). Binding a guest store ticket to an account later is repair, not the default.

Studying it

Place one order on each of two channels, then give only one client to find both and start after-sales on one. Compare fully isolated lists with an account-level merge.

Independent variables: merged or not, whether a store ticket can bind later, whether duplicate sync creates two rows. Dependent variables: time to the target order, wrong channel, support because it could not be found.

A one-client lab will not show aggregation. Use at least two surfaces. “Total order count is right” is not success—the count can match with duplicate rows.

Where it stops holding

Shops under different legal entities on a marketplace should not become one merchant bag, but the consumer account should still have a cross-shop history. A guest paying in store with no phone cannot aggregate; lookup is by ticket number. A partner channel (a delivery platform placing the order) that is legally another merchant must label source, not pretend it is this shop’s POS.

Applying it

• Signed-in order lists merge all first-party channels, each row labeled App / store / web.
• Offer binding a ticket or payment id to the account; after-sales then uses the same set.
• Deduplicate sync: one payment intent, one row.
• Verify: web order, app order, bind a store test ticket; all three rows on any surface’s “My orders,” each able to enter after-sales. Missing or duplicate rows fail aggregation.

Related

• Within the group: H7.12.1 E-invoices and purchase receipts serve different legal uses · H7.12.3 Receipt content must not be rewritten after issue · H7.12.4 Confirmations across channels must stay consistent
• Adjacent: H7.05 Order confirmation · H6.06 Multi-device sessions · H7.07 Refunds and after-sales
• Search terms: omnichannel order history · order aggregation · POS plus app