How POS Terminals Actually Work

A point-of-sale terminal looks like a small peripheral. It has a screen, a card slot, a contactless antenna, a keypad, a printer in some models, and a network connection. A customer taps a card, enters a PIN if asked, and the merchant sees approved or declined.

The terminal is doing more than reading a number and calling a bank.

A modern POS terminal is a secure payment computer. It runs certified payment software, talks to EMV chips through APDU commands, manages contactless kernels, performs terminal risk management, captures PINs inside a protected environment, builds authorisation messages, stores receipts, handles reversals, supports fallback, and protects keys under strict hardware and software controls.

This article explains how POS terminals actually work. We will cover device architecture, EMV kernels, APDU exchange, contact and contactless flows, terminal action analysis, cardholder verification, secure PIN entry, online authorisation, receipts, offline approval, fallback, store-and-forward, key management, estate operations, and why payment terminals are treated as security devices rather than ordinary tablets with card readers.

A POS Terminal Is a Secure Transaction Endpoint

The terminal is the merchant-side endpoint where the transaction begins.

It usually handles:

• card reading
• contactless field generation
• EMV application selection
• terminal risk management
• cardholder verification prompts
• PIN entry
• transaction amount confirmation
• message construction
• acquirer host communication
• receipt generation
• reversal and batch handling

Depending on merchant setup, the terminal may be standalone, integrated with an electronic point-of-sale cash register, part of an unattended kiosk, or embedded inside a vending machine, parking machine, ticket gate, or petrol pump.

The terminal must bridge two worlds:

customer and card interaction
  -> secure payment protocol processing
  -> acquirer network and merchant system integration

This is why terminals are certified and controlled. A compromised terminal can steal card data, capture PINs, alter amounts, suppress reversals, or route transactions incorrectly.

The Hardware Boundary Matters

A payment terminal commonly includes:

• main application processor
• secure processor or security module
• tamper sensors
• secure keypad
• display
• contact chip reader
• magnetic stripe reader on some devices
• NFC antenna and radio front end
• printer
• Ethernet, Wi-Fi, cellular, or Bluetooth connectivity
• secure key storage

The most important boundary is the one around sensitive payment data and PIN entry. PCI PTS-style requirements exist because the terminal must protect PINs and cryptographic keys even if the device is physically accessible to merchants, staff, or attackers.

Tamper controls may respond to:

• case opening
• voltage manipulation
• temperature attack
• probing attempt
• clock attack
• mesh break

If tamper is detected, the terminal may erase sensitive keys. That can make the device unusable until re-injected or replaced, but it prevents attackers from extracting secrets.

This is why a payment terminal is not equivalent to a cheap Android tablet plus USB card reader. The security boundary is part of the product.

The EMV Kernel Is the Payment Protocol Engine

The EMV kernel is the software component that implements EMV transaction logic for a payment application or contactless scheme profile.

It handles tasks such as:

• application selection
• reading card records
• processing restrictions
• cardholder verification
• terminal risk management
• data authentication
• terminal action analysis
• generating application cryptograms
• issuer script processing

There may be different kernels for contact EMV and different contactless brands or profiles. Contactless kernels are often scheme-specific because each network's contactless rules differ in timing, data, and risk handling.

The kernel sits between the terminal application and the card. The merchant app may say:

start purchase for €23.40

The kernel turns that into a structured conversation with the card:

select application
get processing options
read application records
perform verification and risk checks
request cryptogram
return transaction outcome

This separation is why terminal certification focuses heavily on kernels. If the kernel implements EMV incorrectly, the terminal may approve transactions it should decline or fail transactions it should accept.

APDU Commands Are the Language Between Terminal and Chip

For contact chip transactions, the terminal communicates with the card using APDUs, application protocol data units.

A simplified exchange:

terminal -> card: SELECT payment application
card -> terminal: application selected
 
terminal -> card: GET PROCESSING OPTIONS
card -> terminal: AIP and AFL
 
terminal -> card: READ RECORD
card -> terminal: card data records
 
terminal -> card: GENERATE AC
card -> terminal: application cryptogram

The APDU format carries command class, instruction, parameters, command data, and expected response length. The response carries data and status words.

Example status words:

9000: success
6A82: file or application not found
6985: conditions of use not satisfied

The customer never sees this conversation. The terminal screen may only say "processing". Underneath, the card and terminal exchange structured commands that determine the payment application, read records, verify risk parameters, and create cryptographic evidence.

Application Selection Decides Which Card Application Runs

A card can contain multiple applications. A terminal must choose the correct one.

The card and terminal use application identifiers, or AIDs. For example, a card may support debit and credit applications, domestic and international applications, or contact and contactless profiles.

The terminal may:

