Loyal customers get refunded the moment the parcel is scanned at hand-over. Everyone else gets their refund only after the item reaches the hub and passes inspection — turning speed into an earned loyalty benefit.
Customer drops off → eligibility gate → instant credit or hub inspection
A returns flow inside the shop app where a customer selects an item to return and — if their loyalty tier and risk profile allow it — receives the refund the instant the parcel is scanned at drop-off, instead of waiting for hub inspection.
The customer, arriving from My orders → Return an item after a delivered order. Ops agents see the same decision as a read-only audit trail; they do not drive this flow.
All data below is mock / sample: customer profile (tier, risk score, 90-day return count, disputed returns, tenure), order items (name, category, price, order date, serialised flag), return reasons, drop-off locations with their scan event types, and tier-level refund caps.
Empty (nothing selected yet), loading (scan in progress), error (scan failed — refund not triggered), success — instant credit, and success — return booked with refund pending QC.
No auth, no payment processing, no backend persistence, no real label generation, no ops back-office, no fraud-model training. Front-end simulation only.
The eligibility engine reacts to tier, risk score and item — switch profiles to see the fallback behaviour.
Select an item above to start the return.
Prototype only — customers, orders, risk scores and scan events are simulated data. No payments are processed and nothing is persisted.