The Terminal

20.0 What this chapter gives you#

1. You will be able to explain why a card machine wipes its own keys the instant its case is opened, and why the result is a device that will never take another payment.
2. You will be able to say what tamper response protects and what it does not, and why overlays, shimmers and prompt manipulation make the enclosure the wrong place to look.
3. You will be able to name the three certification regimes, say who runs each and what each actually tests, and stop hearing “EMV certified” as a security statement.
4. You will be able to read a PCI approval listing and see that it attaches to a hardware revision, a firmware version and an expiry date rather than to a product name.
5. You will be able to explain why deployment takes months, and point at the stage of the process that repeats per scheme and per configuration.
6. You will be able to separate minor terminal settings from major ones, and say which change invalidates the description of an approved configuration.
7. You will be able to pick the right PCI approval class for a form factor, from a countertop terminal to a fuel dispenser to a PIN pad module inside somebody else’s kiosk.
8. You will be able to explain why an unattended fuel transaction runs as a pre-authorisation and a completion, and why the enclosure that matters there is the dispenser’s door.
9. You will be able to say what changed with softPOS: that PCI lists a whole solution rather than a phone, and that attestation and monitoring replaced the mesh.
10. You will be able to point at the four kernel data objects where the contactless limits actually live, and explain why a regulator can change a rule overnight and an estate cannot.

The previous chapters were about the card. Each of them had a second party standing just off the page, holding out a slot or a radio field and asking the questions. This chapter is about that second party.

It is the least glamorous object in payments and the most heavily regulated. A card is a piece of plastic a bank posts to you. A terminal is certified hardware built under audit, attacked in a laboratory with a scalpel and an oscilloscope, carrying an approval number valid until a stated date, and becoming an inert brick the moment somebody opens the case. Three separate certification regimes sit on top of it, run by three different sets of people, none of whom accepts the others’ paperwork. That is why it takes months rather than days to put a new one into a shop, and why the machine in a corner shop in Leeds and the one at a motorway fuel pump in Perth are not the same class of object at all.

The plain version#

Think of the card machine as a locked translation booth.

Two parties who cannot speak to each other need to do business. One is your card, which speaks a compressed technical language and will only answer certain questions in a certain order. The other is your bank, hundreds of miles away, which speaks a different language entirely. Between them sits a booth with a window on each side and a translator inside, who listens to the card, writes the question down in the bank’s language, sends it off, waits, and tells everybody what happened.

Now the important part. The translator also hears your PIN. That single fact changes everything: it is why the booth is locked, why the walls are lined with sensors, and why there are rules about who may build one, who may deliver one, and what must happen if anybody ever gets inside.

The dye pack#

Banks used to put dye packs into bags of cash. Force the bag open away from the counter, a small charge goes off, the notes are stained bright red, and the robbery has produced a bag of worthless paper. The money simply stops being money. The card machine works on exactly that principle, and it is the single most useful thing to understand about it.

Inside every one of these machines are secret numbers, called keys. They let the machine scramble your PIN so nobody along the wire can read it, and without them it cannot take a payment at all. The keys are worth stealing; the plastic case is not.

So the case is wired. A fine mesh, thinner than a hair, is printed around the inside carrying a small current. There are little switches under the screws, and sensors that notice if the machine gets very cold, or if somebody slows its clock down, or if light reaches a place inside where light never reaches. All of it runs day and night, even while the terminal sits unplugged in a stockroom.

Cut the mesh, undo the wrong screw, freeze it, drill it: the machine wipes its keys. Not “logs an alert”. Wipes them, in the instant, permanently. Switch it back on and the screen says something like TAMPER, and it will never take a payment again. It goes back to the manufacturer to be rebuilt and re-keyed.

The thief has the bag. The money is red.

The family of machines#

The booths do not all look the same, because the jobs differ.

There is the countertop one by the till, and the portable one the waiter carries to your table: the same machine with a battery and a radio, docking into a base near the bar. There is the little reader that pairs with a phone, which market traders and plumbers use: the phone does the amount and the internet, the reader does the card and the PIN.

There is the unattended one: the fuel pump, the car park machine, the vending machine, the ticket kiosk. Same job, no human anywhere near it, and that absence is the difficulty. In a shop, if somebody kneels at the counter for ten minutes with a screwdriver, the shopkeeper notices. At three in the morning at pump four, nobody notices.

There is the integrated till, where the card machine and the shop’s computer talk so nobody keys the amount twice. That sounds like a small convenience. It is where most of the interesting failures happen, because now there are two computers and only one of them is certified.