• build a candidate list
• compare supported AIDs
• apply priority rules
• ask the customer to choose if multiple applications are available
• select the final application

Application selection affects fees, routing, risk rules, and cardholder experience. In some European markets, domestic debit applications may coexist with international scheme applications. The terminal configuration and merchant agreement may influence routing choices where rules allow.

Bad application selection can produce wrong routing or failed transactions. It is not a cosmetic menu.

AIP and AFL Tell the Terminal What to Do Next

After selection, the terminal sends GET PROCESSING OPTIONS. The card returns data including:

• application interchange profile, AIP
• application file locator, AFL

The AIP tells the terminal which capabilities and checks are relevant. The AFL tells the terminal which records to read from the card.

The terminal then reads the indicated records. Those records may include:

• primary account number or equivalent token data
• expiry
• application usage controls
• cardholder verification method list
• public key certificate data
• risk parameters
• issuer application data

This is why EMV is not "read card number and send". The card provides a structured set of data and rules. The terminal kernel interprets them according to EMV and scheme requirements.

Terminal Risk Management Happens Before Online Authorisation

The terminal performs local risk checks before deciding whether to go online, approve offline, or decline.

Checks may include:

• floor limit
• random transaction selection
• velocity checking where supported
• expired application
• service restrictions
• exception file
• offline data authentication result
• cardholder verification result
• terminal country and currency constraints

The terminal has its own configuration:

floor limit: €0 for many chip retail profiles
contactless CVM limit: market-specific
terminal capabilities: online PIN, offline PIN, signature, no CVM
terminal type: attended POS

Many modern terminals force online authorisation for most retail transactions, especially where connectivity is reliable. But terminal risk management still matters because it produces bits used later in terminal action analysis and issuer decisioning.

Offline Data Authentication Checks the Card Is Genuine Enough

EMV supports offline data authentication methods:

• SDA, static data authentication
• DDA, dynamic data authentication
• CDA, combined dynamic data authentication and application cryptogram

SDA proves that card data was signed by the issuer but does not prove the chip can generate fresh signatures. DDA adds dynamic challenge signing. CDA combines dynamic authentication with transaction cryptogram generation, improving protection against certain attacks.

The terminal uses public key certificates and scheme public keys to verify card data. This lets the terminal detect some counterfeit cards even before going online.

Offline data authentication is not the same as issuer online authorisation. It answers a different question:

Does the card data and cryptographic proof look valid under EMV rules?

Online authorisation asks:

Does the issuer permit this transaction now?

Both can matter.

Cardholder Verification Is a Negotiation

The terminal and card decide how the cardholder should be verified.

Possible CVMs include:

• offline plaintext PIN
• offline enciphered PIN
• online PIN
• signature
• no CVM
• consumer device cardholder verification method for mobile wallets

The card contains a CVM list. The terminal has capabilities. The amount and transaction context matter. The kernel chooses an applicable method.

For example:

if amount below contactless CVM limit:
    no CVM may be allowed
else if terminal supports online PIN:
    prompt for PIN
else:
    decline or choose another allowed CVM

For mobile wallets, the phone may perform biometric or device PIN verification. The terminal may see this as a CDCVM result and avoid asking for terminal PIN.

Cardholder verification is therefore not simply "always ask PIN". It is a rule-driven outcome of card, terminal, amount, and scheme context.

Secure PIN Entry Is Isolated

When a customer enters a PIN, the terminal must protect it.

Online PIN is usually encrypted into a PIN block and sent to the issuer or processor for verification. The clear PIN should not be exposed to the merchant application, operating system logs, or ordinary memory.

The secure PIN entry path involves:

• secure keypad
• PIN entry timeout
• PIN block formation
• encryption under terminal keys
• key hierarchy managed through acquirer or processor
• tamper response if keys are attacked

The merchant application should receive only a result, not the PIN.

This is why certified terminals restrict debugging, screen capture, key access, and application loading. A malicious merchant app must not be able to intercept PIN digits.

Terminal Action Analysis Decides the Transaction Path

After reading card data, verifying cardholder method, and running risk checks, the terminal performs terminal action analysis.

The terminal compares:

• terminal verification results
• issuer action codes from card
• terminal action codes from configuration
• transaction context

The outcome can be:

• request offline approval
• request online authorisation
• decline offline

The terminal then asks the card to generate an application cryptogram:

• TC, transaction certificate for approval
• ARQC, authorisation request cryptogram for online authorisation
• AAC, application authentication cryptogram for decline

Most retail flows produce an ARQC, meaning the terminal must go online to the issuer. But offline TC and offline AAC remain part of the EMV model.

The cryptogram outcome is important evidence. The issuer can validate ARQC data to confirm the chip participated in this transaction.

