EMV Level 1 vs Level 2 for POS Terminals: What Buyers Need to Verify Before Certification and Rollout

This guide is for POS hardware buyers, integrators, and deployment teams evaluating EMV certification requirements. Understanding the distinction between EMV Level 1 and Level 2 is crucial for deployment success, as it directly impacts rollout readiness, compatibility, and long-term support for payment terminals in real-world environments. Knowing these differences helps ensure that your POS terminals are not only compliant but also reliable and scalable across diverse payment environments.

EMV Level 1 vs Level 2 is not a minor technical distinction for payment terminals. In buyer terms, EMV Level 1 checks whether the terminal can communicate correctly with a chip card or contactless payment device at the physical interface level, while EMV Level 2 checks whether the terminal’s software kernel or payment application can process EMV transactions correctly. EMV standards are a set of specifications and certification levels that ensure payment devices and software meet security and interoperability requirements. EMV technology is a critical security standard in digital payment systems, enabling secure, contactless transactions and reducing fraud through chip-based cryptographic protocols. Proper EMV certification and compliance efforts help mitigate fraud risks, enhance transaction security, and protect businesses from fraudulent activities associated with card payments. EMV certification is a multi-level process essential for ensuring the security, interoperability, and reliability of payment devices and systems. Together, EMVCo describes Level 1 and Level 2 as Terminal Type Approval, but buyers still need to remember that end-to-end deployment success also depends on Level 3 integration with payment-system infrastructure.

For POS hardware teams, that means a terminal can look modern, support tap, and still become a rollout problem if the reader hardware, kernel version, processor dependencies, or field replacement path are not controlled. Full EMV compliance is crucial for global card network approval and platform compatibility, ensuring that all EMV standards and certification levels (L1, L2, L3) are met to prevent deployment delays and gain trust from stakeholders and payment networks. The right buying question is not simply “Does it support EMV?” but “Which EMV layer has been approved, what exact configuration is covered, and what could break when we scale this terminal across real sites?”

EMV certification compliance is required for all payment processing systems, including POS terminals, kiosks, and payment software, to meet security and functionality standards.

Definitions

• EMV Level 1 certification primarily focuses on the physical and electrical functionality of the payment device, ensuring it can communicate properly with EMV cards under various operating conditions.
• EMV Level 2 certification evaluates the software layer of the payment device, commonly referred to as the EMV Kernel, which interprets card data and executes transaction rules.
• The main difference between EMV Level 1 and Level 2 is that Level 1 covers hardware plumbing, while Level 2 covers software logic.
• EMV Level 1 focuses on the physical and electrical interface between the card and the reader, while Level 2 focuses on the EMV transaction logic and scheme kernels that run on the terminal.

The Shortest Accurate Explanation

EMV Level 1 is the terminal’s communication layer. EMVCo says it covers the communication protocols between the payment instrument and the acceptance device, including the mechanical, electrical, and radio-frequency interfaces. In plain buyer language, L1 is about whether the reader hardware can reliably talk to inserted chip cards or contactless cards, phones, and wearables. EMV Level 1 specifically focuses on the physical and electrical interface between the card and the reader, ensuring that the hardware can establish secure card communication as the foundation for all subsequent transaction processing.

EMV Level 2 is the terminal’s processing layer. EMVCo describes L2 as the software component, commonly known as the kernel or payment application, that contains the processing logic and data needed to perform an EMV contact or contactless transaction. In buyer language, L2 is about whether the terminal software stack knows how to handle the EMV transaction correctly after the card or device is read. Level 2 focuses on the EMV transaction logic and scheme kernels that run on the terminal, supporting various transaction types such as card authentication, PIN verification, and real-world transaction processing across multiple card schemes and payment networks.

That is why the cleanest summary is this: Level 1 verifies that the terminal can communicate correctly, Level 2 verifies that the terminal can process correctly, and Level 3 verifies that the terminal functions correctly with the actual acceptance infrastructure used in the field. EMV Level 3 certification ensures that the entire transaction flow and lifecycle work seamlessly, including communication between the payment device, acquiring bank, and card network. EMV certification at all levels is designed to ensure secure transaction processing, so that payment transactions are processed securely and in compliance with industry standards. Supporting various transaction types and ensuring secure transaction flow through all certification levels is critical for reliable and fraud-resistant payment acceptance. Buyers who skip that layered view usually underestimate rollout risk.

