2026-10-27 Author : ZCS
A PIN pad is the customer-facing payment interface used to enter a personal identification number during an eligible card transaction. Its secure role sits inside the wider POS terminal certification stack, where PCI PTS, EMV testing, payment applications and acquiring approval cover different parts of the acceptance path.
The visible keypad is only one part of that role.
A PIN pad captures cardholder input inside a protected point-of-interaction device, applies the payment application’s approved PIN-entry controls and supports cardholder verification. The POS checkout application supplies transaction context, but it should receive transaction status and results rather than the customer’s plaintext PIN digits.
That separation explains why a cashier can see “Waiting for customer” while the customer privately completes PIN entry on another screen.
A PIN pad is a secure input device or protected terminal area that allows a cardholder to enter a PIN during a payment transaction. The input surface may use physical keys or a touchscreen, and it may appear as a separate countertop unit or as part of an all-in-one payment terminal.
Payment professionals often use the term PIN Entry Device, shortened to PED, for equipment that accepts cardholder PINs. “PIN pad” is the common merchant-facing term, but device classifications matter in formal security documentation. An Encrypting PIN Pad, or EPP, is a specific category commonly integrated into equipment such as ATMs or unattended machines. The labels should not be treated as interchangeable without checking the product’s approval class.
The PIN pad does more than display numbers. A payment application determines when the PIN-entry screen may appear, the secure device protects the input path, cryptographic functions prepare the PIN information for the permitted verification route, and tamper protections help defend the physical boundary. The checkout application should not capture the customer’s raw keystrokes.
PCI Security Standards Council’s current PTS point-of-interaction overview identifies PIN Entry Devices, Unattended Payment Terminals, Encrypting PIN Pads and secure card-reader components as distinct supported categories. The approval class describes the evaluated product boundary, so merchants should verify the exact model and configuration rather than assume every numeric keypad is a payment PIN pad.
The POS manages the sale, the payment terminal manages the payment interaction, and the PIN pad protects customer PIN entry. These functions can live in separate boxes or inside one device, but the responsibility boundaries should remain clear.
| Component | Primary role | Typical information handled | What it should not do |
|---|---|---|---|
| POS checkout application | Builds the order and starts payment | Basket, tax, total, tender type, order reference and final payment status | Capture or store plaintext PIN digits |
| Payment application or terminal | Runs the card-present payment flow | Card interface, EMV decisions, customer prompts, host messages and transaction result | Let ordinary POS screens imitate secure PIN entry |
| PIN pad or protected PIN-entry area | Accepts cardholder PIN input | Secure keystrokes or touches and protected PIN-processing data | Expose the entered PIN to the cashier or general POS application |
| Card reader | Communicates with chip, contactless card, magnetic stripe or wallet | Card and EMV interface data | Decide the complete sale amount or maintain the merchant’s product basket |
| Processor, acquirer and issuer | Route, evaluate and respond to the authorization request | Transaction message, protected verification data, account controls and approval result | Return the customer’s PIN to the POS |
The practical boundary can be stated in one compact rule.
The POS owns order context and requests a payment; the payment terminal owns the secure cardholder interaction; the PIN pad protects PIN entry; and the payment host returns an outcome. A combined device may contain every interface, but software isolation still prevents the checkout layer from reading sensitive PIN input.
This division lets the cashier application remain useful without becoming the trusted surface for every payment secret.
A connected PIN pad works through a controlled message exchange rather than by typing PIN digits into the cash register. The exact protocol varies by provider, but a semi-integrated payment normally follows this sequence:
J.P. Morgan’s official in-store payment flow documents the same responsibility split for a semi-integrated setup: the POS sends the transaction type and amount to the PIN pad or terminal, while the terminal application collects the customer’s card data and communicates with the payment host.
The message boundary also prevents a common design mistake. A merchant application may display “Enter PIN on terminal,” but it should not draw its own look-alike PIN screen and request the secret through an ordinary application field. Secure prompts belong to the approved payment environment.
A properly designed POS integration does not receive or store the customer’s plaintext PIN. The checkout application can know that the transaction has reached a PIN-entry stage and can receive the final result, but the protected PIN value stays inside the approved verification path.
The cashier may see a neutral status such as “Customer input required,” “PIN entry,” “Processing” or “Cancelled.” Those messages help staff guide the checkout without revealing which digits the customer entered. A receipt can show the cardholder verification method or transaction outcome, but it must never print the PIN.
The wider POS payment security layers include device security, payment-application controls, network protection, access management and merchant procedures. A secure PIN pad reduces exposure at the input point, but it does not make unrelated checkout software, networks or user accounts automatically secure.
POS developers should also avoid sensitive logging. A useful log records timestamps, transaction references, connection states, terminal status codes and final outcomes. It should not capture raw card data, PIN keystrokes or screen coordinates that could reconstruct sensitive input.
The cashier and POS application do not independently decide whether a customer must enter a PIN. The decision arises from the card or wallet, terminal capabilities, transaction type, payment application, network rules, issuer controls and local market configuration.
EMV calls the selected check a Cardholder Verification Method, or CVM. EMVCo explains that chip transactions can support online PIN, offline PIN, signature, no verification and consumer-device verification such as a phone’s biometric or passcode. The available method depends on the payment instrument and acceptance environment.
The supported choices are broader than “PIN or no PIN.”
EMV cardholder verification can use online PIN, offline PIN, signature, no CVM or consumer-device verification. The terminal and payment instrument apply their supported rules to the transaction, so a contact, contactless or mobile-wallet payment does not automatically require the same customer action in every market.
That is why two purchases for the same amount can present different prompts without either terminal being faulty.
The official EMV cardholder verification explanation confirms that EMV chip transactions do not all require a PIN. Merchants should therefore avoid publishing a universal PIN threshold unless their acquirer has supplied a market-specific rule for the exact cards and payment methods they accept.
PIN bypass is also not a general customer entitlement. Some payment applications, transaction types or merchant programs may allow a bypass prompt; others may reject the transaction or require another method. Staff should follow the terminal prompt instead of improvising a workaround.
Online PIN is verified through the issuer or its designated processor, while offline PIN is verified by the chip card. The words “online” and “offline” describe the verification destination, not whether the merchant’s entire checkout system is cloud-based.
The technical distinction changes where the protected PIN evidence goes.
Online PIN entry produces protected PIN data for verification through the acquiring and issuing path. Offline PIN lets the chip card perform the verification locally through an EMV-supported method. Both require an approved terminal flow, but only online PIN depends on issuer-side PIN verification during authorization.
For merchants, the visible customer action may look almost identical even though the verification path is different.
The PIN-entry device protects the customer’s input and supports creation of the encrypted PIN information required by the payment path. The transaction message travels through the acquirer or processor toward the issuer, which checks the PIN as part of its authorization decision.
Online PIN does not mean the POS software sees the PIN. The POS receives the transaction outcome after the payment terminal and host complete the permitted exchange.
The EMV chip card performs the PIN comparison. EMV supports plaintext and enciphered offline PIN methods, subject to card and terminal capabilities. “Plaintext” in this EMV context does not authorize the merchant’s POS application to record or display the PIN. It describes the card-to-terminal verification method inside the controlled EMV interaction.
J.P. Morgan’s October 2026 release notes list offline plaintext PIN, offline enciphered PIN, online enciphered PIN, CDCVM and no CVM as supported methods in its current Payment Terminal Application. That provider example shows why POS teams must test several verification outcomes instead of treating PIN entry as the only valid path.
A disconnected POS network cannot simply convert an online PIN transaction into offline PIN. Store-and-forward eligibility, offline authorization and offline PIN are different concepts. Provider rules may exclude transactions that require online or offline PIN from particular deferred-authorization programs.
Merchants should follow the terminal’s outcome during a connection failure. A “declined,” “unable to process” or “try another payment method” result should not be overridden based on the assumption that the chip already checked the PIN.
A PIN pad accepts protected customer input, while a card reader communicates with a payment card or wallet. A single payment terminal often combines both functions, which makes the names sound interchangeable at checkout.
A separate customer-facing unit may contain a keypad, display, chip slot, contactless antenna and magnetic-stripe reader. In that form factor, staff may casually call the whole unit a PIN pad even when it also performs card-reading and display functions.
The underlying responsibilities still differ. The contactless card reader role concerns communication with a tapped card, phone or wearable. PIN entry concerns cardholder verification on a protected input surface. A contactless reader can complete transactions that use no PIN or rely on consumer-device verification.
This distinction matters during support. A card-read error points to the chip interface, contactless field, card orientation or payment instrument. A PIN-entry error points to the secure prompt, keypad or touchscreen, payment application, supported CVM or PIN verification result. One integrated device can produce either fault.
PIN entry can appear in several hardware arrangements without changing its basic security purpose.
A separate PIN pad sits beside a cashier workstation and faces the customer. The POS runs on another device, sends the payment request and waits for the terminal result. Multi-lane retail commonly uses this arrangement because the customer interface remains fixed and private while the cashier controls the basket on a larger screen.
An integrated terminal combines display, card interfaces and PIN entry in one payment device. It can operate next to a POS or run a payment application alongside checkout software. Integration into one enclosure does not erase the software boundary between normal merchant functions and protected payment entry.
A handheld terminal lets staff bring the payment interaction to the customer. Physical keys or a protected touchscreen can provide PIN entry. The payment provider must approve the intended device, application and communication configuration.
Kiosks, fuel dispensers, ticket machines and ATMs use PIN-entry components designed for unattended environments. Their physical integration, privacy, tamper resistance and approval class can differ from a supervised countertop device.
Some approved mobile payment solutions support PIN entry on a phone or tablet under specialized PCI programs and security controls. An ordinary POS touchscreen with a numeric form does not become a compliant PIN pad merely because it can display digits.
A PIN pad handles a secret used to verify the cardholder, so the input path needs protection against physical and logical attack. Security evaluation addresses the device and its defined configuration, not just the strength of its enclosure.
Relevant controls can cover:
PCI PTS approval is not the same as PCI DSS compliance. PCI PTS evaluates payment devices and components under a defined program. PCI DSS applies to the wider people, processes, systems and networks that store, process or transmit account data. EMV testing and acquirer approval address other layers of the transaction.
Merchants should verify the exact device model, hardware version, firmware, approval number, expiry information and intended deployment class. A supplier’s statement that a product is “PCI compliant” does not identify which standard or configuration was evaluated.
Staff should protect customer privacy, follow terminal prompts and treat unexpected hardware or screen changes as support events. A secure device cannot compensate for an overlay that employees ignore or a replacement unit installed outside the provider’s process.
A practical operating routine includes:
Connectivity also changes what the device can complete. The guide to contactless payments without internet explains why offline capability depends on the payment method and provider rules. A working keypad alone cannot authorize a transaction when the required online verification path is unavailable.
PIN pad messages describe stages in the payment flow, not guaranteed financial outcomes. Exact wording varies by provider, so the merchant should use its terminal guide for device-specific instructions.
| Message or behavior | Typical meaning | Appropriate response |
|---|---|---|
| Enter PIN | The selected CVM requires PIN input | Give the customer privacy and wait for completion |
| PIN incorrect | The verification attempt did not succeed | Follow the terminal prompt; do not ask for the PIN |
| PIN tries exceeded | The card or issuer has limited further attempts | Stop retrying and follow issuer or provider guidance |
| PIN bypass offered | The payment application permits a configured alternative path | Let the customer choose only the options displayed |
| Cancelled | The customer or terminal ended the flow | Confirm the POS order remains unpaid before retrying |
| Processing | The terminal is completing card or host communication | Avoid removing the card or restarting the device |
| Unable to process | The required payment step could not complete | Check the documented code and offer another permitted method |
| Approved | The authorization flow returned approval | Let the POS attach the result to the correct order |
An approved screen still does not mean funds have reached the merchant’s bank. Authorization, clearing, settlement and payout remain separate stages. The PIN pad confirms customer interaction within the payment flow; it does not control the entire funds lifecycle.
POS and payment teams should agree on the interface boundary before deployment. Useful questions include:
The answers should be documented in the integration specification and tested with approved, declined, cancelled, timed-out and interrupted transactions. A successful sale alone does not prove that the recovery path keeps the order and payment state aligned.
PIN stands for Personal Identification Number. A PIN pad is the protected keypad or touchscreen area used by a cardholder to enter that number during an eligible payment transaction.
A PIN pad can be a complete customer-facing payment terminal or one secure function inside a larger terminal. Some separate units also include chip, contactless and magnetic-stripe readers, while other PIN-entry components require integration into another system.
No. The card, terminal, transaction, network, issuer and market rules determine the cardholder verification method. A transaction may use online PIN, offline PIN, consumer-device verification, signature or no CVM.
Only when the complete solution uses an approved payment architecture for secure PIN entry. A normal checkout application displaying a numeric keypad is not automatically a certified PIN-entry environment.
The cashier and ordinary POS application should not see the plaintext PIN. The payment terminal can report that PIN entry is in progress and return the transaction result without revealing the digits.
No. Receipts and reports can contain permitted transaction references, masked card data and the verification method, but they must not contain the customer’s PIN.
The selected cardholder verification method may be no CVM, consumer-device verification, signature or another supported option. The result depends on the payment instrument and transaction rules, not only the purchase amount.
Encryption is one control, not the entire security model. Device approval can also cover tamper resistance, secure prompts, key protection, software boundaries, communications, integration and lifecycle management.
A PIN pad is the protected customer interface for PIN entry, not an extension of the cash register keyboard. The POS supplies the order amount and transaction context, the payment terminal controls the card-present flow, and the PIN-entry environment keeps sensitive input away from ordinary checkout software.
PIN entry is only one possible EMV cardholder verification method. Online PIN reaches issuer-side verification through a protected payment path, while offline PIN is checked by the chip card. Contactless and mobile-wallet payments can use other methods, including consumer-device verification or no CVM.
Merchants should verify the exact device approval, maintain the physical terminal, follow provider prompts and keep useful transaction logs without sensitive input. Clear responsibility boundaries make PIN pad integrations easier to support and reduce the risk that convenience features weaken the payment-security boundary.
Home 
What Is a POS Terminal ID and How Does a TID Differ From a Merchant ID? 