Online Authorisation Builds the Acquirer Message

When online authorisation is required, the terminal sends transaction data to the acquirer host.

The message includes:

• amount
• currency
• merchant id
• terminal id
• entry mode
• card data or token data
• EMV data elements
• cryptogram
• PIN block if online PIN was used
• transaction sequence data

The acquirer forwards the transaction through the scheme to the issuer. The issuer validates EMV data, risk, funds, and product rules. It returns approval or decline.

The terminal then displays the outcome and may ask the card to complete the transaction with issuer response data.

For contact EMV, the second GENERATE AC may produce a final cryptogram reflecting issuer response. For contactless, flows vary and are optimised for speed.

Receipts Are Evidence, Not Settlement Proof

The receipt is a local transaction record.

It may include:

• merchant name and location
• masked PAN or token reference
• application label
• amount
• date and time
• authorisation code
• terminal id
• merchant id
• cardholder verification method
• response text

An approved receipt proves the terminal received an approval response or produced an offline approval. It does not prove merchant funding is complete. Settlement and clearing still happen later.

Receipts matter for:

• customer disputes
• merchant reconciliation
• terminal batch close
• chargeback evidence
• offline transaction upload

Digital receipts and merchant POS integrations still need the same core evidence. A paper slip is only one representation.

Fallback Exists Because Card Reading Fails

Terminals may support fallback when chip or contactless reading fails.

Fallback can include:

• contactless to contact chip
• chip to magnetic stripe
• online key entry in limited merchant contexts

Fallback is risky because it may weaken security. Magnetic stripe data is easier to clone than EMV chip data. Keyed entry has higher fraud risk. Schemes and acquirers therefore monitor fallback rates.

A high fallback rate may indicate:

• faulty terminal
• damaged cards
• merchant training issue
• deliberate fraud attempt
• misconfigured terminal

The terminal should record fallback reason and entry mode. The issuer uses that data in authorisation risk scoring.

Fallback is not a convenience feature to bypass chip. It is a controlled exception path.

Store-and-Forward Handles Connectivity Gaps

Some terminals operate where connectivity is unreliable. They may support store-and-forward under strict rules.

In store-and-forward, the terminal accepts transactions locally and uploads them later. This can be useful for:

• transport
• outdoor events
• remote kiosks
• temporary market stalls
• aircraft or ferry environments

But it creates risk because the issuer may not authorise in real time.

Controls may include:

• low transaction limits
• merchant-level risk approval
• card type restrictions
• offline floor limits
• velocity limits
• mandatory upload deadline
• acquirer reserve

If stored transactions later decline, the merchant or acquirer may bear loss depending on rules and agreement. Store-and-forward is therefore not a generic offline mode. It is a risk-managed acceptance product.

Batch Close and Settlement Reporting Still Matter

Many terminals or merchant systems run end-of-day settlement or batch close processes.

The terminal or acquirer host may group transactions into batches and produce reports:

• total sales
• refunds
• voids
• tips
• offline uploads
• reversals
• settlement batch id

The batch close does not necessarily move money instantly to the merchant. It prepares or confirms merchant-side totals for acquirer processing and later funding.

A merchant in Milan may compare:

cash register card total: €4,820
terminal batch total:     €4,820
acquirer settlement:      €4,760 after refunds and fees
bank deposit:             €4,760 next day

If those values disagree, merchant reconciliation begins. Terminal records are one source of evidence.

Integrated POS Adds Another Failure Boundary

In many shops, the payment terminal is integrated with an electronic point-of-sale system. The cash register sends amount and transaction request to the terminal. The terminal returns approved, declined, or failed.

Integration failures create awkward states:

• terminal approved but cash register did not record sale
• cash register recorded sale but terminal declined
• receipt printed by one system but not the other
• reversal failed after POS cancellation
• amount mismatch between POS and terminal

Good integrations use transaction identifiers and explicit state machines. The cash register should not assume that a terminal timeout means no approval happened. The terminal should not accept amount changes outside controlled flow.

This boundary is a common source of merchant support incidents.

Terminal Estate Management Is Operationally Hard

Large acquirers and merchants manage thousands of terminals.

They need to handle:

• software updates
• key injection
• certificate rotation
• parameter downloads
• terminal activation
• merchant assignment
• remote diagnostics
• tamper events
• replacement logistics
• compliance evidence

A parameter update can change contactless limits, supported AIDs, acquirer routing, receipt text, or risk settings. A bad update can affect many merchants quickly.

Terminals therefore often check in with terminal management systems. Updates are signed, staged, and monitored. Rollback may be constrained by security policy. Key material must never be exposed during remote management.

The terminal estate is an operational platform, not a pile of devices.