And lately there is the machine that has no machine: the shop’s own phone is the terminal, and you tap your card on the back of it. That required an entirely new rulebook, because every rule until then assumed a sealed case with a mesh in it.

A worked example: £34.60 in a bakery#

Here is a sale in a small bakery with one countertop terminal. The baker keys £34.60 into it; the screen shows 34.60 and the contactless symbol lights. You tap your card. The radio side wakes, powers your card through the air and asks which payment applications it carries; your card answers with a list, and the terminal picks one.

Now the terminal checks its own rulebook. It has been given four numbers by whoever runs its payments:

£34.60 is under £100, so no PIN. The floor limit is zero, so the bank gets asked anyway.

The terminal asks your card to sign the transaction. The card produces an eight-byte code — computed from the amount, the date, the currency, a random number the terminal invented on the spot and a counter inside the card — and hands it over. The terminal packs that code, the card number, the amount and about forty other small facts into a message and sends it down the line. Two seconds later the bank approves, the terminal beeps and prints, and the baker gives you your bread.

Now change one thing. Make it £134.60, because you bought a cake. Same tap, same card, but 134.60 is above the CVM required limit of £100, so the terminal asks for a PIN. You put the card in the slot and type four digits. Those digits never leave the sealed part of the machine as digits: they go straight into the secure processor, which scrambles them with one of its keys into a block of gibberish. The gibberish travels; the PIN does not.

If somebody has glued a fake keypad over the real one — an overlay — they get your PIN and the machine never knows, which is the first hint that the dye pack is not the whole story.

Why a new machine takes months#

The baker is switching payment provider, and assumes a new terminal is like a new kettle: order Tuesday, plug in Thursday. It is not, because three different bodies must each be satisfied by their own tests.

Test one: does the plug fit? Can this reader physically talk to a card — the right voltages in the right order in the slot, a radio field of the right strength so that a card held at a sensible distance actually answers? Electrical and mechanical, done once, by the manufacturer, for the model.

Test two: does the software know the rules? Inside the terminal is a program that knows the whole question-and-answer sequence a chip card expects: what to ask, in what order, what to do with each answer, when to go online, when to decline. It is tested against a very large book of scenarios, again by the manufacturer.

Test three: does this setup, talking to this bank, work end to end? This is the one that takes months, because it must be redone for the bakery’s particular combination of terminal, software version, payment provider and card schemes. Every scheme has its own test list; every test is a scripted transaction with a test card, checked field by field. One wrong value and that section starts again. Then someone must load the secret keys, two people present, in a room built for it, before the machine can take its first real payment.

That is the sentence to carry to dinner: the card machine is a locked booth that destroys its own secrets if you open it, and it takes months to deploy not because the hardware is hard but because three separate examiners must each pass it, and only the last of them cares about your particular shop.

Where the plain version stops being true#

The booth is a good picture, and it is wrong in four ways that matter to anyone who buys, builds or certifies one.

There is no such thing as “the terminal”#

The plain version speaks of one object with one approval. In the paperwork there is no such object. There is a contact interface module, separately approved; a proximity coupling device — the radio front end — separately approved; a contact kernel and up to eight contactless kernels, each separately approved; a PIN entry device with its own security approval, which may be a physically separate module bought from another vendor; a payment application on top of the kernels, which is nobody’s type approval and everybody’s problem; and the till, certified by no one.

Approvals attach not to a product name but to a product name plus a hardware revision plus a firmware version plus a checksum. Change the firmware and you may or may not still be approved, depending on which requirements the change touches; the process for answering that has a name, delta evaluation, and a laboratory must run it. Where a device embeds other approved devices, the renewal date of the whole is the earliest among all of them: one expiring component expires the terminal. So “is this terminal certified?” is not a yes or no question. It is a query against several lists, each with its own dates.

Tamper response protects the keys, not the transaction#

Tamper response guarantees one thing: an attacker who penetrates the enclosure gets no usable cryptographic material. It guarantees nothing about attacks that never penetrate it, and those are the ones that take money. Overlays: a moulded plastic keypad sitting on top of the real keypad, recording digits, defeated by nothing inside the box. Shimmers: a paper-thin device pushed into the card slot to sit between card and reader. Prompt manipulation: persuading the terminal to display “ENTER PIN” when the software behind it is not doing what the cardholder thinks. And at unattended sites the enclosure that matters is the dispenser’s door, not the payment module’s.

PCI’s requirements do address prompt control, and its technical FAQ spends considerable space on touchscreens precisely because a bezel can conceal an overlay. But the honest statement is narrower than the analogy: opening the box is one of the harder ways in, which is why intelligent attackers stopped trying.

The three certifications test three unrelated things#

