Embedded POS Software: Engineering Payment Systems at Device Level

Why device-level payments are different

There are two worlds here, and the distance between them is wider than most teams expect. In the first, you build a payment application that runs on a finished terminal someone else already certified. The vendor owns the certified terminal, including the EMV Level 2 kernel, and its security boundary. You write to an Software Development Kit (SDK), and the burden of compliance sits below you.

The second world is the one this article is about. At device level in embedded payment systems, you own the firmware and the kernel, and that ownership extends to cryptographic key handling and the certifications on silicon you cannot patch your way out of after the fact. That ownership is what makes Embedded POS software a different discipline from app development. In this world, you are building the boundary.

And here is the through-line that holds for everything below. The difficulty comes from stacking strict payment security and certification requirements on top of constraints that were already tight before payments entered the picture. That stack is what turns embedded POS software from a normal embedded build into a multi-year compliance program.

Constraints that shape the build

Three hard constraints govern every decision in this work, and they're worth naming before anything else. The first is limited memory. The second is limited CPU. The third is the presence of dedicated secure hardware, a secure element or secure processor that holds keys and runs sensitive operations in isolation from the main application.

These constraints are the defining context. In embedded POS software, the payment application has to share a small footprint with a certified EMV kernel and the cryptographic operations behind every transaction without missing timing windows. Those windows are real and they're short. Adyen's platform cancels a transaction if the issuer hasn't processed it within 120 seconds on a local integration, and the on-device interaction budget is far tighter than that. In embedded payment systems, a contactless tap has to complete in well under a second, so the kernel cannot afford to wait on a sluggish crypto routine or a memory allocation that stalls.

The secure hardware constraint cuts the other way too. A typical secure element ships with 10 to 30 KB of SRAM and a non-volatile memory measured in hundreds of kilobytes. Every key and certificate competes with protected routines for that space. What you decide here cascades into everything later. Choose the wrong partition between secure and non-secure execution, and you'll feel it during key storage design and again during certification, when the lab tests exactly those boundaries.

Core engineering layers of embedded POS software

Four engineering areas make up the device-level stack for embedded POS software, and the thing to understand up front is that they interlock. The firmware underpins the kernel. The kernel relies on keys the storage layer protects. The abstraction layer determines how cleanly all of it moves to new silicon.

Each subsection below explains what the work involves and where teams without payment experience tend to come apart under the constraints already described. The depth here is meant for an engineer who will scope the work, while a product lead can still follow what's at stake in each one.

POS firmware development

POS firmware development at this level starts with secure boot and a hardware root of trust. Secure boot is the first code that runs after reset, and it verifies the authenticity and integrity of everything that loads after it. As the STMicroelectronics documentation puts it, secure boot "is the foundation of the device security," the root of trust that every later stage extends. If that chain breaks anywhere, the security guarantees above it are worthless.

In POS firmware development, firmware enforces device security at startup and at runtime, and it's itself under scrutiny during certification. The PCI PTS rules require change-control procedures so that any security-relevant change to the device triggers re-certification, and the certified firmware must be stored to preclude unauthorized modification. For hardware tampering, one embedded security team notes that secure boot "must be complemented with physical security measures" like tamper detection and mesh protection.

The constraint pressure shows up immediately. POS firmware development has to stay small and deterministic while still driving the low-level driver path between the card reader and the secure element interface, with the contactless front end and PIN pad tied into that same path. Determinism matters as much as size here. A firmware path that occasionally takes twice as long will eventually miss a timing window, and that failure surfaces in the field.

EMV kernel integration

In embedded POS software, the EMV Level 2 kernel is the software that performs EMV processing inside the device. ATM Marketplace describes it plainly: L2 testing evaluates the kernel, "the software inside the terminal" that runs EMV transaction logic and confirms support for the payment application functions. Selecting a kernel is the easy part. Integration is where the effort and the certification risk live.

Integration means configuring terminal and application parameters, then handling brand-specific processing. Until recently each network ran its own contactless kernel: Mastercard on C-2, Visa on C-3, with American Express on C-4 and other schemes following their own mappings. That fragmentation is what drove cost and complexity into every contactless build. You debugged and certified the same transaction flow several times over.