This overview sets the stage for understanding why confusion between Level 1 and Level 2 is common—and why it matters for successful deployment. Next, let’s explore why buyers often confuse these two EMV certification levels.

Why Buyers Confuse EMV Level 1 and Level 2

Many teams hear that a terminal is “EMV certified” and assume the terminal is fully ready for deployment. However, the EMV certification process is a structured procedure designed to ensure payment acceptance systems meet strict security and interoperability standards across payment networks and card networks. EMVCo’s own materials show why that assumption is too broad. EMV Level 1 and EMV Level 2 assess different functional aspects of the acceptance device, and together they are referred to as Terminal Type Approval. That means the approval is layered, not monolithic.

The confusion gets worse because commercial discussions often collapse hardware, kernel, and processor integration into one sentence. A product team may talk about “EMV approval,” while an acquirer or processor may still require additional Level 3 testing or certification for the terminal’s end-to-end behavior in the target acceptance infrastructure. For payment acceptance systems, meeting EMV certification requirements is essential to handle transactions securely and reliably across different environments, from retail POS terminals to EV charging stations. EMVCo explicitly states that Level 3 testing is defined by each payment system’s policies and is used by acquirers and processors to achieve L3 testing and certification with participant systems.

For buyers, the result is predictable: teams approve hardware assuming certification is done, while deployment teams later discover kernel dependencies, software mismatches, or processor-specific integration steps that were never frozen at the purchase stage. That risk is not a theory. It follows directly from the fact that L1, L2, and L3 govern different parts of terminal readiness, with payment networks and card networks playing a key role in defining Level 3 testing and certification requirements.

Now, let’s break down what EMV Level 1 actually covers in a POS terminal, and why it’s more than just “the card reader works.”

EMV Level 1: What It Actually Covers in a POS Terminal

Contact Terminals

For contact terminals, L1 touches the chip reader path. The process of card insertion and the electrical interface are critical for establishing a secure connection between the EMV chip and the reader, ensuring the card is correctly powered, detected, and read by the terminal during Level 1 testing.

Contactless Terminals

For contactless terminals, L1 covers the radio and proximity behavior that makes tap acceptance work, with field communication ensuring reliable data exchange between the payment instrument and the acceptance device. Configuring appropriate risk parameters is essential for contactless acceptance, as it ensures compliance with certification requirements and supports reliable operation in real-world deployments.

Approval Processes

EMVCo’s approval processes reflect this separation: there is an IFM Level 1 Approval Process for the contact interface module, and a PCD Level 1 Approval Process for the proximity coupling device used in contactless acceptance. In both cases, EMVCo issues a Letter of Approval when the test report demonstrates sufficient product conformance.

Buyer Implications

This matters because buyers often reduce L1 to “the card reader works.” That is too shallow. In real deployments, Level 1 has direct consequences for dip stability, tap performance, contactless read behavior, antenna behavior, insertion feel, and field consistency. Level 1 certification primarily focuses on the physical and electrical functionality of chip terminals, ensuring proper communication with EMV chip cards and adherence to EMV chip specifications. If L1 is weak or poorly matched to the intended use case, the customer experience slows down, and support teams inherit unnecessary troubleshooting. That is an inference from EMVCo’s description of L1 as the communications interface layer and its emphasis on contactless range and data exchange reliability.

If you are sourcing a terminal for both dip and tap, do not treat “EMV ready” as enough. Verify which Level 1 paths are actually relevant to the terminal you are buying and whether the approved configuration matches the exact deployment form factor. Level 1 certification ensures the reader can reliably power and communicate with the card under defined conditions, which is crucial for transaction success. The adoption of chip technology in EMV chip terminals plays a key role in reducing fraud and enabling secure, contactless payments for modern commerce.

Understanding Level 1’s scope leads directly to the next layer: what happens after the card or device is read? That’s where Level 2 comes in.

EMV Level 2: What It Actually Covers in a POS Terminal

Contact Transactions

For contact transactions, EMVCo maintains a Contact Kernel approval process.

Contactless Transactions

For contactless, EMVCo has launched an approval process for the new EMV Contactless Kernel, and its published explanation notes that kernels are the software used by point-of-sale terminals and ATMs to process contactless transactions. EMVCo also says the new contactless kernel was designed to standardise contactless kernels and create opportunities to reduce costs, improve rollout speed, and shorten time to market.