“EMV certified” is used in the trade as though it were a security statement. It is not. EMVCo’s functional approvals assess performance and compatibility: Level 1 asks whether the electrical and radio interface conforms, Level 2 whether the kernel implements the specified processing logic. Neither asks whether the device resists attack.

The security standard for the terminal is PCI PTS POI, from a different organisation, tested in different laboratories, against a different document. Level 3 is a third thing again: not run by EMVCo, not a security test, and not a conformance test in the usual sense, but an integration test whose content each payment system writes for its own acquirers. Merchants routinely assume that possession of any one implies the others. Nothing implies anything.

With softPOS, the phone is not the terminal#

The last form factor breaks the analogy rather than stretching it. When the shopkeeper’s own phone accepts the tap there is no sealed enclosure, no tamper mesh, no key store you control and no PCI PTS approval, because PCI PTS approves hardware and there is no hardware to approve. What replaced it is a different architecture: cryptographic work pushed into whatever secure element the phone already has, plus continuous attestation — the phone proving to a back-end service, repeatedly, that it is the device it claims to be and has not been rooted, hooked or emulated — plus monitoring, a server-side system that can refuse to let a suspect device transact. The certified thing is the whole solution including its servers, not the handset.

The security boundary therefore moved off the counter and into somebody’s data centre, and a softPOS solution can be switched off remotely in a way a countertop terminal never could: a real gain and a real new dependency, and the booth analogy has nothing to say about either.

The technical version#

What is physically inside#

A conventional attended terminal contains a contact card reader, a contactless front end, a secure processor with a protected key store, a keypad, a display, communications and usually a magnetic stripe head and a printer.

The contact interface is governed by ISO/IEC 7816: part 2 defines the eight contacts and their positions, part 3 the electrical characteristics and the transmission protocols, of which EMV uses the character-oriented T=0 and the block-oriented T=1. The reader must handle the class A (5 V), class B (3 V) and class C (1.8 V) supply classes cards may demand, negotiate the answer-to-reset, and cope with cards inserted crookedly or withdrawn mid-transaction. In EMVCo’s vocabulary this component is the Interface Module, or IFM.

The contactless front end is governed by ISO/IEC 14443, at 13.56 MHz with an initial data rate of 106 kbit/s, supporting Type A and Type B modulation and framing, and supplies the card’s power through the field. In EMVCo’s vocabulary it is the Proximity Coupling Device, or PCD, specified in the EMV Contactless Interface Specification with the protocol layer in Book D of the EMV Contactless Specifications for Payment Systems.

The secure processor holds the keys, performs PIN block encryption, executes firmware whose authenticity it checks at boot and drives the tamper circuitry. It is permanently powered from a coin cell or supercapacitor, so the tamper sensors run while the terminal sits unplugged.

The catalogue of form factors#

PCI SSC’s approval classes, exactly as the approved-devices listing filters them, are PED, EPP, HSM, Multi-tenant HSM, UPT, Non PED, SCR, SCRP, KLD (key loading device) and RAP (remote administration platform). The PED/EPP distinction matters commercially: an EPP is a module supplied to an ATM or kiosk manufacturer, and a UPT built around an approved EPP still requires its own laboratory evaluation, because the final enclosure introduces cardholder interfaces the EPP vendor never saw. The OEM’s module cannot itself receive a UPT approval; the final form factor vendor’s product does, and the module is listed separately as an approved component.

EMV classifies the environment in a single byte, tag 9F35, Terminal Type, defined in Annex A of EMV Book 4. The first digit is who controls the terminal: 1 a financial institution, 2 a merchant, 3 the cardholder. The second digit carries environment and capability together, 1 to 3 attended and 4 to 6 unattended, and within each triple the order is online only, offline with online capability, offline only.

A supermarket lane is typically 21 or 22, a fuel dispenser 24 or 25, a bank-operated ATM 14. Terminal Type is a major setting: change it and the Level 2 approval of the configuration no longer describes the device.

The PIN entry device as a certified object#

The security standard is the PCI PIN Transaction Security Point of Interaction Modular Security Requirements, published by the PCI Security Standards Council. Version 7.0 was published on 29 May 2025, superseding v6.2, and PCI SSC describes it as containing 59 requirement changes and 23 pieces of additional guidance arising from two requests for comment during 2024. Among them: a new requirement for the physical and logical security of biometric interfaces; a new requirement permitting third-party applications, that is, app stores, on a POI device; an allowance for keys not to be zeroised on tamper where forward secrecy is used and extraction would require destroying the processing element; and a rule that terminal security keys, such as firmware authentication and tamper or storage keys, must use cryptography with an effective key strength of 128 bits or stronger.