Key Injection and Remote Key Loading Protect Communications

Terminals need cryptographic keys for functions such as PIN encryption, MAC generation, and secure communication with acquirer hosts.

Historically, some keys were injected in secure facilities. Modern estates may support remote key loading under strict cryptographic protocols.

Key management involves:

• terminal master keys
• session keys
• key serial numbers
• acquirer or processor key hierarchies
• HSM integration
• key rotation
• compromise response

If terminal keys leak, attackers may be able to decrypt PIN blocks, forge messages, or impersonate terminals depending on the key type. That is why key ceremonies, HSMs, tamper response, and certificate controls matter.

The terminal is trusted because its keys and software are controlled.

Unattended Terminals Have Different Constraints

Unattended terminals appear in parking machines, fuel pumps, vending machines, ticket machines, and self-service kiosks.

They differ from attended retail terminals:

• no cashier supervises the interaction
• physical tampering risk is higher
• customer support is remote
• pre-authorisation may be common
• receipt availability may be limited
• connectivity may be variable
• accessibility requirements are harder

Fuel pumps are a classic example. The terminal may pre-authorise a high amount, then complete for the actual fuel dispensed. If the final completion fails, the customer may see a stale hold.

Unattended environments require careful terminal risk configuration and strong reconciliation between device events, acquirer records, and merchant back office systems.

Contactless Optimises for Speed

Contactless card transactions have strict timing expectations. Customers expect tap-and-go. Transport gates require even faster interaction.

Contactless kernels reduce round trips and optimise card-terminal exchange. The terminal must still:

• detect the card
• select application
• read data
• perform risk checks
• determine CVM
• produce outcome
• go online if required

The transaction may complete at the terminal before the customer realises several cryptographic and rule steps occurred.

Contactless speed creates tradeoffs. Low-value no-CVM transactions improve convenience but require counters and limits. Mobile wallet CDCVM improves high-value contactless experience but relies on device verification evidence. Offline contactless may be allowed in some contexts, but issuer and acquirer risk rules constrain it.

Security Certification Shapes Development

Payment terminal software is not deployed like ordinary web software.

Changes may require:

• PCI PTS considerations
• EMV Level 1 and Level 2 testing
• scheme contactless certification
• acquirer host certification
• regression testing
• key management review
• secure code signing

EMV Level 1 concerns the physical and electrical interface with the card. Level 2 concerns kernel behaviour. Scheme certifications add brand-specific requirements. Acquirer certification checks host integration.

This slows development, but it is necessary. A bug in a terminal kernel or PIN path can create fraud exposure at physical merchants.

A Full Contact Chip Walkthrough

Take a €36 chip purchase at a pharmacy in Prague.

The terminal receives the amount from the cashier. The customer inserts the card. The terminal powers the chip and performs reset. It selects a payment application using AID matching.

The terminal sends GET PROCESSING OPTIONS. The card returns AIP and AFL. The terminal reads records listed in the AFL. It obtains application data, CVM list, certificates, and risk parameters.

The terminal performs processing restrictions and risk management. The CVM list says online PIN is preferred for this amount and terminal type. The terminal prompts for PIN through the secure keypad, forms an encrypted PIN block, and includes it in the online authorisation data.

Terminal action analysis requests an ARQC. The card generates the cryptogram. The terminal sends the authorisation request to the acquirer. The issuer validates the cryptogram and PIN, checks funds and fraud rules, then approves.

The terminal receives issuer response, completes the card interaction, prints receipt, and stores transaction evidence for batch and reversal handling.

The customer saw insert, PIN, approved. The terminal ran a secure protocol.

A Failure Walkthrough: Terminal Approved, POS Lost Response

Assume an integrated POS sends €88 to the terminal. The terminal obtains issuer approval. The cable or local network between terminal and cash register fails before the POS receives the result.

The terminal state:

approved, auth code present

The cash register state:

unknown or failed

If the cashier retries immediately, the customer may be charged twice unless the integration handles recovery. The POS should query terminal status or trigger reversal for the approved-but-not-recorded transaction. The terminal should retain enough state to answer.

This is why integrated payment APIs include transaction ids, status queries, completion messages, and cancellation flows. The local merchant integration is part of payment correctness.

Level 1 and Level 2 Certification Split the Problem

EMV terminal certification is often described in levels.

Level 1 focuses on the physical, electrical, and protocol interface between card and terminal. For contact cards, this includes things such as card activation, voltage, reset, timing, and low-level communication. For contactless, it includes radio frequency behaviour, field strength, polling, and communication timing.

Level 2 focuses on the EMV kernel logic. This is where application selection, GPO handling, record reading, risk processing, CVM logic, terminal action analysis, and cryptogram handling are tested.

