Buyer guide

PCI DSS / P2PE for Payment Kiosks: What OEM/ODM Buyers Must Audit Before Launch

PCI DSS is a go/no-go gate for unattended payment kiosks, not a final paperwork step. Here is the evidence pack OEM/ODM buyers must demand from a factory — PTS POI listing, EMVCo letters, P2PE reference, chain of custody — and how to read an AOC or approval notice.

PCI DSS / P2PE for Payment Kiosks: What OEM/ODM Buyers Must Audit Before Launch

Quick answer: PCI DSS is a go/no-go gate for unattended payment kiosks, not a final paperwork step. Here is the evidence pack OEM/ODM buyers must demand from a factory — PTS POI listing, EMVCo letters, P2PE reference, chain of custody — and how to read an AOC or approval notice.

Overview

Short answer: When you buy an unattended payment or cash-handling kiosk OEM/ODM, PCI compliance is a go/no-go condition of the project , not a final paperwork step. Before you sign, get four things from the factory: the PCI PTS POI approval listing for the exact card reader, the PCI SSC validated P2PE solution reference (if encryption is claimed), the EMVCo approval for the reader kernel, and a chain-of-custody process you can audit. Below is the evidence pack to request and how to read each document.

Why PCI is a procurement gate, not a sticker

Most supplier articles answer “what is PCI DSS.” The buyer’s real question is different: which documents prove the machine I am buying is actually approved, and who carries the liability when a card brand audits the deployment? In unattended projects — self-checkout, ticketing, parking, casino cash-out — the terminal sits outside any cashier’s supervision. That is exactly where a paper-deep “we are PCI compliant” claim fails: the acquirer asks for device-level approvals, not a logo.

Non-compliance is not an abstract risk. Acquirers fine merchants, and card brands can exclude a terminal from a tender or a rollout. The failure mode buyers describe again and again is the same: the factory showed a certificate, but it was issued for a different reader, a different model, or a different factory.

Know which layer you are auditing

PCI is a stack of separate approvals. A supplier that blurs them is usually hiding a gap. Map your project to the right layer before you ask for documents:

Know which layer you are auditing
LayerWhat it approvesWho holds it
PCI PTS POIThe physical card reader / PIN pad hardware (tamper response, key management)The reader manufacturer (Ingenico, Verifone, etc.), not the kiosk integrator
EMVCo L1 / L2Reader hardware (L1) and the payment kernel (L2)The reader and kernel vendors
PCI validated P2PEThe encryption solution that removes card data from your environmentA P2PE solution provider, listed by PCI SSC
PCI DSS AOCA service provider’s own DSS assessmentAny provider touching card data (hosting, gateway, managed service)
SAQ (A / A-EP / P2PE)Your merchant scope, based on how you deployYou, the merchant/operator

The practical point: a kiosk integrator rarely holds PTS or P2PE approval — those belong to the reader and encryption vendors. What the integrator must prove is that it uses approved components and does not break their approval during integration. That is the distinction most RFPs miss.

The evidence pack: demand documents, not logos

For every payment kiosk quote, request these artifacts in writing. Each has a specific proof it carries and a specific red flag:

The evidence pack: demand documents, not logos
ArtifactWhat proves it is realRed flag
PCI PTS POI approvalReader model appears on the PCI SSC approved-POI listing, with the approval version“PCI compliant reader” with no model or listing reference
EMVCo approval letterReader L1 and kernel L2 approvals reference the exact firmware versionApproval for a different firmware revision than shipped
P2PE solution referenceSolution is listed on the PCI SSC validated P2PE solutions page, with reference number“P2PE encrypted” with no validated solution ID
Chain of custodyDocumented process for device injection, shipping, and tamper-seal verificationDevices shipped without sealed, recorded custody
Integration change noteWritten confirmation that integration did not modify the approved moduleReader mounted/enclosed with no re-validation statement

How to read a CoC / attestation / approval notice

Three documents look similar and mean different things. Read them in this order:

  • Attestation of Compliance (AOC). A service provider’s signed statement of its own DSS assessment. It tells you the provider was assessed — not that your kiosk’s reader is approved. Check the scope, the assessment date, and the DSS version it cites.
  • Approval / listing letter. For hardware, this is the PCI SSC PTS POI listing or the EMVCo letter. Verify the model and firmware version match the units you will receive, not a sibling model.
  • Certificate of Conformity (CoC) from a lab. A test lab’s report that a device met a standard. Useful supporting evidence, but it is not a substitute for a PCI SSC listing. Ask which standard, which version, and which exact configuration was tested.