Approval Processes

EMVCo’s contactless product approval process requires successful validation of the PCD, the Entry Point, and at least one kernel. That means contactless readiness is not a single checkbox. It is a structured approval stack.

Buyer Implications

A terminal may have solid reader hardware, but if the wrong kernel variant, wrong payment application, or wrong approved configuration is deployed, the terminal can still fail certification or behave inconsistently in production. L2 is therefore not just a software footnote. It is one of the main points where deployment readiness, processor compatibility, and version control converge. That conclusion follows from EMVCo’s own description of the kernel as the software that actually processes EMV transactions. Robust error handling is also critical at this stage to ensure smooth transaction flows, prevent failures, and maintain compliance during real-world payment processing scenarios. EMV Level 2 testing confirms that the terminal can handle various transaction types and scenarios, including different card brands, EMV chip cards, and EMV cards, across multiple card schemes. The EMV Level 2 kernel must validate the card, authenticate the cardholder, and determine whether the transaction should be approved or declined. EMV testing tools and processes are vital for validating the software layer and kernel functions, supporting transaction simulation, cryptogram validation, and compliance across all supported card brands and schemes.

With Level 2’s software logic defined, the next step is to compare how Level 1 and Level 2 map to real buyer questions and deployment scenarios.

EMV Level 1 vs Level 2 for POS Terminals: The Buyer’s Comparison

Buyer question	More tied to Level 1	More tied to Level 2	Why it matters
Will the terminal reliably read an inserted chip card?	Yes	Indirectly	This starts with the physical and electrical communication layer
Will tap payments work consistently at the counter?	Yes	Yes	L1 affects contactless exchange behavior; L2 affects contactless transaction processing
Does the terminal kernel support the required EMV transaction logic?	No	Yes	That is the kernel’s role in EMV processing
Can the terminal be updated without breaking approvals or processor dependencies?	Indirectly	Yes	Kernel and payment application control are usually the bigger risks
Can we swap failed hardware without changing the reader behavior?	Yes	Indirectly	Mechanical, electrical, and RF paths must stay stable across replacements
Can the same terminal family be standardized across many stores?	Yes	Yes	Standardization fails if either the interface behavior or the kernel baseline drifts
Are we actually ready for launch with the chosen processor/payment system?	No	No	This is where Level 3 and participant-system requirements enter

What Buyers Should Verify First: Hardware Path, Kernel Path, or Integration Path?

The answer depends on the project.

If the terminal is being selected for a new counter design, a new self-checkout unit, or a new mobile form factor, buyers should start with the hardware path first. That means verifying the Level 1 side: inserted chip behavior, contactless positioning, antenna or reader behavior, and form-factor suitability for the actual checkout motion. EMVCo’s Level 1 definition makes that the correct starting point because it governs the physical exchange of payment data between the payment instrument and the acceptance device. Regular firmware updates are also critical at this stage to maintain terminal stability, security, and compatibility with evolving scheme requirements.

If the physical platform is already fixed but the deployment is changing processors, payment applications, contactless methods, or regional acceptance requirements, start with the kernel path. That means verifying the Level 2 side: which kernel is in use, which contact or contactless processing path is implemented, and whether the exact approved software baseline matches the target deployment. Terminal manufacturers play a key role here, as they are responsible for developing and testing payment terminals to ensure EMV compliance at both Level 1 and Level 2. EMVCo’s descriptions of contact kernels and contactless kernels support that priority.

If the terminal is already chosen and both L1 and L2 appear to be in place, the next question is the integration path. EMVCo states that Level 3 testing validates the integration of an EMV acceptance device with its acceptance infrastructure to help ensure interoperability of an end-to-end EMV transaction, and that participant systems provide the L3 test cases. Financial institutions are actively involved at this stage to ensure secure, reliable, and smooth payment transactions between merchants, card networks, and issuing banks during certification and deployment. That means buyers cannot treat L1 and L2 as the final deployment gate.

With priorities set, the next section provides a structured matrix to guide your certification and rollout checks.

Selection Matrix: What to Check Before Certification and Rollout

Deployment Scenarios and Priorities