The distinction matters because a terminal can fail in different ways:

• poor contact reader hardware
• weak contactless antenna tuning
• incorrect APDU timing
• kernel selects wrong application
• kernel mishandles TVR bits
• terminal sends malformed authorisation data

A merchant only sees failed or approved. Certification labs and acquirers need to know which layer failed.

For developers, Level 2 testing is especially important because it catches protocol logic bugs that ordinary retail testing may miss. A terminal might approve many cards in a pilot and still mishandle a specific CVM list or issuer script path.

Terminal Parameters Are a Live Control Surface

Terminals are configurable. Parameters can change behaviour without replacing the whole application.

Typical parameters include:

• supported AIDs
• floor limits
• contactless CVM limits
• terminal capabilities
• transaction types allowed
• acquirer host addresses
• merchant identifiers
• receipt text
• public key tables
• risk management settings
• language and currency

A parameter file can decide whether a terminal supports a domestic debit application, whether it forces online authorisation, or whether it allows contactless no-CVM below a threshold.

This makes parameter management powerful and risky. A wrong parameter rollout can affect thousands of merchants:

old contactless CVM limit: €50
new parameter mistakenly sets: €500
effect: high-value no-CVM transactions possible until corrected

Parameter downloads should be signed, versioned, staged, and auditable. Acquirers need to know which terminal had which parameters at transaction time, because disputes and certification questions may depend on it.

Terminal Capabilities Tell the Card What Is Possible

During EMV processing, the terminal reports its capabilities. These fields describe what the terminal can support.

Capabilities include:

• magnetic stripe
• contact chip
• contactless
• offline PIN
• online PIN
• signature
• no CVM
• SDA, DDA, or CDA support
• transaction types such as purchase or cash

The card and terminal use these capabilities during CVM and risk decisions. If the terminal says it does not support online PIN, a card that requires PIN may decline or choose another method if allowed.

Incorrect capability configuration can create real payment errors. A terminal that falsely claims offline PIN support may direct the card down a path the hardware cannot complete. A terminal that fails to report contactless capabilities correctly may trigger unnecessary declines.

Terminal capabilities are not marketing flags. They are protocol inputs.

Terminal Verification Results Must Be Accurate

The terminal verification results, or TVR, records what happened during EMV checks. It is sent to the issuer and used in terminal action analysis.

TVR bits may indicate:

• offline data authentication failed
• application expired
• cardholder verification failed
• transaction exceeds floor limit
• random online selection performed
• issuer authentication failed
• script processing failed

If the terminal sets TVR bits incorrectly, the issuer sees a distorted picture.

For example:

offline data authentication failed
terminal fails to set TVR bit
issuer sees cleaner transaction than reality

or:

CVM succeeded
terminal incorrectly marks CVM failed
issuer may decline a legitimate transaction

This is why kernels are tested with trace-level validation. The final approval result is not enough. The intermediate risk evidence must be correct.

Receipts Need to Match Host Reality

A terminal receipt should represent the transaction outcome accurately, but receipt generation sits at an awkward boundary.

The terminal may print:

• approved receipt
• declined receipt
• void receipt
• refund receipt
• duplicate receipt
• offline transaction receipt

Problems happen when printer, host, or POS integration state diverges.

Examples:

• host approved but printer jammed
• receipt printed but POS failed to record sale
• duplicate receipt printed after status query
• void receipt printed but reversal failed
• offline receipt printed but upload later failed

The receipt should include enough references for investigation:

merchant id
terminal id
transaction sequence
authorisation code
date and time
amount
masked card data
application label

A receipt is not settlement proof, but it is operational evidence. If the terminal cannot print, the transaction may still be valid. If the terminal prints approved without host approval, the merchant has a problem.

Voids and Reversals Are Different Merchant Actions

Merchants often use the words cancel, void, reverse, and refund loosely. Terminals treat them differently.

A void usually cancels a transaction before settlement or batch close in the merchant environment. A reversal undoes or advises cancellation of an authorisation. A refund is a new financial transaction after the sale exists.

Terminal software must map merchant actions correctly:

cashier cancels before approval:
    no network financial effect
 
cashier cancels after approval before completion:
    send reversal or void according to flow
 
customer returns goods next day:
    process refund

Using the wrong action creates reconciliation issues. A refund instead of reversal may create extra merchant fees and confusing customer history. A missing reversal can leave a stale hold. A void after batch close may be invalid and require refund instead.

The terminal UI should guide the merchant, but the back-end state machine is what protects correctness.

Offline PIN Is Verified by the Card

Offline PIN differs from online PIN.

