Quick answer: A module swap is a certification event before it is a purchasing event. The checks below are written as questions you send a module vendor, so the shortlist conversation produces documents instead of datasheet claims.
Overview
A module swap is a certification event before it is a purchasing event. The checks below are written as questions you send a module vendor, so the shortlist conversation produces documents instead of datasheet claims.
Your kiosk module choice sets the certification footprint, not just the BOM line
The approval that governs your build sits on a specific module SKU plus its hardware and firmware revision, so swapping the part can reset part of the approval chain even when the replacement is itself approved. The decision in front of you is therefore a certification-footprint decision, not a BOM-line decision.
Buyers routinely conflate two separate questions. The first is what the module vendor holds: the EMV L1 hardware approval for the reader, the EMV L2 approval for the payment application, and the PCI PTS approval for the device as shipped. The second is what your deployment must show: your own payment application approval state, your acquirer and processor onboarding, and the PCI DSS scope that sits with the deployer or merchant rather than with the module vendor.
Approval scope, revision coverage, fees and renewal cycles vary by vendor, by scheme and by date. Nothing on this page should be treated as a fixed figure or a version number — where we do not have a confirmed value, we say so and give you the field to fill in with your vendor and acquirer in writing.
This page is deliberately narrow: module selection and what a swap re-triggers. If your open question is who carries assessment obligations once the kiosk is deployed, that is a different topic — keep the two separate in your sourcing file so you do not pay twice for one answer. For how hardware and certification lines sit inside a full quotation, the line-item kiosk cost breakdown is a useful worked structure.
Six checks to run before a contactless payment kiosk module reaches your shortlist
Run these as a written questionnaire, not a call. A module should only reach the shortlist when the vendor has answered all six with documents or explicit “not covered” statements, because the answers determine your recertification exposure, your mounting design and your second-source options.
Check 1 — Ask for the approval letter, not the datasheet
The document must name the product, the hardware revision and the firmware version it covers. A datasheet that says “EMV approved” without a named revision cannot be reconciled with the part you are buying.
Check 2 — Confirm who holds the PCI PTS approval, and what voids it
Ask whether the vendor holds the PCI PTS approval for the module as shipped, and ask directly what happens to that approval if you change firmware, the secure element, the antenna or the surrounding housing. Get the answer in writing before you design the bezel.
Check 3 — Establish the approved mounting and environment
A reader approved for indoor countertop use is not automatically approved for an outdoor or high-vibration enclosure. Ask the vendor to state the mounting and environmental conditions the approval covers, and compare that against your actual kiosk — a freestanding cash-handling build and a wall-mounted unit impose different mechanical conditions on the same reader.
Check 4 — Request the integration interface sheet
USB or serial, power budget, supported OS versions, SDK maturity, and whether a reference integration exists on your compute platform. A module with no reference integration on your platform shifts engineering hours into your budget.
Check 5 — Get the second-source answer before you need it
Ask whether an approved, pin-compatible alternative exists, whether it reuses your existing integration, and what the vendor’s documented product change notification and end-of-life notice periods are. If the answer is “no alternative”, price that into the programme.
Check 6 — Confirm the delivery package contents
State precisely what arrives with the part: approval documentation, kernel and attestation files, firmware update path, and who is responsible for supplying updates over the product’s life.
What must be re-certified vs what stays valid when you swap the EMV module
Assume the module-level approval does not transfer: your integration, payment application approval and acquirer acceptance normally need re-confirmation for the new SKU and firmware revision. Treat re-confirmation as the default until the vendor and your acquirer prove otherwise in writing for your exact configuration.
| Element | Commonly re-triggered by a module swap | Commonly still valid | Who confirms it |
|---|---|---|---|
| EMV L1 hardware approval | Yes — bound to the reader product and revision | — | Module vendor |
| EMV L2 payment application approval | Often, if the application or kernel pairing changes | If the same approved application is reused unchanged | Payment application provider |
| PCI PTS approval | Yes if firmware, secure element or housing changes | Only within the vendor’s stated approved configuration | Module vendor |
| Firmware / kernel attestation | Yes — new baseline must be attested | — | Module vendor and payment app provider |
| Deployment PCI DSS scope | Re-assess, not automatically reset | Your existing controls and documentation | Deployer / merchant and acquirer |
| Acquirer onboarding and terminal identity | Usually, for a new terminal or new build variant | Existing merchant agreement terms | Acquirer / processor |
| Field pilot and acceptance test | Yes — new part, new pilot | — | You |
The cells above describe what is commonly re-triggered, not a rule. The only authority is your vendor’s and acquirer’s written confirmation for your exact SKU, hardware revision and firmware version.
The classic misread this table prevents: “the new module is approved” is not the same statement as “your kiosk build is approved”.
Where swap cost actually bites: BOM, integration effort, field re-test
A swap budget has more lines than the unit price delta. Split it into five buckets before comparing modules: module unit price change, mechanical change (bezel, cutout, antenna clearance, cable routing), firmware and kernel integration hours, re-approval or laboratory time, and pilot units plus field validation before any fleet release.
Two line items buyers routinely miss: stocking spares across two module generations during the transition, and re-issuing documentation and training so field technicians can service both variants. Both are real costs in a multi-year build.
Timelines and fees for re-approval are vendor-, scheme- and laboratory-dependent and should be quoted per project. Put these questions to your vendor instead of accepting an estimate: what is covered in the approval you already hold, what is charged for a revision change, how long the revision change takes in their experience, and whether the change requires a new sample submission.
The counter-case is worth stating plainly: a module with a documented second source, a published notice period and a clear firmware update path can be cheaper across a three-to-five-year build than a cheaper module that forces a mid-life redesign. That trade sits inside total cost of ownership rather than unit cost, and the kiosk procurement TCO comparison shows how to structure it.
How to verify EMV L1/L2 scope and PCI PTS status without taking anyone’s word for it
Verification means matching a document to a part. The approval must name the exact product, hardware revision and firmware version you are buying, and be dated within a cycle your vendor confirms is current. Anything that cannot be matched to your build is an open item, not a settled one.
Practical sequence:
- Ask the vendor to point you to the listing or register entry that supports their claim, and cross-check it against the scheme and standards bodies that publish approvals — the EMVCo and PCI Security Standards Council sites are the starting points for what an approval programme covers.
- Reconcile the documentation with the physical sample: secure element identifier, labelling, and the revision markings on the part you actually receive.
- Require a written statement covering the approval holder, the products and revisions covered, what voids the approval, and the notice period for changes.
- Run a sample-level acceptance test across multiple card schemes and mobile wallets, record tap behaviour and transaction timing, and confirm that the terminal identity your acquirer registers matches your build — not a development unit.
- For every number, date or fee you cannot confirm from a primary source, create a “confirm with vendor” field in your sourcing sheet rather than writing a value into the specification.
The vendor listing pages maintained by contactless reader manufacturers are useful for orientation on what products exist in the unattended category, but they are marketing pages: they show that a product line exists, not that your configuration is covered.
Dual-sourcing an NFC payment module kiosk build without re-certifying twice
Dual-sourcing only saves money if both modules can be approved under the same integration and the same payment application. The qualifying question for a second source is not price — it is whether the second module reuses each approval layer or resets it.
- Qualify the second source in parallel, while the first is still in volume production. A second approval is far cheaper before you are under delivery pressure.
- Insist on pin-compatibility, identical mounting geometry and the same host interface before discussing commercial terms. A part that needs a chassis change is a second product, not a second source.
- Contract for documented product change notification and end-of-life notice periods, plus last-time-buy terms.
- Keep a versioned firmware baseline for each approved variant, so a future swap is a comparison exercise rather than a discovery.
Broader contactless acceptance and multi-currency capability are widely cited drivers behind kiosk payment builds, but demand trends do not change the sourcing decision — approval scope does. If you are also specifying cash and biometric elements alongside contactless, the payment hardware selection guide covers how those choices interact mechanically and in certification scope.
Contract terms that protect you when a payment module is discontinued
Put four things in the supply agreement: a written approval-scope statement per SKU and revision, a stated notice period for product change and end of life, a last-time-buy guarantee, and either a named approved second source or a documented alternates path.
Tie payment milestones to delivery of approval documentation and a passing sample acceptance test, not to shipment alone. State who owns the effort and cost of re-approval if the vendor changes firmware, the secure element or the module itself. Those clauses convert a future discontinuity from an emergency into a scheduled task.
If your build needs a contactless module integrated into a bespoke enclosure — the mechanical side of a swap is where most swaps go wrong — that is a design-and-manufacturing question as much as a component question. Products such as the freestanding cash-handling self-service kiosk show how reader placement, cable routing and service access are resolved at the platform level rather than left to the module datasheet.
Request a 2026 quote plus a list of pre-approved EMV/NFC payment module options for your kiosk. Tell us your kiosk form factor, compute platform, mounting environment, target card schemes and whether you already hold a payment application approval — we will return module options with their documented approval scope, the integration path, and the questions to send your acquirer. Our custom kiosk payment hardware capability covers design, integration and volume manufacturing for self-service builds.
FAQ: module swaps, PCI PTS and dual-sourcing
Does swapping the payment module force full EMV re-certification?
Assume module-level approval does not transfer. Your integration, payment application approval and acquirer acceptance normally need re-confirmation for the new SKU and firmware revision. The exact scope depends on what the vendor’s approval covered and what actually changed — reuse of the same payment application is the main factor that limits the work, so confirm that in writing rather than assuming it.
Can I use any PCI PTS approved module in my kiosk?
No. The PCI PTS approval belongs to a specific product and revision as the vendor shipped it. Changing firmware, the secure element, the housing or the way the reader is mounted can fall outside that approval, so ask the vendor to confirm coverage for your exact configuration and mounting before you commit the mechanical design.
How long does a module swap re-approval take?
Timelines are vendor-, scheme- and laboratory-dependent and should be quoted per project. Budget re-approval, pilot and fleet validation as separate phases with their own gates, and ask the vendor for the duration of comparable revision changes they have processed rather than accepting a general estimate.
How do I dual-source a contactless payment kiosk without paying twice for certification?
Qualify the second module in parallel while the first is still in production, prefer pin-compatible parts that reuse the same integration and the same approved payment application, and contract for notice periods and last-time-buy terms. If the second module resets every approval layer, it is not a second source — it is a separate programme, and it should be costed as one.