One rule saves most buyers: look up the device yourself. An approval you cannot independently verify on the PCI SSC site is not evidence.

Where OEM/ODM customization breaks compliance

This is the risk that is unique to OEM/ODM and that finished-brand suppliers do not face. When you change the enclosure, swap the reader, add a cash module, or move to a different factory, you can invalidate an approval that was granted for a different configuration. Ask explicitly:

  1. If I change the reader model or its mounting, does the PTS/EMVCo approval still apply to my configuration?
  2. Who re-runs validation, and who pays for the cost and timeline of re-approval?
  3. If my market is the US, EU, or GCC, does the payment approval travel with the hardware, or is it market-specific?
  4. Who owns the merchant SAQ — you, the operator, or a third-party processor — under my deployment model?

Get the answer in the quotation, not after tooling is paid for. Re-certification can add weeks to a schedule and belongs in the contract as a named responsibility.

Copy-paste RFP questions for payment approval

  1. List the exact reader model in your proposed configuration and its PCI PTS POI approval version and listing reference.
  2. Provide the EMVCo L1/L2 approval letters for the reader and kernel, including firmware version.
  3. If P2PE is claimed, give the PCI SSC validated P2PE solution name and reference number.
  4. Provide your chain-of-custody procedure for device injection, shipping and tamper-seal verification.
  5. Confirm in writing whether your integration modifies the approved module, and if so, what re-validation is required.
  6. Identify which party is responsible for the merchant SAQ under my deployment model.
  7. For my target market, list any market-specific payment approvals beyond the global ones.

Payment approval is one layer of a risk-managed OEM/ODM buy. For the certification layer around it — CE, FCC, RoHS and ISO 9001 — see the 2026 OEM/ODM Kiosk Procurement Checklist . For the factory paperwork that must accompany payment hardware before production, see Kiosk Production Approval: 9 Documents a Factory Must Provide . To see how cash and payment modules are specified end-to-end, review this payment kiosk hardware and cash integration guide and the cash recycler vs. deposit machine comparison . For a worked example of a payment-ready cabinet, see this freestanding cash-handling kiosk or its currency-exchange configuration .

Does a kiosk being “PCI DSS compliant” mean the card reader is approved?

No. PCI DSS is the data-security standard; the physical reader is approved under the separate PCI PTS POI programme, and the payment kernel under EMVCo. Ask for the device-level listing, not only a DSS claim.

What is a validated P2PE solution and why does the reference number matter?

A P2PE solution encrypts card data at the point of interaction so it never enters your systems in the clear, which can reduce your PCI scope to SAQ P2PE. Only solutions listed by PCI SSC as validated carry that benefit — so ask for the solution name and reference number, not just the phrase “P2PE.”

Can OEM/ODM customization invalidate a payment approval?

Yes, potentially. Changing the reader, its mounting, firmware or the factory can move the product outside the configuration that was approved. Confirm in writing whether integration modifies the approved module and who is responsible for any re-validation.

Your next step

Do not accept “we are PCI compliant” as an answer. Ask for the reader listing, the EMVCo letters, the P2PE reference and the chain-of-custody process — and verify them yourself before tooling is committed. If you are evaluating a payment or cash-handling kiosk partner and want to see how approvals are documented up front, review a payment-ready cash-handling kiosk , or request a quote or datasheet and we will send the approval package for our current production models.

Editorial standard

Prepared from Usingwin product, engineering and manufacturing information. Final compatibility, certification, MOQ and lead time are confirmed for each project.

Chengdu Usingwin Technology Co., Ltd.

From research to requirements

Put this guide to work for your project.

Tell us what you need to build or source. Our OEM/ODM team can help you review the hardware fit and the next steps toward a quotation.

  • Application and target market
  • Screen, peripherals and software integration needs
  • Order quantity and target timeline

Prefer email? [email protected]

Your inquiry will reference: PCI DSS / P2PE for Payment Kiosks: What OEM/ODM Buyers Must Audit Before Launch

Our OEM/ODM team will review your requirements and reply by email.

Chat with us