The target is moving. EMVCo published the unified C-8 contactless kernel specification in late 2022 to consolidate those proprietary kernels into one standard, and Ingenico's AXIUM DX8000 earned the first EMVCo C-8 approval. But C-8 has to coexist with the older kernels through a multi-year transition, so integration today means planning for both. And the cost of getting it wrong is concrete. Terminal simulator vendors report that "the slightest error results in certification failure," which is why most teams debug kernel test cases in-house before they ever book lab time.

Secure key injection and storage

Keys have to get onto the device, and they have to stay protected once they're there. Both halves are governed by PCI PIN security rules, and both are as much a process problem as an engineering one.

Loading happens through key injection, and PCI requires that top-level keys be injected in a secure room or facility over an encrypted TLS connection. In practice that work runs through a certified key injection facility operated by an Encryption Service Organization. As Level 10, a certified ESO, explains it, the facility "is a secure location subject to PCI PIN security standards" with badged access and dual control over storage under a documented chain of custody. You design the device and its provisioning flow around it.

Once loaded in embedded payment systems, the keys live inside the secure hardware so they never appear in clear text outside it. PCI-validated point-to-point encryption requires that key management and decryption happen within HSMs validated to FIPS 140-2 Level 3 and that on-device encryption occur inside the SRED tamper-resistant security module. This is exactly where the secure-hardware constraint from earlier comes back. The element protecting your keys is the same constrained chip with kilobytes of memory, so the storage scheme has to support the key hierarchy and the operations you run inside a budget that was small to begin with.

Hardware abstraction layers

In embedded POS software, a hardware abstraction layer (HAL) sits between your payment logic and the device-specific SDKs and silicon underneath. Done well, the same core application moves to new hardware with far less rework, because a stable interface isolates the hardware-specific paths behind a boundary.

The payoff is the part a product leader weighs. A clean HAL reduces vendor lock-in and makes hardware transitions manageable as deployments grow. It also speeds re-certification when the hardware changes. That last point isn't small. PCI PTS change-control rules force re-certification on security-relevant hardware changes, so the less your payment core has to change when the silicon does, the less of that cycle you repeat.

There's a tension to manage, though. A HAL that abstracts cleanly can also add overhead the constrained CPU and memory can't absorb. Every layer of indirection costs cycles, and cycles are what you're rationing inside a sub-second transaction window. For embedded payment systems, the architecture has to abstract enough to be portable without inserting itself into the hot path of a tap or a dip. Get that balance wrong and you've traded portability for missed timing windows, which is the worst trade in this business.

How certification reshapes development cycles

The instinct is to treat certification as a final gate, a test phase you schedule at the end. That instinct is what wrecks timelines. For embedded pos software, certification shapes the whole project, and it does so from the first architectural decision.

For embedded payment systems, four distinct approvals are in play, and they don't overlap neatly:

• PCI PTS for the device itself, which covers the physical and logical security of the point-of-interaction hardware.

• EMV Level 1 for the hardware, which tests the mechanical and electrical interface between card and reader.

• EMV Level 2 for the kernel software.

• EMV Level 3 for end-to-end integration with the acquirer host, which confirms the configured terminal works with the merchant or bank systems before deployment.

Levels 1 and 2 are certified by EMVCo, but Level 3 has to pass tests with each card brand individually, so each card brand demands its own approval. That single fact multiplies the work. A custom payment application is held to the same testing standard as a generic one, and the burden falls on whoever wrote it.

Now the schedule reality. A single terminal model's Level 3 network certification in the U.S. "can take a few months and cost thousands of dollars," and that's per terminal per network. Blankfactor notes the full path "can take up to two years or maybe more." Worse, it repeats. Firmware and software updates in pos firmware development require portions of the L3 certification process to be repeated, so every meaningful change reopens part of the cycle. Mature teams design for certification from day one, with test planning and host simulation built into the architecture before lab work exposes any gaps.

Why most vendors cannot do both

The biggest challenge in embedded POS software is bringing together two specialized disciplines: low-level embedded engineering and payment certification. Teams often excel at one but lack the other, leading to delays, redesigns, or certification hurdles late in the project.

Successful delivery requires expertise across firmware, EMV kernels, PCI requirements, and certification from the start. As the U.S. Payments Forum, quoted by Blankfactor, notes, certification timelines are often extended by testing, scheduling, and review cycles that experienced teams know how to plan for.

At EGS, we combine embedded engineering with end-to-end payment integration and certification expertise, covering firmware, kernel integration, and key management as one coordinated effort. If you're planning or scaling an embedded POS software project, reach out to discuss your requirements and the most practical path to certification.