EMV POS Software: Building Secure Chip Card Payment Systems

Why chip payments are hard to build

You can build software. You've just been handed EMV POS software as a project, and the first thing you've discovered is that accepting a chip card has almost nothing in common with reading a magstripe swipe. A swipe hands you a block of static data and asks you to send it onward. A chip card negotiates.

An EMV transaction is a back-and-forth conversation between the card and the terminal. When the transaction goes online, the issuer's host joins, and cryptography underpins the exchange. The card authenticates itself. The terminal runs risk checks. The card decides, cryptographically, whether it wants to go online or settle on the spot. None of that happens in a magstripe world, and each piece has to be implemented correctly or the transaction breaks in ways that are hard to diagnose.

Underestimating this is the single most common reason payment projects slip past their deadlines. Teams scope EMV POS software as if it were a data-forwarding job and then hit the certification wall months later. The point here is to give you the real shape of the work so you can scope it honestly, then decide whether to grow this expertise in-house or bring in help.

How an EMV transaction flows

An EMV transaction is a sequence of stages, and each one exists to close a specific gap that magstripe left open. Trace the whole path once and the architecture of your EMV POS software starts to make sense. What follows is the flow an engineer would see if they could watch the messages move between card and terminal.

Card insertion and app selection

The moment a cardholder presents a card, the terminal has to figure out what it's talking to. With a chip, the reader and the card first agree on which payment application to run, because a single physical card can carry more than one. For example, one card holds both a scheme-branded credit application and a common debit application, and the terminal has to pick the right one.

The mechanism behind this is application selection. On contact, the reader asks the card for a directory of what it supports and builds a candidate list of applications the card and terminal both recognize before it chooses by priority. On contactless, the reader queries the Proximity Payment System Environment (PPSE) instead, and the card returns each application's identifier with a priority indicator so the reader can select automatically.

Contact and contactless entry points behave differently here, and that difference matters later when you test. Contact selection can involve cardholder choice between applications, while contactless is built to resolve without asking. Get the entry-point logic wrong and the terminal either picks the wrong application or fails to start the transaction at all.

Chip card processing and authentication

Once an application is selected, the terminal's EMV POS software reads the card's data records and moves to card authentication, the step that confirms the card is genuine rather than a counterfeit clone. This is the heart of chip card processing, and it's where the fraud problem magstripe couldn't solve gets addressed directly.

Authentication splits into two ideas. Offline Data Authentication (ODA) is a cryptographic check the terminal performs locally, without contacting the issuer, to validate that the card's data hasn't been altered and that the card holds a legitimate key. According to B2 Payment Solutions, there are three ODA methods. Static Data Authentication (SDA) checks a signature over static card data. Dynamic Data Authentication (DDA) has the card generate a unique signature for each transaction, while Combined Data Authentication (CDA) signs the transaction data along with the card. American Express now mandates DDA for new card issuers because SDA can't catch a card that copied all the original data. Online authentication, by contrast, happens when the issuer's host validates a cryptogram in real time.

Cardholder verification runs alongside this. The card and terminal agree on a Cardholder Verification Method (CVM), which is how the person is confirmed to be the legitimate cardholder. Common methods include an offline PIN checked by the chip and an online PIN sent to the issuer. With a phone, on-device verification confirms identity with a fingerprint or passcode. The reason this whole chip card processing block exists is fraud prevention. If authentication is implemented wrong, counterfeit cards that should have been caught here sail straight through.

Risk management and cryptograms

This is the conceptually hardest part of the flow, so slow down here. After authentication, the transaction goes through risk management, where two parties weigh in on how it should be handled. The EMV POS software runs the terminal's own checks, and the card runs card action analysis against issuer-defined risk parameters stored on the chip. Those parameters decide, for instance, whether a low-value transaction can settle offline or whether the issuer wants to see it. The card communicates its verdict cryptographically, by generating an application cryptogram. There are three you need to know, and each signals a different intent.

EMV Book 3 frames the result this way:

• ARQC (Authorization Request Cryptogram): the card wants to go online to the issuer for a decision.

• TC (Transaction Certificate): the card approves the transaction offline.

• AAC (Application Authentication Cryptogram): the card declines.

A cryptogram is a message authentication code the card computes over the transaction data using a key shared with the issuer. Because the issuer can recompute and verify it, the cryptogram protects the transaction from tampering in transit. If someone alters the amount between the card and the host, the cryptogram won't validate. As ID TECH puts it, these values "only represent the card's advice," and the online authority makes the final call. That distinction trips up a lot of first implementations, so hold onto it.

Online and offline decision

Now the loop closes. Based on the cryptogram the card returned and the terminal's own risk logic, the transaction resolves to online or offline, and the choice is constrained by rules rather than left open. The card is not permitted to request offline acceptance if the terminal has already proposed online authorization, for example. A TC or an AAC completes the transaction on the spot, approved or declined. An ARQC sends it online.

For an online authorization, EMV POS software packages the cryptogram and transaction data into an authorization request, with the amount included, and sends it to the issuer through the acquirer. The issuer validates the ARQC and responds with its decision. Part of that response is the Authorization Response Cryptogram (ARPC), which the terminal passes to the card so the card can confirm it heard back from its own issuer. That mutual check is what makes the online path trustworthy.

