microSD Card Spec for POS and Self-Service Terminals (Buyer Guide)

TL;DR

Specify a microSD card for a POS or self-service terminal as replaceable media, not as the terminal’s database. In practice that means: an 8–32 GB card with a FAT32 or exFAT volume sized to your firmware image plus 12 months of logs, a documented cluster size, and a controller/flash pairing that has been power-cut tested on your own host board. Anything above 64 GB, any card that has not been tested for brown-out behaviour, and any card whose controller changes without a BOM revision are the three failure modes that generate field returns.

This guide is the segment checklist a POS or kiosk buyer needs before releasing a purchase order. It links out to the existing technical articles for the physics; it does not repeat them.

Why POS and self-service terminals are a distinct card segment

A dashcam writes large sequential video files and tolerates a dropped frame. A medical wearable writes tiny records and cares about retention. A POS terminal sits between them: it writes small, frequent, latency-sensitive records (receipts, transaction logs, queue state) during business hours, then sits idle, then is rebooted or power-cycled by a cleaner pulling a plug at 2 a.m. Self-service terminals add a second problem — they are often in an unheated lobby or an outdoor canopy, and nobody is watching the screen when the card fails.

That combination drives three requirements that generic “industrial microSD” marketing does not address:

• Power-loss survival matters more than peak sequential speed.
• Removability is a security and serviceability feature, but it is also a data-loss vector.
• Long field life with an unchanging BOM matters more than the fastest card available today.

If your design can avoid a removable card entirely, read the comparison in microSD card vs embedded eMMC for portable devices before you commit to a card slot.

The numbered checks

1. Decide whether the card is primary or secondary storage

Write this down before you choose a capacity. If the card holds the only copy of a transaction until it is synced to a server, you have made the card part of your data-integrity story, and you owe your customer a documented recovery procedure. If the card holds firmware images, logs, spool files, and cached assets that can be regenerated, the card is secondary storage and a failure is an inconvenience rather than an incident.

Most POS deployments should be in the second category. The card is a service hatch: it lets a field technician swap firmware without a laptop, and it lets the terminal keep a rolling log that survives a mainboard replacement. Design the software so that the terminal can boot, transact, and sync with the card absent or blank.

2. Size the capacity band from the workload, not from the price list

Work backwards from what the terminal actually writes. A typical small-merchant POS writes a few kilobytes per transaction, a few hundred kilobytes per day of logs, and receives a firmware image of tens to low hundreds of megabytes a few times a year. That workload fits comfortably in 8 GB and leaves room for years of logs. A self-service kiosk with a camera, a signature pad, or age-verification capture may write image evidence, which changes the arithmetic quickly.

Use the capacity bands in capacity bands — where they stop making sense as the frame, and the TF card capacity estimator to run your own numbers. As a rough illustration only — not WINTEL data — a terminal writing 500 KB per day of logs plus a 200 MB firmware image renewed four times a year needs well under 1 GB per year of retained history, so an 8 GB card with a 12-month retention policy is generous.

Above 32 GB you are usually paying for capacity the terminal will never use, and you are buying into exFAT, larger cluster sizes, and a longer format and verification cycle on the production line. Go there only when the workload proves it.

3. Choose the file system deliberately, and record the cluster size

FAT32 is the safe default for POS firmware because virtually every bootloader, RTOS, and Linux kernel can mount it read-write without extra drivers. Its limitation is the 4 GB maximum file size and the practical volume-size ceiling; Microsoft documents the cluster-size defaults for FAT and exFAT in its cluster size reference. exFAT removes the file-size limit and is well supported on modern Linux and Windows, but older bootloaders and some embedded RTOS builds still cannot read it — the exFAT specification is the reference your firmware team should confirm against.

Two rules follow. First, the file system and cluster size are part of the BOM, not a production-line preference; a change of cluster size between lots can change write amplification and therefore card life. Second, if you choose exFAT, test the exact host kernel and bootloader version, not “Linux in general.” The Linux MMC/SD subsystem documentation is the right starting point for how your host will enumerate and recover the card.

4. Match the bus mode to the host controller, not to the card’s headline speed

A POS mainboard built around a low-cost SoC may only support the default-speed or high-speed SD bus, not UHS-I. In that case a UHS-I card runs in a slower mode and the extra capability is wasted. Confirm the host controller’s supported modes before you specify a card class, and confirm that the card’s SPI-mode fallback (if your board uses SPI) has been tested — the throughput ceiling in SPI mode is covered in microSD card SPI mode throughput ceiling.

The SD Association’s physical layer specification is the authoritative reference for bus modes and speed classes; quote it in your specification rather than a vendor’s marketing page.