The standard is modular, which is the point of its name. The evaluation modules are: POI Device Core Requirements, covering core logical and physical requirements; Device Integration Requirements, which apply whenever previously approved components are combined; Open Protocols, covering the interface to open networks; Secure Reading and Exchange of Data, or SRED, covering encryption of account data inside the POI; and Device Management Security Requirements, covering how the device is produced, controlled, transported, stored and used across its life. Products need not support Open Protocols or SRED, but a product that implements either must be evaluated against that module.

Within those modules the requirements are lettered rather than numbered straight through: the core physical requirements run from A1, the core logical requirements from B1, and the SRED requirements are the K series, which is why practitioners talk about “requirement K20” rather than a section number.

Security is measured, not asserted. The standard uses an attack-costing framework expressed in points, combining the effort to identify an attack with the effort to exploit it. The headline physical requirement, A1, requires that defeating the device’s tamper protections to disclose sensitive material demands an attack potential of at least 26 points for identification and initial exploitation, with a minimum of 13 for initial exploitation. The same figures recur through the physical requirements, including side-channel monitoring during PIN entry.

Some specifics from PCI’s technical FAQ that decide whether a device passes:

Open Protocols. New POI evaluations using the Internet Protocol suite must support TLS 1.2 or higher, with cipher suites providing at least 112 bits of security. Suites using triple DES are no longer permitted, on the grounds that a 64-bit block size does not protect large volumes encrypted under one key. Where a device runs Android, the version must be one officially supported with security patches; reports submitted with an unsupported version are rejected, and where Google no longer patches, the vendor must evidence its own monthly patching, validated by the laboratory.

Key loading. The initial terminal master key must be loaded by asymmetric techniques or manual ones such as the keypad, an IC card or a key loading device; plaintext keys and their components are never permitted over a network connection. Key blocks are mandatory: ASC X9 TR-31 for triple DES keys, TR-31 or ISO 20038 for AES, or a demonstrably equivalent scheme that has passed independent expert review. Remote key distribution using asymmetric techniques follows ASC X9 TR-34, in either its two-pass form using nonces or its one-pass form using timestamps, and binding the device to its key distribution host is a prerequisite for both. PIN block formats are constrained too: ISO 9564 format 4, the AES format, is treated explicitly, with its use distinguished under DUKPT, fixed key and master/session key schemes. Where a device is compromised, keys are not reloaded by any methodology; the device is withdrawn.

Approval identity and expiry. A PCI listing identifies a device by model name and number, a hardware number that may contain wildcard positions, a firmware number, an approval number and an expiry date, alongside a vendor-published security policy setting out the roles the device supports and the services each may use. The device must perform only its designed functions; no hidden functionality is permitted. Approvals expire, and the vendor must have the model re-evaluated against the current version before the renewal date. PCI SSC’s listing records that version 3 POI approvals expired on 30 April 2021 and version 4 on 30 April 2024. Version 5 approvals were due to expire on 30 April 2026, and a Council bulletin of September 2025 extended them by one year to 30 April 2027, which is now the earliest expiry date on the approved-devices list. These dates govern new deployments rather than the instant removal of installed units, but they are why estates are replaced on a cycle unrelated to hardware wearing out, and why the version of an approval matters as much as its existence.

Tamper: what actually happens#

PCI’s technical FAQ leaves no room for a cheaper design. A card reader or non-PIN device cannot meet the physical requirements through tamper resistance and tamper evidence alone; it must have permanently active tamper detection that monitors for intrusion and responds with the immediate erasure of sensitive information, rendering the device inoperative. More broadly, in PCI’s words: “A device cannot meet PTS POI requirements without having an active tamper response mechanism to zeroize secret and private keys during a penetration attack regardless of which modules of the PTS POI standard the device is designed to comply with.”

The mechanisms in a real device are layered. A flexible printed circuit or serpentine trace forms a mesh wrapping the secure area, monitored for open circuit, short circuit and resistance change, so that cutting it, bridging it or drilling through it all register. Switches detect case separation, light sensors an opened enclosure, and further sensors out-of-range temperature, supply voltage and clock frequency, defeating the classic laboratory tricks of freezing memory so that it retains its contents or under-clocking a processor to make its behaviour observable. Where the device offers a service hatch, requirement K20 of the SRED module obliges the design either to make sensitive material physically unreachable from that hatch or to erase it when the hatch is opened.

