#R01 — POS Hardware & Peripherals

Scope: terminals, receipt/kitchen printing, counter peripherals, in-restaurant networking, build-vs-resell hardware, and a certified v1 matrix. Date: 2026-08-18. Prices are single-unit EU reseller, ex-VAT, unless stated. Labels: [verified] = checked this session with a URL, [known] = confident from training data, [estimate] = reasoned guess.

Bottom line: the hardware is not the hard part — buying it is easy, driving it is not. The real cost centres are (1) the printing stack, which is 8–10 engineer-months of genuinely nasty work and produces ~60% of your support tickets forever; (2) fiscalization hardware in Poland/Romania, which invalidates the "just print ESC/POS" assumption and is a market-entry gate, not a feature; (3) the fact that a browser cannot open a TCP socket, which forces an architectural decision (native app vs. pull-based cloud printing) in week one. Reselling commodity hardware is correct and the legal argument for it is stronger than the cost argument.

#1. Terminal options

#1.1 The four archetypes

#1.2 Concrete price anchors (checked 2026-08-18)

Source: shopnfc.com EU catalogue, single-unit prices [verified].

Distributor reality: these are retail. As a registered reseller with a distributor (Jarltech, Logiscenter, ITG Store, Concept Data, Sunmi's regional distributors) expect 28–40% off list at 50+ units/yr [estimate], and Sunmi will quote directly at 100+ units. Budget your hardware GM at 15–25% after freight, spares, and DOA.

#1.3 The GMS / EDLA trap — read this before choosing Android

Google requires an EDLA (Enterprise Device Licensing Agreement) for GMS on dedicated/purpose-built devices; that is why the Sunmi catalogue splits into "no GMS" and "GMS EDLA" SKUs at a EUR 30–260 delta [verified from price table]. Consequences on a non-GMS device:

• No Firebase Cloud Messaging. Your push channel for "new online order arrived" must be your own persistent MQTT/WebSocket connection with your own reconnect/backoff/doze handling. Budget 1.0 eng-month for a reliable foreground-service transport, plus battery/thermal testing.
• No Play Store distribution → you ship APKs by MDM/OTA yourself, plus your own update rollout, staged rollback, and signing infrastructure.
• No Google Sign-In / Maps / Play Integrity / SafetyNet.
• WebView and Chrome are frozen at the ROM's version unless the vendor ships an update. On a 2023 Sunmi ROM you can be stuck on a WebView with no ResizeObserver edge cases fixed, no Intl.Segmenter, etc. If your POS UI is a WebView, this is a genuine product risk.

Recommendation: buy GMS/EDLA SKUs even at +EUR 100–250/unit for anything running your app. Non-GMS is acceptable only for KDS and customer-facing displays.

#1.4 Environmental reality: spills, heat, glare, gloves

#1.5 Lifespan and warranty

Refresh planning: assume you re-certify your hardware matrix every 18 months because SKUs go EOL. Budget 0.25 eng-months/quarter forever for matrix maintenance.

#2. Receipt and kitchen printing (the hard part)

#2.1 Protocol landscape

#2.2 Recommended printer SKUs and prices

#2.3 Interface decision matrix

#2.4 Cloud-pull printing: Epson Server Direct Print vs Star CloudPRNT

Both invert the connection: the printer polls your HTTPS server for jobs. This is the only clean way to print from a browser-based or cloud-only POS.

Architectural consequence: if you go browser-first, a 3–10 s delay on the guest's receipt at the counter is a UX wart your competitors (native apps + port 9100) don't have. Kitchen tickets don't care. Recommended hybrid: native app → raw 9100 for the receipt printer at the till; CloudPRNT/SDP for every remote kitchen/bar printer and for the "print from the back office in the browser" case.

#2.5 What is genuinely impossible from iOS and from a browser

Three land mines here, each of which has killed a POS roadmap:

1. Mixed content. Your PWA is on HTTPS. The printer speaks HTTP on a RFC1918 address. Browsers block it, and you cannot get a public CA cert for 192.168.1.50. Workarounds: (a) a local agent on localhost with a real cert for a wildcard *.local.yourdomain.com resolving to 127.0.0.1 — this is what several vendors do and it costs you an installer per OS; (b) cloud-pull printing; (c) ship a native app. There is no fourth option.
2. iOS multicast entitlement. Discovery of printers by Bonjour from an iOS app needs an Apple-approved entitlement. Application turnaround is weeks and can be refused. Plan a manual-IP-entry fallback from day one.
3. Chrome's Private Network Access restrictions have been tightening; a public HTTPS page reaching a private IP is on a deprecation path [known — verify current Chrome policy before committing].

#2.6 Discovery and addressing

#2.7 Routing rules (item → station)

Minimum viable model that survives contact with a real kitchen:

PrintStation  { id, name, printer_ids[], fallback_station_id, language, layout_template }
RoutingRule   { menu_category_id | menu_item_id | modifier_group_id, station_id, priority }
Ticket policy { consolidate_by: station|course|seat, fire_mode: on_send|on_course_fire, reprint_marks }

Requirements that always come up and that you must not defer:

• Course firing. Starters print now; mains print when the waiter fires course 2. Without it you cannot sell to any table-service restaurant above a bistro.
• Multi-station items. A burger prints to Grill; its side salad prints to Cold; the expo/pass gets the whole order. One item → N printers.
• Modifier inheritance. "No onion" must reach the same station as the burger, in bold/red.
• Kitchen language ≠ guest language. In PL/CZ/DE the kitchen brigade is frequently Ukrainian-speaking. Per-station language on menu item names is a genuine differentiator in this beachhead and costs you a translation column, not an architecture.
• Void/modify tickets. A cancelled item must print a clearly marked VOID slip at the station that got the original, or the kitchen makes it anyway.
• Reprint with a marker. Every ticket carries a short job ID; reprints are stamped ** REPRINT **.

#2.8 Failover, deduplication and paper-out

Detection. For raw 9100: DLE EOT 1..4 returns Automatic Status Back bytes — printer status, offline cause, error, and paper sensor (paper near-end vs paper-end) [known]. Poll every 20–30 s per printer. For CloudPRNT/SDP, status arrives free in every poll — a strictly better health signal.

Failure taxonomy and response:

Fallback chain (configurable per station): primary printer → secondary printer at same station → expo printer → KDS screen → manager tablet push notification. The last two rungs are what actually saves service.

Duplicate suppression is the hard bit. With raw 9100 you get no job-level ack: the printer may have printed the ticket and then lost power before your socket flushed. You will either double-print or lose tickets. Mitigations that work in practice:

• Assign a monotonically increasing per-station job number, print it on the ticket, and let staff resolve visually ("we already have #412").
• After a socket error, do not auto-retry silently. Surface "Ticket #412 may not have printed — Reprint?" to the person who sent it.
• With CloudPRNT/SDP, the printer acknowledges the job ID after printing — genuine at-least-once with dedupe. Another argument for the pull model on kitchen printers.

#3. Peripherals

#3.1 Cash drawer

• Driven from the printer's DK port (RJ11/RJ12, 6P6C) with ESC p m t1 t2 (m=0 → pin 2, m=1 → pin 5). No separate driver, no separate cable to the PC. [known]
• Voltage mismatch is the classic destroyed-hardware incident: Epson/Star DK ports drive 24 V solenoids; many cheap drawers are 12 V. A 12 V drawer on a 24 V port burns out; a 24 V drawer on a 12 V port simply doesn't open. Specify the drawer with the printer, always.
• One DK port = one drawer. Two drawers (two cashiers, one printer) needs a splitter box (~EUR 60) or a second printer. Two-drawer setups also need cash-accountability logic in software.
• Drawer-open sense line is readable via ASB → log every drawer open with a user ID and correlate against no-sale/void events. This is a genuine loss-prevention feature that sells; it costs ~0.2 eng-months.
• SKUs: APG Vasario 1616 (EUR 110–150), Safescan SD-4141 (EUR 70–100), Star CB-2002 (~EUR 100) [estimate].

#3.2 Legal-for-trade scales — a compliance trap, not an integration

Used for salad-by-weight, deli counters, bakeries, self-serve buffets.

• EU: the instrument must be MID-conformant (Directive 2014/32/EU, Annex NAWI) / OIML R76 class III, with CE + M marking and a metrology verification. US: NTEP CoC + NIST Handbook 44.
• The trap: if your software takes the raw weight and computes the price shown to the customer, the price-computing function may fall inside the legally-relevant software and you inherit WELMEC 7.2 software requirements (checksum-protected legally relevant code, audit trail of legally relevant parameters, separation of legally relevant and non-relevant software, documented version identification) [known — verify with a notified body before scoping]. That is a notified-body engagement, not a sprint.
• v1 rule: only integrate scales that are themselves price-computing and legal-for-trade with their own display (Dibal, Bizerba, CAS PD-II, Mettler Toledo Ariva). The POS receives a completed line item (weight + unit price + total), never computes it. That keeps you out of the legal metrology scope.
• Protocols: mostly RS-232 ASCII (Toledo/8213-style, CAS, Dibal proprietary), a few USB-HID scales using HID Point of Sale Usage Page 0x8D — those are readable from Chrome via WebHID, which is a pleasant surprise for a browser back office [known].
• Cost: EUR 400–1,500/scale, plus a periodic re-verification obligation (typically annual/biennial, per member state).

#3.3 Barcode scanners

• HID keyboard-wedge is the whole answer for v1. Zero integration, works on iPad (Bluetooth HID), Android, Windows. Configure a CR suffix, optionally an STX prefix, via the manufacturer's config-barcode sheet.
• App-side detection: buffer keystrokes and treat a burst with <30 ms inter-key gaps ending in Enter as a scan, not typing. Handle focus stealing — the most common bug is scanning into whatever field happens to be focused.
• SKUs: Zebra DS2208 (EUR 90–130), Honeywell Voyager 1450g 2D (EUR 100–140), Datalogic QuickScan QD2430 (EUR 90–120) [estimate].
• Also plan camera scanning on tablets/handhelds for loyalty QR and e-receipt codes — Sunmi V3 Mix / L2s Pro ship a real 2D engine, which beats camera scanning by ~3× in speed.

#3.4 Prep and label printers

Practical: target ZPL for anything serious (Zebra + Brother TD emulation), and add Brother QL only when a customer needs the small DK label form factor. HACCP date-labelling is a real EU obligation for prepped food and a low-effort upsell (~EUR 8–15/site/month).

#3.5 KDS and bump bars

Bump bar — do not skip:

• Logic Controls KB1700 (USB HID, programmable, spill-resistant): EUR 250–350 [estimate]. Industry standard.
• Budget alternative: a EUR 15 USB numeric keypad with printed key caps. Works. Looks amateur. Sells anyway to a 1-site café.
• Foot pedal or a large physical "BUMP" button for the fryer station.
• Implementation is trivial (HID key events → actions) but you must support key remapping per site and lock the KDS app so the keypad can't nav away.

KDS software requirements that surprise people: order age colour thresholds, all-day counts, recall of bumped orders, split-by-station vs. expo view, prep-time prediction, and screen-off/on scheduling so a 22" panel doesn't burn in with a static header.

#3.6 Customer-facing displays, kiosks, handhelds, pagers, caller-ID

#4. In-restaurant networking — why "the printer is offline" is ticket #1

#4.1 The physics

A commercial kitchen is a worst case for 2.4 GHz: stainless steel surfaces everywhere (specular reflection + multipath), a microwave oven radiating in channels 6–11, walk-in fridges as Faraday cages, and tiled walls. A dining room 8 m away can be fine while the pass is at −85 dBm. 5 GHz has better spectrum but worse penetration through the brick/tile wall between the dining room and the kitchen.

Rule: anything that prints gets a cable. This one policy removes the largest single class of support tickets.

#4.2 Reference site network (single-site, 40–80 covers)

#4.3 VLANs and PCI scope

Minimum three VLANs: POS (terminals, printers, KDS), PAY (card terminals), GUEST (client isolation on, rate-limited, no route to POS/PAY). Segmenting the payment terminals materially reduces PCI DSS scope; PCI DSS v4.0.1 is in force with the previously future-dated requirements mandatory since 31 Mar 2025 [known — verify exact SAQ applicability with your acquirer]. With a semi-integrated / P2PE terminal, the merchant typically lands on SAQ P2PE or SAQ B-IP instead of SAQ D, which is the difference between a 30-question form and a 300-question one.

Practical caveat: 70% of your SMB sites will have an ISP-supplied all-in-one router with no VLAN support. Your two options are (a) ship your own router as part of the bundle — the right answer, EUR 130–250 — or (b) accept a flat network and design for it (device-level auth, TLS everywhere, no trust in the LAN).

#4.4 Ukraine/CEE-specific: power

Ukrainian sites experience scheduled and unscheduled outages. A POS that dies with the mains is unsellable there. Required stack:

• Offline-first POS — orders, payments-by-cash, and printing must work with zero internet. This is an architectural requirement that reaches into every layer of the product, not a hardware item.
• UPS on router + switch + one till + one kitchen printer (~250–400 W for 2–4 h): APC BE850G2 (EUR 120) for a short bridge, or an EcoFlow River 2 / River 3 (EUR 220–350, 256–300 Wh) for multi-hour [estimate].
• 4G/Starlink failover.
• Terminals with internal batteries (handhelds, Sunmi V-series, iPads) keep selling when the AIO doesn't. This is a real reason to favour tablets/handhelds in the UA beachhead.

This is a genuine competitive edge: Lightspeed/Square/SumUp do not design for a 4-hour blackout. Say so in the sales deck.

#4.5 Root-cause ranking for "the printer is offline" [estimate, from category experience]

Support economics: at 0.6–1.2 hardware tickets per site per month and 15 min average handling [estimate], one support FTE covers roughly 400–700 sites. Build remote diagnostics (printer status page, "send test print" button, network self-test, one-tap log upload) before you have 100 sites, or your gross margin evaporates into a phone queue.

#5. Build your own hardware? (Short answer: no. Long answer below.)

#5.1 What "build your own" actually means

Three tiers, increasing cost:

ODM candidates: Sunmi, PAX, Centerm, iMin, Telpo, Urovo, Newland, Feitian. All will do T1; Sunmi and Telpo are the most cooperative with T2 at small volumes [estimate].

#5.2 Indicative BOM for a 15.6" Android AIO with printer [estimate]

Against a Sunmi D3 Pro at EUR 605 retail / ~EUR 400 at reseller price [verified retail, estimated reseller], your saving at T1 is near zero; at T2/T3 it is maybe EUR 60–120/unit — which you recover only after 3,000–8,000 units, before counting the costs below.

#5.3 The regulatory bill you inherit the moment you put your brand on it

This, not the BOM, is the argument.

If you resell under the OEM's brand, essentially all of the above stays with Sunmi/Epson/Elo. That is worth more than EUR 100/unit of margin to a 4-person company.

#5.4 Operations you also inherit

• DOA rate 1–3%; annual failure rate 3–8% for printers and AIOs [estimate]. At 500 installed sites × 2.5 devices, that's 40–100 RMAs/year.
• Spare pool at 5–8% of installed base, in-region. At 500 sites that's ~60 units of dead capital, ~EUR 30–45k.
• RMA to China is 3–8 weeks door-to-door. You must ship a replacement first and eat the float, or your customer is down for a month.
• Working capital. 300 sites × EUR 1,400 hardware = EUR 420k of inventory + in-transit. For an S1 bootstrapped team this alone ends the discussion. Even at S2 (EUR 5–10M), spending EUR 500k on inventory instead of 4 engineers and 3 salespeople is a bad trade.
• Firmware ownership. Own hardware means owning Android security patches, bootloader, and OTA — 1.5–3 engineer-months/year, minimum.

#5.5 Who builds and why

You are software-led at v1 and you are not an acquirer. Resell. Revisit only if (a) you cross ~3,000 terminals/year, and (b) you become the merchant-of-record on payments so hardware can be subsidized, and (c) you have a dedicated hardware/ops hire. All three, not any one.

One nuance where the brief is slightly wrong: don't just "certify commodity hardware" — sell a branded bundle (your box, your quick-start card, your pre-provisioned config, your SIM, your support number) of OEM-branded devices. You get the perceived integration of own hardware and none of the CE/GPSR/CRA/WEEE liability, because the device is still legally Sunmi's.

#6. Recommended certified hardware matrix — v1

#6.1 Tiers

Tier A — "Café / bar, 1 till" (target BOM EUR 1,200–1,700)

Tier B — "Full-service restaurant, 2 tills + kitchen" (target BOM EUR 3,500–5,500)

Tier C — "Small chain / high-volume QSR": swap the front printer for TM-T88VII (EUR 400–480), add a second KDS, add Star SP742 HI X at the expo, add a Zebra ZD421d for takeaway labels, add a managed UniFi gateway.

#6.2 The explicit "we do NOT support in v1" list

Publishing this saves more engineering time than any feature.

• Wi-Fi-only printers (LAN or USB only; Wi-Fi is "unsupported, best effort")
• Serial-only legacy printers without a network bridge
• Bluetooth printers on iOS that are not MFi-certified
• Coaster pagers (use SMS/WhatsApp)
• USB caller-ID modems (use SIP webhooks)
• Non-price-computing scales (legal metrology risk)
• Self-order kiosks with unattended payment (v2)
• Windows POS terminals as primary — except as a fiscal-printer bridge in PL

#6.3 The elephant: fiscalization changes the printer matrix per country

This is hardware policy, not just tax policy, and it must be settled before you buy anything.

Impact on this document's recommendations: the "Epson TM-m30III everywhere" plan holds in UA, CZ, DE, AT, FR, and the US. It does not hold in PL, RO, or IT, where a certified fiscal printer sits between your software and the paper. Budget 4–8 engineer-months per fiscal-hardware market on top of everything in §7.

#Build effort

Assumes S1 (founder + 2–4 engineers, AI-assisted). AI assistance helps a lot with the ESC/POS/ZPL/XML plumbing and almost not at all with device-specific quirks, which require the physical device on a desk. Budget EUR 6–10k for a device lab (one of every SKU in §6.1 plus 3–4 clones) — without it these estimates are fiction.

Calendar time, S1 (3 engineers, ~1 on hardware full-time + shared): the 24 eng-months of core work is 9–12 calendar months with one dedicated hardware/integrations engineer plus part-time help — and it is genuinely parallelizable with the POS app work. S2 can compress to 5–6 months with 3 dedicated engineers plus a field/ops hire, but not below that, because device quirks are discovered serially at real sites.

#Open questions / what would change this answer

1. Which country is the true beachhead? If it's Poland, fiscalization hardware is the first thing built and adds 4–10 eng-months plus an external certification dependency — that reorders the entire roadmap. If it's Ukraine (PRRO, software-only fiscal), the hardware plan in §6 is correct as written and you can ship in 9 months. Verify: current GUM requirements and approval timeline for kasy wirtualne in gastronomy; current ДПС PRRO API and whether the software-RRO route still requires no certified device.
2. Browser-first or native-first? This is the single highest-leverage decision in the document. Browser-first forces cloud-pull printing (Epson SDP / Star CloudPRNT), which caps your printer matrix to those two vendors' supported models and adds 0.2–10 s receipt latency. Native-first (iOS + Android apps) unlocks raw 9100 and every clone printer, at the cost of app-store distribution and two more codebases. Verify: current Chrome Private Network Access policy and whether Apple has granted multicast entitlements for POS use recently.
3. Do we become a payment facilitator / merchant of record? If yes, own hardware becomes defensible (subsidize the terminal against interchange, Square/SumUp model) and §5's conclusion flips at ~3,000 units/yr. If no, resell forever.
4. Exact reseller pricing. The EUR figures in §1.2 are single-unit retail [verified]. Real distributor pricing at 50–200 units/yr is the number that decides whether hardware is a 15% or a 30% GM line. Verify: get quotes from Jarltech, Logiscenter, ITG Store, and Sunmi EU direct for a 100-unit annual commitment on D3 Pro GMS, TM-m30III, TM-U220II, TSP143IV.
5. Cyber Resilience Act applicability. If CRA obligations extend to POS software placed on the EU market — not just branded devices — the "just resell" escape hatch shrinks and you owe SBOM + vulnerability handling + 5-year support regardless. Verify: current CRA guidance on SaaS vs. "products with digital elements," and the Sep 2026 reporting-obligation date.
6. Legal metrology. Whether a POS that receives weight from a legal-for-trade scale and prints it on a receipt is itself in scope of WELMEC 7.2 varies by member state's interpretation. If it is in scope even for our receive-only design, weight-based selling becomes a v3 feature, not a v1 one. Verify: with a notified body (e.g. NMi, PTB) in the target market before promising a deli-counter customer anything.