Offline authorization exists for environments where a real-time connection isn't guaranteed, like transit gates or some unattended terminals. Issuers keep it on a leash through floor limits and offline counters, with velocity checks on the chip, so a card can only accumulate so much offline activity before it's forced online. Seen end to end, the flow is one connected conversation: the terminal selects the application and lets the cryptogram carry the decision after cardholder checks and risk analysis.

What the EMV kernel does

Everything in that flow has to be driven by something, and that something is the EMV kernel. In EMV kernel development, the kernel is the software component that runs the transaction logic at the point of interaction and sits between the terminal application and the acquirer. When EMVCo describes Level 2 testing, it's evaluating exactly this: the kernel that performs EMV processing for compliance with the chip specifications.

The structure is where teams get surprised. A common Level 2 stack has a shared entry point plus one kernel per scheme. Historically, each card network maintained its own contactless kernel, which is why one industry breakdown lists separate Level 2 certifications for Mastercard and Visa contactless; American Express has its own path as well. Supporting several card brands has meant integrating and certifying several kernels, each with its own quirks.

That picture is changing, and it changes your options. In October 2022, EMVCo published the C-8 Contactless Kernel Specification, a single unified kernel meant to eventually replace the scheme-specific ones so a terminal can be certified once and meet requirements across brands. The C-8 kernel also supports cloud operations, so processing can be split across locations for mobile point-of-sale and TapToMobile setups. Ingenico obtained the first EMVCo C-8 approval on its AXIUM DX8000 device, and the new kernel runs on existing hardware, so it coexists with older kernels during the transition. When you decide whether to license a kernel or build your own during emv kernel development, this is the map you're navigating.

Certifying your EMV POS software

Building EMV POS software is only half the job. Before you go live, you clear a certification path, and the levels matter because they test different things. EMV Level 1 covers the physical and electrical interface between the reader and the card. Level 2 evaluates the kernel and its transaction logic. Level 3, the brand or scheme certification, validates the whole thing end to end against a specific acquirer and host.

Level 3 is what trips teams up. It confirms your terminal configuration works with a particular acquirer and gateway, with the required host message formats covered through real scenarios like approvals and declines. It does not test whether your product is well designed or whether it handles every card in the field gracefully. Certification proves conformance to a defined set of test cases, while edge cases outside those cases are still your problem.

The cost and timeline surprise comes from multiplication. Because each acquirer has its own configuration requirements, multiple networks require repeated certification cycles. And the process is slow by nature. The U.S. Payments Forum notes that "end-to-end testing currently can take weeks"; scheduling and acquirer reviews add calendar time on top of the test cases themselves, and network and receipt reviews add more. One consultancy estimates the full Level 3 effort will take up to two years or more when specialists design and run tests for each terminal and region, with each business handled separately. Worse, even minor software changes can trigger partial recertification, because an update can introduce issues that require retesting. If you're building a plan you've never scoped before, this is the line item that decides whether your launch date is real.

Where EMV projects go wrong

The failure points in EMV kernel development are consistent, and they compound. The first is the certification queue itself. Test labs handling Level 3 face backlogs from high demand, and those scheduling delays push project deadlines back regardless of how clean your code is. You can be ready and still wait.

The second is inconsistent requirements across networks. What passes for one acquirer fails for another, so you end up adjusting configurations and writing additional test cases per network. The third is interoperability. A terminal that reads one card or works with one issuer can fail on another, because EMV has enough optional behavior and edge cases that real-world cards expose gaps a lab script missed. Teams new to payments underestimate all three because none of them look like software bugs. They look like process, and process doesn't show up in a code review.

Here's why this is more than a scheduling headache. Correct implementation is a fraud and liability question. Since the October 1, 2015 liability shift, responsibility for counterfeit card-present fraud falls on whichever party isn't EMV-compliant. Deploy an uncertified or flawed terminal running EMV POS software and you push fraud liability onto the merchant using your product. The stakes are real because the technology works when it's done right. Merchants using chip-enabled terminals saw an 80% drop in counterfeit fraud between 2015 and 2018, and roughly 95% of card-present transactions globally now use EMV chip technology, according to EMVCo's data as of December 2023. A terminal that flunks its checks exposes your customers.

Getting it right with a partner

Correct EMV POS software implementation is what stands between your product and fraud exposure, while failed certifications keep the launch date moving. Everything above points to one honest conclusion: the EMV flow and the certification gauntlet demand expertise that's scarce and slow to grow. Building a team that knows EMV kernel development and chip card processing from the inside is expensive, and hiring for certification expertise is hard.

So weigh the build-versus-partner decision on real terms. If your core product isn't payments, spending a year and a half learning certification the hard way is a steep price. EGS has done this EMV kernel development work before, across flow design and kernel integration, with scheme certification cycles that stall most teams. If you want to pressure-test your project scope against people who've shipped EMV POS software, book a call with EGS and get an honest read before you commit the timeline.