A POS terminal is not a PC. It runs an embedded or locked-down operating system, often mounts storage read-only or through a whitelist, and may reject a drive that mounts perfectly on your laptop. Before you buy, confirm the file system the terminal accepts, whether it enumerates at all, what volume label its software expects, and whether the controller is on any approved list.
POS and self-service terminals are embedded systems, not general-purpose PCs. They often run a locked-down OS, mount removable storage read-only or only from a whitelist, and reject drives that enumerate fine on a laptop. Before ordering, confirm four things against the actual terminal model: the file system it accepts, whether it enumerates the drive at all, the exact volume label its software expects, and whether the controller appears on any approved-hardware list. Test a sample in the terminal, not on your desk.
The short answer
A POS terminal is not a PC. It is an embedded system with a restricted USB stack, often a locked-down or read-only operating system, and frequently a whitelist of hardware it will accept.
That means a drive that mounts perfectly on your laptop proves nothing about the till. Before you order, resolve four things against the specific terminal model:
| Unknown | Why it matters |
|---|---|
| File system the terminal accepts | Many embedded builds have no exFAT support |
| Whether it enumerates at all | Restricted USB stack may reject the descriptor |
| The exact volume label its software expects | Software often references label, not letter |
| Whether the controller is on an approved list | Whitelist by vendor/product ID is common |
Then test a sample in the terminal — not on your desk.
Why the laptop test lies
A laptop has a general-purpose operating system with a driver stack designed to accept almost any mass-storage device. It will mount a drive with a nonstandard descriptor, an odd capacity report, an unusual controller, or a file system it merely tolerates.
An embedded terminal does none of that. It has:
- a slimmed USB stack that may only recognise specific device classes;
- a file system layer that may support FAT32 and nothing else;
- sometimes a policy layer that mounts removable storage read-only, or blocks it entirely except during a service window;
- occasionally a hardware whitelist keyed to vendor and product ID.
Any one of those turns a working drive into a non-working one, with no error message a shop assistant can interpret.
This is the same class of problem covered in my custom USB drives work on my laptop but not in my device, and the diagnostic path is the same: the drive is rarely faulty, it is simply outside the host’s accepted set.
The four specifications that decide it
1. File system
FAT32 in almost all cases. Many embedded POS builds ship without exFAT, and some do not mount NTFS. FAT32 is also the format vendors most often pre-load, so it is the least likely to trigger an unexpected prompt mid-shift.
Confirm against the terminal model and firmware version, because a vendor update can change what is supported.
2. Enumeration behaviour
This is the one buyers cannot test without the terminal. A drive either appears to the host or it does not, and if the terminal’s USB stack is picky about descriptors, the drive silently fails to appear.
There is no datasheet field that predicts this. The only reliable test is the terminal itself, which is why the sample gate matters more here than in almost any other segment.
3. Volume label
Underrated and frequently the actual cause of a “drive problem”. POS software commonly stores import and export paths as a fixed label rather than a drive letter, because letters move between boots.
If software expects EXPORT and the drive arrives as NO NAME, the import fails — and the person on shift has no way to know that the fix is renaming a drive.
Write the label into the PO as an exact string. Require it on every reorder.
4. Controller consistency
Embedded hosts with whitelists check vendor and product ID. Change the controller and the terminal sees an unrecognised device. Even without a whitelist, a different controller changes timing and descriptor details that a narrow USB stack may not tolerate.
Lock the controller in the PO and require written approval for substitution — the same discipline that prevents a supplier swapping the chip anywhere else in the BOM.
Speed is the wrong place to spend
POS workloads are small: transaction logs, a product image set, a configuration file, an end-of-day export. Most terminals are USB 2.0 hosts regardless of what you buy.
USB 3.0 adds cost and, on older embedded controllers, can occasionally introduce enumeration trouble. Buy 2.0 unless a specific workflow moves genuinely large files — a nightly full-database export at a high-volume site is about the only common case.
A scenario: the rollout that failed on batch two
A retail chain rolled out custom drives to several hundred self-service terminals, using them for nightly price-list imports. Batch one deployed cleanly. Batch two — same part number, same supplier, lower price — failed at roughly a third of sites: terminals did not see the drive at all.
The cause was a controller substitution. The supplier had moved to a cheaper controller mid-programme without flagging it. Batch one’s controller was accepted by the terminal firmware; batch two’s vendor/product ID was not on the approved list.
Nothing in the delivery was defective. The drives worked on laptops. The programme still lost three weeks of site visits and a re-shipment.
The fix was contractual, not technical: a locked controller, a written substitution clause, and a new rule that every batch gets tested in one terminal before release to sites.
A purchase order template for POS and kiosks
Item: Custom USB flash drive for POS terminal use
Capacity: 8GB or 16GB nominal, real capacity verified per batch
Interface: USB 2.0, standard Type-A
File system: FAT32, pre-formatted
Volume label: EXPORT <- exact string, required every batch
Controller: (named in PO, locked; substitution needs written approval)
NAND: (grade stated, locked)
Housing: small form factor, low-profile so it does not foul the
terminal's recessed port or a locked cabinet door
Labels: physical label on housing matching the volume label
Testing: per-batch test report incl. capacity verification
Sample: one pre-production unit tested in the target terminal model
and firmware build before bulkThat low-profile housing note is not filler. Terminals often have recessed or cabinet-mounted ports, and a drive with a wide body or a keyring loop will not fit or will be knocked loose. Ask for the terminal’s port clearance before you choose the shell.
What to check before you order
- Which file system does this terminal model and firmware accept?
- Have I tested a sample in the terminal, not on a laptop?
- Does the software reference a volume label, and is it in the PO exactly?
- Is the controller locked, with a written substitution clause?
- Is the housing narrow enough for the terminal’s recessed port?
- Is USB 2.0 adequate for the actual data volume?
- Will the drive be re-tested after the next terminal firmware update?
Order for the terminal, not for the desk. The till is the only test that counts.
Frequently asked questions
Why does my USB drive work on my laptop but not in the POS terminal?
Because a terminal is an embedded system with a restricted USB stack, and a laptop is a general-purpose PC with drivers for anything. Common causes: the terminal only mounts FAT32 and the drive is exFAT or NTFS; the terminal's USB port is configured read-only or for a specific device class; the drive's controller reports a capacity or descriptor the terminal's enumeration logic rejects; or the terminal's OS whitelists approved hardware. The drive is not faulty — it is simply outside the terminal's accepted set.
What file system should a POS USB drive be formatted to?
Whatever the terminal's operating system accepts, which is usually FAT32. Many embedded and locked-down POS builds ship without exFAT support, and some do not mount NTFS at all. FAT32 is also the format most likely to be pre-loaded by the vendor and least likely to trigger a permission prompt. Confirm against the specific terminal model and firmware version rather than assuming.
Does the volume label really affect whether software can read the drive?
Yes, more often than buyers expect. POS software frequently references the export or import path as a fixed drive label rather than a drive letter, because letters shift between boots and across devices. If the software expects EXPORT and the drive arrives as NO NAME, the import silently fails or prompts for a path nobody on shift knows how to enter. Specify the exact label in the PO and hold every reorder to it.
How do I test a drive for a terminal I have not deployed yet?
Buy one pre-production sample and test it in the actual terminal model, on the actual firmware build, in the actual software workflow: plug it in, confirm it enumerates, confirm the label appears, run the real import or export, then eject and re-run twice more. Repeat after a firmware update, because terminal vendors change USB behaviour between releases without documenting it. A drive that passes on your desk and fails at the till is a refund you will fight for months later.
Is USB 3.0 worth it for a POS drive?
Rarely. POS data is small — transaction logs, product images, a config file — and most terminals are USB 2.0 hosts anyway. Spending on 3.0 buys nothing at the till and can occasionally cause enumeration problems on older embedded controllers that expect a 2.0-speed device. Buy USB 2.0 unless a specific workflow moves genuinely large files, such as nightly full-database exports on a high-volume site.
What happens if the supplier changes the controller on a reorder?
The terminal may stop recognising the drive. Controller substitution changes the USB descriptors the host sees, and an embedded host with a narrow acceptance path is exactly where that difference surfaces. Some terminals whitelist by vendor and product ID, so a new controller means an unrecognised device. Lock the controller in the PO, and require written approval for any substitution — this is the single most common cause of 'the second batch doesn't work in our terminals'.