5. Treat A1/A2 as a floor, not a promise

Application Performance Class A1 and A2 describe random read/write IOPS under defined conditions, as the SD Association’s application performance class page explains. They do not describe behaviour after a power cut, they do not describe sustained small-write endurance, and they do not tell you what happens when the card is 90% full. For a SQLite-backed queue or a log file, A1/A2 is a reasonable screening criterion; it is not a substitute for testing your workload on the card. The mechanics are covered in microSD A1/A2 application performance.

6. Power-cut test on your own board, and write the result into the specification

This is the check that most POS programmes skip, and it is the check that generates the field returns. Pull power at random points during a write, repeatedly, and verify that the file system mounts, that the last committed transaction is intact, and that the terminal recovers without a factory reset. The behaviour depends on the controller’s handling of an interrupted program/erase cycle, on the file system’s journaling, and on the host’s mount options. Background on what protects data is in microSD card power loss corruption and what protects data, and the write-strategy side is in microSD card power-fail-safe write strategy.

Record the test method, the number of cycles, and the pass criterion in the card specification. A supplier who cannot tell you how their controller behaves under an interrupted write is telling you something.

7. Lock the controller and flash pairing, and define approved alternates

The card you qualified in month one may not be the card you receive in month nine. Controllers get revised, flash die gets substituted, and a card that passes your power-cut test today can fail it after a silent BOM change. The pairing matters because controller firmware and flash die characteristics interact; see flash brand controller pairing and bad block handling — what the controller does.

In the purchase specification, name the controller family and the flash die vendor, and require written notification before any substitution. If you accept alternates, list them explicitly and require the same power-cut test on each. Traceability from a returned card back to a lot is covered in flash memory lot traceability and die marking.

8. Decide how the image gets onto the card — and how it is verified

If the factory pre-loads your firmware image, the process must be reproducible and verifiable. Ask for the flashing tool, the write verification method, and a per-card hash check that the terminal repeats at boot. Volume flashing at scale is covered in microSD image flashing at volume; the general question of pre-loading is covered in can you preload software on custom USB drives, which applies to cards as well.

9. Specify the physical card and the slot

A POS terminal in a retail environment is opened by staff, cleaned by staff, and occasionally dropped. The card form factor, the slot type (push-push, push-pull, hinged), and the retention mechanism are part of the specification, not an afterthought. If the card sits near a display backlight or a power supply, thermal behaviour matters; background is in microSD card heat sink and thermal throttling and capacity drift across temperature sizing.

10. Agree the marking and part-number scheme

Every card you ship should carry a marking that lets you trace it back to a lot, a production date, and a firmware revision. Without that, a field return is uninformative. This is cheap to agree at PO time and expensive to retrofit.

What the terminal will and will not accept

Host capability	What it means for the card	What to do
Default-speed or high-speed SD bus only	UHS-I card runs in a slower mode	Specify the mode the host supports; do not pay for capability you cannot use
SPI-mode host	Throughput ceiling well below SD bus	Confirm SPI-mode testing; see the SPI article
FAT32-only bootloader	4 GB file-size limit, volume-size ceiling	Keep firmware images under 4 GB; use FAT32
exFAT-capable kernel	No file-size limit, larger clusters	Test the exact kernel version; record cluster size
No card-detect line	Hot-swap may not be noticed	Design for power-cycle after card swap
No write-protect switch support	Card can be modified by any process	Rely on file-system permissions and signed images
Unbuffered power rail	Brown-out during write	Power-cut test; consider a supercapacitor or a graceful-shutdown signal

What to lock in the BOM

The BOM line for the card should carry, at minimum:

1. Capacity and tolerance — e.g. “8 GB nominal, formatted capacity ≥ 7.2 GB” rather than “8 GB.”
2. File system and cluster size — e.g. “FAT32, 32 KB clusters” — as a controlled attribute.
3. Form factor and bus mode — microSD, and the bus mode your host actually uses.
4. Controller family and flash die vendor, plus an explicit approved-alternates list.
5. Power-cut test result — the method and the pass criterion, referenced by document number.
6. Pre-load image hash and verification method, if the card ships pre-loaded.
7. Marking and part-number scheme — lot, date code, firmware revision.
8. Packaging and labelling — reel, tray, or individual bag, and the label content.

Anything not on this list is a production-line decision, and production-line decisions drift.

Purchase-order checklist for POS and self-service terminals

This is the sequence a buyer should walk through before releasing a PO. Each item is a decision, not a form field.

1. Confirm the storage role. Written confirmation from the firmware team that the card is secondary storage, with the recovery procedure documented for the case where the card is absent or blank.

