2026-10-15 Author : ZCS
PCI PTS verification should end with a matched production configuration, not a certificate file saved by procurement. The broader POS terminal certification stack explains how PCI PTS, EMV, CE and FCC answer different questions; this guide turns one layer of that stack into an evidence-based buying process.
The verification boundary is precise enough to define in one record.
PCI PTS certification verification matches a payment terminal's vendor, model, approval number, approval class, hardware version, firmware version and expiry date against the PCI SSC device listing. A certificate PDF or product-family claim cannot validate a delivered unit when any security-relevant identifier differs from the approved configuration.
That definition changes the purchasing task from collecting logos to controlling an exact device identity.
PCI PTS verification proves that an identified point-of-interaction device configuration appears in the PCI Security Standards Council approval program. The approval reflects evaluation against the applicable PIN Transaction Security requirements and the functions recorded for that device. The approval does not certify every terminal sold under a similar enclosure, every payment application installed on the terminal or every deployment that uses the same marketing name.
PCI PTS does not replace PCI DSS, EMV approval or acquiring acceptance. PCI DSS addresses the protection of account data across an entity's payment environment. EMV testing covers defined card-to-terminal communication and payment-kernel functions. The acquirer or payment brand decides whether the completed terminal and application can enter a particular live payment program.
A useful procurement statement names the approval rather than using the adjective “compliant.” “PCI PTS approved device, approval number X, hardware Y, firmware Z” is auditable. “PCI-certified POS” is incomplete because the phrase omits the evaluated version, approval class, configuration and expiry status.
The PCI SSC approved-device listing is the primary public source for a PCI PTS device claim. The Approved PTS Devices listing supports searches by company name, model name or approval number and separates current approvals from expired approvals.
An approval search should begin with the approval number whenever the supplier can provide it. Model names can be reused, localized or extended with suffixes, while the approval number points to a specific record. Procurement should still compare the company and model because a copied approval number can belong to a different product.
A buyer should preserve dated evidence from the listing. The evidence pack can include an exported record or screenshot, the query date, the listing URL and the person who completed the check. A stored copy creates a traceable baseline when the listing, firmware status or commercial configuration changes later.
A missing result in the current list does not prove that the model never held approval. The device may appear in the expired section, the supplier name may differ from the brand printed on the enclosure or the commercial product may use another approved platform name.
A result in the expired list does not authorize or prohibit deployment by itself. The result establishes lifecycle status. The buyer must then ask the acquirer or relevant payment brand whether purchasing, deploying or continuing to use that device is acceptable for the intended program.
A certificate image without an approval number is insufficient for a purchase decision. The image may be old, cropped, issued for another configuration or supplied only as evidence of a completed laboratory activity. The official record must still match the product that will ship.
A company-level certificate cannot validate every model in a supplier's catalogue. PCI PTS approvals are attached to defined devices and versions rather than to a manufacturer's general engineering capability. ISO certificates, laboratory relationships and quality-system documents may support a supplier audit, but they do not substitute for the device record.
Seven listing fields create the minimum identity tuple for a PCI PTS purchasing check. Procurement should compare each field with the quotation, sample, production specification and physical or diagnostic evidence from the delivered unit.
The matching rule can be compressed into a reusable technical test.
A valid PCI PTS device match requires the same vendor, model, approval number, approval class, hardware version, firmware version and unexpired or accepted lifecycle status. A familiar enclosure, shared product family or similar model suffix cannot compensate for a mismatch in a security-relevant identifier.
That rule lets a receiving team turn an abstract certification promise into seven pass-or-fail checks.
| Field | Evidence to compare | Common failure |
|---|---|---|
| Vendor | PCI SSC record, quotation and nameplate | Reseller name is presented as the approval holder |
| Model | PCI SSC record, nameplate and system information | A product-family name hides an unlisted suffix |
| Approval number | PCI SSC record and supplier evidence | The number belongs to another device |
| Approval class | Listing and intended deployment | An attended PED is proposed for an unattended design |
| Hardware version | Listing, label, BOM declaration or diagnostic screen | The sample and mass-production board revisions differ |
| Firmware version | Listing and secure diagnostic information | An OTA build falls outside the listed pattern |
| Expiry status | Listing plus acquirer or brand policy | The buyer treats an expiry date as either irrelevant or an automatic shutdown |
Version wildcards apply only where the approved record permits variation. A hardware string such as `ABC1xx` does not allow a supplier to change every character or component. Fixed characters identify controlled attributes, while variable positions cover the differences accepted within the device family.
The supplier should explain every variable position that affects the quoted configuration. Procurement should request a version-decoding table that maps characters to contactless support, modem, camera, memory, enclosure, region or other options. Security-relevant differences must remain within the approved scope.
A nameplate is necessary but may not expose the complete secure firmware identity. Receiving inspection should pair label photographs with a protected diagnostic screen, signed system report or vendor tool that shows the secure firmware and hardware revision.
A software “About” page alone is weak evidence when an application can change its displayed text. The acceptance procedure should identify where the authoritative hardware and secure firmware values originate, who can access them and how the values are exported without weakening the device.
Approval class defines the evaluated device boundary and intended security function. A Personal Identification Number Entry Device, Unattended Payment Terminal, Encrypting PIN Pad, Secure Card Reader or non-PIN device can appear within the PTS program, but the labels do not describe interchangeable hardware.
An attended PED is not automatically an approved unattended terminal. A vending machine, parking station or EV charger exposes payment hardware without cashier supervision and may require a device class and integration approach suitable for that environment. A wall bracket does not convert an attended terminal into a UPT approval.
An EPP or secure reader approval does not automatically approve the completed kiosk. The component remains part of a larger architecture, and the system builder must preserve the approved integration boundary, listed components and installation conditions.
| Deployment | Approval question to ask |
|---|---|
| Staffed retail checkout | Does the PED record match the terminal and supported PIN functions? |
| Unattended vending or parking | Is the proposed device listed for the unattended architecture? |
| ATM or self-service PIN entry | Does the EPP and completed system follow the required integration path? |
| External reader attached to a host | Does the SCR or SCRP scope cover the data path and host relationship? |
| Contactless-only acceptance | Does the listed function and payment stack support the intended cardholder verification flow? |
The PCI PTS version identifies the requirements used during evaluation, not a permanent quality grade. A version number must be read together with the exact device, approval class, approval date, firmware record and expiry date.
The current PCI SSC schedule gives POI v5, v6 and v7 device models different approval horizons. The official listing shows 30 April 2027 for v5.x POI device models, 30 April 2032 for v6.x and 30 April 2035 for v7.x. A buyer should recheck the schedule at procurement because PCI SSC can update program documents and listing presentation.
PCI PTS POI v7.0 changed the current evaluation baseline rather than cancelling every earlier device overnight. According to the PCI SSC v7.0 announcement published in May 2025, the revision added requirements and guidance for areas including biometric interfaces, third-party applications, stronger effective key strength and accessibility-related PIN-entry features.
POI v6 and later firmware entries can expire before the overall device approval. PCI SSC listing guidance states that firmware for v6 or higher expires three years from approval and cannot extend beyond the device's overall approval expiry. Procurement must therefore check the firmware row instead of copying only the device-level date.
The distinction between technical expiry and deployment permission deserves a direct rule.
PCI PTS approval expiry ends the device's active approval-listing period; it does not remotely disable installed hardware. Payment brands and acquirers determine whether expired devices may be purchased, newly deployed or kept in service, and a replacement decision should consider both policy and exposure to newer attack methods.
That distinction prevents two costly errors: replacing an entire fleet without checking program rules, or buying end-of-life stock because the terminal still powers on.
Remaining approval life should cover the procurement, integration, rollout and support plan. A device with 12 months before expiry may be technically acceptable for an existing program but economically poor for a three-year launch that still needs certification, pilot testing and field deployment.
A near-expiry purchase needs a written migration path. The supplier should identify the successor model, expected approval route, software compatibility, accessory reuse, key-injection implications, spare-parts period and last order date.
PCI PTS expiry and manufacturer end of life are different events. A supplier can stop producing a currently approved device, or continue holding stock for a model whose approval period is closing. Procurement should track both dates because one affects program status and the other affects availability, repair and support.
Secure firmware forms part of the evaluated device configuration. Firmware can control PIN handling, secure boot, key management, tamper responses, card interfaces and the separation between payment functions and third-party applications. A model-name match cannot compensate for an unlisted secure firmware build.
An Android version and a PCI firmware version are not necessarily the same identifier. A smart terminal may expose an Android build number, payment application version, kernel version, bootloader version and secure processor firmware. The supplier must identify which values map to the PCI SSC listing and which values belong to other approval layers.
OTA management should block unapproved combinations before deployment. A terminal management system should target devices by hardware and secure firmware eligibility, stage the release, record the installed result and support a controlled recovery path. The wider POS payment security controls remain relevant because fleet identity, access control and monitoring determine whether an approved configuration stays controlled after shipment.
Every production firmware change should carry a certification-impact decision. The change record should identify the affected device versions, security functions, laboratory or approval-holder review, regression tests, release authorization and whether the listing needs an update.
A rollback image needs the same scrutiny as an upgrade image. A rollback can reintroduce a vulnerable or expired build even when the newest version is approved. The TMS policy should define the lowest permitted version and the emergency conditions under which rollback is allowed.
OEM and ODM changes can affect approval when they alter the evaluated configuration or security boundary. A new logo or carton may be low risk, while a different secure component, card reader, keypad, PCB, enclosure, antenna placement or secure firmware can require assessment by the approval holder and laboratory.
Component substitution deserves a stop point in the engineering change process. PCI listing guidance warns that using components different from the approved components can invalidate the device approval. Procurement should not accept a “form, fit and function equivalent” argument for a security component without approval evidence.
Third-party Android applications need explicit control on newer payment devices. PCI PTS POI v7 listings can identify support for third-party applications under defined isolation conditions. An open application environment should therefore be reviewed against the feature notation, secure architecture and supplier policy rather than assumed from the presence of Android.
The same rule applies when a buyer evaluates a named supplier platform.
ZCS Z90 is an Android payment terminal whose manufacturer documents list PCI 5.x, EMV Contact Terminal L1 and L2, and EMV Contactless Terminal L1. Those manufacturer-stated claims remain procurement inputs until the buyer matches the approval number, hardware, firmware, expiry status and acquiring acceptance.
That evidence standard would apply equally to any PAX, Ingenico, Verifone or other terminal proposed for the same project.
A useful engineering change request answers five compliance questions before release. The change owner should record what changed, which approvals may be affected, who assessed the change, what testing is required and which document authorizes production.
Mass production should remain traceable to the accepted sample. The production BOM, PCB revision, secure component list, firmware package and label format should link to the sample that passed the buyer's review. Approved substitutions should carry the same traceability.
The acquirer or payment brand determines program acceptance questions that the PCI SSC listing does not answer. The listing shows approval facts and lifecycle status, but it does not grant a merchant universal permission to deploy the device in every country, network or acquiring program.
A written acceptance request should name the exact configuration and project. The request should include the approval number, hardware, firmware, payment application, EMV components, country, acquiring host, transaction types, cardholder verification methods and planned deployment dates.
Expired-device decisions should not rely on a salesperson's verbal assurance. PCI SSC FAQ 1322 states that payment brands determine whether purchasing and using devices beyond the PTS approval expiry date is acceptable and directs entities to consult their acquirer or payment brand.
The buyer should ask the following questions:
A supplier evidence pack should make the quoted terminal independently traceable. Procurement should request the pack with the quotation and refresh it before the production release, not wait until customs clearance or acquirer onboarding exposes a mismatch.
| Required evidence | Minimum content | Buyer action |
|---|---|---|
| PCI SSC listing reference | Approval number, vendor, model, class and URL | Verify directly in the official listing |
| Configuration declaration | Hardware, firmware and option codes | Compare with quotation, sample and production BOM |
| Lifecycle statement | Approval expiry, firmware expiry and EOL dates | Map against rollout and support periods |
| Label and diagnostic evidence | Nameplate image and secure version output | Add to incoming-inspection criteria |
| Change-control procedure | Approval-impact review and notification timing | Add notice obligations to the contract |
| Production traceability | Lot, serial number, BOM and firmware mapping | Audit pilot and first mass-production lot |
| Acquirer evidence | Written acceptance or integration status | Confirm ownership and open conditions |
| Successor plan | Replacement model and migration assumptions | Price the lifecycle risk before award |
The evidence pack should distinguish vendor ownership from buyer ownership. The approval holder may control the PCI submission, while the buyer or payment-service provider controls the application, acquiring contract, remote-management policy and regional deployment evidence.
A decision matrix prevents commercial urgency from weakening the approval rule. The purchasing team should assign one of five statuses only after the official record, delivered configuration and acquiring policy have been checked.
| Verification result | Procurement decision | Required next action |
|---|---|---|
| Exact match, active approval, accepted by acquirer | Proceed to technical pilot | Preserve evidence and freeze configuration |
| Exact match, active but near expiry | Conditional approval | Approve lifecycle and successor plan |
| Exact match, approval expired | Hold for policy decision | Obtain written acquirer or payment-brand acceptance |
| Hardware or firmware mismatch | Reject current evidence | Require corrected unit or approval-holder explanation |
| No traceable listing | Do not describe as PCI PTS approved | Remove the claim or obtain valid official evidence |
“Proceed” still means proceed to integration and acceptance testing rather than approve mass production automatically. PCI PTS verification closes one security question. EMV, payment application, radio, market access, acquirer, operational and contractual questions remain separate release gates.
Sample inspection should create the reference configuration for production. The buyer should photograph labels, export secure version information, record the approval lookup, identify installed applications and capture the sample serial number before functional testing begins.
Production inspection should compare physical and digital identifiers. An incoming inspector can check cartons and nameplates quickly, but a defined sample from each lot should also enter the diagnostic workflow for hardware and secure firmware confirmation.
A first-article audit should include the update path. The team should verify that the TMS identifies the correct model, rejects an ineligible firmware package, records deployment results and reports failures without exposing sensitive payment data.
Recommended acceptance steps are:
The strongest red flags hide device identity behind broad compliance language. A supplier should be able to explain exactly which record supports the claim and how the delivered unit matches that record.
Contactless capability deserves its own evidence rather than a logo copied from a brochure. The article on contactless POS security standards explains why NFC hardware, EMV contactless functions, cardholder verification and payment-network acceptance remain distinct checks.
PCI PTS and PCI DSS address different scopes. PCI PTS evaluates defined payment devices and security functions, while PCI DSS establishes requirements for protecting account data across an entity's payment environment. PCI DSS does not turn an unlisted terminal into a PCI PTS-approved device.
A buyer should search the PCI SSC approved-device listing and match seven fields. The vendor, model, approval number, approval class, hardware version, firmware version and expiry status should correspond to the quoted and delivered terminal. The acquirer should separately confirm program acceptance.
An expired approval does not automatically stop a terminal from operating. Payment brands and acquirers decide whether an expired device can be purchased, newly deployed or retained in a specific program. The merchant should obtain written guidance and consider the device's ability to resist newer attacks.
PCI PTS POI v5.x device-model approvals can remain listed through 30 April 2027, subject to the exact device record and status. A buyer must still check the specific hardware, firmware, approval entry, remaining deployment period and acquiring policy rather than rely on the version label alone.
A firmware mismatch means the buyer has not demonstrated that the delivered configuration is represented by the approval. Procurement should pause the claim and request an explanation from the approval holder, updated listing evidence or a corrected production build.
EMV approval does not prove PCI PTS approval. EMV and PCI PTS evaluate different layers. A terminal may have EMV interface or kernel evidence without a matching PCI PTS device record, and a PCI PTS-approved terminal still needs the relevant payment integration and acceptance work.
Branding alone does not produce one universal answer because the exact change and listing identity matter. A buyer should ask the approval holder whether the model name, label, enclosure and production record remain within the approved device family. Security-relevant hardware or firmware changes require deeper assessment.
The relevant payment brand or acquirer decides whether use beyond PCI PTS approval expiry is acceptable for its program. PCI SSC publishes the approval status and expiry framework, but merchants should obtain program-specific direction before purchasing or continuing deployment.
A defensible PCI PTS purchase decision approves one traceable terminal configuration. The approved record should connect the supplier, model, approval number, approval class, hardware, firmware and lifecycle status to the sample, production BOM, incoming inspection and acquiring decision.
The purchasing rule is simple: no exact match means no verified claim. A recognized brand, familiar enclosure, laboratory logo or certificate PDF can support due diligence, but none can replace the official record and the identifiers on the delivered unit.
Lifecycle evidence should remain active after the purchase order. Firmware releases, component substitutions, OEM changes, approval expiry and product end of life can change the answer. The buyer should therefore treat PCI PTS verification as a controlled release process rather than a one-time document collection exercise.
Home 
How to Specify Unattended Payment Terminals for Kiosks, Vending, Parking and EV Charging? 
