On this page
Payment terminals are part of the cardholder data environment when they capture, process or transmit payment account data. A PTS-approved device or a supplier’s “PCI compliant” statement does not, by itself, establish compliance for the merchant’s kiosk environment. Last reviewed: August 10, 2026 against PCI DSS v4.0.1 and current PCI SSC terminal FAQs. Confirm scope and validation with your acquirer, payment brand and qualified assessor. This guide is not compliance or legal advice.
Map the cardholder data environment from tap to authorization
Begin with a data-flow diagram for the exact kiosk configuration. Follow payment account data from the customer’s card or wallet through the point-of-interaction device, payment application, kiosk computer, network, gateway, processor and any logs or receipts. Record where data is encrypted, decrypted, displayed, cached, printed or made available to support personnel. Include failure and fallback paths rather than documenting only a successful online transaction.
Determine whether the payment terminal communicates directly with a validated payment service or passes information through the kiosk application or operating system. That architectural choice can materially affect the systems connected to or influencing the cardholder data environment. Do not assume physical separation between the terminal and touch display creates logical isolation; verify interfaces, cables, APIs, drivers and network routes.
Inventory systems that may affect security even when they do not store card data: identity services, software-distribution platforms, terminal management systems, remote support, monitoring, DNS, network security and the build pipeline. PCI scope is an assessment decision, but procurement must provide enough accurate architecture for that decision to be made before rollout.
Data-flow questions
- What account data enters each component and in what form?
- Where does encryption begin and who controls the keys?
- Can the kiosk application, OS or support tool access clear-text data?
- Which connections can affect the terminal or transaction?
- What changes in offline, fallback, refund or receipt-reprint scenarios?
Assign merchant, acquirer and supplier responsibilities
A kiosk program can involve the merchant, acquirer, payment service provider, terminal vendor, kiosk integrator, application developer, network provider, field-service partner and hosting provider. Contracts sometimes describe the same control as another party’s responsibility. Build a responsibility matrix that names who performs the task, who provides evidence, who approves exceptions and who is accountable when the root cause crosses suppliers.
| Control area | Operational owner | Evidence owner | Decision to document |
|---|---|---|---|
| Terminal approval and configuration | Acquirer or payment provider | Terminal service provider | Approved model, firmware and application |
| Kiosk OS and application patching | Kiosk operator or integrator | Managed-service provider | Patch SLA and fleet status |
| Physical inspection | Site operations | Merchant | Frequency, method and escalation |
| Remote access and TMS | Service provider | Provider and merchant | MFA, authorization and logs |
| Assessment scope | Merchant | Qualified assessor/acquirer | Systems and validation method |
Third-party management does not remove merchant responsibility. Request current Attestations of Compliance where relevant, confirm that the specific service you buy was in assessment scope and document shared responsibilities. A provider’s assessment date and service boundary matter; a company-level badge is not enough to evaluate the proposed transaction path.
Include operating handoffs. Site staff need a route for suspicious devices; the help desk needs criteria for taking a kiosk out of service; field engineers need controlled identities; and the security team needs notification when a payment or remote-management component changes.
Separate PCI DSS, PTS, SRED and P2PE claims
PCI DSS defines baseline technical and operational requirements for protecting payment account data within the relevant environment. PCI PTS Point of Interaction standards assess physical and logical security properties of payment devices. SRED refers to Secure Reading and Exchange of Data functionality within PTS. A PCI-listed Point-to-Point Encryption solution combines approved components, cryptographic processes and provider management in a validated solution.
These terms are related but not interchangeable. PCI SSC states that a PTS-approved terminal does not automatically guarantee PCI DSS compliance or reduce the merchant’s cardholder-data-environment scope. SRED capability may be optional or dependent on the installed payment application. Scope reduction associated with P2PE depends on using a validated solution according to its instructions and on the merchant’s actual implementation.
Evidence to request
- Exact terminal model, hardware version and approval listing
- Payment application name, version and support status
- Whether SRED is enabled in the deployed configuration
- P2PE solution listing and instruction manual where claimed
- Acquirer confirmation of accepted devices and validation approach
- Documentation of any merchant-managed controls that remain
Do not write an RFP that mandates a label without describing the desired outcome. Ask the payment security owner and acquirer to define required listings, encryption path and evidence. Then ensure the kiosk enclosure, software and service model do not undermine that design.
Control terminal configuration, application support and patching
The assessed terminal is a combination of hardware, firmware, payment application, configuration and connected services. Record approved versions and prevent unauthorized changes. Verify that sensitive authentication data is not stored after authorization and that any account data output is rendered unreadable according to the payment design. Disable unused services, accounts and interfaces while preserving approved maintenance functions.
Ask every supplier to state support dates and patch responsibilities. The terminal, kiosk operating system and payment application may follow different release cycles. Establish how security advisories are received, evaluated and deployed; what happens when a critical update conflicts with kiosk software; and how the fleet proves successful installation. Include certificate expiration and cryptographic changes in lifecycle planning.
- Approved configuration baseline and drift monitoring
- Vendor support and end-of-life date register
- Critical and routine patch service levels
- Controlled test, staged release and rollback
- Inventory of installed applications and services
- Evidence that security functions remain enabled
- Exception approval and compensating-control process
Use a representative pilot to test an interrupted update, an offline device, a failed certificate and replacement of a terminal. A patch process that works only in the laboratory will not protect a geographically distributed estate.
Design inspection and tamper response into store operations
Payment devices used in card-present transactions need protection against tampering and substitution. Procurement should help the merchant maintain a device inventory with model, serial number, location and distinguishing characteristics. The physical design should allow staff to inspect the terminal, seals, cabling and mounting without dismantling the kiosk or relying on an image they cannot see.
Define inspection frequency according to risk and the merchant’s PCI program. Train relevant personnel to recognize unexpected overlays, damaged housings, changed labels, unusual cables and replacement devices. The procedure should state who can replace a terminal, how identity and work authorization are verified, and what to do when a device appears suspicious. Staff should be able to take a kiosk out of service without exposing themselves to unnecessary risk or destroying potential evidence.
Remote telemetry can support, but not necessarily replace, physical controls. An enclosure-open sensor or serial-number check can improve detection only when alerts are monitored and investigated. Consider the whole public environment: camera coverage, after-hours access, queue layout, cleaning activity and temporary merchandising can alter exposure.
Tamper response sequence
- Stop the affected terminal or kiosk from accepting payment.
- Preserve the device and relevant logs according to incident procedure.
- Notify the named payment-security and acquirer contacts.
- Check related devices and recent authorized work.
- Return to service only after accountable approval and evidence capture.
Govern terminal management systems and remote access
A terminal management system can distribute software, configuration and keys across the fleet. That capability makes it operationally valuable and security-relevant. Map whether it connects to the merchant environment, who hosts it, who administers it and which terminals it controls. Include it in scope discussions rather than treating it as an invisible supplier service.
Require individual administrator identities, multi-factor authentication, least privilege, controlled production changes and security logs. Remote sessions should be authorized, time-bound and attributable. Shared supplier accounts and permanently open support tools make responsibility difficult to prove. Clarify whether the merchant can receive logs or evidence needed for assessment and incident investigation.
Control field-service access as rigorously as central administration. Technicians may handle replacement terminals, local credentials or network ports. Use verified work orders, named identities, inventory reconciliation and post-work checks. Remove or rotate temporary credentials promptly. If a third party manages the TMS, document which PCI DSS controls it performs and which remain with the merchant.
Build an assessment evidence pack before scale approval
Collect evidence during design and pilot rather than reconstructing it before an assessment. The pack should contain current diagrams, inventories, data flows, responsibility matrices, supplier assurance, approved configurations, support dates, patch records, access-control evidence, physical inspection procedures, training records, incident contacts and pilot acceptance. Each item needs an owner and review date.
Align the pack with the validation method agreed with the acquirer or payment brand. PCI SSC Self-Assessment Questionnaires have eligibility criteria; they should not be selected because one appears shorter. Organizations with complex or unusual environments should obtain qualified advice early. Preserve evidence that the production implementation matches the assessed design.
| Gate | Minimum output | Approver |
|---|---|---|
| Architecture | Confirmed CDE and encryption path | Payment security owner |
| Supplier | Current assurance and shared responsibility | Risk/procurement |
| Device | Approved model, application and baseline | Acquirer/technical owner |
| Operations | Inspection, patch and incident procedures | Operations/security |
| Validation | Agreed assessment method and evidence | Merchant/acquirer/assessor |
Review scope when payment flow, terminal, processor, kiosk software, remote-support method or network changes. Compliance is a maintained operating condition, not a property inherited permanently from the terminal.
Make sampling and review populations explicit. The fleet inventory should show every terminal location and state so an assessor can understand how any sample represents the estate. New openings, replacement devices and temporarily offline kiosks must not disappear between asset, TMS and site records. Reconcile those sources on a defined schedule, investigate unexplained differences and retain evidence of approval when the standard build changes.
Continue planning
Place payment controls inside the wider self-service kiosk planning journey, compare system boundaries for self-checkout kiosks, and review the integration model for restaurant self-order kiosks.
Official sources and further reading
PCI SSC material should be read with the current standard, program documentation and instructions from the organization that manages your compliance program.
Clarify payment responsibility across the kiosk chain.
Assign responsibilities and evidence across the merchant, payment provider, integrator and device operator before pilot.