Retail / operating model
Design the path from product scan to payment, receipt, stock update and store handover across counters, sales floors and back-office operations.
Discuss your projectRetail / operating model
A fixed till can handle the transaction, but it is not the only point where work happens. Associates may check stock on the sales floor, take payment in a queue, print a receipt at a pickup point or apply a label in the back room. The useful question is which role needs which endpoint, and where the authoritative POS or ERP record is updated.
01 / transaction flow
The same store may need several physical setups. These steps describe the data and responsibility that should survive as a customer moves from browsing to payment and collection.
Search the product, scan a barcode or open the customer order while standing away from the counter.
The retail application retrieves price, stock, promotion and customer context from its existing services.
Barcode cannot be read, item is out of stock or the customer record is unavailable. Define a manual search and escalation path.
Add items, quantities, discounts, returns or age and approval checks according to store policy.
The POS remains responsible for pricing, tax, promotion and approval rules; the device presents the next action.
A promotion, return or supervisor override needs approval. Record who can authorize it and what happens if the network is unavailable.
Pass the amount and order reference to the approved payment flow, then wait for an unambiguous success or failure result.
The acquirer or payment service owns authorization. The retail app should store a transaction reference, not treat a visual screen state as proof.
Decline, timeout, duplicate callback or customer cancellation. Define idempotency, retry and reconciliation rules before pilot.
Print a paper receipt where required, provide a digital receipt where supported and record collection or delivery status.
The POS creates the receipt payload and order status. The printer reports completion or failure back to the app.
Paper out, cover open, partial print or reprint request. Test whether reprint is safe and how duplicate receipts are marked.
Update stock, cash, payment settlement and end-of-shift records across the named back-office systems.
The inventory and finance systems reconcile against order and payment IDs; the device should expose exceptions clearly.
A device was offline, a payment settled without a local receipt or a stock update failed. Define the queue, owner and reconciliation report.
For a multi-site rollout, repeat this map for the flagship store, the smallest store, a pickup point and the highest-volume shift. The device recommendation should survive all four conditions.
02 / endpoint design
A model can appear to cover several use cases while the exact variant, printer, scanner, payment configuration or accessory changes the result. Treat every role as a starting point for a named configuration review.
A stable station for cashier-led transactions, receipt output, cash drawer control and optional customer display.
Countertop families are the natural starting point when the store has a fixed till, wired accessories or a dedicated queue position.
Printer width, cash drawer interface, customer display, LAN or Wi-Fi, tax rules and exact regional configuration.
A mobile screen for stock lookup, basket building and payment before the customer reaches a fixed counter.
A mobile endpoint can move the transaction to the sales floor, but printing, battery, scanning and connectivity must be designed together.
Scanner and printer variant, charging pattern, hand strap, battery expectation, Wi-Fi roaming and application screen size.
A payment-focused endpoint where the approved acquiring flow is the central task.
P3 is a useful starting point for a separate payment role or a flow where payment is paired with an existing retail application.
Acquirer, country, payment methods, certifications, key injection, receipt ownership, connectivity and transaction callback behavior.
Fast capture for receiving, cycle counts, shelf work and label output without returning to the till.
The scan and label task is different from checkout. A compact mobile flow can reduce transcription and queue the update to the inventory system.
Barcode symbologies, scan distance, label size, printer connection, stock API behavior and offline queue handling.
03 / software contract
Keep the retail application, payment service, inventory service and device interface separate in the technical brief. That makes it possible to change a model or accessory without rewriting business rules blindly.
Confirm whether the existing Android application already supports the named screen size, OS version and device lifecycle.
Treat barcode and printer output as explicit events with result handling. Do not infer a successful stock update from a local scan or a successful print from a button tap.
Keep card data, authorization and settlement inside the approved payment/acquirer boundary. The retail app should receive the permitted result and reference needed for fulfillment and reconciliation.
A repeatable store deployment needs device naming, policy, app signing, update ownership and a recovery path for a lost or replaced endpoint.
04 / pilot to scale
A showroom checkout can pass while a real store fails at shift change, weak Wi-Fi, a return, a reprint or a battery swap. Stage the test around the exceptions that create operational cost.
PILOT / STAGE / HANDOVER
Use the exact model or variant, app build, printer, scanner, payment configuration and store network that the project intends to buy.
Output: a named configuration and an open-question list.Repeat opening, checkout, discount, return, payment decline, printer failure, offline queue, end-of-shift and replacement-device scenarios.
Output: raw results, known limitations and an acceptance decision.Preload the approved build, enroll policy, pair accessories, label the devices and record serial or asset ownership for each store batch.
Output: a handover pack and a responsibility matrix.05 / public reference
SUNMI publishes examples of commercial device use across retail and payment environments. The reference below helps frame the business question; it does not prove a particular model, acquirer, country configuration or UnitWeave delivery.
SUNMI reports 30% lower cost and 40% less space for the all-in-one device.
The Elzab reference is useful when evaluating whether retail and payment work should be consolidated into a smaller endpoint footprint. Treat the reported outcome as manufacturer material and validate the actual store configuration independently.
On-site supporting briefs
All case language above is based on SUNMI manufacturer material and presented with UnitWeave's delivery perspective as SUNMI's global authorized distributor within the scope of our current authorization. It is not a standalone UnitWeave-owned case study or UnitWeave test result; availability, certification, payment and support terms remain specific to the named project and destination.
06 / retail questions
Not automatically. A common application and device policy can support a standard fleet, but counter, mobile, payment and back-room roles may need different variants or accessories. Compare the highest-volume and smallest store before standardizing.
It can be assessed when the exact app build, Android version, firmware, permissions, screen behavior and peripheral interface are available. A catalog capability is not a compatibility result.
P3 is a payment-focused starting point with manufacturer-listed payment methods, but acquiring, certification, key management and market support must be confirmed for the exact project.
Define it in the POS and payment architecture first. The device can surface a queue or retry state, but it should not invent authorization, stock or settlement rules that belong to the business systems.
Include the exact model and variant, app and firmware versions, accessory pairing, asset naming, MDM state, network assumptions, test results, replacement process and local ownership.
Retail project intake
Tell us how many sites, lanes, associates and back-room stations are involved, which POS or ERP is already in place, and where payment, printing, scanning and offline behavior need proof.