The response is defined as tightly as the detection. On tamper the device must become immediately inoperable and must automatically erase secret information such that recovery becomes infeasible. The FAQ closes the obvious loopholes: keys that could be used to download further keys must be zeroised or rendered unusable for that purpose, covering both symmetric key-encrypting keys and the private keys used in asymmetric key loading; and where a device encrypts other keys under an internally generated key held in a register, erasing that one register suffices, provided the encrypted keys are protected under compliant algorithms and key sizes.

A tampered PIN-acceptance device must immediately stop processing all PIN-based transactions. If a reset is implemented at all, only one is permitted unless the device is removed for inspection and repair, and any intervention that re-enables transactions requires on-site presence, dual control, logged user identities with timestamps and actions, and authentication values that cannot be replayed on the same or another device. Decommissioning is a security event too: PCI PIN Security requires that a device removed from service has all keys destroyed that were, or could have been, used for any cryptographic purpose — firmware validation keys, display prompt control keys and keys used during loading included — and if that cannot be assured, the device is physically destroyed.

The practical consequences are unglamorous and expensive. Terminals tamper for reasons unconnected with attack: dropped on a tiled floor, left in a van overnight in February, battery flat for months in a drawer, or a well-meaning engineer removing a case screw. Each produces a device that cannot be repaired in the field, must be returned and must be re-keyed under dual control. It cannot be swapped for a spare unless the spare was keyed in advance, so estates carry keyed spares, and keyed spares are themselves controlled inventory.

EMV certification, level by level#

Level 1 tests the electrical, mechanical and radio-frequency interfaces. For contact the object of the test is the IFM; for contactless, the PCD. EMVCo defines the processes and recognises the laboratories but performs no testing itself: laboratories test with qualified tools and submit reports, and EMVCo issues a Letter of Approval when a report demonstrates sufficient conformance. Contactless Level 1 includes range and positioning tests, measuring how close a card must be held before the exchange succeeds — a functional question with a large effect on how the terminal feels to use.

Because a phone’s antenna is not designed to be a payment reader’s antenna, EMVCo launched a Reduced Range PCD Level 1 approval process on 10 September 2024, defining two reduced-range compliance levels with different read-range and positioning requirements, specifically so TapToMobile devices could be measured at all.

Level 2 tests the kernel. For contact, the governing document is the EMV Integrated Circuit Card Specifications for Payment Systems, version 4.4 of October 2022, in four books: Book 1 on the application-independent ICC-to-terminal interface, Book 2 on security and key management, Book 3 on the application specification, Book 4 on cardholder, attendant and acquirer interface requirements. EMVCo now calls this the Contact Kernel Approval Process; the vendor registers once, declares the product in an Implementation Conformance Statement on a versioned form — 4.4c and 4.4d are the current ones — has a recognised laboratory run the Terminal Level 2 Test Cases, and receives a four-year Letter of Approval.

For contactless the architecture is different and routinely misdescribed. The EMV Contactless Specifications for Payment Systems comprise Book A (Architecture and General Requirements), Book B (Entry Point), Books C-1 to C-8 (the kernel specifications) and Book D (the contactless communication protocol). Books A and B and the C-x kernel books stood at v2.12, published 6 July 2026. Books C-1 to C-7 are the individual payment systems’ kernels, published by EMVCo on their behalf, with test plans managed by the relevant scheme rather than by EMVCo. Book C-8 is EMVCo’s own kernel, separately versioned at v1.2 and licensable on the same terms as the contact specification; it introduces a split architecture allowing processing in different locations including the cloud, Secure Channel, Blinded Diffie-Hellman and elliptic-curve cryptography, and it may be tested either inside a full acceptance device or standalone.

A contactless product approval requires the successful validation of the PCD, of Entry Point (Books A and B) and of at least one kernel, and ends with a three-year Letter of Approval — one year shorter than the contact kernel’s. Where a manufacturer’s architecture complies with EMVCo’s Modular Architecture Requirements, an EMVCo-qualified compliance auditor must validate that architecture and report to EMVCo before approval, and separate lighter processes exist for a product change, a derivative product and a renewal.

The granularity of an actual approval surprises people. A contact Level 2 Letter of Approval names a kernel version, tested on a named terminal model, with a named PIN pad running named firmware, on a named operating system. It carries approval numbers of the form 2-05820-1-1S-0426-4.4c, in which the trailing element is the specification version tested against and the four digits before it the month and year of approval, plus a renewal date four years out, a laboratory report identifier, an eight-hex-digit kernel checksum and a separate configuration checksum. EMVCo states in it that the samples sufficiently conform, and that the letter is valid while the approval number is posted on the EMVCo website — which is to say, EMVCo can end it.