Deployment scenario	Priority	What to verify	Main risk if missed	Best-fit POSZEO family bridge
Fixed cashier station with dip + tap	L1, then L2	Reader stability, contactless behavior, exact kernel baseline	Customer-facing payment friction at scale	Desktop POS Systems
Tap added late, and rollout complexity spikes	L1, then L2, then L3	Tap ergonomics, device RF behavior, kernel baseline, processor path	Great demo, unstable field acceptance	Mobile Handheld POS
Self-checkout or kiosk	L1 and serviceability together	Contactless positioning, reader placement, swap path, kernel approvals	High downtime if a reader fails or misreads	Self-Service Kiosk
Refresh of an existing accepted terminal family	L2 and L3 first	Whether the new kernel/software baseline changes the certification effort	Pilot works, rollout stalls later	Desktop POS Systems / Peripherals
Contactless upgrade on existing estate	L2 and contactless approval stack	PCD, Entry Point, minimum one kernel, software coexistence	Tap was added late, and rollout complexity spikes	POS Accessories & Peripherals

EMV chip technology and contactless payments have seen widespread adoption in global markets, driving secure and efficient transactions across regions.

Major schemes such as Visa, Mastercard, and RuPay play a critical role in ensuring interoperability and security across different payment environments, setting certification standards that POS terminals must meet for reliable transaction processing.

With deployment scenarios mapped, it’s important to understand why Level 1 and Level 2 approvals alone do not guarantee market readiness. The next section explains why.

Why Level 1 and Level 2 Still Do Not Equal “Ready for Market”

This is the biggest mistake buyers make after they learn the L1/L2 distinction.

EMVCo says that L1 and L2 are collectively Terminal Type Approval, while Level 3 aims to validate integration of the EMV acceptance device with acceptance infrastructure for end-to-end interoperability. L3 certification is the final validation stage that ensures end-to-end transaction integrity, interoperability across payment schemes, and reliable processing of payment transactions in real-world scenarios. EMVCo also states that L3 testing is defined by each payment system’s policies and is used by acquirers and processors in achieving L3 testing and certification. That means the terminal can be strong at L1 and L2 and still need additional work before commercial launch under the target payment systems.

EMV compliance at all certification levels—L1, L2, and L3—is critical for security, reliability, and international acceptance. These certifications ensure the hardware, software, and transaction processes meet global payment standards, reducing fraud and enabling seamless, secure payments.

For buyers, this changes the approval checklist. You should not only ask whether the terminal has EMV approvals. You should ask which approvals apply to the exact product configuration, which kernel and software version are in scope, which participant systems or processors still require L3 work, and whether the project schedule already accounts for that path. Those questions are a reasonable deployment inference from EMVCo’s split between Terminal Type Approval and L3 integration testing.

In other words, L1 and L2 are necessary, but they are not the same thing as rollout clearance.

Next, let’s examine the most common failure patterns that buyers encounter in EMV terminal projects.

Five Failure Patterns Buyers Miss in EMV Terminal Projects

1) The terminal has Level 1 strength, but the wrong kernel baseline

• Why it happens: Procurement validates the reader hardware and assumes the terminal is “EMV certified,” but the deployed Level 2 kernel path does not match the intended processor or scheme requirements.
• How to verify: Ask for the exact kernel or payment application approval path, not just the terminal model name. Match the software baseline to the planned deployment and any L3 obligations. The EMV kernel, as the critical software layer (Level 2), is responsible for processing chip and contactless transactions, interpreting card data, and ensuring secure, compliant operation with the intended processor or card scheme.
• How to prevent: Freeze the kernel baseline before bulk ordering and treat kernel changes as controlled release events. Ensuring the correct EMV kernel and software layer are deployed is essential for reliable, compliant transaction processing across all required card schemes.

2) Contactless is added too late in the project

• Why it happens: A team assumes tap is “just another reader function,” but EMVCo’s contactless approval path requires the contactless product stack, including the PCD, Entry Point, and at least one kernel. EMV contactless transactions rely on secure field communication between NFC-enabled devices (like smartphones or wearables) and the POS terminal, making it essential to follow EMV standards for both performance and security.
• How to verify: Confirm whether the exact contactless configuration has the relevant approval evidence and whether it is the same configuration being rolled out. Ensure that the solution supports EMV contactless transactions and that field communication is tested for compliance and reliability.
• How to prevent: Treat contactless as its own approval and deployment stream, not as a late-stage feature toggle.