With offline PIN, the terminal sends the PIN to the card for verification, either plaintext inside the secure contact interface or enciphered depending on method. The issuer is not checking the PIN live. The card checks it against a value stored securely on the chip and updates retry counters.

With online PIN, the terminal encrypts a PIN block and sends it through the acquirer and network path to the issuer or issuer processor.

The difference matters:

• offline PIN can work without issuer connectivity
• online PIN lets issuer verify centrally
• offline PIN retry counters live on card
• online PIN failures may be tracked by issuer

Terminals must support the correct secure path. They must not expose PIN digits to the merchant application in either case.

Signature Has Become a Weak CVM

Signature used to be common, but it is weak compared with PIN or device verification. Many regions have reduced or removed signature as a meaningful cardholder verification method for ordinary card-present transactions.

Still, terminals may support signature in specific contexts:

• fallback
• cards without PIN capability
• markets where signature remains allowed
• certain offline flows

Signature creates operational evidence issues. A merchant may need to retain a signed receipt. Issuers may evaluate whether the signature was checked during disputes. In practice, signature is weaker because merchants rarely compare it carefully.

For terminal design, signature support requires receipt prompts, merchant workflow, and storage or retrieval of evidence where applicable.

Contactless Collision Handling Is Real

Contactless terminals can see more than one card or device in the field. If two cards are presented together, the terminal should not randomly choose one and charge it.

The contactless reader performs polling and anti-collision procedures. If multiple payment applications or cards are detected in a way that prevents safe selection, the terminal may display:

Present one card only

Wallets and phones add more complexity because a device may expose a selected payment credential only after user interaction.

Contactless UX depends on RF design, polling timing, kernel behaviour, and clear prompts. A poorly designed reader can produce failed taps, double taps, or customer confusion.

Unattended Fuel Has a Special Completion Problem

Fuel terminals are operationally tricky because the final amount is unknown at the start.

A common flow:

pre-authorise up to €150
allow pump
customer takes €63.40 of fuel
send completion for €63.40
release unused hold

Failures create customer complaints:

• pre-authorisation approved but pump failed
• completion not sent
• unused hold remains
• final amount clears late
• receipt unavailable at unattended pump

The terminal and fuel controller must coordinate physical dispensing with payment state. If the pump dispenses after payment failure, merchant loss is possible. If payment holds remain after no fuel is dispensed, customer trust suffers.

Fuel is a good example of POS terminals controlling real-world physical goods, not only payment messages.

Restaurants Need Tip Adjustment and Table Workflows

Restaurant terminals often support:

• pre-tip authorisation
• tip adjustment
• pay-at-table
• split bill
• gratuity prompts
• offline fallback during service

The terminal may authorise the base amount, then later capture a higher final amount including tip where rules allow.

This creates reconciliation requirements:

authorised: €80
tip added: €12
final clearing: €92

The terminal receipt, merchant POS, and acquirer clearing must agree. If the final amount exceeds allowed tolerance, the issuer may dispute or reject. If staff enter tip incorrectly, the customer may complain.

Restaurant flows show why terminal software is often merchant-segment specific.

Accessibility Is Part of Terminal Design

Payment terminals must be usable by people with different abilities.

Accessibility concerns include:

• tactile keypad layout
• audio prompts
• screen contrast
• privacy during PIN entry
• contactless placement cues
• timeout lengths
• wheelchair-reachable mounting
• receipt alternatives

Touchscreen-only PIN entry can create accessibility and security issues. Physical keypads remain important in many certified payment devices because they provide tactile input and a protected PIN path.

Accessibility is not separate from security. A customer who cannot read the screen or use the keypad safely may need help, which can expose PINs or transaction details.

Terminal Logs Must Be Useful but Not Dangerous

Terminals need logs for support, but logs must not leak sensitive data.

Useful logs include:

• transaction sequence number
• terminal status
• host connection result
• EMV outcome codes
• printer errors
• reversal attempts
• batch upload status
• parameter version

Dangerous logs include:

• full PAN
• track data
• PIN data
• cryptographic keys
• sensitive authentication data

PCI rules restrict storage of sensitive authentication data after authorisation. Developers must design logging carefully. A verbose debug log that is helpful in test can become a compliance incident in production.

Good terminal logs use masked card data and references that support investigation without exposing secrets.

Remote Diagnostics Reduce Merchant Downtime

A merchant cannot wait days for a technician every time a terminal has a configuration problem.

Remote diagnostics can report:

• network status
• battery and power
• printer paper status
• tamper status
• software version
• parameter version
• last successful transaction
• host connection failures
• contactless reader health

Support teams use this to decide whether to:

• reboot terminal
• push parameter update
• replace SIM
• dispatch technician
• swap device
• investigate acquirer host issue

