Android POS terminal OEM: what to specify before you brand it

Time：2026-10-04 Views：0

A branded Android POS terminal is not one product. It is a retail computer, a printer, a payment device, a barcode reader and a cash-drawer controller sharing one housing, one power budget and one firmware image — and each has a different supplier, a different failure rate and, in the payment case, a completely different certification burden. Resellers, payment companies and chains that badge hardware get quoted for the first two and discover the other three in the field.

The display decision, and what the second screen is for

One facing-operator display is the default and it is defensible. A customer-facing panel adds a screen whose job is not specification-related: it is trust. A customer who watches each line ring up, sees the total before paying and gets the tip prompt facing them rather than sideways disputes less and tips more, which is why the second panel pays for itself in food service and often nowhere else.

What it costs you is engineering: a second display path, so more draw and more heat behind a counter housing with no fan; a second surface to protect and clean; geometry that clears the operator's head and the card reader; viewing angle against a sunlit window; and a privacy rule, because a customer display showing a loyalty balance or a partial card number has created a data exposure with no software involved. If that panel needs touch you have bought a self-service device, with a different cleaning regime and a different vandalism assumption.

The printer decides the queue

In a counter device the printer determines whether the line moves. Speed matters, but paper path and access matter more: a jam is not a hardware defect, it is fifteen seconds of queue nobody budgeted for. So the argument with the OEM is maintenance access — a lid that opens with one hand and stays open, a visible path with no hidden roller, a guide that returns to position without fiddling, a cutter whose blade is a serviceable item rather than a unit swap, and an end-of-paper condition reported before the ticket is requested rather than after.

Width is your layout decision: 58 mm and 80 mm mechanisms differ in characters per line, roll capacity and whether a cutter exists at all, and a mechanism built into a handheld fixes the width for you. EDOO's EP600 descriptor states a 120 mm/s thermal printer and EP520's label printer 80 mm/s — class figures worth benchmarking against your ticket length. Ask for the paper specification (width, maximum outer diameter, core, stock thickness) and for duty cycle and cutter life with test conditions, because a duty-cycle number without conditions is a guess.

"NFC" is not one thing: three payment paths, three burdens

Any listing that says "NFC payment" is hiding which of these you are buying.

Architecture	What you build	Certification burden that lands on you
Tap-to-pay on the device: app plus host card emulation and an acquiring SDK's contactless kernel	Checkout app, payment integration, attestation	The heaviest, and yours: PCI MPoC for mobile acceptance, software attestation and trusted-payment-navigation rules, EMVCo contactless L3 with the scheme through your acquirer, key injection in a certified facility
A certified PIN pad or POI module attached to the terminal	Integration and UI, not the sensitive path	Largely bought in through the module vendor's PCI PTS POI listing — but that listing covers a device family and an approved configuration, and you still own EMV L3 applet work, key injection and PCI DSS around the device
No cardholder data in your boundary: QR or redirect, cloud authorisation, or a P2PE-listed reader encrypting before your app	Orchestration, plus the evidence	Narrowest PCI DSS scope, but only if provable and if you hold that line through five years of feature work
Soft-SEC: secure-element functions in software with a remote trust service	A device with no payment hardware	Depends entirely on whether the schemes and your acquirer certify that configuration in your market; the answer is not on a datasheet

Two Android specifics. The operating system permits one default payment application at a time, so on a shared counter device somebody must own that slot. And PA-DSS was retired in favour of the PCI Secure Software Framework: a supplier offering a "PA-DSS certified" SDK is quoting an expired programme, so ask which SSF validation the component holds. Note too that a PTS approval is a claim about a listed device family and its documented configuration — your housing, cable, firmware version and added peripherals may sit outside it, which is a question for the lab or your assessor before you print boxes.

PCI scope is an integration choice, not a certificate

No supplier can hand you a scope reduction. Scope follows whether a primary account number enters your software, your logs, your screenshots or your screen-sharing session — and the usual leak is not an attack but a debug log serialising the whole transaction object, or telemetry posting an authorisation response. So decide up front: encrypt at the reader, tokenise before your app, forbid the PAN in every display and log path, and make the vendor state in SDK documentation which fields it exposes. Then have your own assessor confirm what you built.

The scan viewport and the payment box

Self-checkout hardware lives or dies on a window. Decode geometry — glass thickness, tilt, the reflective tray, light from the ceiling and the door — separates a demo from a lane. EDOO lists the built-for-it families at model level: MF61-M as a hands-free module for supermarket and self-service checkout, B21-10 as a desktop scan box, MF28-YG as a fixed-mount module with an NFC reader and Wiegand interface, MF26P as an engine for payment and vending machines.