3) A pilot passes, but the scaled rollout breaks on replacement units

• Why it happens: The pilot uses one hardware revision or antenna/reader behavior, while field replacements are not controlled tightly enough.
• How to verify: Confirm exact approved configurations and make sure replacement stock follows the same approved hardware path.
• How to prevent: Build spare-pool discipline into the rollout plan and prohibit uncontrolled substitutions. Coordinate firmware updates with terminal manufacturers to ensure all deployed units maintain consistent, approved configurations and remain compliant with EMV requirements. EMVCo’s approval model and approved-products listing support this exact model discipline.

4) Teams treat L1/L2 approval as end-to-end launch approval

• Why it happens: “EMV approved” is used as shorthand for market readiness.
• How to verify: Ask what L3 testing or participant-system certification still remains. L3 certification is required as the final validation stage, ensuring the POS terminal works reliably with payment networks and meets their specific requirements for transaction processing and interoperability.
• How to prevent: Separate terminal type approval from deployment certification in every project plan. Make sure to account for payment network-specific certification steps, as payment networks must approve the terminal for use on their schemes before deployment.

5) Contactless ergonomics are ignored

• Why it happens: The terminal is technically approved, but the device is mounted or positioned badly for real tap usage.
• How to verify: Test actual customer tap distance, angle, screen clearance, and queue flow in the target counter or kiosk design.
• How to prevent: Include form factor, bracket, customer reach, and cable routing in approval readiness reviews. EMVCo’s emphasis on contactless data exchange distance makes this a real deployment factor, not a cosmetic one. Proper contactless payment ergonomics enable merchants to offer secure and convenient contactless payments, meeting customer expectations for speed and ease at checkout.

6) Kernel updates are treated like routine patches

• Why it happens: Operations teams apply software changes without understanding the kernel’s role in EMV transaction processing.
• How to verify: Review whether the update touches the kernel or payment application path tied to approval or certification.
• How to prevent: Put kernel updates under certification-aware change control, not generic endpoint patching. EMVCo’s definition of L2 as the processing logic inside the terminal is what makes this necessary. Regular firmware updates are also critical to maintain stability, security, and compatibility with scheme requirements. Additionally, robust error handling should be implemented and tested to ensure reliable transaction flows and maintain certification, especially during end-to-end transaction scenarios.

With these failure patterns in mind, let’s turn to the physical realities of hardware fit and why it can make or break EMV approval in the field.

Hardware Fit Still Decides Whether EMV Approval Works in Real Life

The payment terminal, especially chip terminals, plays a central role in the payment acceptance architecture—serving as the certified hardware interface between the cardholder, the POS system, and the payment processor. Ensuring that payment terminals and chip terminals meet EMV Level 1 and Level 2 certification is critical for secure, reliable transactions and compliance with payment network standards.

A terminal that is solid on Level 1 and Level 2 can still be the wrong choice if the physical deployment is poor. Form factor affects dip and tap posture. The peripheral stack affects counter clutter and cable strain. Ports and connectivity affect whether the reader, printer, customer display, and drawer can be staged cleanly. Serviceability affects whether a failed unit can be swapped in minutes or takes a site offline for half a day. None of those issues is outside EMV rollout planning, because they determine whether an approved terminal remains usable and consistent in the field. This is a deployment inference grounded in EMVCo’s hardware and kernel approval structure.

This is also where catalog alignment becomes practical instead of promotional. Fixed checkout counters often belong in a Desktop POS Systems strategy when the priority is stable card-present acceptance, clean staging, and easy replacement, which aligns with POSZEO’s high-quality POS systems for retail and business. Store-associate selling or line-busting often belongs in Mobile Handheld POS only when tap ergonomics, RF behavior, and kernel control are disciplined enough for field use, a pattern supported by Android portable handheld POS systems for field use. Unattended ordering or self-checkout often belongs in a Self-Service Kiosk strategy where reader placement, visibility, service doors, and swap paths are engineered from the start, as seen in POSZEO self-service kiosks for touchscreen ordering and payments. When the host terminal is already chosen but the bottleneck is mounting, customer reach, or cable control, the answer may sit in POS Accessories & Peripherals rather than a new terminal family offered by a leading POS solutions provider like POSZEO. Those are hardware-deployment judgments, not marketing categories.

With hardware fit addressed, let’s clear up two common myths that distort EMV buying decisions.