Remote diagnostics must be authenticated and limited. A diagnostic channel that can alter payment behaviour without proper controls becomes an attack surface.

Terminal Software Updates Are Security Events

Updating terminal software is not like updating a kiosk menu.

The update package should be:

• signed
• versioned
• authorised for that terminal estate
• compatible with certification
• staged by merchant group
• monitored after rollout

The terminal should verify signatures before installing. Rollout should detect failure rates and stop if problems appear. A bad kernel update can break acceptance at many merchants. A bad security update can expose payment data.

Some updates require recertification or acquirer approval. This slows delivery, but payment terminals are part of a regulated acceptance infrastructure.

The Acquirer Host Is the Terminal's Counterparty

The terminal usually talks to an acquirer host or gateway, not directly to every issuer.

The host handles:

• terminal authentication
• message parsing
• merchant validation
• transaction routing
• reversals
• batch upload
• parameter download
• settlement reporting

The terminal and host maintain protocol expectations. The host may reject a transaction because:

• terminal id inactive
• merchant suspended
• MAC verification failed
• duplicate sequence
• unsupported transaction type
• parameter version invalid

This host relationship is the terminal's operational lifeline. If host connectivity fails, online authorisation fails even if the card and issuer are healthy.

Time Synchronisation Affects Evidence

Terminals need reasonably accurate clocks.

Timestamps appear on:

• receipts
• transaction logs
• batch reports
• reversal timing
• settlement files
• support investigations

If a terminal clock drifts, reconciliation becomes harder. A transaction at 18:05 may appear as 17:42. Batch close may include wrong periods. Fraud systems may see impossible sequences.

Terminals often synchronise time through host communication or network time mechanisms. In offline contexts, drift still needs management.

Time may sound mundane, but payment evidence depends on it.

Network Connectivity Has to Fail Safely

Terminals connect through Ethernet, Wi-Fi, cellular, Bluetooth to a phone, or merchant LAN. Each option has failure modes.

Connectivity failures can happen because:

• merchant broadband is down
• cellular signal is weak
• SIM subscription expired
• DNS or routing failed
• acquirer host endpoint changed
• firewall blocks outbound traffic
• TLS certificate validation fails

The terminal should distinguish local communication failure from issuer decline. A cashier should not tell the customer "your card was declined" when the terminal never reached the acquirer.

Good terminal messaging separates:

declined by issuer
communication error
try again
use another payment method

This is not only customer service. It affects duplicate risk. If the terminal reached the issuer but lost the response, retry handling differs from never connecting at all. The terminal and host need reversal and status-query paths for ambiguous cases.

Local Storage Must Survive Power Loss Without Leaking Secrets

Terminals store some local state:

• pending reversals
• offline transactions
• batch totals
• receipt sequence numbers
• parameter versions
• diagnostic logs

Power loss can occur after approval but before receipt, after offline acceptance but before upload, or during batch close. The terminal should persist enough state to recover safely.

At the same time, local storage must not expose sensitive data. Full magnetic stripe data, PIN data, and sensitive authentication data cannot be retained casually. Logs and queues need masking, encryption, and retention limits.

This creates a design tension:

store enough to recover payment state
do not store secrets that create compromise risk

Payment terminal storage is therefore structured around transaction references, masked card data, EMV evidence, and encrypted operational queues rather than raw sensitive payloads.

Terminal Sequence Numbers Help Detect Duplicates

Terminals usually maintain transaction sequence numbers or counters. These help acquirers detect duplicates and reconstruct terminal activity.

A sequence can identify:

• authorisation request
• reversal
• refund
• batch upload item
• duplicate retry

If a terminal reboots and repeats a sequence incorrectly, the acquirer may reject messages or treat legitimate retries as duplicates. If sequence gaps appear, operations may investigate missing transactions.

Sequence management is especially important for offline and store-and-forward. The terminal may hold several accepted transactions locally, then upload them later. The host needs to know whether all items arrived once.

This is another small mechanism that protects money movement during unreliable retail conditions.

Merchant Training Is Part of Terminal Reliability

Some payment failures are human workflow failures.

Cashiers need to know:

• when to ask customer to insert rather than tap
• what fallback is allowed
• how to handle communication error
• when to print duplicate receipt
• when to void versus refund
• how to close batches
• how to avoid asking for PIN disclosure

Poor training creates payment risk. A cashier who forces magnetic stripe because chip takes longer may shift fraud liability. A cashier who retries after an ambiguous approval may duplicate a charge. A cashier who refunds instead of voiding may create unnecessary fees and confusing statements.

Terminal UI should reduce training burden, but it cannot remove merchant process completely. The payment device is used by humans under queue pressure, often in noisy retail environments. Good terminal design assumes mistakes will happen and makes the safe path obvious.