Attached is the Implementation Conformance Statement, and it is the ICS, not the letter, that tells you what the terminal can do. It enumerates, item by item: manual key entry, magnetic stripe and contact IC input; plaintext PIN, enciphered online PIN, paper signature, offline enciphered PIN, no-CVM and biometric CVMs; SDA, DDA, CDA and Extended Data Authentication; whether the terminal performs floor limit checking, random transaction selection and velocity checking; whether it holds a transaction log or exception file; and whether it supports PIN bypass.

That granularity is why re-certification is a live risk rather than a formality. Terminal settings divide into minor ones — Terminal Country Code, tag 9F1A, or Transaction Currency Exponent, tag 5F36 — changeable freely, and major ones, such as Terminal Type, tag 9F35, whose change invalidates the description of the approved configuration.

Level 3 is the integration test, and EMVCo describes its own role narrowly: L3 validates the integration of an approved acceptance device with its acceptance infrastructure, and the test plans are provided not by EMVCo but by the Participant Systems — the payment systems and other entities that elect to use the framework. What EMVCo supplies is the EMV L3 Testing Framework: standardised test-tool components, a qualification process for L3 test tools, and a Participant System Identifier service that lets domestic schemes place their own requirements inside a qualified tool alongside the international schemes’, so the tool selects and runs the right tests for the right system. In practice your acquirer or processor obtains a qualified tool, loads the relevant test plans and runs scripted transactions against your terminal and your host, scheme by scheme and configuration by configuration, each result inspected field by field.

Why deployment takes months#

Two features of that table explain the months. First, the repeat column: L3 is per scheme and per configuration, so an estate supporting four schemes across attended, unattended and mobile configurations is not running one certification but a matrix of them. Second, the delta problem: a change to the payment application, the kernel version, the terminal type or the CVM configuration can reopen the L3 matrix and, if it touches security, the PTS evaluation as well. A laboratory test cycle cannot be paused and resumed either: if it ends with discrepancies, it ends.

Unattended terminals#

The unattended payment terminal is not a countertop terminal in a metal box. PCI treats the UPT as its own approval class, covering cardholder-operated devices that read, capture and transmit card information in conjunction with an unattended self-service device, with fuel dispensers, ticketing machines and vending machines named explicitly, and notes that UPTs may have a compound architecture combining payment with the delivery of goods or services. That compound architecture is the difficulty: the payment module and the thing being sold share an enclosure, a controller and often a maintenance regime, and the people who service the dispenser are not the people who understand the payment module.

Three consequences follow. The first is prompt control: in an attended environment the cardholder can see who is asking for the PIN, while in an unattended one the display and keypad may be driven by a device controller outside the secure boundary, which is why PCI constrains what may be displayed during PIN entry, and why an EPP with no display of its own must be integrated with a display it can trust.

The second is inspection. An overlay on a countertop keypad has a shopkeeper looking at it all day; an overlay inside a fuel dispenser has nobody. Estate owners answer with tamper-evident seals, dispenser door alarms wired into the site controller and scheduled physical inspection — none of it in the terminal standard, all of it in the operational regime around it.

The third is the transaction shape. An unattended fuel transaction cannot know its final amount before authorisation, because the fuel has not been dispensed; it runs as a pre-authorisation for an estimated amount followed by a completion for the actual amount, so the terminal must support offline data capture and later completion messaging, and the terminal type byte reflects that offline capability. Vending and parking behave differently again, often as small online transactions with no CVM at all. Fuel also has its own integration standard, maintained by IFSF, between forecourt controller, dispenser and payment application.

softPOS: when the phone is the terminal#

The standards arrived in three steps. PCI SSC published Software-based PIN Entry on COTS (SPoC) in 2018 for PIN entry on an ordinary phone paired with a secure card reader, and Contactless Payments on COTS (CPoC) in 2019 for contactless acceptance on the phone’s own NFC with no PIN. It then combined them into Mobile Payments on COTS (MPoC), first published in November 2022, with version 1.1 in November 2024, whose principal addition is allowing both PIN entry and contactless card data on the same commercial off-the-shelf device.

“Objective-based”, PCI’s own description of MPoC, is doing real work. PCI PTS specifies a physical enclosure and tests it with tools; MPoC cannot, because the enclosure is a phone the solution provider did not design and cannot control. It therefore states security objectives and requires evidence that the solution meets them, across the software, the back-end, the attestation mechanism and the monitoring system. Solutions, not devices, are listed.

