Self-POS (Unmanned Checkout): Designing MUSINSA's Offline Customer Experience

In offline stores, customers experience waiting in line at checkout before they experience the products. To solve this problem, MUSINSA introduced Self-POS (unmanned checkout) to separate the options for customers who want to pay quickly from those who want assistance.

The rollout scope was limited from the start. Priority was given to stores of 300 pyeong or larger with monthly sales above a certain threshold, while stores with a high proportion of senior customers were excluded. In terms of staffing efficiency and installation space, Self-POS also allowed the number of units in the same area to increase from 4 to 6, compared to staffed POS.

The first problem that had to be solved was multi-UID. To resolve cases where a single barcode was mapped to multiple UIDs because the same product had an event-specific UID attached, instead of relying on simple exception handling, the product data was set to offline sales availability = N, so that such products would not appear on Self-POS. This moved a problem that used to depend on staff judgment into system and data consistency.

The planning covered not just the current experience but also future transitions. The launch started barcode-based, but the hardware was designed on the premise of a long-term transition plan: Barcode Only → Barcode + RFID Dual → RFID Only. So even though RFID isn't used now, the kiosk already houses an RFID reader, an embedded QR/barcode reader, and even a passport reader.

The frontend treated Self-POS not as a simple screen but as a continuous checkout flow. To keep the flow from breaking even when a non-member signs up during checkout, or when a customer goes back to a previous screen during the payment step to add more items to the cart, state was not scattered across individual screens but maintained as a single state flow. Events from external devices such as the barcode scanner, passport reader, payment terminal, and receipt printer were all handled within this same flow.

In addition, clear entry conditions were defined for each step to prevent moving to the next step in an invalid state.

• Enter the payment step only when the scanned items match the order
• Enter the Tax Free step only when Tax Refund eligibility conditions are met
• Enter the payment-complete step only when the payment status is normal

The reset strategy also mattered. Since multiple customers use the same POS in sequence, idle-time-based reset was necessary, but sections where a flow was actually in progress—such as payment terminal communication or API calls—could not simply be cut off by a timeout. So the design separated sections where reset is allowed from sections that must be held off, pausing and restarting the timer based on the current state.

Errors were separated by perspective—customer versus staff. The customer screen only shows a short, understandable message like "There was a problem processing your order," while the cause and response information are left on the receipt and the staff screen. Network status and device connection errors are pre-detected via events, and logs before and after Tax Free and payment, API errors, and session analysis are all recorded so that it's possible to trace exactly where the flow broke down.

On the backend, rather than separating out a dedicated Self-POS server, a POS-type axis was added on top of the existing MPOS. Flows unrelated to who is operating the device—such as product lookup, inventory deduction, ERP integration, and payment processing—were reused, and type-specific branching was handled only where necessary. In exchange, server-side validation was strengthened accordingly.

On Self-POS, the customer is the operator, so the client cannot be trusted. When an order is created, the server re-validates the amount, membership tier, and quantity, and discounts are also filtered against an allow list depending on the POS type. A key point is that this was implemented via condition composition, so the operations team can change whether a specific discount policy is allowed on Self-POS without a code deployment.

Orders were split into two stages: order creation and order completion. Because physical payment terminal communication occurs between these two stages, it couldn't be completed with a single API. Instead, a token is included in the order-creation response and validated at order completion, ensuring integrity across requests. As all flows converged onto the same server, boundary issues such as Cross-POS refunds also surfaced, and it was corrected so that refund transactions carry information about the POS performing the refund, not the original order.

Ultimately, the biggest part of the Self-POS project wasn't building new features—it was turning rules that staff used to handle implicitly into explicit system-level validation. What remains is a structure that gives customers a fast, simple checkout, gives staff tools for recovery and operations, and gives the system room to accommodate a future RFID transition.