Multi-Acquirer Routing Adds Configuration Complexity

Large merchants may route transactions to more than one acquirer. They may do this for resilience, pricing, domestic routing, or regional coverage.

The terminal or merchant payment platform may choose an acquirer based on:

• card scheme
• domestic debit application
• merchant location
• transaction type
• acquirer availability
• cost
• currency
• fallback rules

Multi-acquirer routing increases configuration risk. The terminal must use the correct merchant id, terminal id, keys, host endpoint, and receipt data for the chosen route. Settlement and reconciliation must later map transactions to the right acquirer.

If routing fails, the merchant may see missing deposits, duplicate batches, or transactions funded by the wrong acquirer.

This is why large merchant payment stacks often centralise routing in a payment orchestration layer rather than configuring every terminal manually.

Terminal Compromise Is a Supply Chain Concern

Terminals pass through manufacturers, distributors, key-injection facilities, installers, merchants, repair teams, and sometimes refurbishers. Every handoff is a potential control point.

Risks include:

• device substitution
• malicious firmware
• skimming hardware
• compromised repair process
• incorrect key injection
• stolen inactive terminals
• tamper events ignored

Acquirers and merchants manage this with:

• serial number inventory
• secure shipping
• activation controls
• key injection records
• tamper status checks
• signed firmware
• estate monitoring
• decommissioning procedures

A terminal should not be trusted only because it looks like the right model. The host should know which serial number and key identity are expected for a merchant.

Semi-Integrated Architectures Reduce POS Scope

Many merchants use semi-integrated payment architecture. The cash register sends amount and transaction commands to the terminal, but sensitive card data stays inside the terminal and payment processor path.

This reduces the PCI exposure of the cash register environment. The POS does not need to handle full card data. It receives transaction result and tokenised references.

The flow:

cash register -> terminal: sale €42
terminal -> acquirer: card transaction
terminal -> cash register: approved, token, auth code

The POS can store the token for refund or receipt lookup without storing PAN. This architecture is common because ordinary retail POS systems are harder to secure than certified payment terminals.

Semi-integration still needs careful state handling. Amount integrity, transaction id correlation, and cancellation flows remain important.

Terminal Design Has to Handle Slow Customers

Payment terminals operate in public, under time pressure, with unpredictable users.

Customers may:

• remove card too early
• tap the wrong card
• insert card upside down
• walk away during PIN prompt
• enter PIN slowly
• cancel after approval
• present phone without unlocking wallet
• ask for receipt after timeout

The terminal needs timeouts, prompts, cancellation paths, and recovery states. It must avoid charging the wrong card, avoid leaving sensitive prompts on screen, and avoid ambiguous merchant outcomes.

This is user-interface engineering with financial consequences. A confusing prompt can become a duplicate charge, failed sale, or support case.

Decommissioning Is a Security Process

Old payment terminals cannot simply be thrown into a drawer or sold as generic electronics.

Before decommissioning, an acquirer or merchant should consider:

• terminal keys
• merchant configuration
• stored transaction queues
• diagnostic logs
• certificates
• SIM cards
• asset inventory
• tamper state
• repair history

A terminal that still contains keys or merchant configuration can become a security problem. Even if keys are protected by tamper hardware, the device identity may still be active at the acquirer host. An attacker with a lost terminal should not be able to submit transactions as a real merchant.

Safe decommissioning usually includes:

disable terminal id at host
confirm no pending offline transactions
wipe merchant parameters where supported
remove or disable SIM
record serial number retirement
send device through approved disposal or refurbishment

Refurbishment has similar controls. A device moving from a restaurant in Vienna to a shop in Athens needs new merchant parameters, keys or key associations, receipt text, and host configuration. If any old state remains, settlement and support records can become confused.

The terminal lifecycle ends only when the payment system no longer trusts that device identity.

The Smallest Useful Mental Model

A POS terminal is a secure payment endpoint that turns a customer-card interaction into a controlled authorisation or offline outcome.

The key ideas are:

1. the EMV kernel runs the card protocol
2. APDUs carry structured chip commands and responses
3. terminal risk management decides whether local risk is acceptable
4. cardholder verification is negotiated between card, terminal, amount, and scheme rules
5. PIN entry must stay inside a protected security boundary
6. receipts prove terminal outcome, not merchant funding
7. fallback and store-and-forward are controlled risk exceptions
8. terminal estate management is part of payment reliability

The terminal is small, but it sits at the most exposed edge of the card payment system. It has to be fast enough for retail, secure enough for PINs and keys, flexible enough for many card products, and reliable enough for merchants who cannot stop selling when a network hiccups.

That is how POS terminals actually work.