Apple’s implementation is the best-documented public example. In Tap to Pay on iPhone the Secure Element hosts the payment acceptance applets and the kernel configurations, downloaded from Apple’s servers and validated for integrity and authenticity before installation. The applet performs the card read and then encrypts and signs the card data, so the card number is, in Apple’s words, “secured by the Secure Element and isn’t visible to the acceptance device”, and is released only to the merchant’s payment service provider. The Secure Element also captures the PIN digits and builds the encrypted PIN block; screenshots and screen recording are blocked during PIN entry; and because the phone has been facing the payer, the merchant must re-authenticate with Face ID, Touch ID or a passcode to get control of it back. Apple states that on iOS 18.4 or later Tap to Pay on iPhone is a PCI MPoC validated solution listed by PCI SSC, and that its servers monitor device security compatibly with MPoC. Store-and-forward transactions do not support PIN entry.

On the EMVCo side nothing is waived. A TapToMobile solution still needs Level 1 for its reader, which is why the Reduced Range PCD process exists, Level 2 for its kernels, which is why kernel configurations are provisioned onto the Secure Element at all, and Level 3 with each acquirer. So softPOS is not “a phone with PCI approval” — PCI PTS does not approve phones — but a listed solution of which the phone is one component, and it does not remove certification effort so much as move it: the hardware burden goes and a continuous attestation, monitoring and lifecycle burden takes its place.

The integrated till, and the interface nobody certifies#

An integrated deployment connects the electronic cash register to the payment terminal so the basket total flows across automatically and the result flows back. In a fully integrated design the ECR drives the payment device directly and is therefore in scope for card data. In a semi-integrated design — now the common architecture — the ECR sends only an amount and receives only a result, card data never traverses it, and the till leaves PCI DSS scope for that data, which is very often the entire commercial reason the architecture exists.

The interface between them is covered by no EMVCo or PCI approval. In practice it is either proprietary to the terminal vendor or acquirer, or an industry protocol: nexo standards’ Retailer protocol, built on ISO 20022 messages, specifying the interface between payment application and ECR, with the companion nexo FAST specification defining the payment application itself; or IFSF’s equivalents in fuel. Choosing an open protocol does not shorten Level 3, which tests the messages that reach the acquirer, not those that cross the counter.

The terminal’s own configuration#

Everything a terminal decides is driven by data loaded into it, per acquirer and per application identifier. These are the terminal-side data objects a practitioner meets most often, as defined in EMV Book 3 Annex A.

Alongside these sit the Terminal Action Codes — Default, Denial and Online, five bytes each, held per application identifier. They are terminal-resident acquirer policy, bit-masked against the Terminal Verification Results together with the card’s Issuer Action Codes to decide whether to decline offline, go online or approve offline. Getting them wrong is the classic cause of a terminal that approves offline what it should have sent online, and it is exactly what Level 3 exists to catch.

The contactless reader carries a second set of limits, held by the kernel rather than the contact application. In the Kernel 2 configuration these are the Reader Contactless Floor Limit at tag DF8123, the Reader Contactless Transaction Limit without on-device CVM at DF8124, the Reader Contactless Transaction Limit with on-device CVM at DF8125, and the Reader CVM Required Limit at DF8126. Those four values, per application and per currency, decide whether a tap goes through, whether it demands a PIN and whether it is refused outright.

Which is where this chapter ends, because those four numbers are also where policy lands. From 19 March 2026, following an FCA announcement in December 2025, United Kingdom firms with strong fraud controls have been permitted to set their own contactless limits in place of the old fixed pair of £100 per transaction and £300 in the background. UK Finance’s guidance observes that most banks were likely to keep existing limits at first, and that “separate changes would also need to be made to card acceptance terminals and the industry rules that govern them to process contactless card payments above £100”. A regulator can change a rule overnight. Changing DF8124 across a national estate is a deployment programme, and mobile wallets were never inside the cap in the first place, because they are governed by DF8125.

20.98 Common wrong ideas#

Wrong: a terminal is one object with one approval. Right: it is a contact interface module, a proximity coupling device, a contact kernel and up to eight contactless kernels, a PIN entry device and an uncertified payment application, each with its own paperwork and its own dates.

Wrong: the approval belongs to the product. Right: it belongs to a product name plus a hardware revision plus a firmware version plus a checksum, and where approved devices are embedded in others the earliest renewal date among them expires the whole terminal.

Wrong: tamper response protects the transaction. Right: it guarantees only that an attacker who penetrates the enclosure gets no usable cryptographic material, and the attacks that take money — overlays, shimmers, prompt manipulation — never go inside the box.

Wrong: “EMV certified” means the device is secure. Right: EMVCo Level 1 tests the electrical and radio interface and Level 2 the kernel logic; neither asks whether the device resists attack, and the security standard is PCI PTS POI from a different organisation entirely.