Two Myths That Distort EMV Buying Decisions

Myth 1: “Level 1 is hardware, so once it passes, the rest is easy.”

Not true. Level 1 only confirms the communications interface side. EMV chip specifications and EMV specifications define the requirements for both Level 1 (hardware and physical communication) and Level 2 (kernel or payment application) certification, ensuring secure and interoperable payment systems. EMVCo makes clear that Level 2 covers the kernel or payment application that performs EMV processing, and Level 3 covers end-to-end integration with acceptance infrastructure. A strong reader alone does not finish the job.

Myth 2: “Level 2 is just software, so it can be changed later without much impact.”

Also wrong. EMVCo defines Level 2 as the software logic that actually performs the EMV transaction, and its contact and contactless kernel approval processes make clear that the kernel is a formal approval object, not a casual patch layer. The software layer—specifically, the EMV Level 2 kernel—is responsible for processing chip and contactless transactions, interpreting card data, executing transaction rules, and ensuring secure, compliant operation across multiple card schemes. The EMV kernel is a critical software component that undergoes rigorous certification and testing to ensure card authentication, transaction processing, and compliance with EMV standards.

The better mental model is this: Level 1 gives you the reader foundation, Level 2 gives you the EMV transaction brain, and Level 3 proves the terminal can operate correctly in the target ecosystem.

With these myths dispelled, let’s clarify who needs to go deep on these distinctions.

Who Should Not Overcomplicate This Comparison

Not every merchant needs to go deep into EMV terminology. If the buyer is purchasing a tightly bundled, provider-controlled terminal program for a simple single-site environment, the main priority may simply be to confirm that the terminal already fits the required payment methods and deployment support model.

But integrators, distributors, OEM buyers, multi-location operators, and procurement teams managing hardware standardization absolutely should go deeper. They are the ones who bear the cost of failed tap behavior, kernel mismatches, delayed certifications, spare incompatibility, and site-level drift. Supporting multiple card brands and card networks (such as Visa, Mastercard, American Express, and RuPay) is critical for ensuring interoperability, certification compliance, and secure transaction processing across all locations. The more locations and the more support teams involved, the more valuable it becomes to separate Level 1, Level 2, and Level 3 clearly.

Next, here’s a practical checklist to use before you approve any purchase order.

What to Ask Vendors Before You Approve the PO

Vendor Approval Checklist

• What exact terminal configuration is being quoted?
• Which Level 1 approvals apply to the contact and contactless paths of that exact configuration?
• Which Level 2 kernel or payment application approvals apply?
• Is the contactless path approved as a full product, and if so, which PCD, Entry Point, and kernel path are in scope?
• What Letter of Approval evidence can the vendor provide?
• Is the product listed on the EMVCo-approved products site? Check the EMVCo website for approved products and current standards.
• What Level 3 testing or participant-system certification remains?
• Which processors, acquirers, or payment systems are already supported by the approved configuration?
• What happens if the kernel is updated after pilot approval?
• Can replacement units be field-swapped without changing the approved behavior?
• How are mounts, cables, power supplies, and peripherals standardized across sites?
• Which deployment scenarios are a poor fit for this terminal family?

Visa, Mastercard, and Europay Mastercard and Visa (the founders of EMV) are directly involved in the development and certification of secure payment technologies, setting the standards for global payment acceptance. Payment acceptance systems must meet the requirements of these major card schemes to ensure secure, interoperable transactions across all environments.

These questions align the purchase process with how EMVCo separates terminal type approval, approved product evidence, and L3 integration.

With your vendor questions ready, let’s summarize the key takeaways for buyers.

Buyer Checklist: What to Remember

• EMV Level 1 is the communication and interface layer.
• EMV Level 2 is the kernel and transaction-processing layer.
• EMV Level 3 is the end-to-end integration and certification layer defined by participant systems.

EMV standards and EMV technology are essential for enabling secure, interoperable payments across global markets. These standards ensure that POS terminals meet strict security and compliance requirements, supporting worldwide adoption of chip and contactless transactions.

And if you remember one more thing, make it this:

• The best terminal is not the one with the most impressive approval language. It is the one whose exact configuration, kernel path, replacement plan, and deployment model stay controlled when the rollout moves from one pilot lane to a real estate of stores, kiosks, or mobile checkout points.