The detail buyers miss is identity rather than decoding: where a lane has three readers, the decoded string must arrive saying which reader produced it, and keyboard emulation cannot carry that. Demand a framed serial or USB-CDC protocol with a device identifier in the payload.

Peripheral sprawl, and the driver bill nobody quotes

A counter carries a drawer, a scanner, a scale, a customer display, sometimes a second printer, a badge reader and a payment bridge. Each is a small project: the drawer kick is a pulse on a line whose polarity and drive width are device-specific; ESC/POS exists in several incompatible dialects; and OPOS, JavaPOS and the Windows unified POS layers are not automatically available for a device whose vendor targets Android. On Android you are handed an SDK rather than a driver, and an SDK is often a demo with a header file. Ask per peripheral which interfaces stay live simultaneously, whether charging and USB host mode coexist, and who maintains the driver through the next OS release. Then price five firmware streams over five years.

Durability for a fourteen-hour counter

Counter devices die at the connector, the printer latch, the cutter and the power inlet, not at the processor. Ask for insertion-cycle ratings on ports, cutter life and mechanism duty cycle with their test methods, the thermal behaviour of a sealed enclosure running printer and two displays for fourteen hours, and the housing's reaction to daily disinfectant wipes — a chemical question an ingress rating under IEC 60529 does not answer. Where a descriptor states an IP rating, treat it as a per-model claim with a report behind it; never infer one from the category.

Mounting, and the cable reality of an island

The mechanical list: the VESA or pole pattern and its load, a flush insert whose cut-out must clear the largest connector you own, a customer-display arm that adjusts without tools, and a drawer kick cable crossing the under-counter cavity. Then the physics: a passive full-speed USB run is a few metres before it becomes unreliable, which is why the hub ends up inside the cabinet — and a hub there changes enumeration order and becomes a single point of failure for the island. A power brick in a closed cabinet is a heat source and one of the likeliest parts in the system to fail early; powering the device from a shared supply, or over PoE where offered, moves that failure into infrastructure someone is employed to monitor.

The OS horizon, and who patches this in year five

Ask for the shipped Android version, the current security patch level, the committed cadence and the model-specific end-of-support date, in writing. A five-year fleet on a device with two years of patches is a compliance problem you scheduled. On a payment device there is a twist: if the approved configuration names the operating system and firmware version, patching is a change-management process involving your acquirer rather than a download.

What to put in writing in a POS OEM agreement

discharges each MPoC and attestation obligation.

housing, connector, radio or battery change triggering documented re-assessment.

a band variant or custom launcher typically adds time.

Exact model and SKU, SoC, and RAM/flash as reported by the OS rather than printed on the carton.
Display configuration, and the permitted content map for the customer-facing panel.
Printer mechanism part number, paper specification, cutter rating and duty cycle with the test method for each.
For payment: the PCI PTS POI reference number and the configurations its approval covers; for on-device tap, which party
EMV kernel versions, who runs EMV L3 certification with which acquirer, and who owns key injection.
The interface set, which ports stay live simultaneously, and the framing protocol for scan events.
Driver and SDK inventory per peripheral, platforms supported, and the redistribution licence.
Android version, patch cadence, end-of-support date, update mechanism, bootloader policy, MDM compatibility.
Certificate files per model per destination market, current-dated, naming the exact model and the holder.
Spare parts and their price horizon, which parts a shop manager may replace, and the change or EOL notice period, with a
MOQ and lead time: EDOO publishes OEM from 100 units, 15 days for samples and 30 days for mass production, noting that

FAQ

What can an Android POS terminal OEM actually customise? A POS ODM partner changes the visible and interface layer — branding and boot logo, preinstalled app set, launcher and kiosk lockdown, connector and cable choice, printer mechanism substitution, regional power and radio variants, and firmware framing so a host can tell a scan from a heartbeat — whereas a new mainboard, payment module or tool is a new product with its own certification work.

Is a dual-screen POS terminal worth it? It is worth it where the customer needs to see the transaction to trust it, such as food service with tips, because the second panel's job is visible line items and a tip prompt facing the customer rather than specification headroom; it costs you heat, mounting geometry and a rule about what it may display.

Does a PTS-approved payment module remove my PCI obligations? No: a PCI PTS POI approval belongs to a device family and a defined approved configuration, so your housing, firmware version and added peripherals may sit outside it, and you still carry EMV L3 integration, the key-injection duty under PCI PIN Security Requirements and PCI DSS for the environment around it.

What is the most under-priced part of a branded POS deployment? Peripheral integration: a drawer kick, a scale, a scanner, a customer display and a payment bridge each bring their own driver, firmware and failure mode, and on Android the vendor typically ships an SDK rather than a maintained OPOS or JavaPOS driver, so the true cost is five supported software streams across the life of the fleet.