Wrong: Level 3 is another conformance test. Right: it is an integration test whose plans each payment system writes for its own acquirers, run in a qualified tool, repeated per scheme and per configuration.

Wrong: a tampered terminal can be reset on site. Right: it cannot be repaired in the field; it goes back to be re-keyed under dual control, which is why estates carry pre-keyed spares as controlled inventory.

Wrong: terminals tamper because somebody attacked them. Right: most tamper because they were dropped, left in a van overnight in February, allowed to go flat in a drawer, or opened by a well-meaning engineer — and the response is identical.

Wrong: an approved encrypting PIN pad inside a kiosk makes the kiosk approved. Right: the final form factor needs its own evaluation, because the finished enclosure introduces cardholder interfaces the module vendor never saw.

Wrong: softPOS is a phone with a PCI approval. Right: PCI PTS approves hardware and there is no hardware to approve; what is listed is a whole solution, including its attestation and monitoring servers, of which the phone is one component.

Wrong: the FCA removing the contactless caps raised the limit. Right: the limits live in reader data objects across a national estate, so changing them is a deployment programme accompanied by changes to the industry rules — and wallets were never inside the cap anyway.

20.99 Chapter summary in 20 lines#

1. The terminal is the second party standing just off the page in every chapter about the card: the thing holding out a slot or a radio field and asking the questions.
2. It is best pictured as a locked translation booth, listening to the card in one language and to the bank in another.
3. What makes it a certified object rather than a peripheral is that the translator also hears your PIN.
4. Inside sits a secure processor holding the keys, checking its own firmware at boot and driving a tamper circuit powered from a coin cell so it runs even while the terminal is unplugged in a stockroom.
5. A fine mesh, switches under the screws and sensors for light, temperature, supply voltage and clock frequency all report to that circuit.
6. On tamper the device zeroises its keys immediately and becomes inoperable, like a dye pack turning a bag of notes into worthless paper.
7. That protects the keys and nothing else: overlays, shimmers and prompt manipulation take money without ever entering the enclosure, which is why intelligent attackers stopped trying to open it.
8. The form factors differ by job — countertop, portable, mPOS reader, unattended kiosk, PIN pad module, softPOS — and each maps to its own PCI approval class.
9. EMV records the environment in a single byte, Terminal Type at tag 9F35, encoding who operates the device and whether it is attended and online-capable.
10. The security standard is the PCI PTS POI Modular Security Requirements, now version 7.0, modular by design and measuring attack potential in points rather than asserting it.
11. Approvals name a hardware revision, a firmware version and an expiry date, so “is this terminal certified?” is a query against several lists rather than a yes or no.
12. EMVCo’s Level 1 and Level 2 approvals assess conformance and processing logic; neither is a security test.
13. Level 3 is not EMVCo’s test at all but the Participant Systems’ integration test plans, run by an acquirer or processor in a qualified tool.
14. A Level 2 letter names a kernel version on a named terminal with a named PIN pad and firmware, and the attached Implementation Conformance Statement, not the letter, is what tells you what the terminal can do.
15. Settings divide into minor ones that may be changed freely and major ones, such as Terminal Type, whose change means the approval no longer describes the device.
16. Deployment therefore takes months because Level 3 repeats per scheme and per configuration, because a delta can reopen the matrix and the security evaluation with it, and because keys must then be injected under dual control.
17. Unattended terminals are a class of their own: nobody to notice an overlay, a display and keypad possibly driven from outside the secure boundary, and an enclosure shared with the goods being sold.
18. A fuel transaction cannot know its own amount before dispensing, so it runs as a pre-authorisation followed by a completion, and the terminal type byte must reflect that offline capability.
19. softPOS removes the enclosure and replaces it with continuous attestation and server-side monitoring, moving the security boundary off the counter and into a data centre without removing any EMVCo obligation.
20. Everything the terminal decides comes from data loaded into it, and the four contactless reader limits are where policy finally lands — which is why a rule can change overnight and a national estate cannot.

Sources: EMVCo specification, approval-process and knowledge-hub pages, published Letters of Approval, the EMV Contactless Specifications for Payment Systems and the EMV Integrated Circuit Card Specifications v4.4; PCI Security Standards Council publications, including the PTS POI Modular Security Requirements v7.0 announcement, the PTS Device Testing and Approval Program Guide, the PTS POI technical FAQs, the approved PTS devices listing and the MPoC standard pages; Apple’s Tap to Pay on iPhone security documentation; UK Finance guidance on contactless card limits; ISO/IEC 7816 and ISO/IEC 14443; nexo standards and IFSF documentation.