2. Confirm the capacity band against a real workload calculation. The estimator output, signed off by the firmware owner, and a retention policy that states how long logs are kept before rotation.

3. Confirm the file system and cluster size against the exact host kernel and bootloader version. Not “Linux” — the version string. Record it in the specification.

4. Confirm the host bus mode and whether SPI fallback is used. If SPI, confirm SPI-mode throughput and testing.

5. Confirm the power-cut test has been run on the production host board, with the method, cycle count, and pass criterion written into the specification.

6. Confirm the controller and flash pairing, and the approved-alternates list, with a written notification requirement before any substitution.

7. Confirm the pre-load procedure and verification method, including the per-card hash check the terminal repeats at boot.

8. Confirm the marking and part-number scheme, and that it appears on the card, the packaging, and the shipping documents.

9. Confirm the sample acceptance criteria against the sample acceptance checklist, and keep the accepted sample as the reference lot.

10. Confirm the commercial terms — deposit, payment schedule, and the currency and freight clauses — against how much deposit and payment schedules work and currency clauses — two places the price moves.

11. Confirm the delivery date against a working-back schedule, not against a wish. The working back from a date article is the right frame.

12. Confirm the certificate of conformance content against certificate of conformance — what it says, and that it names the controller and flash pairing you qualified.

Where WINTEL fits

WINTEL (Shenzhen Wintel Digital Technology Limited) manufactures custom TF/microSD cards, USB flash drives, UDP modules, and semi-finished boards for OEM/ODM buyers. The company’s confirmed capabilities relevant to this segment are: a 5,000 m² factory, 200+ employees, monthly capacity of 500,000+ units, export to 50+ countries, and SGS, RoHS, CE, and FCC certifications. The team’s history in the industry dates to 2006, and the registered entity was established on 2015-05-12.

WINTEL does not publish speed classes, endurance ratings, temperature ranges, MOQ, lead times, or test results for specific card programmes in this guide; those are programme-specific and should be confirmed in writing for your requirement. The TF card product page and the request-a-quote form are the right starting points. For buyers who need to understand how a Chinese flash factory is structured before they shortlist, how to tell a real Chinese flash factory from a trading company is the relevant read.

FAQ

Is a microSD card acceptable as the primary storage in a POS terminal? It is acceptable as removable or secondary storage for logs, firmware updates, and receipt spool files. It is a poor choice as the only copy of transaction data, because the card is removable, subject to power-loss corruption, and has no wear-levelling telemetry the host can read. Treat it as replaceable media, not as a database.

Which capacity band should I specify? Most POS and self-service firmware images plus logs fit in 8 GB to 32 GB. Go to 64 GB only when the terminal writes image or video evidence, and only if the host kernel and bootloader have been tested with exFAT. Above 64 GB the failure modes multiply faster than the benefit.

Does an A1 or A2 rating matter for a POS terminal? Only if your application does small random reads and writes — a SQLite-backed queue, a log file, or a thumbnail cache. Sequential writes from a receipt spool or a firmware image do not benefit. A1/A2 is a floor, not a guarantee, and it does not describe behaviour after a power cut.

What should I lock in the BOM? Capacity, file system, cluster size, card form factor and bus mode, controller family and flash die vendor (or an approved alternates list), power-loss behaviour tested on your host, and a marking/part-number scheme that lets you trace a returned card back to a lot.

Can the factory pre-load our firmware image on the cards? Pre-loading is a normal service, but the image must be signed and hash-checked by the terminal at boot, and the card must be written and verified at the factory with the same tool you use in the field. Ask for the flashing procedure and the verification method, not just a promise.

Sources

• SD Association — SD Specifications, Part 1 Physical Layer and Part 2 File System: https://www.sdcard.org/downloads/pls/ (accessed 2026-10-30)
• SD Association — Application Performance Class: https://www.sdcard.org/developers/sd-standard-overview/application-performance-class/ (accessed 2026-10-30)
• Microsoft Learn — exFAT file system specification: https://learn.microsoft.com/en-us/windows/win32/fileio/exfat-specification (accessed 2026-10-30)
• Microsoft Support — Default cluster size for NTFS, FAT, and exFAT: https://support.microsoft.com/en-us/topic/default-cluster-size-for-ntfs-fat-and-exfat-4640e16c-5b1c-4e0a-9f0f-0b7f2c35d9d3 (accessed 2026-10-30)
• Linux kernel documentation — MMC/SD subsystem: https://docs.kernel.org/driver-api/mmc/index.html (accessed 2026-10-30)
• JEDEC — Standards and documents index (JESD84 eMMC, JESD220 UFS): https://www.jedec.org/standards-documents (accessed 2026-10-30)